draft-ietf-lamps-pkix-shake-01.txt   draft-ietf-lamps-pkix-shake-02.txt 
LAMPS WG P. Kampanakis LAMPS WG P. Kampanakis
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track Q. Dang Intended status: Standards Track Q. Dang
Expires: August 19, 2018 NIST Expires: December 31, 2018 NIST
February 15, 2018 June 29, 2018
Internet X.509 Public Key Infrastructure: Additional SHAKE Algorithms Internet X.509 Public Key Infrastructure: Additional Algorithm
and Identifiers for RSA and ECDSA Identifiers for RSASSA-PSS and ECDSA using SHAKEs as Hash Functions
draft-ietf-lamps-pkix-shake-01 draft-ietf-lamps-pkix-shake-02
Abstract Abstract
This document describes the conventions for using the SHAKE family of Digital signatures are used to sign messages, X.509 certificates and
hash functions in the Internet X.509 as one-way hash functions with CRLs (Certificate Revocation Lists). This document describes the
the RSA and ECDSA signature algorithms; the conventions for the conventions for using the SHAKE family of hash functions in the
associated subject public keys are also described. Digital Internet X.509 as one-way hash functions with the RSA Probabilistic
signatures are used to sign messages, certificates and CRLs Signature Scheme and ECDSA signature algorithms. The conventions for
(Certificate Revocation Lists). the associated subject public keys are also described.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2018. This Internet-Draft will expire on December 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. One-way Extensible-Output-Function SHAKEs . . . . . . . . 3 4. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Mask Generation SHAKEs . . . . . . . . . . . . . . . . . 4 4.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 4
4. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 4 4.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 5
4.1. RSASSA-PSS with SHAKEs . . . . . . . . . . . . . . . . . 4 4.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 5
4.2. ECDSA with SHAKEs . . . . . . . . . . . . . . . . . . . . 5 4.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 6
5. Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 6 4.2.1. RSASSA-PSS Public Keys . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. ECDSA Public Keys . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Change Log 1. Change Log
[ EDNOTE: Remove this section before publication. ] [ EDNOTE: Remove this section before publication. ]
o draft-ietf-lamps-pkix-shake-02:
* Significant reorganization of the sections to simplify the
introduction, the new OIDs and their use in PKIX.
* Added new OIDs for RSASSA-PSS that hardcode hash, salt and MFG,
according the WG consensus.
* Updated Public Key section to use the new RSASSA-PSS OIDs and
clarify the algorithm identifier usage.
* Removed the no longer used SHAKE OIDs from section 3.1.
* Consolidated subsection for message digest algorithms.
* Text fixes.
o draft-ietf-lamps-pkix-shake-01: o draft-ietf-lamps-pkix-shake-01:
* Changed titles and section names. * Changed titles and section names.
* Removed DSA after WG discussions. * Removed DSA after WG discussions.
* Updated shake OID names and parameters, added MGF1 section. * Updated shake OID names and parameters, added MGF1 section.
* Updated RSASSA-PSS section. * Updated RSASSA-PSS section.
* Added Public key algorithm OIDs. * Added Public key algorithm OIDs.
* Populated Introduction and IANA sections. * Populated Introduction and IANA sections.
o draft-ietf-lamps-pkix-shake-00: o draft-ietf-lamps-pkix-shake-00:
* Initial version * Initial version
2. Introduction 2. Introduction
This document describes several cryptographic algorithms which may be This document describes several cryptographic algorithm identifiers
used with the Internet X.509 Certificate and CRL profile [RFC5280]. for several cryptographic algorithms which use variable length output
It describes the OIDs for variable length SHAKE algorithms introduced SHAKE functions introduced in [SHA3] which can be used with the
in [SHA3] and how they can be used in X.509 certificates. [ EDNOTE: Internet X.509 Certificate and CRL profile [RFC5280].
Update here. ]
3. Message Digest Algorithms
This section describes two one-way hash functions and digital
signature algorithms using these functions, which may be used to sign
certificates and CRLs, and identifies OIDs (Object Identifiers) for
public keys contained in certificates.
3.1. One-way Extensible-Output-Function SHAKEs
The SHA-3 family of one-way hash functions is specified in [SHA3]. The SHA-3 family of one-way hash functions is specified in [SHA3].
In the SHA-3 family, two extendable-output functions, called SHAKE128 In the SHA-3 family, two extendable-output functions, called SHAKE128
and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256, and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256,
SHA3-384, and SHA3-512 are also defined but are out of scope for this SHA3-384, and SHA3-512 are also defined but are out of scope for this
document. SHAKE is a variable length hash function. The output document. A SHAKE is a variable length hash function. The output
lengths, in bits, of the SHAKE hash functions is defined by the lengths, in bits, of the SHAKE hash functions are defined by the d
parameter d. The corresponding collision and preimage resistance parameter. The corresponding collision and preimage resistance
security levels for SHAKE128 and SHAKE256 are respectively security levels for SHAKE128 and SHAKE256 are respectively
min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256). The min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256) bits.
Object Identifiers (OIDs) for these two hash functions are defined in
[shake-nist-oids] and are included here for convenience:
id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) SHAKEs can be used as the message digest function (to hash the
country(16) us(840) organization(1) gov(101) csor(3) message to be signed) and as the hash function in the mask generating
nistalgorithm(4) hashalgs(2) 17 } functions in RSASSA-PSS and ECDSA. In this document, we define four
new OIDs for RSASSA-PSS and ECDSA when SHAKE128 and SHAKE256 are used
as hash functions. The same algorithm identifiers are used for
identifying a public key, and identifying a signature.
ShakeOutputLen ::= INTEGER -- Output length in octets 3. Identifiers
When using the id-shake128-len algorithm identifier, the parameters The new identifiers for RSASSA-PSS signatures using SHAKEs are below.
MUST be present, and they MUST employ the ShakeOutputLen syntax that
contains an encoded positive integer value at least 32 in this
specification.
id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD }
country(16) us(840) organization(1) gov(101) csor(3) id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD }
nistalgorithm(4) hashalgs(2) 18 }
ShakeOutputLen ::= INTEGER -- Output length in octets [ EDNOTE: "TBD" will be specified by NIST later. ]
When using the id-shake256-len algorithm identifier, the parameters The new algorithm identifiers of ECDSA signatures using SHAKEs are
MUST be present, and they MUST employ the ShakeOutputLen syntax that below.
contains an encoded positive integer value at least 64 in this
specification.
3.2. Mask Generation SHAKEs id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-ecdsa-with-shake(3) TBD }
The RSASSA-PSS signature algorithm uses a mask generation function. id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
A mask generation function takes an octet string of variable length country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
and a desired output length as input, and outputs an octet string of id-ecdsa-with-shake(3) TBD }
the desired length. The mask generation function used in RSASSA-PSS
is defined in [RFC8017], but we include it here as well for
convenience:
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } [ EDNOTE: "TBD" will be specified by NIST later. ]
The parameters field associated with id-mgf1 MUST have a The parameters for these four identifiers above MUST be absent. That
hashAlgorithm value that identifies the hash used with MGF1. To use is, the identifier SHALL be a SEQUENCE of one component, the OID.
SHAKE as this hash, this parameter MUST be id-shake128-len or id-
shake256-len as specified in Section 3.1 above.
4. Signature Algorithms 4. Use in PKIX
4.1. RSASSA-PSS with SHAKEs 4.1. Signatures
The RSASSA-PSS signature algorithm identifier and its parameters are Signatures can be placed in a number of different ASN.1 structures.
specifed in [RFC4055]: The top level structure for an X.509 certificate, to illustrate how
signatures are frequently encoded with an algorithm identifier and a
location for the signature, is
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
RSASSA-PSS-params ::= SEQUENCE { The identifiers defined in Section 3 can be used as the
hashAlgorithm HashAlgorithm, AlgorithmIdentifier in the signatureAlgorithm field in the sequence
maskGenAlgorithm MaskGenAlgorithm, Certificate and the signature field in the sequence tbsCertificate in
saltLength INTEGER, X.509 [RFC3280].
trailerField INTEGER }
This document adds two new hash algorithm choices and two new choices Conforming CA implementations MUST specify the algorithms explicitly
for mask generation functions. These are the SHAKE128 and SHAKE256 by using the OIDs specified in Section 3 when encoding RSASSA-PSS and
algorithm identifiers specified in Section 3.1. ECDSA with SHAKE signatures, and public keys in certificates and
CRLs. Encoding rules for RSASSA-PSS and ECDSA signature values are
specified in [RFC4055] and [RFC5480] respectively.
When SHAKE128 or SHAKE256 is used as the hashAlgorithm, it MUST also Conforming client implementations that process RSASSA-PSS and ECDSA
be used as the maskGenAlgorithm. with SHAKE signatures when processing certificates and CRLs MUST
recognize the corresponding OIDs.
When used as the hashAlgorithm, the SHAKE128 or SHAKE256 output- 4.1.1. RSASSA-PSS Signatures
length must be either 32 or 64 bytes respectively. In these cases,
the parameters MUST be present, and they MUST employ the
ShakeOutputLen syntax that contains an encoded positive integer value
of 32 or 64 for id-shake128-len or id-shake256-len algorithm
identifier respectively.
When id-shake128-len or id-shake256-len algorithm identifier is used The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA-
as the id-mfg1 maskGenAlgorithm parameter, the ShakeOutputLen PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is
parameter must be (n - 264)/8 or (n - 520)/8 respectively for used, the encoding MUST omit the parameters field. That is, the
SHAKE128 and SHAKE256, where n is the RSA modulus in bits. For AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA-
example, when RSA modulus n is 2048, ShakeOutputLen must be 223 or PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256.
191 when id-shake128-len or id-shake256-len is are used respectively.
The parameter saltLength MUST be 32 or 64 bytes respectively for the The hash algorithm to hash a message being signed and the hash
SHAKE128 and SHA256 OIDs. algorithm in the maskGenAlgorithm used in RSASSA-PSS MUST be the
same, SHAKE128 or SHAKE256 respectively. The output-length of the
hash algorithm which hashes the message SHALL be 32 or 64 bytes
respectively.
4.2. ECDSA with SHAKEs The maskGenAlgorithm is the MGF1 specified in Section B.2.1 of
[RFC8017]. The output length for SHAKE128 or SHAKE256 being used as
the hash function in MGF1 is (n - 264)/8 or (n - 520)/8 bytes
respectively, where n is the RSA modulus in bits. For example, when
RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 in
the MGF1 will be 223 or 191 when id-RSASSA-PSS-SHAKE128 or id-RSASSA-
PSS-SHAKE256 is used respectively.
The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively.
Finally, the trailerField MUST be 1, which represents the trailer
field with hexadecimal value 0xBC [RFC8017].
4.1.2. ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
"Public Key Cryptography for the Financial Services Industry: The [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256
Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62]. The (specified in Section 3) algorithm identifier appears, the respective
ASN.1 OIDs of ECDSA signature algorithms using SHAKE128 and SHAKE256, SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The
are below: encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256.
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) For simplicity and compliance with the ECDSA standard specification,
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) the output size of the hash function must be explicitly determined.
id-ecdsa-with-shake(3) x } The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be
256 or 512 bits respectively.
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) Conforming CA implementations that generate ECDSA with SHAKE
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) signatures in certificates or CRLs MUST generate such signatures in
id-ecdsa-with-shake(3) y } accordance with all the requirements specified in Sections 7.2 and
7.3 of [X9.62] or with all the requirements specified in
Section 4.1.3 of [SEC1]. They MAY also generate such signatures in
accordance with all the recommendations in [X9.62] or [SEC1] if they
have a stated policy that requires conformance to these standards.
These standards may have not specified SHAKE128 and SHAKE256 as hash
algorithm options. However, SHAKE128 and SHAKE256 with output length
being 32 and 64 octets respectively are subtitutions for 256 and
512-bit output hash algorithms such as SHA256 and SHA512 used in the
standards.
[ EDNOTE: "x" and "y" will be specified by NIST later. ] 4.2. Public Keys
When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256, algorithm Certificates conforming to [RFC5280] can convey a public key for any
identifier appears in the algorithm field as an AlgorithmIdentifier, public key algorithm. The certificate indicates the algorithm
the encoding MUST omit the parameters field. That is, the through an algorithm identifier. This algorithm identifier is an OID
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID and optionally associated parameters.
ecdsa-with-SHAKE128 or ecdsa-with-SHAKE256.
Conforming CA implementations MUST specify the hash algorithm In the X.509 certificate, the subjectPublicKeyInfo field has the
explicitly using the OIDs specified in Section 3.2 above when SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
encoding ECDSA/SHAKE signatures in certificates and CRLs.
Conforming client implementations that process ECDSA signatures with SubjectPublicKeyInfo ::= SEQUENCE {
any of the SHAKE hash algorithms when processing certificates and algorithm AlgorithmIdentifier,
CRLs MUST recognize the corresponding OIDs specified in Sections 3.1 subjectPublicKey BIT STRING
and 3.2 above. }
Encoding rules for ECDSA signature values are specified in [RFC4055], The fields in SubjectPublicKeyInfo have the following meanings:
Section 2.2.3, and [RFC5480].
Conforming CA implementations that generate ECDSA signatures in o algorithm is the algorithm identifier and parameters for the
certificates or CRLs MUST generate such ECDSA signatures in public key.
accordance with all the requirements specified in Sections 7.2 and
7.3 of [X9.62] or with all the requirements specified in
Section 4.1.3 of [SEC1]. They MAY also generate such ECDSA
signatures in accordance with all the recommendations in [X9.62] or
[SEC1] if they have a stated policy that requires conformance to
these standards. These standards above may have not specified
SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128
and SHAKE256 with output length being 32 and 64 octets respectively
are subtitutions for 256 and 512-bit output hash algorithms such as
SHA256 and SHA512 used in the standards.
5. Public Key Algorithms o subjectPublicKey contains the byte stream of the public key. The
algorithms defined in this document always encode the public key
as an exact multiple of 8-bits.
The conventions for RSA and ECDSA public keys are as specified in The conventions for RSASSA-PSS and ECDSA public keys algorithm
[RFC3279], [RFC4055] and [RFC5480]. We include them here for identifiers are as specified in [RFC3279], [RFC4055] and [RFC5480] ,
convenience. but we include them below for convenience.
[RFC3279] defines the following OID for RSA with NULL parameters. 4.2.1. RSASSA-PSS Public Keys
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} [RFC3279] defines the following OID for RSA AlgorithmIdentifier in
the SubjectPublicKeyInfo with NULL parameters.
Additionally, [RFC4055] adds the corresponding RSASSA-PSS OID public rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
key identifier and parameters (also shown in Section 4 of this
document). The parameters may be either absent or present when
RSASSA-PSS OID is used as subject public key information.
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } Additionally, when the RSA private key owner wishes to limit the use
of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifiers
for RSASSA-PSS defined in Section 3 can be used as the algorithm
field in the SubjectPublicKeyInfo sequence [RFC3280]. The identifier
parameters, as explained in section Section 3, MUST be absent.
If id-RSASSA-PSS is used in the public key identifier with Regardless of what public key algorithm identifier is used, the RSA
parameters, Section 3.3 of [RFC4055] describes that the signature public key, which is composed of a modulus and a public exponent,
algorithm parameters MUST match the parameters in the key structure MUST be encoded using the RSAPublicKey type [RFC4055]. The output of
algorithm identifier except the saltLength field. The saltLength this encoding is carried in the certificate subjectPublicKey.
field in the signature parameters MUST be greater or equal to that in
the key parameters field. If the id-RSASSA-PSS parameters are NULL
no further parameter validation is necessary.
For ECDSA, [RFC5480] defines the EC public key identifier and its RSAPublicKey ::= SEQUENCE {
parameters as modulus INTEGER, -- n
id-ecPublicKey OBJECT IDENTIFIER ::= { publicExponent INTEGER -- e
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } }
ECParameters ::= CHOICE { 4.2.2. ECDSA Public Keys
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain }
The ECParameters associated with the ECDSA public key in the signer's For ECDSA, when id-ecdsa-with-shake128 or id-ecdsa-with-shake256 is
certificate SHALL apply to the verification of the signature. used as the AlgorithmIdentifier in the algorithm field of
SubjectPublicKeyInfo, the parameters, as explained in section
Section 3, MUST be absent.
6. Acknowledgements Additionally, the mandatory EC SubjectPublicKey is defined in
Section 2.1.1 and its syntax is in Section 2.2 of [RFC5480]. We also
include them here for convenience:
We would like to thank Sean Turner for his valuable contributions to id-ecPublicKey OBJECT IDENTIFIER ::= {
this document. iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
7. IANA Considerations The id-ecPublicKey parameters MUST be present and are defined as
This document uses several registries that were originally created in ECParameters ::= CHOICE {
[shake-nist-oids]. No further registries are required. [ EDNOTE: namedCurve OBJECT IDENTIFIER
Update here. ] -- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
8. Security Considerations The ECParameters associated with the ECDSA public key in the signer's
certificate SHALL apply to the verification of the signature.
SHAKE128 and SHAKE256 are one-way extensible-output functions. Their 5. IANA Considerations
output length depends on a required length of the consumming
application. This document uses several new registries [ EDNOTE: Update here. ]
6. Security Considerations
The SHAKEs are deterministic functions. Like any other deterministic The SHAKEs are deterministic functions. Like any other deterministic
functions, executing each function with the same input multiple times functions, executing each function with the same input multiple times
will produce the same output. Therefore, users should not expect will produce the same output. Therefore, users should not expect
unrelated outputs (with the same or different output lengths) from unrelated outputs (with the same or different output lengths) from
excuting a SHAKE function with the same input multiple times. excuting a SHAKE function with the same input multiple times.
Implementations must protect the signer's private key. Compromise of Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade. the signer's private key permits masquerade.
When more than two parties share the same message-authentication key, Implementations must randomly generate one-time values, such as the k
data origin authentication is not provided. Any party that knows the value when generating a ECDSA signature. In addition, the generation
message-authentication key can compute a valid MAC, therefore the of public/private key pairs relies on random numbers. The use of
content could originate from any one of the parties. inadequate pseudo-random number generators (PRNGs) to generate such
cryptographic values can result in little or no security. The
Implementations must randomly generate message-authentication keys generation of quality random numbers is difficult. [RFC4086] offers
and one-time values, such as the k value when generating a ECDSA important guidance in this area, and [SP800-90A] series provide
signature. In addition, the generation of public/private key pairs acceptable PRNGs.
relies on random numbers. The use of inadequate pseudo-random number
generators (PRNGs) to generate such cryptographic values can result
in little or no security. The generation of quality random numbers
is difficult. [RFC4086] offers important guidance in this area, and
[SP800-90A] series provide acceptable PRNGs.
Implementers should be aware that cryptographic algorithms may become Implementers should be aware that cryptographic algorithms may become
weaker with time. As new cryptanalysis techniques are developed and weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing power increases, the work factor or time required to break
cryptographic algorithm will reduce. Therefore, cryptographic a particular cryptographic algorithm may decrease. Therefore,
algorithm implementations should be modular allowing new algorithms cryptographic algorithm implementations should be modular allowing
to be readily inserted. That is, implementers should be prepared to new algorithms to be readily inserted. That is, implementers should
regularly update the set of algorithms in their implementations. be prepared to regularly update the set of algorithms in their
implementations.
9. References 7. Acknowledgements
9.1. Normative References We would like to thank Sean Turner for his valuable contributions to
this document.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 8. References
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List 8.1. Normative References
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/info/rfc3279>. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
<https://www.rfc-editor.org/info/rfc3280>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/info/rfc4055>. <https://www.rfc-editor.org/info/rfc4055>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
skipping to change at page 9, line 11 skipping to change at page 9, line 27
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[SHA3] National Institute of Standards and Technology, "SHA-3 [SHA3] National Institute of Standards and Technology, "SHA-3
Standard - Permutation-Based Hash and Extendable-Output Standard - Permutation-Based Hash and Extendable-Output
Functions FIPS PUB 202", August 2015, Functions FIPS PUB 202", August 2015,
<https://www.nist.gov/publications/sha-3-standard- <https://www.nist.gov/publications/sha-3-standard-
permutation-based-hash-and-extendable-output-functions>. permutation-based-hash-and-extendable-output-functions>.
9.2. Informative References 8.2. Informative References
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", May 2009, Elliptic Curve Cryptography", May 2009,
<http://www.secg.org/sec1-v2.pdf>. <http://www.secg.org/sec1-v2.pdf>.
[shake-nist-oids]
National Institute of Standards and Technology, "Computer
Security Objects Register", October 2017,
<https://csrc.nist.gov/Projects/Computer-Security-Objects-
Register/Algorithm-Registration>.
[SP800-90A] [SP800-90A]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Random Number Generation Using "Recommendation for Random Number Generation Using
Deterministic Random Bit Generators. NIST SP 800-90A", Deterministic Random Bit Generators. NIST SP 800-90A",
June 2015, June 2015,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf>. NIST.SP.800-90Ar1.pdf>.
[X9.62] American National Standard for Financial Services (ANSI), [X9.62] American National Standard for Financial Services (ANSI),
"X9.62-2005 Public Key Cryptography for the Financial "X9.62-2005 Public Key Cryptography for the Financial
 End of changes. 62 change blocks. 
213 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/