idnits 2.17.1 draft-ietf-lamps-cms-shakes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 137: '...ifiers, the parameters MUST be absent....' RFC 2119 keyword, line 138: '..., the identifier SHALL be a SEQUENCE o...' RFC 2119 keyword, line 162: '...ASSA-PSS and ECDSA identifiers MUST be...' RFC 2119 keyword, line 163: '... each identifier SHALL be a SEQUENCE o...' RFC 2119 keyword, line 177: '...hSHAKE128 and id-KmacWithSHAKE256 MUST...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8017 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-185' == Outdated reference: A later version (-02) exists of draft-housley-lamps-cms-sha3-hash-00 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS WG Q. Dang 3 Internet-Draft NIST 4 Intended status: Standards Track P. Kampanakis 5 Expires: December 31, 2018 Cisco Systems 6 June 29, 2018 8 Use of the SHAKE One-way Hash Functions in the Cryptographic Message 9 Syntax (CMS) 10 draft-ietf-lamps-cms-shakes-01 12 Abstract 14 This document describes the conventions for using the SHAKE family of 15 hash functions with the Cryptographic Message Syntax (CMS). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 31, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 5 58 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 6 59 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3.1. RSASSA-PSS Public Keys . . . . . . . . . . . . . . . 6 61 4.3.2. ECDSA Public Keys . . . . . . . . . . . . . . . . . . 7 62 4.4. Message Authentication Codes . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Change Log 74 [ EDNOTE: Remove this section before publication. ] 76 o draft-ietf-lamps-cms-shake-01: 78 * Significant reorganization of the sections to simplify the 79 introduction, the new OIDs and their use in CMS. 81 * Added new OIDs for RSASSA-PSS that hardcodes hash, salt and 82 MFG, according the WG consensus. 84 * Updated Public Key section to use the new RSASSA-PSS OIDs and 85 clarify the algorithm identifier usage. 87 * Removed the no longer used SHAKE OIDs from section 3.1. 89 o draft-ietf-lamps-cms-shake-00: 91 * Various updates to title and section names. 93 * Content changes filling in text and references. 95 o draft-dang-lamps-cms-shakes-hash-00: 97 * Initial version 99 2. Introduction 101 The Cryptographic Message Syntax (CMS) [RFC5652] is used to digitally 102 sign, digest, authenticate, or encrypt arbitrary message contents. 103 This specification describes the use of the SHAKE128 and SHAKE256 104 specified in [SHA3] as new hash functions in CMS. In addition, it 105 describes the use of these functions with the RSASSA-PSS signature 106 algorithm [RFC8017] and the Elliptic Curve Digital Signature 107 Algorithm (ECDSA) [X9.62] with the CMS signed-data content type. 109 The SHA-3 family of one-way hash functions is specified in [SHA3]. 110 In the SHA-3 family, two extendable-output functions, called SHAKE128 111 and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256, 112 SHA3-384, and SHA3-512 are also defined but are out of scope for this 113 document. A SHAKE is a variable length hash function. The output 114 lengths, in bits, of the SHAKE hash functions are defined by the d 115 parameter. The corresponding collision and preimage resistance 116 security levels for SHAKE128 and SHAKE256 are respectively 117 min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256) bits. 119 A SHAKE can be used in CMS as a message digest, message 120 authentication code or a mask generation function (in RSASSA-PSS). 121 In this document we define six new OIDs using SHAKE128 and SHAKE256 122 in CMS. 124 3. Identifiers 126 The object identifiers for SHAKE128 and SHAKE256 hash functions are 127 defined in [shake-nist-oids] and we include them here for 128 convenience. 130 id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 131 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 17 } 133 id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 134 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 18 } 136 In this specification, when using the id-shake128-len or id- 137 shake256-len algorithm identifiers, the parameters MUST be absent. 138 That is, the identifier SHALL be a SEQUENCE of one component, the 139 OID. 141 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 143 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 144 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 146 [ EDNOTE: "TBD" will be specified by NIST later. ] 148 The new algorithm identifiers of ECDSA signatures using SHAKEs are 149 below. 151 id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 152 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 TBD } 154 id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 155 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 TBD } 157 [ EDNOTE: "TBD" will be specified by NIST. ] 159 The same RSASSA-PSS and ECDSA with SHAKEs algorithm identifiers are 160 used for identifying public keys and signatures. 162 The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be 163 absent. That is, each identifier SHALL be a SEQUENCE of one 164 component, the OID. 166 The new object identifiers for KMACs using SHAKE128 and SHAKE256 are 167 below. 169 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 170 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 TBD } 172 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 173 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 TBD } 175 EDNOTE: "TBD" will be specified by NIST. 177 The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST 178 be absent. That is, each identifier SHALL be a SEQUENCE of one 179 component, the OID. 181 4. Use in CMS 183 4.1. Message Digests 185 The id-shake128-len and id-shake256-len OIDs (Section 3) can be used 186 as the digest algorithm identifiers located in the SignedData, 187 SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm 188 fields in CMS [RFC5652]. The encoding MUST omit the parameters field 189 and the output size, d, for the SHAKE128 or SHAKE256 message digest 190 MUST be 256 or 512 bits respectively. 192 The digest values are located in the DigestedData field and the 193 Message Digest authenticated attribute included in the 194 signedAttributes of the SignedData signerInfo. In addition, digest 195 values are input to signature algorithms. 197 4.2. Signatures 199 In CMS, signature algorithm identifiers are located in the SignerInfo 200 signatureAlgorithm field of SignedData content type and 201 countersignature attribute. Signature values are located in the 202 SignerInfo signature field of SignedData and countersignature. 204 Conforming implementations that process RSASSA-PSS and ECDSA with 205 SHAKE signatures when processing CMS data MUST recognize the 206 corresponding OIDs specified in Section 3. 208 4.2.1. RSASSA-PSS Signatures 210 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 211 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is 212 used, the encoding MUST omit the parameters field. That is, the 213 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 214 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. 216 The hash algorithm to hash a message being signed and the hash 217 algorithm in the maskGenAlgorithm used in RSASSA-PSS MUST be the 218 same, SHAKE128 or SHAKE256 respectively. The output-length of the 219 SHAKE which hashes the message SHALL be 32 or 64 bytes respectively. 221 The maskGenAlgorithm is the MGF1 specified in Section B.2.1 of 222 [RFC8017]. A mask generation function in RSASSA-PSS takes an octet 223 string of variable length and a desired output length as input, and 224 outputs an octet string of the desired length. The output length for 225 SHAKE128 or SHAKE256 being used as the hash function in MGF1 is (n - 226 264)/8 or (n - 520)/8 bytes respectively, where n is the RSA modulus 227 in bits. For example, when RSA modulus n is 2048, the output length 228 for SHAKE128 or SHAKE256 in the maskGenAlgorithm will be 223 or 191 229 when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used 230 respectively. 232 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 233 Finally, the trailerField MUST be 1, which represents the trailer 234 field with hexadecimal value 0xBC [RFC8017]. 236 4.2.2. ECDSA Signatures 238 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 239 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 240 (specified in Section 3) algorithm identifier appears, the respective 241 SHAKE function is used as the hash. The encoding MUST omit the 242 parameters field. That is, the AlgorithmIdentifier SHALL be a 243 SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id- 244 ecdsa-with-SHAKE256. 246 For simplicity and compliance with the ECDSA standard specification, 247 the output size of the hash function must be explicitly determined. 248 The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 249 256 or 512 bits respectively. The ECDSA message hash function is 250 SHAKE128 or SHAKE256 respectively. 252 4.3. Public Keys 254 In CMS, the signer's public key algorithm identifiers are located in 255 the OriginatorPublicKey's algorithm attribute. 257 The conventions for RSASSA-PSS and ECDSA public keys algorithm 258 identifiers are as specified in [RFC3279], [RFC4055] and [RFC5480] , 259 but we include them below for convenience. 261 4.3.1. RSASSA-PSS Public Keys 263 [RFC3279] defines the following OID for RSA AlgorithmIdentifier in 264 the SubjectPublicKeyInfo with NULL parameters. 266 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 268 Additionally, when the RSA private key owner wishes to limit the use 269 of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifier 270 for RSASSA-PSS defined in Section 3 can be used as the algorithm 271 attribute in the OriginatorPublicKey sequence. The identifier 272 parameters, as explained in Section 3, MUST be absent. The RSASSA- 273 PSS algorithm functions and output lengths are the same as defined in 274 Section 4.2.1. 276 Regardless of what public key algorithm identifier is used, the RSA 277 public key, which is composed of a modulus and a public exponent, 278 MUST be encoded using the RSAPublicKey type [RFC4055]. The output of 279 this encoding is carried in the CMS publicKey bit string. 281 RSAPublicKey ::= SEQUENCE { 282 modulus INTEGER, -- n 283 publicExponent INTEGER -- e 284 } 286 4.3.2. ECDSA Public Keys 288 When id-ecdsa-with-shake128 or id-ecdsa-with-shake256 are used as the 289 algorithm identitifier in the public key, the parameters, as 290 explained in Section 3, MUST be absent. The hash function and its 291 output-length are the same as in Section 4.2.2. 293 Additionally, the mandatory EC SubjectPublicKey is defined in 294 Section 2.1.1 and its syntax in Section 2.2 of [RFC5480]. We also 295 include them here for convenience: 297 id-ecPublicKey OBJECT IDENTIFIER ::= { 298 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 300 ECParameters ::= CHOICE { 301 namedCurve OBJECT IDENTIFIER 302 -- implicitCurve NULL 303 -- specifiedCurve SpecifiedECDomain 304 } 306 The ECParameters associated with the ECDSA public key in the signers 307 certificate SHALL apply to the verification of the signature. 309 4.4. Message Authentication Codes 311 KMAC message authentication code (KMAC) is specified in [SP800-185]. 312 In CMS, KMAC algorithm identifiers are located in the 313 AuthenticatedData macAlgorithm field. The KMAC values are located in 314 the AuthenticatedData mac field. 316 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm 317 identifier is used as the KMAC algorithm identifier, the parameters 318 field MUST be absent. 320 Conforming implementations that process KMACs with the SHAKEs when 321 processing CMS data MUST recognize these identifiers. 323 When calculating the KMAC output, the variable N is 0xD2B282C2, S is 324 an empty string, and L, the integer representing the requested output 325 length in bits, is 256 or 512 for KmacWithSHAKE128 or 326 KmacWithSHAKE256 respectively in this specification. 328 5. IANA Considerations 330 This document uses several new registries [ EDNOTE: Update here. ] 332 6. Security Considerations 334 SHAKE128 and SHAKE256 are one-way extensible-output functions. Their 335 output length depends on a required length of the consuming 336 application. 338 The SHAKEs are deterministic functions. Like any other deterministic 339 functions, executing each function with the same input multiple times 340 will produce the same output. Therefore, users should not expect 341 unrelated outputs (with the same or different output lengths) from 342 excuting a SHAKE function with the same input multiple times. 344 Implementations must protect the signer's private key. Compromise of 345 the signer's private key permits masquerade. 347 When more than two parties share the same message-authentication key, 348 data origin authentication is not provided. Any party that knows the 349 message-authentication key can compute a valid MAC, therefore the 350 content could originate from any one of the parties. 352 Implementations must randomly generate message-authentication keys 353 and one-time values, such as the k value when generating a ECDSA 354 signature. In addition, the generation of public/private key pairs 355 relies on random numbers. The use of inadequate pseudo-random number 356 generators (PRNGs) to generate such cryptographic values can result 357 in little or no security. The generation of quality random numbers 358 is difficult. [RFC4086] offers important guidance in this area, and 359 [SP800-90A] series provide acceptable PRNGs. 361 Implementers should be aware that cryptographic algorithms may become 362 weaker with time. As new cryptanalysis techniques are developed and 363 computing power increases, the work factor or time required to break 364 a particular cryptographic algorithm may decrease. Therefore, 365 cryptographic algorithm implementations should be modular allowing 366 new algorithms to be readily inserted. That is, implementers should 367 be prepared to regularly update the set of algorithms in their 368 implementations. 370 7. Acknowledgements 372 This document is based on Russ Housley's draft 373 [I-D.housley-lamps-cms-sha3-hash] It replaces SHA3 hash functions by 374 SHAKE128 and SHAKE256 as the LAMPS WG agreed. 376 8. References 378 8.1. Normative References 380 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 381 Algorithms and Identifiers for RSA Cryptography for use in 382 the Internet X.509 Public Key Infrastructure Certificate 383 and Certificate Revocation List (CRL) Profile", RFC 4055, 384 DOI 10.17487/RFC4055, June 2005, 385 . 387 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 388 "Elliptic Curve Cryptography Subject Public Key 389 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 390 . 392 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 393 RFC 5652, DOI 10.17487/RFC5652, September 2009, 394 . 396 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 397 "PKCS #1: RSA Cryptography Specifications Version 2.2", 398 RFC 8017, DOI 10.17487/RFC8017, November 2016, 399 . 401 [SHA3] National Institute of Standards and Technology, U.S. 402 Department of Commerce, "SHA-3 Standard - Permutation- 403 Based Hash and Extendable-Output Functions", FIPS PUB 202, 404 August 2015. 406 [SP800-185] 407 National Institute of Standards and Technology, "SHA-3 408 Derived Functions: cSHAKE, KMAC, TupleHash and 409 ParallelHash. NIST SP 800-185", December 2016, 410 . 413 8.2. Informative References 415 [I-D.housley-lamps-cms-sha3-hash] 416 Housley, R., "Use of the SHA3 One-way Hash Functions in 417 the Cryptographic Message Syntax (CMS)", draft-housley- 418 lamps-cms-sha3-hash-00 (work in progress), March 2017. 420 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 421 Identifiers for the Internet X.509 Public Key 422 Infrastructure Certificate and Certificate Revocation List 423 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 424 2002, . 426 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 427 "Randomness Requirements for Security", BCP 106, RFC 4086, 428 DOI 10.17487/RFC4086, June 2005, 429 . 431 [shake-nist-oids] 432 National Institute of Standards and Technology, "Computer 433 Security Objects Register", October 2017, 434 . 437 [SP800-90A] 438 National Institute of Standards and Technology, 439 "Recommendation for Random Number Generation Using 440 Deterministic Random Bit Generators. NIST SP 800-90A", 441 June 2015, 442 . 445 [X9.62] American National Standard for Financial Services (ANSI), 446 "X9.62-2005 Public Key Cryptography for the Financial 447 Services Industry: The Elliptic Curve Digital Signature 448 Standard (ECDSA)", November 2005. 450 Appendix A. ASN.1 Module 452 [EDNOTE: Update] 454 Authors' Addresses 456 Quynh Dang 457 NIST 458 100 Bureau Drive 459 Gaithersburg, MD 20899 461 Email: quynh.Dang@nist.gov 463 Panos Kampanakis 464 Cisco Systems 466 Email: pkampana@cisco.com