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/ |