| < draft-ietf-lamps-pkix-shake-08.txt | draft-ietf-lamps-pkix-shake-15.txt > | |||
|---|---|---|---|---|
| LAMPS WG P. Kampanakis | LAMPS WG P. Kampanakis | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Standards Track Q. Dang | Updates: 3279 (if approved) Q. Dang | |||
| Expires: August 4, 2019 NIST | Intended status: Standards Track NIST | |||
| January 31, 2019 | Expires: January 22, 2020 July 21, 2019 | |||
| Internet X.509 Public Key Infrastructure: Additional Algorithm | Internet X.509 Public Key Infrastructure: Additional Algorithm | |||
| Identifiers for RSASSA-PSS and ECDSA using SHAKEs | Identifiers for RSASSA-PSS and ECDSA using SHAKEs | |||
| draft-ietf-lamps-pkix-shake-08 | draft-ietf-lamps-pkix-shake-15 | |||
| Abstract | Abstract | |||
| Digital signatures are used to sign messages, X.509 certificates and | Digital signatures are used to sign messages, X.509 certificates and | |||
| CRLs (Certificate Revocation Lists). This document describes the | CRLs. This document updates the "Algorithms and Identifiers for the | |||
| conventions for using the SHAKE function family in Internet X.509 | Internet X.509 Public Key Infrastructure Certificate and Certificate | |||
| certificates and CRLs as one-way hash functions with the RSA | Revocation List Profile" (RFC3279) and describes the conventions for | |||
| Probabilistic signature and ECDSA signature algorithms. The | using the SHAKE function family in Internet X.509 certificates and | |||
| conventions for the associated subject public keys are also | revocation lists as one-way hash functions with the RSA Probabilistic | |||
| described. | signature and ECDSA signature algorithms. The conventions for 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 4, 2019. | This Internet-Draft will expire on January 22, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5 | 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 6 | 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 | |||
| 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 7 | 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8 | |||
| 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 | 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | 9.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
| Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 11 | Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 13 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 1. Change Log | 1. Change Log | |||
| [ EDNOTE: Remove this section before publication. ] | [ EDNOTE: Remove this section before publication. ] | |||
| o draft-ietf-lamps-pkix-shake-15: | ||||
| * Minor editorial nits. | ||||
| o draft-ietf-lamps-pkix-shake-14: | ||||
| * Fixing error with incorrect preimage resistance bits for SHA128 | ||||
| and SHA256. | ||||
| o draft-ietf-lamps-pkix-shake-13: | ||||
| * Addressing one applicable comment from Dan M. about sec levels | ||||
| while in secdir review of draft-ietf-lamps-cms-shakes. | ||||
| * Addressing comment from Scott B.'s opsdir review about | ||||
| references in the abstract. | ||||
| o draft-ietf-lamps-pkix-shake-12: | ||||
| * Nits identified by Roman, Eric V. Ben K., Barry L. in ballot | ||||
| position review. | ||||
| o draft-ietf-lamps-pkix-shake-11: | ||||
| * Nits identified by Roman in AD Review. | ||||
| o draft-ietf-lamps-pkix-shake-10: | ||||
| * Updated IANA considerations section to request for OID | ||||
| assignments. | ||||
| o draft-ietf-lamps-pkix-shake-09: | ||||
| * Fixed minor text nits. | ||||
| * Added text name allocation for SHAKEs in IANA considerations. | ||||
| * Updates in Sec Considerations section. | ||||
| o draft-ietf-lamps-pkix-shake-08: | o draft-ietf-lamps-pkix-shake-08: | |||
| * Small nits from Russ while in WGLC. | * Small nits from Russ while in WGLC. | |||
| o draft-ietf-lamps-pkix-shake-07: | o draft-ietf-lamps-pkix-shake-07: | |||
| * Incorporated Eric's suggestion from WGLC. | * Incorporated Eric's suggestion from WGLC. | |||
| o draft-ietf-lamps-pkix-shake-06: | o draft-ietf-lamps-pkix-shake-06: | |||
| skipping to change at page 3, line 8 ¶ | skipping to change at page 3, line 48 ¶ | |||
| * Updated IANA considerations. | * Updated IANA considerations. | |||
| o draft-ietf-lamps-pkix-shake-05: | o draft-ietf-lamps-pkix-shake-05: | |||
| * Added RFC8174 reference and text. | * Added RFC8174 reference and text. | |||
| * Explicitly explained why RSASSA-PSS-params are omitted in | * Explicitly explained why RSASSA-PSS-params are omitted in | |||
| section 5.1.1. | section 5.1.1. | |||
| * Simplified Public Keys section by removing redundand info from | * Simplified Public Keys section by removing redundant info from | |||
| RFCs. | RFCs. | |||
| o draft-ietf-lamps-pkix-shake-04: | o draft-ietf-lamps-pkix-shake-04: | |||
| * Removed paragraph suggesting KMAC to be used in generating k in | * Removed paragraph suggesting KMAC to be used in generating k in | |||
| Deterministric ECDSA. That should be RFC6979-bis. | Deterministic ECDSA. That should be RFC6979-bis. | |||
| * Removed paragraph from Security Considerations that talks about | * Removed paragraph from Security Considerations that talks about | |||
| randomness of k because we are using deterministric ECDSA. | randomness of k because we are using deterministic ECDSA. | |||
| * Various ASN.1 fixes. | * Various ASN.1 fixes. | |||
| * Text fixes. | * Text fixes. | |||
| o draft-ietf-lamps-pkix-shake-03: | o draft-ietf-lamps-pkix-shake-03: | |||
| * Updates based on suggestions and clarifications by Jim. | * Updates based on suggestions and clarifications by Jim. | |||
| * Added ASN.1. | * Added ASN.1. | |||
| skipping to change at page 4, line 17 ¶ | skipping to change at page 5, line 9 ¶ | |||
| * 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 cryptographic algorithm identifiers for | [RFC3279] defines cryptographic algorithm identifiers for the | |||
| several cryptographic algorithms which use variable length output | Internet X.509 Certificate and Certificate Revocation Lists (CRL) | |||
| SHAKE functions introduced in [SHA3] which can be used with the | profile [RFC5280]. This document updates RFC3279 and defines | |||
| Internet X.509 Certificate and CRL profile [RFC5280]. | identifiers for several cryptographic algorithms that use variable | |||
| length output SHAKE functions introduced in [SHA3] which can be used | ||||
| with . | ||||
| In the SHA-3 family, two extendable-output functions (SHAKEs), | In the SHA-3 family, two extendable-output functions (SHAKEs), | |||
| SHAKE128 and SHAKE256, are defined. Four other hash function | SHAKE128 and SHAKE256, are defined. Four other hash function | |||
| instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also | instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also | |||
| defined but are out of scope for this document. A SHAKE is a | defined but are out of scope for this document. A SHAKE is a | |||
| variable length hash function defined as SHAKE(M, d) where the output | variable length hash function defined as SHAKE(M, d) where the output | |||
| is a d-bits long digest of message M. The corresponding collision | is a d-bits-long digest of message M. The corresponding collision | |||
| and second preimage resistance strengths for SHAKE128 are | and second-preimage-resistance strengths for SHAKE128 are | |||
| min(d/2,128) and min(d,128) bits respectively. And, the | min(d/2,128) and min(d,128) bits, respectively (Appendix A.1 [SHA3]). | |||
| corresponding collision and second preimage resistance strengths for | And the corresponding collision and second-preimage-resistance | |||
| SHAKE256 are min(d/2,256) and min(d,256) bits respectively. | strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, | |||
| respectively. | ||||
| A SHAKE can be used as the message digest function (to hash the | A SHAKE can be used as the message digest function (to hash the | |||
| message to be signed) in RSASSA-PSS and ECDSA and as the hash in the | message to be signed) in RSASSA-PSS [RFC8017] and ECDSA [X9.62] and | |||
| mask generating function in RSASSA-PSS. This specification describes | as the hash in the mask generation function (MGF) in RSASSA-PSS. | |||
| the identifiers for SHAKEs to be used in X.509 and their meaning. | ||||
| 3. Terminology | 3. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 4. Identifiers | 4. Identifiers | |||
| This section defines four new object identifiers (OIDs), for RSASSA- | This section defines four new object identifiers (OIDs), for RSASSA- | |||
| PSS and ECDSA with each of SHAKE-128 and SHAKE-256. The same | PSS and ECDSA with each of SHAKE128 and SHAKE256. The same algorithm | |||
| algorithm identifiers can be used for identifying a public key in | identifiers can be used for identifying a public key in RSASSA-PSS. | |||
| RSASSA-PSS. | ||||
| The new identifiers for RSASSA-PSS signatures using SHAKEs are below. | The new identifiers for RSASSA-PSS signatures using SHAKEs are below. | |||
| id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } | id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) | |||
| identified-organization(3) dod(6) internet(1) | ||||
| id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } | security(5) mechanisms(5) pkix(7) algorithms(6) | |||
| TBD1 } | ||||
| [ EDNOTE: "TBD" will be specified by NIST later. ] | id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) | |||
| identified-organization(3) dod(6) internet(1) | ||||
| security(5) mechanisms(5) pkix(7) algorithms(6) | ||||
| TBD2 } | ||||
| The new algorithm identifiers of ECDSA signatures using SHAKEs are | The new algorithm identifiers of ECDSA signatures using SHAKEs are | |||
| below. | below. | |||
| id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) | id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) | |||
| country(16) us(840) organization(1) gov(101) | identified-organization(3) dod(6) internet(1) | |||
| csor(3) algorithms(4) id-ecdsa-with-shake(3) | security(5) mechanisms(5) pkix(7) algorithms(6) | |||
| TBD } | TBD3 } | |||
| id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) | ||||
| country(16) us(840) organization(1) gov(101) | ||||
| csor(3) algorithms(4) id-ecdsa-with-shake(3) | ||||
| TBD } | ||||
| [ EDNOTE: "TBD" will be specified by NIST later. ] | id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) | |||
| identified-organization(3) dod(6) internet(1) | ||||
| security(5) mechanisms(5) pkix(7) algorithms(6) | ||||
| TBD4 } | ||||
| The parameters for the four identifiers above MUST be absent. That | The parameters for the four identifiers above MUST be absent. That | |||
| is, the identifier SHALL be a SEQUENCE of one component, the OID. | is, the identifier SHALL be a SEQUENCE of one component, the OID. | |||
| Section 5.1.1 and Section 5.1.2 specify the required output length | Section 5.1.1 and Section 5.1.2 specify the required output length | |||
| for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In | for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In | |||
| summary, when hashing messages to be signed, output lengths of | summary, when hashing messages to be signed, output lengths of | |||
| SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the | SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the | |||
| SHAKEs are used as mask generation functions RSASSA-PSS, their output | SHAKEs are used as mask generation functions RSASSA-PSS, their output | |||
| length is (n - 264) or (n - 520) bits respectively, where n is the | length is (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, | |||
| RSA modulus size in bits. | respectively, where n is the RSA modulus size in bits. | |||
| 5. Use in PKIX | 5. Use in PKIX | |||
| 5.1. Signatures | 5.1. Signatures | |||
| Signatures are used in a number of different ASN.1 structures. In an | Signatures are used in a number of different ASN.1 structures. As | |||
| X.509 certificate a signature is encoded with an algorithm identifier | shown in the ASN.1 representation from [RFC5280] below, in an X.509 | |||
| in the signatureAlgorithm attribute and a signatureValue that | certificate, a signature is encoded with an algorithm identifier in | |||
| the signatureAlgorithm attribute and a signatureValue attribute that | ||||
| contains the actual signature. | contains the actual signature. | |||
| Certificate ::= SEQUENCE { | Certificate ::= SEQUENCE { | |||
| tbsCertificate TBSCertificate, | tbsCertificate TBSCertificate, | |||
| signatureAlgorithm AlgorithmIdentifier, | signatureAlgorithm AlgorithmIdentifier, | |||
| signatureValue BIT STRING } | signatureValue BIT STRING } | |||
| The identifiers defined in Section 4 can be used as the | The identifiers defined in Section 4 can be used as the | |||
| AlgorithmIdentifier in the signatureAlgorithm field in the sequence | AlgorithmIdentifier in the signatureAlgorithm field in the sequence | |||
| Certificate and the signature field in the sequence tbsCertificate in | Certificate and the signature field in the sequence TBSCertificate in | |||
| X.509 [RFC5280]. The parameters of these signature algorithms are | X.509 [RFC5280]. The parameters of these signature algorithms are | |||
| absent as explained in Section 4. | absent as explained in Section 4. | |||
| Conforming CA implementations MUST specify the algorithms explicitly | Conforming CA implementations MUST specify the algorithms explicitly | |||
| by using the OIDs specified in Section 4 when encoding RSASSA-PSS or | by using the OIDs specified in Section 4 when encoding RSASSA-PSS or | |||
| ECDSA with SHAKE signatures in certificates and CRLs. Conforming | ECDSA with SHAKE signatures in certificates and CRLs. Conforming | |||
| client implementations that process RSASSA-PSS or ECDSA with SHAKE | client implementations that process certificates and CRLs using | |||
| signatures when processing certificates and CRLs MUST recognize the | RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs. | |||
| corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA | Encoding rules for RSASSA-PSS and ECDSA signature values are | |||
| signature values are specified in [RFC4055] and [RFC5480] | specified in [RFC4055] and [RFC5480], respectively. | |||
| respectively. | ||||
| When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA | ||||
| curve order SHOULD be chosen in line with the SHAKE output length. | ||||
| Refer to Section 7 for more details. | ||||
| 5.1.1. RSASSA-PSS Signatures | 5.1.1. RSASSA-PSS Signatures | |||
| The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- | The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- | |||
| PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is | PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is | |||
| used, the encoding MUST omit the parameters field. That is, the | used, the encoding MUST omit the parameters field. That is, the | |||
| AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- | AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- | |||
| PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- | PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- | |||
| PSS-params that are used to define the algorithms and inputs to the | PSS-params that are used to define the algorithms and inputs to the | |||
| algorithm. This specification does not use parameters because the | algorithm. This specification does not use parameters because the | |||
| hash and mask generating algorithsm and trailer and salt are embedded | hash, mask generation algorithm, trailer and salt are embedded in the | |||
| in the OID definition. | OID definition. | |||
| The hash algorithm to hash a message being signed and the hash | The hash algorithm to hash a message being signed and the hash | |||
| algorithm as the mask generation function used in RSASSA-PSS MUST be | algorithm used as the mask generation function in RSASSA-PSS MUST be | |||
| the same, SHAKE128 or SHAKE256 respectively. The output-length of | the same: both SHAKE128 or both SHAKE256. The output length of the | |||
| the hash algorithm which hashes the message SHALL be 32 or 64 bytes | hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or | |||
| respectively. | 64 bytes (for SHAKE256). | |||
| The mask generation function takes an octet string of variable length | The mask generation function takes an octet string of variable length | |||
| and a desired output length as input, and outputs an octet string of | and a desired output length as input, and outputs an octet string of | |||
| the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be | the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be | |||
| used natively as the MGF function, instead of the MGF1 algorithm that | used natively as the MGF function, instead of the MGF1 algorithm that | |||
| uses the hash function in multiple iterations as specified in | uses the hash function in multiple iterations as specified in | |||
| Section B.2.1 of [RFC8017]. In other words, the MGF is defined as | Section B.2.1 of [RFC8017]. In other words, the MGF is defined as | |||
| the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- | the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- | |||
| SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the | SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is | |||
| seed from which mask is generated, an octet string [RFC8017]. As | the seed from which mask is generated, an octet string [RFC8017]. As | |||
| explained in Step 9 of section 9.1.1 of [RFC8017], the output length | explained in Step 9 of section 9.1.1 of [RFC8017], the output length | |||
| of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message | of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message | |||
| length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 | length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 | |||
| and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 | and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, | |||
| respectively. Thus when SHAKE is used as the MGF, the SHAKE output | respectively. Thus when SHAKE is used as the MGF, the SHAKE output | |||
| length maskLen is (n - 264) or (n - 520) bits respectively. For | length maskLen is (8*emLen - 264) or (8*emLen - 520) bits, | |||
| example, when RSA modulus n is 2048, the output length of SHAKE128 or | respectively. For example, when RSA modulus n is 2048, the output | |||
| SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- | length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits | |||
| SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. | when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, | |||
| respectively. | ||||
| The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. | The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 | |||
| Finally, the trailerField MUST be 1, which represents the trailer | or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField | |||
| field with hexadecimal value 0xBC [RFC8017]. | MUST be 1, which represents the trailer field with hexadecimal value | |||
| 0xBC [RFC8017]. | ||||
| 5.1.2. ECDSA Signatures | 5.1.2. ECDSA Signatures | |||
| The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in | The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in | |||
| [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 | [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 | |||
| (specified in Section 4) algorithm identifier appears, the respective | (specified in Section 4) algorithm identifier appears, the respective | |||
| SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The | SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The | |||
| encoding MUST omit the parameters field. That is, the | encoding MUST omit the parameters field. That is, the | |||
| AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- | AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- | |||
| ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256. | ecdsa-with-shake128 or id-ecdsa-with-shake256. | |||
| For simplicity and compliance with the ECDSA standard specification, | For simplicity and compliance with the ECDSA standard specification, | |||
| the output length of the hash function must be explicitly determined. | the output length of the hash function must be explicitly determined. | |||
| The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be | The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be | |||
| 256 or 512 bits respectively. | 256 or 512 bits, respectively. | |||
| It is RECOMMENDED that conforming CA implementations that generate | Conforming CA implementations that generate ECDSA with SHAKE | |||
| ECDSA with SHAKE signatures in certificates or CRLs generate such | signatures in certificates or CRLs SHOULD generate such signatures | |||
| signatures with a deterministically generated, non-random k in | with a deterministically generated, non-random k in accordance with | |||
| accordance with all the requirements specified in [RFC6979]. They | all the requirements specified in [RFC6979]. They MAY also generate | |||
| MAY also generate such signatures in accordance with all other | such signatures in accordance with all other recommendations in | |||
| recommendations in [X9.62] or [SEC1] if they have a stated policy | [X9.62] or [SEC1] if they have a stated policy that requires | |||
| that requires conformance to these standards. These standards may | conformance to those standards. Those standards have not specified | |||
| have not specified SHAKE128 and SHAKE256 as hash algorithm options. | SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 | |||
| However, SHAKE128 and SHAKE256 with output length being 32 and 64 | and SHAKE256 with output length being 32 and 64 octets, respectively, | |||
| octets respectively are subtitutions for 256 and 512-bit output hash | can be used instead of 256 and 512-bit output hash algorithms such as | |||
| algorithms such as SHA256 and SHA512 used in the standards. | SHA256 and SHA512. | |||
| 5.2. Public Keys | 5.2. Public Keys | |||
| Certificates conforming to [RFC5280] can convey a public key for any | Certificates conforming to [RFC5280] can convey a public key for any | |||
| public key algorithm. The certificate indicates the public key | public key algorithm. The certificate indicates the public key | |||
| algorithm through an algorithm identifier. This algorithm identifier | algorithm through an algorithm identifier. This algorithm identifier | |||
| is an OID and optionally associated parameters. The conventions and | is an OID and optionally associated parameters. The conventions and | |||
| encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers | encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers | |||
| are as specified in Section 2.3 of [RFC3279], Section 3.1 of | are as specified in Section 2.3.1 and 2.3.5 of [RFC3279], Section 3.1 | |||
| [RFC4055] and Section 2.1 of [RFC5480]. | of [RFC4055] and Section 2.1 of [RFC5480]. | |||
| Traditionally, the rsaEncryption object identifier is used to | Traditionally, the rsaEncryption object identifier is used to | |||
| identify RSA public keys. The rsaEncryption object identifier | identify RSA public keys. The rsaEncryption object identifier | |||
| continues to identify the subject public key when the RSA private key | continues to identify the subject public key when the RSA private key | |||
| owner does not wish to limit the use of the public key exclusively to | owner does not wish to limit the use of the public key exclusively to | |||
| RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to | RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to | |||
| limit the use of the public key exclusively to RSASSA-PSS with | limit the use of the public key exclusively to RSASSA-PSS with | |||
| SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 | SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 | |||
| SHOULD be used as the algorithm field in the SubjectPublicKeyInfo | SHOULD be used as the algorithm field in the SubjectPublicKeyInfo | |||
| sequence [RFC5280]. Conforming client implementations that process | sequence [RFC5280]. Conforming client implementations that process | |||
| RSASSA-PSS with SHAKE public keys when processing certificates and | RSASSA-PSS with SHAKE public keys when processing certificates and | |||
| CRLs MUST recognize the corresponding OIDs. | CRLs MUST recognize the corresponding OIDs. | |||
| Conforming CA implementations MUST specify the X.509 public key | Conforming CA implementations MUST specify the X.509 public key | |||
| algorithm explicitly by using the OIDs specified in Section 4 when | algorithm explicitly by using the OIDs specified in Section 4 when | |||
| encoding ECDSA with SHAKE public keys in certificates and CRLs. | encoding ECDSA with SHAKE public keys in certificates and CRLs. | |||
| Conforming client implementations that process ECDSA with SHAKE | Conforming client implementations that process ECDSA with SHAKE | |||
| public keys when processing certificates and CRLs MUST recognize the | public keys when processing certificates and CRLs MUST recognize the | |||
| corresponding OIDs. | corresponding OIDs. | |||
| The identifier parameters, as explained in section Section 4, MUST be | The identifier parameters, as explained in Section 4, MUST be absent. | |||
| absent. | ||||
| 6. IANA Considerations | 6. IANA Considerations | |||
| One object identifier for the ASN.1 module in Appendix A was assigned | One object identifier for the ASN.1 module in Appendix A is requested | |||
| in the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) | for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) | |||
| registry: | registry: | |||
| PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) | +---------+--------------------------+--------------------+ | |||
| internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) | | Decimal | Description | References | | |||
| id-mod-pkix1-shakes-2019(TBD) } | +---------+--------------------------+--------------------+ | |||
| | TBD | id-mod-pkix1-shakes-2019 | [EDNOTE: THIS RFC] | | ||||
| +---------+--------------------------+--------------------+ | ||||
| IANA is requested to update the SMI Security for PKIX Algorithms | ||||
| [SMI-PKIX] (1.3.6.1.5.5.7.6) registry with four additional entries: | ||||
| +---------+------------------------+--------------------+ | ||||
| | Decimal | Description | References | | ||||
| +---------+------------------------+--------------------+ | ||||
| | TBD1 | id-RSASSA-PSS-SHAKE128 | [EDNOTE: THIS RFC] | | ||||
| | TBD2 | id-RSASSA-PSS-SHAKE256 | [EDNOTE: THIS RFC] | | ||||
| | TBD3 | id-ecdsa-with-shake128 | [EDNOTE: THIS RFC] | | ||||
| | TBD4 | id-ecdsa-with-shake256 | [EDNOTE: THIS RFC] | | ||||
| +---------+------------------------+--------------------+ | ||||
| IANA is also requested to update the Hash Function Textual Names | ||||
| Registry [Hash-Texts] with two additional entries for SHAKE128 and | ||||
| SHAKE256: | ||||
| +--------------------+-------------------------+--------------------+ | ||||
| | Hash Function Name | OID | Reference | | ||||
| +--------------------+-------------------------+--------------------+ | ||||
| | shake128 | 2.16.840.1.101.3.4.2.11 | [EDNOTE: THIS RFC] | | ||||
| | shake256 | 2.16.840.1.101.3.4.2.12 | [EDNOTE: THIS RFC] | | ||||
| +--------------------+-------------------------+--------------------+ | ||||
| 7. Security Considerations | 7. Security Considerations | |||
| The SHAKEs are deterministic functions. Like any other deterministic | This document updates [RFC3279]. The security considerations section | |||
| function, executing multiple times with the same input will produce | of that document applies to this specification as well. | |||
| the same output. Therefore, users should not expect unrelated | ||||
| outputs (with the same or different output lengths) from running a | ||||
| SHAKE function with the same input multiple times. The shorter of | ||||
| any two outputs produced from a SHAKE with the same input is a prefix | ||||
| of the longer one. It is a similar situation as truncating a 512-bit | ||||
| output of SHA-512 by taking its 256 left-most bits. These 256 left- | ||||
| most bits are a prefix of the 512-bit output. | ||||
| When using ECDSA with SHAKEs, the ECDSA curve order SHOULD be chosen | NIST has defined appropriate use of the hash functions in terms of | |||
| in line with the SHAKE output length. NIST has defined appropriate | the algorithm strengths and expected time frames for secure use in | |||
| use of the hash functions in terms of the algorithm strengths and | Special Publications (SPs) [SP800-78-4] and [SP800-107]. These | |||
| expected time frames for secure use in Special Publications (SPs) | documents can be used as guides to choose appropriate key sizes for | |||
| [SP800-78-4] and [SP800-107]. These documents can be used as guides | various security scenarios. | |||
| to choose appropriate key sizes for various security scenarios. In | ||||
| the context of this document id-ecdsa-with-shake128 is RECOMMENDED | SHAKE128 with output length of 256-bits offers 128-bits of collision | |||
| for curves with group order of 256-bits. id-ecdsa-with-shake256 is | and preimage resistance. Thus, SHAKE128 OIDs in this specification | |||
| RECOMMENDED for curves with group order of 384-bits or more. | are RECOMMENDED with 2048 (112-bit security) or 3072-bit (128-bit | |||
| security) RSA modulus or curves with group order of 256-bits (128-bit | ||||
| security). SHAKE256 with 512-bits output length offers 256-bits of | ||||
| collision and preimage resistance. Thus, the SHAKE256 OIDs in this | ||||
| specification are RECOMMENDED with 4096-bit RSA modulus or higher or | ||||
| curves with group order of at least 521-bits (256-bit security). | ||||
| Note that we recommended 4096-bit RSA because we would need 15360-bit | ||||
| modulus for 256-bits of security which is impractical for today's | ||||
| technology. | ||||
| 8. Acknowledgements | 8. Acknowledgements | |||
| We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for | We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for | |||
| their valuable contributions to this document. | their valuable contributions to this document. | |||
| The authors would like to thank Russ Housley for his guidance and | The authors would like to thank Russ Housley for his guidance and | |||
| very valuable contributions with the ASN.1 module. | very valuable contributions with the ASN.1 module. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [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>. | ||||
| [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 | |||
| Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
| skipping to change at page 10, line 22 ¶ | skipping to change at page 12, line 13 ¶ | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [SHA3] National Institute of Standards and Technology (NIST), | [SHA3] National Institute of Standards and Technology (NIST), | |||
| "SHA-3 Standard - Permutation-Based Hash and Extendable- | "SHA-3 Standard - Permutation-Based Hash and Extendable- | |||
| Output Functions FIPS PUB 202", August 2015, | Output 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 | 9.2. Informative References | |||
| [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and | [Hash-Texts] | |||
| Identifiers for the Internet X.509 Public Key | IANA, "Hash Function Textual Names", July 2017, | |||
| Infrastructure Certificate and Certificate Revocation List | <https://www.iana.org/assignments/hash-function-text- | |||
| (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April | names/hash-function-text-names.xhtml>. | |||
| 2002, <https://www.rfc-editor.org/info/rfc3279>. | ||||
| [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the | [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the | |||
| Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, | Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, | |||
| DOI 10.17487/RFC5912, June 2010, | DOI 10.17487/RFC5912, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5912>. | <https://www.rfc-editor.org/info/rfc5912>. | |||
| [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | |||
| Algorithm (DSA) and Elliptic Curve Digital Signature | Algorithm (DSA) and Elliptic Curve Digital Signature | |||
| Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | |||
| 2013, <https://www.rfc-editor.org/info/rfc6979>. | 2013, <https://www.rfc-editor.org/info/rfc6979>. | |||
| [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>. | |||
| [SMI-PKIX] | ||||
| IANA, "SMI Security for PKIX Algorithms", March 2019, | ||||
| <https://www.iana.org/assignments/smi-numbers/ | ||||
| smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6>. | ||||
| [SP800-107] | [SP800-107] | |||
| National Institute of Standards and Technology (NIST), | National Institute of Standards and Technology (NIST), | |||
| "SP800-107: Recommendation for Applications Using Approved | "SP800-107: Recommendation for Applications Using Approved | |||
| Hash Algorithms", May 2014, | Hash Algorithms", May 2014, | |||
| <https://csrc.nist.gov/csrc/media/publications/sp/800-107/ | <https://csrc.nist.gov/csrc/media/publications/sp/800-107/ | |||
| rev-1/final/documents/draft_revised_sp800-107.pdf>. | rev-1/final/documents/draft_revised_sp800-107.pdf>. | |||
| [SP800-78-4] | [SP800-78-4] | |||
| National Institute of Standards and Technology (NIST), | National Institute of Standards and Technology (NIST), | |||
| "SP800-78-4: Cryptographic Algorithms and Key Sizes for | "SP800-78-4: Cryptographic Algorithms and Key Sizes for | |||
| skipping to change at page 12, line 11 ¶ | skipping to change at page 14, line 4 ¶ | |||
| -- | -- | |||
| -- Message Digest Algorithms (mda-) | -- Message Digest Algorithms (mda-) | |||
| -- | -- | |||
| DigestAlgorithms DIGEST-ALGORITHM ::= { | DigestAlgorithms DIGEST-ALGORITHM ::= { | |||
| -- This expands DigestAlgorithms from [RFC5912] | -- This expands DigestAlgorithms from [RFC5912] | |||
| mda-shake128 | | mda-shake128 | | |||
| mda-shake256, | mda-shake256, | |||
| ... | ... | |||
| } | } | |||
| -- | -- | |||
| -- One-Way Hash Functions | -- One-Way Hash Functions | |||
| -- | -- | |||
| -- SHAKE128 | -- SHAKE128 | |||
| mda-shake128 DIGEST-ALGORITHM ::= { | mda-shake128 DIGEST-ALGORITHM ::= { | |||
| IDENTIFIER id-shake128 -- with output length 32 bytes. | IDENTIFIER id-shake128 -- with output length 32 bytes. | |||
| } | } | |||
| id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) | id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) | |||
| us(840) organization(1) gov(101) | us(840) organization(1) gov(101) | |||
| csor(3) nistAlgorithm(4) | csor(3) nistAlgorithm(4) | |||
| hashAlgs(2) 11 } | hashAlgs(2) 11 } | |||
| -- SHAKE-256 | -- SHAKE256 | |||
| mda-shake256 DIGEST-ALGORITHM ::= { | mda-shake256 DIGEST-ALGORITHM ::= { | |||
| IDENTIFIER id-shake256 -- with output length 64 bytes. | IDENTIFIER id-shake256 -- with output length 64 bytes. | |||
| } | } | |||
| id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) | id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) | |||
| us(840) organization(1) gov(101) | us(840) organization(1) gov(101) | |||
| csor(3) nistAlgorithm(4) | csor(3) nistAlgorithm(4) | |||
| hashAlgs(2) 12 } | hashAlgs(2) 12 } | |||
| -- | -- | |||
| -- Public Key (pk-) Algorithms | -- Public Key (pk-) Algorithms | |||
| skipping to change at page 12, line 47 ¶ | skipping to change at page 14, line 39 ¶ | |||
| PublicKeys PUBLIC-KEY ::= { | PublicKeys PUBLIC-KEY ::= { | |||
| -- This expands PublicKeys from [RFC5912] | -- This expands PublicKeys from [RFC5912] | |||
| pk-rsaSSA-PSS-SHAKE128 | | pk-rsaSSA-PSS-SHAKE128 | | |||
| pk-rsaSSA-PSS-SHAKE256, | pk-rsaSSA-PSS-SHAKE256, | |||
| ... | ... | |||
| } | } | |||
| -- The hashAlgorithm is mda-shake128 | -- The hashAlgorithm is mda-shake128 | |||
| -- The maskGenAlgorithm is id-shake128 | -- The maskGenAlgorithm is id-shake128 | |||
| -- Mask Gen Algorithm is SHAKE128 with output length | -- Mask Gen Algorithm is SHAKE128 with output length | |||
| -- (n - 264) bits, where n is the RSA modulus in bits. | -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA | |||
| -- the saltLength is 32 | -- modulus in bits. | |||
| -- the trailerField is 1 | -- The saltLength is 32. The trailerField is 1. | |||
| pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { | pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { | |||
| IDENTIFIER id-RSASSA-PSS-SHAKE128 | IDENTIFIER id-RSASSA-PSS-SHAKE128 | |||
| KEY RSAPublicKey | KEY RSAPublicKey | |||
| PARAMS ARE absent | PARAMS ARE absent | |||
| -- Private key format not in this module -- | -- Private key format not in this module -- | |||
| CERT-KEY-USAGE { nonRepudiation, digitalSignature, | CERT-KEY-USAGE { nonRepudiation, digitalSignature, | |||
| keyCertSign, cRLSign } | keyCertSign, cRLSign } | |||
| } | } | |||
| -- The hashAlgorithm is mda-shake256 | -- The hashAlgorithm is mda-shake256 | |||
| -- The maskGenAlgorithm is id-shake256 | -- The maskGenAlgorithm is id-shake256 | |||
| -- Mask Gen Algorithm is SHAKE256 with output length | -- Mask Gen Algorithm is SHAKE256 with output length | |||
| -- (n - 520)-bits, where n is the RSA modulus in bits. | -- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA | |||
| -- the saltLength is 64 | -- modulus in bits. | |||
| -- the trailerField is 1 | -- The saltLength is 64. The trailerField is 1. | |||
| pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { | pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { | |||
| IDENTIFIER id-RSASSA-PSS-SHAKE256 | IDENTIFIER id-RSASSA-PSS-SHAKE256 | |||
| KEY RSAPublicKey | KEY RSAPublicKey | |||
| PARAMS ARE absent | PARAMS ARE absent | |||
| -- Private key format not in this module -- | -- Private key format not in this module -- | |||
| CERT-KEY-USAGE { nonRepudiation, digitalSignature, | CERT-KEY-USAGE { nonRepudiation, digitalSignature, | |||
| keyCertSign, cRLSign } | keyCertSign, cRLSign } | |||
| } | } | |||
| -- | -- | |||
| skipping to change at page 14, line 9 ¶ | skipping to change at page 15, line 49 ¶ | |||
| ... | ... | |||
| } | } | |||
| -- RSASSA-PSS with SHAKE128 | -- RSASSA-PSS with SHAKE128 | |||
| sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { | sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { | |||
| IDENTIFIER id-RSASSA-PSS-SHAKE128 | IDENTIFIER id-RSASSA-PSS-SHAKE128 | |||
| PARAMS ARE absent | PARAMS ARE absent | |||
| -- The hashAlgorithm is mda-shake128 | -- The hashAlgorithm is mda-shake128 | |||
| -- The maskGenAlgorithm is id-shake128 | -- The maskGenAlgorithm is id-shake128 | |||
| -- Mask Gen Algorithm is SHAKE128 with output length | -- Mask Gen Algorithm is SHAKE128 with output length | |||
| -- (n - 264) bits, where n is the RSA modulus in bits. | -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA | |||
| -- the saltLength is 32 | -- modulus in bits. | |||
| -- the trailerField is 1 | -- The saltLength is 32. The trailerField is 1 | |||
| HASHES { mda-shake128 } | HASHES { mda-shake128 } | |||
| PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } | PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } | |||
| SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } | SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } | |||
| } | } | |||
| id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } | id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) | |||
| identified-organization(3) dod(6) internet(1) | ||||
| security(5) mechanisms(5) pkix(7) algorithms(6) | ||||
| TBD1 } | ||||
| -- RSASSA-PSS with SHAKE256 | -- RSASSA-PSS with SHAKE256 | |||
| sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { | sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { | |||
| IDENTIFIER id-RSASSA-PSS-SHAKE256 | IDENTIFIER id-RSASSA-PSS-SHAKE256 | |||
| PARAMS ARE absent | PARAMS ARE absent | |||
| -- The hashAlgorithm is mda-shake256 | -- The hashAlgorithm is mda-shake256 | |||
| -- The maskGenAlgorithm is id-shake256 | -- The maskGenAlgorithm is id-shake256 | |||
| -- Mask Gen Algorithm is SHAKE256 with output length | -- Mask Gen Algorithm is SHAKE256 with output length | |||
| -- (n - 520)-bits, where n is the RSA modulus in bits. | -- (8*ceil((n-1)/8) - 520)-bits, where n is the | |||
| -- the saltLength is 64 | -- RSA modulus in bits. | |||
| -- the trailerField is 1 | -- The saltLength is 64. The trailerField is 1. | |||
| HASHES { mda-shake256 } | HASHES { mda-shake256 } | |||
| PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } | PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } | |||
| SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } | SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } | |||
| } | } | |||
| id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } | id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) | |||
| identified-organization(3) dod(6) internet(1) | ||||
| security(5) mechanisms(5) pkix(7) algorithms(6) | ||||
| TBD2 } | ||||
| -- Determinstic ECDSA with SHAKE128 | -- ECDSA with SHAKE128 | |||
| sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { | sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { | |||
| IDENTIFIER id-ecdsa-with-shake128 | IDENTIFIER id-ecdsa-with-shake128 | |||
| VALUE ECDSA-Sig-Value | VALUE ECDSA-Sig-Value | |||
| PARAMS ARE absent | PARAMS ARE absent | |||
| HASHES { mda-shake128 } | HASHES { mda-shake128 } | |||
| PUBLIC-KEYS { pk-ec } | PUBLIC-KEYS { pk-ec } | |||
| SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } | SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } | |||
| } | } | |||
| id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) | id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) | |||
| country(16) us(840) organization(1) | identified-organization(3) dod(6) internet(1) | |||
| gov(101) csor(3) nistAlgorithm(4) | security(5) mechanisms(5) pkix(7) algorithms(6) | |||
| sigAlgs(3) TBD } | TBD3 } | |||
| -- Determinstic ECDSA with SHAKE256 | -- ECDSA with SHAKE256 | |||
| sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { | sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { | |||
| IDENTIFIER id-ecdsa-with-shake256 | IDENTIFIER id-ecdsa-with-shake256 | |||
| VALUE ECDSA-Sig-Value | VALUE ECDSA-Sig-Value | |||
| PARAMS ARE absent | PARAMS ARE absent | |||
| HASHES { mda-shake256 } | HASHES { mda-shake256 } | |||
| PUBLIC-KEYS { pk-ec } | PUBLIC-KEYS { pk-ec } | |||
| SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } | SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } | |||
| } | } | |||
| id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) | id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) | |||
| country(16) us(840) organization(1) | identified-organization(3) dod(6) internet(1) | |||
| gov(101) csor(3) nistAlgorithm(4) | security(5) mechanisms(5) pkix(7) algorithms(6) | |||
| sigAlgs(3) TBD } | TBD4 } | |||
| END | END | |||
| Authors' Addresses | Authors' Addresses | |||
| Panos Kampanakis | Panos Kampanakis | |||
| Cisco Systems | Cisco Systems | |||
| Email: pkampana@cisco.com | Email: pkampana@cisco.com | |||
| End of changes. 54 change blocks. | ||||
| 160 lines changed or deleted | 250 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||