idnits 2.17.1 draft-dang-lamps-cms-shakes-hash-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 7) being 72 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 October 2017) is 2370 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) == Missing Reference: 'KMAC' is mentioned on line 194, but not defined == Missing Reference: 'SP800-90s' is mentioned on line 238, but not defined == Unused Reference: 'HMAC' is defined on line 267, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1-B' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1-E' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Downref: Normative reference to an Informational RFC: RFC 8017 (ref. 'PKCS1') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA3' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Q. Dang 2 Intended status: Standards Track NIST 3 Expires: 29 April 2018 P. Kampanakis 4 Cisco Systems 5 29 October 2017 7 Use of the SHAKE One-way Hash Functions in the 8 Cryptographic Message Syntax (CMS) 10 12 Abstract 14 This document describes the conventions for using 2 one-way 15 hash functions called SHAKE128 and SHAKE256 in the SHA3 family with 16 the Cryptographic Message Syntax (CMS). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 29 April 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 The Cryptographic Message Syntax (CMS) [CMS] is used to digitally 53 sign, digest, authenticate, or encrypt arbitrary message contents. 54 This specification describes the use of the SHAKE128 and SHAKE256 55 specified in [SHA3] as 2 new hash funcitons with the CMS. In addition, 56 this specification describes the use of these 2 one-way hash functions 57 with the RSASSA PKCS#1 version 1.5 signature algorithm [PKCS1] and the 58 Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] with the CMS 59 signed-data content type. 61 1.1. ASN.1 63 CMS values are generated using ASN.1 [ASN1-B], using the Basic 64 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 65 [ASN1-E]. 67 1.2. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 73 2. Message Digest Algorithms 75 One-way hash functions are also referred to as message digest 76 algorithms. This section specifies the conventions employed by CMS 77 implementations that support SHAKE128 and SHAKE256 [SHA3]. 79 Digest algorithm identifiers are located in the SignedData 80 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 81 DigestedData digestAlgorithm field, and the AuthenticatedData 82 digestAlgorithm field. 84 Digest values are located in the DigestedData digest field and the 85 Message Digest authenticated attribute. In addition, digest values 86 are input to signature algorithms. 88 Output lengths of SHAKE128 and SHAKE256 are always 256 and 512 bits 89 respectively in this specification. The object identifiers 90 for these 2 one-way hash functions are as follows: 92 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 93 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } 95 id-SHAKE128 OBJECT IDENTIFIER ::= { hashAlgs 11 } 96 id-SHAKE256 OBJECT IDENTIFIER ::= { hashAlgs 12 } 98 When using the id-SHAKE128 or id-SHAKE256 algorithm identifier, the 99 parameters field MUST be absent; not NULL but absent. Again, the output 100 lengths are fixed as 256 and 512 bits respectively. 102 3. Signature Algorithms 104 This section specifies the conventions employed by CMS 105 implementations that support 2 SHAKE one-way hash functions 106 with the RSASSA PKCS#1 version 1.5 signature algorithm [PKCS1] and 107 the Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] with the 108 CMS signed-data content type. 110 Signature algorithm identifiers are located in the SignerInfo 111 signatureAlgorithm field of SignedData. Also, signature algorithm 112 identifiers are located in the SignerInfo signatureAlgorithm field of 113 countersignature attributes. 115 Signature values are located in the SignerInfo signature field of 116 SignedData. Also, signature values are located in the SignerInfo 117 signature field of countersignature attributes. 119 3.1. RSASSA PKCS#1 v1.5 with SHAKEs 121 The RSASSA PKCS#1 v1.5 is defined in [PKCS1]. When RSASSA PKCS#1 122 v1.5 is used in conjunction with one of the SHAKEs one-way hash 123 functions, the object identifiers are: 125 sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 126 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } 128 id-rsassa-pkcs1-v1_5-with-SHAKE128 ::= { sigAlgs x } 130 id-rsassa-pkcs1-v1_5-with-SHAKE256 ::= { sigAlgs y } 132 Note: x and y will be specified by NIST. 134 The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys 135 in certificates is specified in [PKIXALG], and it is repeated here 136 for convenience: 138 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 139 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 141 When the rsaEncryption id-rsassa-pkcs1-v1_5-with-SHAKE128 or id- 142 rsassa-pkcs1-v1_5-with-SHAKE256 algorithm identifier is used, 143 AlgorithmIdentifier parameters field MUST contain NULL. 145 When the rsaEncryption algorithm identifier is used, the RSA public 146 key, which is composed of a modulus and a public exponent, MUST be 147 encoded using the RSAPublicKey type as specified in [PKIXALG]. The 148 output of this encoding is carried in the certificate subject public 149 key. The definition of RSAPublicKey is repeated here for 150 convenience: 152 RSAPublicKey ::= SEQUENCE { 153 modulus INTEGER, -- n 154 publicExponent INTEGER } -- e 156 When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a 157 single value, and that value is used directly as the signature value. 159 3.2. ECDSA with SHAKEs 161 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 162 [DSS]. When ECDSA is used in conjunction with one of the SHAKE one- 163 way hash functions, the object identifiers are: 165 sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 166 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } 168 id-ecdsa-with-SHAKE128 ::= { sigAlgs x } 170 id-ecdsa-with-SHAKE256 ::= { sigAlgs y } 172 Note: x and y will be specified by NIST. 174 When using the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 175 algorithm identifier, the parameters field MUST be absent; not NULL but 176 absent. 178 The conventions for ECDSA public keys is as specified in [PKIXECC]. 179 The ECParameters associated with the ECDSA public key in the signers 180 certificate SHALL apply to the verification of the signature. 182 When signing, the ECDSA algorithm generates two values. These values 183 are commonly referred to as r and s. To easily transfer these two 184 values as one signature, they MUST be ASN.1 encoded using the ECDSA- 185 Sig-Value defined in [PKIXALG] and repeated here for convenience: 187 ECDSA-Sig-Value ::= SEQUENCE { 188 r INTEGER, 189 s INTEGER } 191 4. Message Authentication Codes with SHAKEs 193 This section specifies the conventions employed by CMS 194 implementations that support the KMAC specified in [KMAC] 195 as authentication code (MAC). 197 KMAC algorithm identifiers are located in the AuthenticatedData 198 macAlgorithm field. 200 MAC values are located in the AuthenticatedData mac field. 202 The object identifiers for KMACs with SHAKE128 and SHAKE256 are: 204 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 205 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } 207 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { hashAlgs x } 209 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { hashAlgs y } 211 Note: x and y will be specified by NIST. 213 The variables N and S in this specification for KMAC are emply strings. 214 L, an integer representing the requested output length in bits, is 215 256 or 512 for KmacWithSHAKE128 or KmacWithSHAKE256 respectively 216 in this specification. 218 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm identifier 219 is used, the parameters field MUST be absent; not NULL but absent. 221 5. Security Considerations 223 Implementations must protect the signer's private key. Compromise of 224 the signer's private key permits masquerade. 226 When more than two parties share the same message-authentication key, 227 data origin authentication is not provided. Any party that knows the 228 message-authentication key can compute a valid MAC, therefore the 229 content could originate from any one of the parties. 231 Implementations must randomly generate message-authentication keys 232 and one-time values, such as the k value when generating a ECDSA 233 signature. In addition, the generation of public/private key pairs 234 relies on random numbers. The use of inadequate pseudo-random 235 number generators (PRNGs) to generate such cryptographic values can 236 result in little or no security. The generation of quality random 237 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 238 this area, and NIST SP 800-90 [SP800-90s] series provide acceptable 239 PRNGs. 241 Implementers should be aware that cryptographic algorithms may become 242 weaker with time. As new cryptanalysis techniques are developed and 243 computing performance improves, the work factor to break a particular 244 cryptographic algorithm will reduce. Therefore, cryptographic 245 algorithm implementations should be modular allowing new algorithms 246 to be readily inserted. That is, implementers should be prepared to 247 regularly update the set of algorithms in their implementations. 249 6. Normative References 251 [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation 252 One (ASN.1): Specification of basic notation", ITU-T 253 Recommendation X.680, 2015. 255 [ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: 256 Specification of Basic Encoding Rules (BER), Canonical 257 Encoding Rules (CER) and Distinguished Encoding Rules 258 (DER)", ITU-T Recommendation X.690, 2015. 260 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 261 RFC 5652, September 2009. 263 [DSS] National Institute of Standards and Technology, U.S. 264 Department of Commerce, "Digital Signature Standard, 265 version 4", NIST FIPS PUB 186-4, 2013. 267 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message 268 Authentication", RFC 2104. February 1997. 270 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [PKCS1] Moriarty, K., Kaliski, B., Jonsson, J., and A. Rusch, 274 "PKCS #1: RSA Cryptography Specifications Version 2.2" 275 RFC 8017, November 2016. 277 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 278 Identifiers for the Internet X.509 Public Key 279 Infrastructure Certificate and Certificate Revocation List 280 (CRL) Profile", RFC 3279, April 2002. 282 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 283 "Elliptic Curve Cryptography Subject Public Key 284 Information", RFC 5480, March 2009. 286 [SHA3] National Institute of Standards and Technology, U.S. 287 Department of Commerce, "SHA-3 Standard - Permutation- 288 Based Hash and Extendable-Output Functions", FIPS PUB 202, 289 August 2015. 290 [SP800-90s]National Institute of Standards and Technology, 291 SP 800-90A,B & C. 293 7. Informative References 295 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 296 Requirements for Security", BCP 106, RFC 4086, June 2005. 298 Appendix A ASN.1 Module 300 TBD 302 Appendix B Acknowledgement 304 This document is just an update of Russ Housley's draft: 305 https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-00 306 This document replaced SHA3 hash functions by SHAKE128 and SHAKE256 307 as the LAMPS working group agreed. 309 Authors' Addresses 311 Quynh Dang & Kampanakis 312 NIST 313 100 Bureau Drive 314 Gaithersburg, MD 20899 316 Email: quynh.Dang & Kampanakis@nist.gov 318 Panos Kampanakis 319 Cisco Systems 321 Email: pkampana@cisco.com