--- 1/draft-ietf-lamps-cms-shakes-09.txt 2019-04-25 09:13:19.306034217 -0700 +++ 2/draft-ietf-lamps-cms-shakes-10.txt 2019-04-25 09:13:19.342035130 -0700 @@ -1,20 +1,20 @@ LAMPS WG P. Kampanakis Internet-Draft Cisco Systems Updates: RFC3370 (if approved) Q. Dang Intended status: Standards Track NIST -Expires: October 13, 2019 April 11, 2019 +Expires: October 27, 2019 April 25, 2019 Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) - draft-ietf-lamps-cms-shakes-09 + draft-ietf-lamps-cms-shakes-10 Abstract This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. @@ -26,63 +26,68 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 13, 2019. + This Internet-Draft will expire on October 27, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Message Authentication Codes . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 8.2. Informative References . . . . . . . . . . . . . . . . . 11 - Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Change Log [ EDNOTE: Remove this section before publication. ] + o draft-ietf-lamps-cms-shake-10: + + * Updated IANA considerations section to request for OID + assignments. + o draft-ietf-lamps-cms-shake-09: * Fixed minor text nit. * Updates in Sec Considerations section. o draft-ietf-lamps-cms-shake-08: * id-shake128-len and id-shake256-len were replaced with id- sha128 with 32 bytes output length and id-shake256 with 64 @@ -211,49 +216,52 @@ nistAlgorithm(4) 2 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 12 } In this specification, when using the id-shake128 or id-shake256 algorithm identifiers, the parameters MUST be absent. That is, the identifier SHALL be a SEQUENCE of one component, the OID. - We define two new identifiers for RSASSA-PSS signatures using SHAKEs. - - id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD1 } + We define two identifiers for RSASSA-PSS signatures using SHAKEs. - id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD2 } + id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD1 } - [ EDNOTE: "TBD1", "TBD2" 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 same RSASSA-PSS algorithm identifiers can be used for identifying public keys and signatures. - We define two new algorithm identifiers of ECDSA signatures using - SHAKEs. - - id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) - country(16) us(840) organization(1) gov(101) csor(3) - nistAlgorithm(4) 3 TBD3 } + We define two algorithm identifiers of ECDSA signatures using SHAKEs. - id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) - country(16) us(840) organization(1) gov(101) csor(3) - nistAlgorithm(4) 3 TBD4 } + id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD3 } - [ EDNOTE: "TBD3", "TBD4" will be specified by NIST. ] + 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 RSASSA-PSS and ECDSA identifiers MUST be absent. That is, each identifier SHALL be a SEQUENCE of one component, the OID. - Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are + Two object identifiers for KMACs using SHAKE128 and SHAKE256 are defined below. id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 19 } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 20 } @@ -405,27 +413,49 @@ Conforming implementations that process KMACs with the SHAKEs when processing CMS data MUST recognize these identifiers. When calculating the KMAC output, the variable N is 0xD2B282C2, S is an empty string, and L, the integer representing the requested output length in bits, is 256 or 512 for KmacWithSHAKE128 or KmacWithSHAKE256 respectively in this specification. 5. IANA Considerations - One object identifier for the ASN.1 module in Appendix A was assigned - in the SMI Security for S/MIME Module Identifiers + One object identifier for the ASN.1 module in Appendix A was + requested for the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) registry: - CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) - rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) - id-mod-cms-shakes-2019(TBD) } + +---------+----------------------+--------------------+ + | Decimal | Description | References | + +---------+----------------------+--------------------+ + | TBD | CMSAlgsForSHAKE-2019 | [EDNOTE: THIS RFC] | + +---------+----------------------+--------------------+ + + IANA has assigned four OID identifiers in the SMI Security for PKIX + Algorithms [SMI-PKIX] (1.3.6.1.5.5.7.6) registry + + id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD1 } + id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD2 } + id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD3 } + id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD4 } 6. Security Considerations This document updates [RFC3370]. The security considerations section of that document applies to this specification as well. NIST has defined appropriate use of the hash functions in terms of the algorithm strengths and expected time frames for secure use in Special Publications (SPs) [SP800-78-4] and [SP800-107]. These documents can be used as guides to choose appropriate key sizes for @@ -533,20 +563,25 @@ [SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", May 2009, . [shake-nist-oids] National Institute of Standards and Technology, "Computer Security Objects Register", October 2017, . + [SMI-PKIX] + IANA, "SMI Security for PKIX Algorithms", March 2019, + . + [SP800-107] National Institute of Standards and Technology (NIST), "SP800-107: Recommendation for Applications Using Approved Hash Algorithms", May 2014, . [SP800-78-4] National Institute of Standards and Technology (NIST), "SP800-78-4: Cryptographic Algorithms and Key Sizes for @@ -627,23 +662,28 @@ -- And Signature identifiers used in SignerInfo -- signatureAlgorithm field of SignedData content -- type and countersignature attribute in CMS. -- -- From RFC5280, for reference. -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } -- When the rsaEncryption algorithm identifier is used -- for a public key, the AlgorithmIdentifier parameters -- field MUST contain NULL. -- - id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD1 } - id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD2 } - + id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD1 } + id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD2 } -- When the id-RSASSA-PSS-* algorithm identifiers are used -- for a public key or signature in CMS, the AlgorithmIdentifier -- parameters field MUST be absent. The message digest algorithm -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or -- 64 byte outout length respectively. The mask generating -- function MUST be SHAKE128 or SHAKE256 with an output length -- of (n - 264) or (n - 520) bits respectively, where n -- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST -- be 32 or 64 bytes respectively. The trailerField MUST be 1, -- which represents the trailer field with hexadecimal value @@ -644,41 +684,42 @@ -- 64 byte outout length respectively. The mask generating -- function MUST be SHAKE128 or SHAKE256 with an output length -- of (n - 264) or (n - 520) bits respectively, where n -- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST -- be 32 or 64 bytes respectively. The trailerField MUST be 1, -- which represents the trailer field with hexadecimal value -- 0xBC. Regardless of id-RSASSA-PSS-* or rsaEncryption being -- used as the AlgorithmIdentifier of the OriginatorPublicKey, -- the RSA public key MUST be encoded using the RSAPublicKey -- type. + -- From RFC4055, for reference. -- RSAPublicKey ::= SEQUENCE { -- modulus INTEGER, -- -- n -- publicExponent INTEGER } -- -- e - id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) - country(16) us(840) organization(1) - gov(101) csor(3) nistAlgorithm(4) - sigAlgs(3) TBD3 } - id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) - country(16) us(840) organization(1) - gov(101) csor(3) nistAlgorithm(4) - sigAlgs(3) TBD4 } - + id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD3 } + id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) + identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) algorithms(6) + TBD4 } -- When the id-ecdsa-with-shake* algorithm identifiers are -- used in CMS, the AlgorithmIdentifier parameters field -- MUST be absent and the signature algorithm should be -- deterministic ECDSA [RFC6979]. The message digest MUST -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout -- length respectively. In both cases, the ECDSA public key, -- MUST be encoded using the id-ecPublicKey type. + -- From RFC5480, for reference. -- id-ecPublicKey OBJECT IDENTIFIER ::= { -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } -- The id-ecPublicKey parameters must be absent or present -- and are defined as -- ECParameters ::= CHOICE { -- namedCurve OBJECT IDENTIFIER -- -- -- implicitCurve NULL -- -- -- specifiedCurve SpecifiedECDomain -- }