idnits 2.17.1 draft-ietf-lamps-cms-shakes-00.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 6 instances of too long lines in the document, the longest one being 10 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 132: '... the parameters MUST be present, and ...' RFC 2119 keyword, line 147: '...ld associated with id-mgf1 MUST have a...' RFC 2119 keyword, line 149: '..., this parameter MUST be id-shake128-l...' RFC 2119 keyword, line 182: '...sed as the hashAlgorithm, it MUST also...' RFC 2119 keyword, line 187: '... the parameters MUST be present, and ...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2018) is 2262 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: August 19, 2018 Cisco Systems 6 February 15, 2018 8 Use of the SHAKE One-way Hash Functions in the Cryptographic Message 9 Syntax (CMS) 10 draft-ietf-lamps-cms-shakes-00 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 August 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 54 3.1. One-way Extensible-Output-Function SHAKEs . . . . . . . . 3 55 3.2. Mask Generation SHAKEs . . . . . . . . . . . . . . . . . 3 56 4. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 4 57 4.1. RSASSA-PSS with SHAKEs . . . . . . . . . . . . . . . . . 4 58 4.2. ECDSA with SHAKEs . . . . . . . . . . . . . . . . . . . . 5 59 5. Message Authentication Codes with SHAKEs . . . . . . . . . . 6 60 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Change Log 71 [ EDNOTE: Remove this section before publication. ] 73 o draft-ietf-lamps-cms-shake-00: 75 * Various updates to title and section names. 77 * Content changes filling in text and references. 79 o draft-dang-lamps-cms-shakes-hash-00: 81 * Initial version 83 2. Introduction 85 The Cryptographic Message Syntax (CMS) [RFC5652] is used to digitally 86 sign, digest, authenticate, or encrypt arbitrary message contents. 87 This specification describes the use of the SHAKE128 and SHAKE256 88 specified in [SHA3] as new hash functions in CMS. In addition, this 89 specification describes the use of these one-way hash functions with 90 the RSASSA-PSS signature algorithm [RFC8017] and the Elliptic Curve 91 Digital Signature Algorithm (ECDSA) [X9.62] with the CMS signed-data 92 content type. 94 3. Message Digest Algorithms 96 3.1. One-way Extensible-Output-Function SHAKEs 98 The SHA-3 family of one-way hash functions is specified in [SHA3]. 99 In the SHA-3 family, two extendable-output functions, called SHAKE128 100 and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256, 101 SHA3-384, and SHA3-512 are also defined but are out of scope for this 102 document. 104 In CMS, Digest algorithm identifiers are located in the SignedData 105 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 106 DigestedData digestAlgorithm field, and the AuthenticatedData 107 digestAlgorithm field. 109 Digest values are located in the DigestedData digest field and the 110 Message Digest authenticated attribute. In addition, digest values 111 are input to signature algorithms. 113 SHAKE is a variable length hash function. The output lengths, in 114 bits, of the SHAKE hash functions is defined by the parameter d. The 115 corresponding collision and preimage resistance security levels for 116 SHAKE128 and SHAKE256 are respectively min(d/2,128) and min(d,128) 117 and min(d/2,256) and min(d,256). The Object Identifiers (OIDs) for 118 these two hash functions are defined in [shake-nist-oids] and are 119 included here for convenience: 121 id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 122 country(16) us(840) organization(1) gov(101) csor(3) 123 nistalgorithm(4) hashalgs(2) 17 } 125 id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 126 country(16) us(840) organization(1) gov(101) csor(3) 127 nistalgorithm(4) hashalgs(2) 18 } 129 ShakeOutputLen ::= INTEGER -- Output length in octets 131 When using the id-shake128-len id-shake256-len algorithm identifiers, 132 the parameters MUST be present, and they MUST employ the 133 ShakeOutputLen syntax that contains an encoded positive integer value 134 at least 32 or 64 respectively. 136 3.2. Mask Generation SHAKEs 138 The RSASSA-PSS signature algorithm uses a mask generation function. 139 A mask generation function takes an octet string of variable length 140 and a desired output length as input, and outputs an octet string of 141 the desired length. The mask generation function used in RSASSA-PSS 142 is defined in [RFC8017], but we include it here as well for 143 convenience: 145 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 147 The parameters field associated with id-mgf1 MUST have a 148 hashAlgorithm value that identifies the hash used with MGF1. To use 149 SHAKE as this hash, this parameter MUST be id-shake128-len or id- 150 shake256-len as specified in Section 3.1 above. 152 4. Signature Algorithms 154 This section specifies the conventions employed by CMS 155 implementations that support 2 SHAKE one-way hash functions with the 156 RSASSA-PSS signature algorithm [RFC8017] and the Elliptic Curve 157 Digital Signature Algorithm (ECDSA) [X9.62] with the CMS signed-data 158 content type. 160 In CMS, signature algorithm identifiers are located in the SignerInfo 161 signatureAlgorithm field of SignedData and countersignature 162 attributes. Signature values are located in the SignerInfo signature 163 field of SignedData and countersignature attributes. 165 4.1. RSASSA-PSS with SHAKEs 167 The RSASSA-PSS signature algorithm identifier and its parameters are 168 specifed in [RFC4055]: 170 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 172 RSASSA-PSS-params ::= SEQUENCE { 173 hashAlgorithm HashAlgorithm, 174 maskGenAlgorithm MaskGenAlgorithm, 175 saltLength INTEGER, 176 trailerField INTEGER } 178 This document adds two new hash algorithm choices and two new choices 179 for mask generation functions. These are the SHAKE128 and SHAKE256 180 algorithm identifiers specified in Section 3.1. 182 When SHAKE128 or SHAKE256 is used as the hashAlgorithm, it MUST also 183 be used as the maskGenAlgorithm. 185 When used as the hashAlgorithm, the SHAKE128 or SHAKE256 output- 186 length must be either 32 or 64 bytes respectively. In these cases, 187 the parameters MUST be present, and they MUST employ the 188 ShakeOutputLen syntax that contains an encoded positive integer value 189 of 32 or 64 for id-shake128-len or id-shake256-len algorithm 190 identifier respectively. 192 When id-shake128-len or id-shake256-len algorithm identifier is used 193 as the id-mfg1 maskGenAlgorithm parameter, the ShakeOutputLen 194 parameter must be (n - 264)/8 or (n - 520)/8 respectively for 195 SHAKE128 and SHAKE256, where n is the RSA modulus in bits. For 196 example, when RSA modulus n is 2048, ShakeOutputLen must be 223 or 197 191 when id-shake128-len or id-shake256-len is used respectively. 199 The parameter saltLength MUST be 32 or 64 bytes respectively for the 200 SHAKE128 and SHAKE256 OIDs. 202 The conventions for RSA public keys are as specified in [RFC3279] and 203 [RFC4055]. [RFC3279] defines the following OID for RSA with NULL 204 parameters. 206 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 208 Additionally, [RFC4055] adds the RSASSA-PSS OID and parameters shown 209 above as a public key identifier. The parameters may be either 210 absent or present when RSASSA-PSS OID is used as subject public key 211 information. If id-RSASSA-PSS is used in the public key identifier 212 with parameters, Section 3.3 of [RFC4055] describes that the 213 signature algorithm parameters MUST match the parameters in the key 214 structure algorithm identifier except the saltLength field. The 215 saltLength field in the signature parameters MUST be greater or equal 216 to that in the key parameters field. If the id-RSASSA-PSS parameters 217 are NULL no further parameter validation is necessary. 219 4.2. ECDSA with SHAKEs 221 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 222 [X9.62]. When ECDSA is used in conjunction with one of the SHAKE 223 one-way hash functions, the object identifiers are: 225 id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 226 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 x} 228 id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 229 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 y} 231 EDNOTE: x and y will be specified by NIST. 233 When using the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 234 algorithm identifier, the parameters field MUST be absent; not NULL 235 but absent. 237 For simplicity and compliance with the ECDSA standard specification, 238 the output size of the hash function must be explicitly determined. 239 The ShakeOutputLen parameter of SHAKE128 or SHAKE256 MUST be 32 or 64 240 bytes respectively when it is used in ECDSA 242 The conventions for ECDSA public keys is specified in [RFC5480] as 244 id-ecPublicKey OBJECT IDENTIFIER ::= { 245 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 247 ECParameters ::= CHOICE { 248 namedCurve OBJECT IDENTIFIER 249 -- implicitCurve NULL 250 -- specifiedCurve SpecifiedECDomain } 252 The ECParameters associated with the ECDSA public key in the signers 253 certificate SHALL apply to the verification of the signature. 255 5. Message Authentication Codes with SHAKEs 257 This section specifies the conventions employed by CMS 258 implementations that support the KMAC specified in [SP800-185] as 259 authentication code (MAC). 261 In CMS, KMAC algorithm identifiers are located in the 262 AuthenticatedData macAlgorithm field. MAC values are located in the 263 AuthenticatedData mac field. 265 The object identifiers for KMACs with SHAKE128 and SHAKE256 are: 267 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 268 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 z } 270 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 271 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 w } 273 EDNOTE: z and w will be specified by NIST. 275 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm 276 identifier is used, the parameters field MUST be absent; not NULL but 277 absent. 279 When calculating the KMAC output, the variable N is 0xD2B282C2, S is 280 an empty string, and L, the integer representing the requested output 281 length in bits, is 256 or 512 for KmacWithSHAKE128 or 282 KmacWithSHAKE256 respectively in this specification. 284 6. Acknowledgement 286 This document is based on Russ Housley's draft 287 [I-D.housley-lamps-cms-sha3-hash] It replaces SHA3 hash functions by 288 SHAKE128 and SHAKE256 as the LAMPS WG agreed. 290 7. IANA Considerations 292 This document uses several registries that were originally created in 293 [shake-nist-oids]. No further registries are required. [ EDNOTE: 294 Update here. ] 296 8. Security Considerations 298 SHAKE128 and SHAKE256 are one-way extensible-output functions. Their 299 output length depends on a required length of the consuming 300 application. 302 The SHAKEs are deterministic functions. Like any other deterministic 303 functions, executing each function with the same input multiple times 304 will produce the same output. Therefore, users should not expect 305 unrelated outputs (with the same or different output lengths) from 306 excuting a SHAKE function with the same input multiple times. 308 Implementations must protect the signer's private key. Compromise of 309 the signer's private key permits masquerade. 311 When more than two parties share the same message-authentication key, 312 data origin authentication is not provided. Any party that knows the 313 message-authentication key can compute a valid MAC, therefore the 314 content could originate from any one of the parties. 316 Implementations must randomly generate message-authentication keys 317 and one-time values, such as the k value when generating a ECDSA 318 signature. In addition, the generation of public/private key pairs 319 relies on random numbers. The use of inadequate pseudo-random number 320 generators (PRNGs) to generate such cryptographic values can result 321 in little or no security. The generation of quality random numbers 322 is difficult. [RFC4086] offers important guidance in this area, and 323 [SP800-90A] series provide acceptable PRNGs. 325 Implementers should be aware that cryptographic algorithms may become 326 weaker with time. As new cryptanalysis techniques are developed and 327 computing performance improves, the work factor to break a particular 328 cryptographic algorithm will reduce. Therefore, cryptographic 329 algorithm implementations should be modular allowing new algorithms 330 to be readily inserted. That is, implementers should be prepared to 331 regularly update the set of algorithms in their implementations. 333 9. References 335 9.1. Normative References 337 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 338 Identifiers for the Internet X.509 Public Key 339 Infrastructure Certificate and Certificate Revocation List 340 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 341 2002, . 343 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 344 Algorithms and Identifiers for RSA Cryptography for use in 345 the Internet X.509 Public Key Infrastructure Certificate 346 and Certificate Revocation List (CRL) Profile", RFC 4055, 347 DOI 10.17487/RFC4055, June 2005, 348 . 350 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 351 "Elliptic Curve Cryptography Subject Public Key 352 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 353 . 355 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 356 RFC 5652, DOI 10.17487/RFC5652, September 2009, 357 . 359 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 360 "PKCS #1: RSA Cryptography Specifications Version 2.2", 361 RFC 8017, DOI 10.17487/RFC8017, November 2016, 362 . 364 [SHA3] National Institute of Standards and Technology, U.S. 365 Department of Commerce, "SHA-3 Standard - Permutation- 366 Based Hash and Extendable-Output Functions", FIPS PUB 202, 367 August 2015. 369 [SP800-185] 370 National Institute of Standards and Technology, "SHA-3 371 Derived Functions: cSHAKE, KMAC, TupleHash and 372 ParallelHash. NIST SP 800-185", December 2016, 373 . 376 9.2. Informative References 378 [I-D.housley-lamps-cms-sha3-hash] 379 Housley, R., "Use of the SHA3 One-way Hash Functions in 380 the Cryptographic Message Syntax (CMS)", draft-housley- 381 lamps-cms-sha3-hash-00 (work in progress), March 2017. 383 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 384 "Randomness Requirements for Security", BCP 106, RFC 4086, 385 DOI 10.17487/RFC4086, June 2005, 386 . 388 [shake-nist-oids] 389 National Institute of Standards and Technology, "Computer 390 Security Objects Register", October 2017, 391 . 394 [SP800-90A] 395 National Institute of Standards and Technology, 396 "Recommendation for Random Number Generation Using 397 Deterministic Random Bit Generators. NIST SP 800-90A", 398 June 2015, 399 . 402 [X9.62] American National Standard for Financial Services (ANSI), 403 "X9.62-2005 Public Key Cryptography for the Financial 404 Services Industry: The Elliptic Curve Digital Signature 405 Standard (ECDSA)", November 2005. 407 Appendix A. ASN.1 Module 409 [EDNOTE: Update] 411 Authors' Addresses 413 Quynh Dang 414 NIST 415 100 Bureau Drive 416 Gaithersburg, MD 20899 418 Email: quynh.Dang@nist.gov 420 Panos Kampanakis 421 Cisco Systems 423 Email: pkampana@cisco.com