idnits 2.17.1 draft-housley-lamps-cms-sha3-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: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (27 March 2017) is 2586 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) == Unused Reference: 'HMAC' is defined on line 280, 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended status: Standards Track Vigil Security 4 Expires: 27 September 2017 27 March 2017 6 Use of the SHA3 One-way Hash Functions in the 7 Cryptographic Message Syntax (CMS) 9 11 Abstract 13 This document describes the conventions for using the four one-way 14 hash functions in the SHA3 family with the Cryptographic Message 15 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 http://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 27 September 2017. 34 Copyright Notice 36 Copyright (c) 2017 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 (http://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 1. Introduction 51 The Cryptographic Message Syntax (CMS) [CMS] is used to digitally 52 sign, digest, authenticate, or encrypt arbitrary message contents. 53 This specification describes the use of the four one-way hash 54 functions in the SHA3 family (SHA3-224, SHA3-256, SHA3-384, and 55 SHA3-512) [SHA3] with the CMS. In addition, this specification 56 describes the use of these four one-way hash functions with the 57 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 SHA3-224, SHA3-256, SHA3-384, and 78 SHA3-512 [SHA3]. 80 Digest algorithm identifiers are located in the SignedData 81 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 82 DigestedData digestAlgorithm field, and the AuthenticatedData 83 digestAlgorithm field. 85 Digest values are located in the DigestedData digest field and the 86 Message Digest authenticated attribute. In addition, digest values 87 are input to signature algorithms. 89 SHA3-224, SHA3-256, SHA3-384, and SHA3-512 produce output values with 90 224, 256, 384, and 512 bits, respectively. The object identifiers 91 for these four one-way hash functions are as follows: 93 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 94 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } 96 id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 } 97 id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 } 99 id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 } 101 id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 } 103 When using the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 104 algorithm identifiers, the parameters field MUST be absent; not NULL 105 but absent. 107 3. Signature Algorithms 109 This section specifies the conventions employed by CMS 110 implementations that support the four SHA3 one-way hash functions 111 with the RSASSA PKCS#1 version 1.5 signature algorithm [PKCS1] and 112 the Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] with the 113 CMS signed-data content type. 115 Signature algorithm identifiers are located in the SignerInfo 116 signatureAlgorithm field of SignedData. Also, signature algorithm 117 identifiers are located in the SignerInfo signatureAlgorithm field of 118 countersignature attributes. 120 Signature values are located in the SignerInfo signature field of 121 SignedData. Also, signature values are located in the SignerInfo 122 signature field of countersignature attributes. 124 3.1. RSASSA PKCS#1 v1.5 with SHA3 126 The RSASSA PKCS#1 v1.5 is defined in [PKCS1]. When RSASSA PKCS#1 127 v1.5 is used in conjunction with one of the SHA3 one-way hash 128 functions, the object identifiers are: 130 sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 131 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } 133 id-rsassa-pkcs1-v1_5-with-sha3-224 ::= { sigAlgs 13 } 135 id-rsassa-pkcs1-v1_5-with-sha3-256 ::= { sigAlgs 14 } 137 id-rsassa-pkcs1-v1_5-with-sha3-384 ::= { sigAlgs 15 } 139 id-rsassa-pkcs1-v1_5-with-sha3-512 ::= { sigAlgs 16 } 141 The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys 142 in certificates is specified in [PKIXALG], and it is repeated here 143 for convenience: 145 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 146 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 148 When the rsaEncryption, id-rsassa-pkcs1-v1_5-with-sha3-224, id- 149 rsassa-pkcs1-v1_5-with-sha3-256, id-rsassa-pkcs1-v1_5-with-sha3-384, 150 and id-rsassa-pkcs1-v1_5-with-sha3-512 algorithm identifier is used, 151 AlgorithmIdentifier parameters field MUST contain NULL. 153 When the rsaEncryption algorithm identifier is used, the RSA public 154 key, which is composed of a modulus and a public exponent, MUST be 155 encoded using the RSAPublicKey type as specified in [PKIXALG]. The 156 output of this encoding is carried in the certificate subject public 157 key. The definition of RSAPublicKey is repeated here for 158 convenience: 160 RSAPublicKey ::= SEQUENCE { 161 modulus INTEGER, -- n 162 publicExponent INTEGER } -- e 164 When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a 165 single value, and that value is used directly as the signature value. 167 3.2. ECDSA with SHA3 169 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 170 [DSS]. When ECDSA is used in conjunction with one of the SHA3 one- 171 way hash functions, the object identifiers are: 173 sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 174 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 } 176 id-ecdsa-with-sha3-224 ::= { sigAlgs 9 } 178 id-ecdsa-with-sha3-256 ::= { sigAlgs 10 } 180 id-ecdsa-with-sha3-384 ::= { sigAlgs 11 } 182 id-ecdsa-with-sha3-512 ::= { sigAlgs 12 } 184 When using the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256, id- 185 ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm 186 identifiers, the parameters field MUST be absent; not NULL but 187 absent. 189 The conventions for ECDSA public keys is as specified in [PKIXECC]. 190 The ECParameters associated with the ECDSA public key in the signers 191 certificate SHALL apply to the verification of the signature. 193 When signing, the ECDSA algorithm generates two values. These values 194 are commonly referred to as r and s. To easily transfer these two 195 values as one signature, they MUST be ASN.1 encoded using the ECDSA- 196 Sig-Value defined in [PKIXALG] and repeated here for convenience: 198 ECDSA-Sig-Value ::= SEQUENCE { 199 r INTEGER, 200 s INTEGER } 202 4. Message Authentication Codes 204 This section specifies the conventions employed by CMS 205 implementations that support the HMAC with SHA3 message 206 authentication code (MAC). 208 MAC algorithm identifiers are located in the AuthenticatedData 209 macAlgorithm field. 211 MAC values are located in the AuthenticatedData mac field. 213 When HMAC is used in conjunction with one of the SHA3 one-way hash 214 functions, the object identifiers are: 216 hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 217 us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 } 219 id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 } 221 id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 } 223 id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 } 225 id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 } 227 When the id-hmacWithSHA3-224, id-hmacWithSHA3-256, id- 228 hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithm identifier is 229 used, the parameters field MUST be absent; not NULL but absent. 231 5. Security Considerations 233 Implementations must protect the signer's private key. Compromise of 234 the signer's private key permits masquerade. 236 When more than two parties share the same message-authentication key, 237 data origin authentication is not provided. Any party that knows the 238 message-authentication key can compute a valid MAC, therefore the 239 content could originate from any one of the parties. 241 Implementations must randomly generate message-authentication keys 242 and one-time values, such as the k value when generating a ECDSA 243 signature. In addition, the generation of public/private key pairs 244 relies on a random numbers. The use of inadequate pseudo-random 245 number generators (PRNGs) to generate cryptographic such values can 246 result in little or no security. An attacker may find it much easier 247 to reproduce the PRNG environment that produced the keys, searching 248 the resulting small set of possibilities, rather than brute force 249 searching the whole key space. The generation of quality random 250 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 251 this area, and Appendix 3 of FIPS Pub 186-4 [DSS] provides some PRNG 252 techniques. 254 Implementers should be aware that cryptographic algorithms become 255 weaker with time. As new cryptanalysis techniques are developed and 256 computing performance improves, the work factor to break a particular 257 cryptographic algorithm will reduce. Therefore, cryptographic 258 algorithm implementations should be modular allowing new algorithms 259 to be readily inserted. That is, implementers should be prepared to 260 regularly update the set of algorithms in their implementations. 262 6. Normative References 264 [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation 265 One (ASN.1): Specification of basic notation", ITU-T 266 Recommendation X.680, 2015. 268 [ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: 269 Specification of Basic Encoding Rules (BER), Canonical 270 Encoding Rules (CER) and Distinguished Encoding Rules 271 (DER)", ITU-T Recommendation X.690, 2015. 273 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 274 RFC 5652, September 2009. 276 [DSS] National Institute of Standards and Technology, U.S. 277 Department of Commerce, "Digital Signature Standard, 278 version 4", NIST FIPS PUB 186-4, 2013. 280 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message 281 Authentication", RFC 2104. February 1997. 283 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [PKCS1] Moriarty, K., Kaliski, B., Jonsson, J., and A. Rusch, 287 "PKCS #1: RSA Cryptography Specifications Version 2.2" 288 RFC 8017, November 2016. 290 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 291 Identifiers for the Internet X.509 Public Key 292 Infrastructure Certificate and Certificate Revocation List 293 (CRL) Profile", RFC 3279, April 2002. 295 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 296 "Elliptic Curve Cryptography Subject Public Key 297 Information", RFC 5480, March 2009. 299 [SHA3] National Institute of Standards and Technology, U.S. 300 Department of Commerce, "SHA-3 Standard - Permutation- 301 Based Hash and Extendable-Output Functions", FIPS PUB 202, 302 August 2015. 304 7. Informative References 306 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 307 Requirements for Security", BCP 106, RFC 4086, June 2005. 309 Appendix. ASN.1 Module 311 TBD 313 Author Address 315 Russ Housley 316 Vigil Security, LLC 317 918 Spring Knoll Drive 318 Herndon, VA 20170 319 USA 321 Email: housley@vigilsec.com