idnits 2.17.1 draft-ietf-lamps-pkix-shake-02.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 2 instances of too long lines in the document, the longest one being 18 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 159: '...dentifiers above MUST be absent. That...' RFC 2119 keyword, line 160: '..., the identifier SHALL be a SEQUENCE o...' RFC 2119 keyword, line 181: '... implementations MUST specify the algo...' RFC 2119 keyword, line 188: '... processing certificates and CRLs MUST...' RFC 2119 keyword, line 195: '...ed, the encoding MUST omit the paramet...' (15 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 2127 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) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Downref: Normative reference to an Informational RFC: RFC 8017 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA3' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS WG P. Kampanakis 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Q. Dang 5 Expires: December 31, 2018 NIST 6 June 29, 2018 8 Internet X.509 Public Key Infrastructure: Additional Algorithm 9 Identifiers for RSASSA-PSS and ECDSA using SHAKEs as Hash Functions 10 draft-ietf-lamps-pkix-shake-02 12 Abstract 14 Digital signatures are used to sign messages, X.509 certificates and 15 CRLs (Certificate Revocation Lists). This document describes the 16 conventions for using the SHAKE family of hash functions in the 17 Internet X.509 as one-way hash functions with the RSA Probabilistic 18 Signature Scheme and ECDSA signature algorithms. The conventions for 19 the associated subject public keys are also described. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 31, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 5 61 4.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 5 62 4.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2.1. RSASSA-PSS Public Keys . . . . . . . . . . . . . . . 6 64 4.2.2. ECDSA Public Keys . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Change Log 76 [ EDNOTE: Remove this section before publication. ] 78 o draft-ietf-lamps-pkix-shake-02: 80 * Significant reorganization of the sections to simplify the 81 introduction, the new OIDs and their use in PKIX. 83 * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MFG, 84 according the WG consensus. 86 * Updated Public Key section to use the new RSASSA-PSS OIDs and 87 clarify the algorithm identifier usage. 89 * Removed the no longer used SHAKE OIDs from section 3.1. 91 * Consolidated subsection for message digest algorithms. 93 * Text fixes. 95 o draft-ietf-lamps-pkix-shake-01: 97 * Changed titles and section names. 99 * Removed DSA after WG discussions. 101 * Updated shake OID names and parameters, added MGF1 section. 103 * Updated RSASSA-PSS section. 105 * Added Public key algorithm OIDs. 107 * Populated Introduction and IANA sections. 109 o draft-ietf-lamps-pkix-shake-00: 111 * Initial version 113 2. Introduction 115 This document describes several cryptographic algorithm identifiers 116 for several cryptographic algorithms which use variable length output 117 SHAKE functions introduced in [SHA3] which can be used with the 118 Internet X.509 Certificate and CRL profile [RFC5280]. 120 The SHA-3 family of one-way hash functions is specified in [SHA3]. 121 In the SHA-3 family, two extendable-output functions, called SHAKE128 122 and SHAKE256 are defined. Four hash functions, SHA3-224, SHA3-256, 123 SHA3-384, and SHA3-512 are also defined but are out of scope for this 124 document. A SHAKE is a variable length hash function. The output 125 lengths, in bits, of the SHAKE hash functions are defined by the d 126 parameter. The corresponding collision and preimage resistance 127 security levels for SHAKE128 and SHAKE256 are respectively 128 min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256) bits. 130 SHAKEs can be used as the message digest function (to hash the 131 message to be signed) and as the hash function in the mask generating 132 functions in RSASSA-PSS and ECDSA. In this document, we define four 133 new OIDs for RSASSA-PSS and ECDSA when SHAKE128 and SHAKE256 are used 134 as hash functions. The same algorithm identifiers are used for 135 identifying a public key, and identifying a signature. 137 3. Identifiers 139 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 141 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 142 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 144 [ EDNOTE: "TBD" will be specified by NIST later. ] 146 The new algorithm identifiers of ECDSA signatures using SHAKEs are 147 below. 149 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 150 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 151 id-ecdsa-with-shake(3) TBD } 153 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 154 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 155 id-ecdsa-with-shake(3) TBD } 157 [ EDNOTE: "TBD" will be specified by NIST later. ] 159 The parameters for these four identifiers above MUST be absent. That 160 is, the identifier SHALL be a SEQUENCE of one component, the OID. 162 4. Use in PKIX 164 4.1. Signatures 166 Signatures can be placed in a number of different ASN.1 structures. 167 The top level structure for an X.509 certificate, to illustrate how 168 signatures are frequently encoded with an algorithm identifier and a 169 location for the signature, is 171 Certificate ::= SEQUENCE { 172 tbsCertificate TBSCertificate, 173 signatureAlgorithm AlgorithmIdentifier, 174 signatureValue BIT STRING } 176 The identifiers defined in Section 3 can be used as the 177 AlgorithmIdentifier in the signatureAlgorithm field in the sequence 178 Certificate and the signature field in the sequence tbsCertificate in 179 X.509 [RFC3280]. 181 Conforming CA implementations MUST specify the algorithms explicitly 182 by using the OIDs specified in Section 3 when encoding RSASSA-PSS and 183 ECDSA with SHAKE signatures, and public keys in certificates and 184 CRLs. Encoding rules for RSASSA-PSS and ECDSA signature values are 185 specified in [RFC4055] and [RFC5480] respectively. 187 Conforming client implementations that process RSASSA-PSS and ECDSA 188 with SHAKE signatures when processing certificates and CRLs MUST 189 recognize the corresponding OIDs. 191 4.1.1. RSASSA-PSS Signatures 193 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 194 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is 195 used, the encoding MUST omit the parameters field. That is, the 196 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 197 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. 199 The hash algorithm to hash a message being signed and the hash 200 algorithm in the maskGenAlgorithm used in RSASSA-PSS MUST be the 201 same, SHAKE128 or SHAKE256 respectively. The output-length of the 202 hash algorithm which hashes the message SHALL be 32 or 64 bytes 203 respectively. 205 The maskGenAlgorithm is the MGF1 specified in Section B.2.1 of 206 [RFC8017]. The output length for SHAKE128 or SHAKE256 being used as 207 the hash function in MGF1 is (n - 264)/8 or (n - 520)/8 bytes 208 respectively, where n is the RSA modulus in bits. For example, when 209 RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 in 210 the MGF1 will be 223 or 191 when id-RSASSA-PSS-SHAKE128 or id-RSASSA- 211 PSS-SHAKE256 is used respectively. 213 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 214 Finally, the trailerField MUST be 1, which represents the trailer 215 field with hexadecimal value 0xBC [RFC8017]. 217 4.1.2. ECDSA Signatures 219 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 220 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 221 (specified in Section 3) algorithm identifier appears, the respective 222 SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The 223 encoding MUST omit the parameters field. That is, the 224 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 225 ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256. 227 For simplicity and compliance with the ECDSA standard specification, 228 the output size of the hash function must be explicitly determined. 229 The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 230 256 or 512 bits respectively. 232 Conforming CA implementations that generate ECDSA with SHAKE 233 signatures in certificates or CRLs MUST generate such signatures in 234 accordance with all the requirements specified in Sections 7.2 and 235 7.3 of [X9.62] or with all the requirements specified in 236 Section 4.1.3 of [SEC1]. They MAY also generate such signatures in 237 accordance with all the recommendations in [X9.62] or [SEC1] if they 238 have a stated policy that requires conformance to these standards. 239 These standards may have not specified SHAKE128 and SHAKE256 as hash 240 algorithm options. However, SHAKE128 and SHAKE256 with output length 241 being 32 and 64 octets respectively are subtitutions for 256 and 242 512-bit output hash algorithms such as SHA256 and SHA512 used in the 243 standards. 245 4.2. Public Keys 247 Certificates conforming to [RFC5280] can convey a public key for any 248 public key algorithm. The certificate indicates the algorithm 249 through an algorithm identifier. This algorithm identifier is an OID 250 and optionally associated parameters. 252 In the X.509 certificate, the subjectPublicKeyInfo field has the 253 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 255 SubjectPublicKeyInfo ::= SEQUENCE { 256 algorithm AlgorithmIdentifier, 257 subjectPublicKey BIT STRING 258 } 260 The fields in SubjectPublicKeyInfo have the following meanings: 262 o algorithm is the algorithm identifier and parameters for the 263 public key. 265 o subjectPublicKey contains the byte stream of the public key. The 266 algorithms defined in this document always encode the public key 267 as an exact multiple of 8-bits. 269 The conventions for RSASSA-PSS and ECDSA public keys algorithm 270 identifiers are as specified in [RFC3279], [RFC4055] and [RFC5480] , 271 but we include them below for convenience. 273 4.2.1. RSASSA-PSS Public Keys 275 [RFC3279] defines the following OID for RSA AlgorithmIdentifier in 276 the SubjectPublicKeyInfo with NULL parameters. 278 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 280 Additionally, when the RSA private key owner wishes to limit the use 281 of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifiers 282 for RSASSA-PSS defined in Section 3 can be used as the algorithm 283 field in the SubjectPublicKeyInfo sequence [RFC3280]. The identifier 284 parameters, as explained in section Section 3, MUST be absent. 286 Regardless of what public key algorithm identifier is used, the RSA 287 public key, which is composed of a modulus and a public exponent, 288 MUST be encoded using the RSAPublicKey type [RFC4055]. The output of 289 this encoding is carried in the certificate subjectPublicKey. 291 RSAPublicKey ::= SEQUENCE { 292 modulus INTEGER, -- n 293 publicExponent INTEGER -- e 294 } 296 4.2.2. ECDSA Public Keys 298 For ECDSA, when id-ecdsa-with-shake128 or id-ecdsa-with-shake256 is 299 used as the AlgorithmIdentifier in the algorithm field of 300 SubjectPublicKeyInfo, the parameters, as explained in section 301 Section 3, MUST be absent. 303 Additionally, the mandatory EC SubjectPublicKey is defined in 304 Section 2.1.1 and its syntax is in Section 2.2 of [RFC5480]. We also 305 include them here for convenience: 307 id-ecPublicKey OBJECT IDENTIFIER ::= { 308 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 310 The id-ecPublicKey parameters MUST be present and are defined as 312 ECParameters ::= CHOICE { 313 namedCurve OBJECT IDENTIFIER 314 -- implicitCurve NULL 315 -- specifiedCurve SpecifiedECDomain 316 } 318 The ECParameters associated with the ECDSA public key in the signer's 319 certificate SHALL apply to the verification of the signature. 321 5. IANA Considerations 323 This document uses several new registries [ EDNOTE: Update here. ] 325 6. Security Considerations 327 The SHAKEs are deterministic functions. Like any other deterministic 328 functions, executing each function with the same input multiple times 329 will produce the same output. Therefore, users should not expect 330 unrelated outputs (with the same or different output lengths) from 331 excuting a SHAKE function with the same input multiple times. 333 Implementations must protect the signer's private key. Compromise of 334 the signer's private key permits masquerade. 336 Implementations must randomly generate one-time values, such as the k 337 value when generating a ECDSA signature. In addition, the generation 338 of public/private key pairs relies on random numbers. The use of 339 inadequate pseudo-random number generators (PRNGs) to generate such 340 cryptographic values can result in little or no security. The 341 generation of quality random numbers is difficult. [RFC4086] offers 342 important guidance in this area, and [SP800-90A] series provide 343 acceptable PRNGs. 345 Implementers should be aware that cryptographic algorithms may become 346 weaker with time. As new cryptanalysis techniques are developed and 347 computing power increases, the work factor or time required to break 348 a particular cryptographic algorithm may decrease. Therefore, 349 cryptographic algorithm implementations should be modular allowing 350 new algorithms to be readily inserted. That is, implementers should 351 be prepared to regularly update the set of algorithms in their 352 implementations. 354 7. Acknowledgements 356 We would like to thank Sean Turner for his valuable contributions to 357 this document. 359 8. References 361 8.1. Normative References 363 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 364 X.509 Public Key Infrastructure Certificate and 365 Certificate Revocation List (CRL) Profile", RFC 3280, 366 DOI 10.17487/RFC3280, April 2002, 367 . 369 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 370 Algorithms and Identifiers for RSA Cryptography for use in 371 the Internet X.509 Public Key Infrastructure Certificate 372 and Certificate Revocation List (CRL) Profile", RFC 4055, 373 DOI 10.17487/RFC4055, June 2005, 374 . 376 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 377 Housley, R., and W. Polk, "Internet X.509 Public Key 378 Infrastructure Certificate and Certificate Revocation List 379 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 380 . 382 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 383 "Elliptic Curve Cryptography Subject Public Key 384 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 385 . 387 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 388 "PKCS #1: RSA Cryptography Specifications Version 2.2", 389 RFC 8017, DOI 10.17487/RFC8017, November 2016, 390 . 392 [SHA3] National Institute of Standards and Technology, "SHA-3 393 Standard - Permutation-Based Hash and Extendable-Output 394 Functions FIPS PUB 202", August 2015, 395 . 398 8.2. Informative References 400 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 401 Identifiers for the Internet X.509 Public Key 402 Infrastructure Certificate and Certificate Revocation List 403 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 404 2002, . 406 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 407 "Randomness Requirements for Security", BCP 106, RFC 4086, 408 DOI 10.17487/RFC4086, June 2005, 409 . 411 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 412 Elliptic Curve Cryptography", May 2009, 413 . 415 [SP800-90A] 416 National Institute of Standards and Technology, 417 "Recommendation for Random Number Generation Using 418 Deterministic Random Bit Generators. NIST SP 800-90A", 419 June 2015, 420 . 423 [X9.62] American National Standard for Financial Services (ANSI), 424 "X9.62-2005 Public Key Cryptography for the Financial 425 Services Industry: The Elliptic Curve Digital Signature 426 Standard (ECDSA)", November 2005. 428 Appendix A. ASN.1 module 430 [ EDNOTE: More here. ] 432 Authors' Addresses 434 Panos Kampanakis 435 Cisco Systems 437 Email: pkampana@cisco.com 439 Quynh Dang 440 NIST 441 100 Bureau Drive, Stop 8930 442 Gaithersburg, MD 20899-8930 443 USA 445 Email: quynh.dang@nist.gov