idnits 2.17.1 draft-ietf-lamps-pkix-shake-13.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 draft header indicates that this document updates RFC3279, but the abstract doesn't seem to directly say this. It does mention RFC3279 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3279, updated by this document, for RFC5378 checks: 2000-07-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 21, 2019) is 1741 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' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 Updates: 3279 (if approved) Q. Dang 5 Intended status: Standards Track NIST 6 Expires: January 22, 2020 July 21, 2019 8 Internet X.509 Public Key Infrastructure: Additional Algorithm 9 Identifiers for RSASSA-PSS and ECDSA using SHAKEs 10 draft-ietf-lamps-pkix-shake-13 12 Abstract 14 Digital signatures are used to sign messages, X.509 certificates and 15 CRLs. This document updates the "Algorithms and Identifiers for the 16 Internet X.509 Public Key Infrastructure Certificate and Certificate 17 Revocation List Profile" (RFC3279) and describes the conventions for 18 using the SHAKE function family in Internet X.509 certificates and 19 revocation lists as one-way hash functions with the RSA Probabilistic 20 signature and ECDSA signature algorithms. The conventions for the 21 associated subject public keys are also described. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 22, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 64 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8 65 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 9.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Change Log 77 [ EDNOTE: Remove this section before publication. ] 79 o draft-ietf-lamps-pkix-shake-13: 81 * Addressing one applicable comment from Dan M. about sec levels 82 while in secdir review of draft-ietf-lamps-cms-shakes. 84 * Addressing comment from Scott B.'s opsdir review about 85 references in the abstract. 87 o draft-ietf-lamps-pkix-shake-12: 89 * Nits identified by Roman, Eric V. Ben K., Barry L. in ballot 90 position review. 92 o draft-ietf-lamps-pkix-shake-11: 94 * Nits identified by Roman in AD Review. 96 o draft-ietf-lamps-pkix-shake-10: 98 * Updated IANA considerations section to request for OID 99 assignments. 101 o draft-ietf-lamps-pkix-shake-09: 103 * Fixed minor text nits. 105 * Added text name allocation for SHAKEs in IANA considerations. 107 * Updates in Sec Considerations section. 109 o draft-ietf-lamps-pkix-shake-08: 111 * Small nits from Russ while in WGLC. 113 o draft-ietf-lamps-pkix-shake-07: 115 * Incorporated Eric's suggestion from WGLC. 117 o draft-ietf-lamps-pkix-shake-06: 119 * Added informative references. 121 * Updated ASN.1 so it compiles. 123 * Updated IANA considerations. 125 o draft-ietf-lamps-pkix-shake-05: 127 * Added RFC8174 reference and text. 129 * Explicitly explained why RSASSA-PSS-params are omitted in 130 section 5.1.1. 132 * Simplified Public Keys section by removing redundant info from 133 RFCs. 135 o draft-ietf-lamps-pkix-shake-04: 137 * Removed paragraph suggesting KMAC to be used in generating k in 138 Deterministic ECDSA. That should be RFC6979-bis. 140 * Removed paragraph from Security Considerations that talks about 141 randomness of k because we are using deterministic ECDSA. 143 * Various ASN.1 fixes. 145 * Text fixes. 147 o draft-ietf-lamps-pkix-shake-03: 149 * Updates based on suggestions and clarifications by Jim. 151 * Added ASN.1. 153 o draft-ietf-lamps-pkix-shake-02: 155 * Significant reorganization of the sections to simplify the 156 introduction, the new OIDs and their use in PKIX. 158 * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, 159 according the WG consensus. 161 * Updated Public Key section to use the new RSASSA-PSS OIDs and 162 clarify the algorithm identifier usage. 164 * Removed the no longer used SHAKE OIDs from section 3.1. 166 * Consolidated subsection for message digest algorithms. 168 * Text fixes. 170 o draft-ietf-lamps-pkix-shake-01: 172 * Changed titles and section names. 174 * Removed DSA after WG discussions. 176 * Updated shake OID names and parameters, added MGF1 section. 178 * Updated RSASSA-PSS section. 180 * Added Public key algorithm OIDs. 182 * Populated Introduction and IANA sections. 184 o draft-ietf-lamps-pkix-shake-00: 186 * Initial version 188 2. Introduction 190 [RFC3279] defines cryptographic algorithm identifiers for the 191 Internet X.509 Certificate and Certificate Revocation Lists (CRL) 192 profile [RFC5280]. This document updates RFC3279 and defines 193 identifiers for several cryptographic algorithms that use variable 194 length output SHAKE functions introduced in [SHA3] which can be used 195 with . 197 In the SHA-3 family, two extendable-output functions (SHAKEs), 198 SHAKE128 and SHAKE256, are defined. Four other hash function 199 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also 200 defined but are out of scope for this document. A SHAKE is a 201 variable length hash function defined as SHAKE(M, d) where the output 202 is a d-bits-long digest of message M. The corresponding collision 203 and second-preimage-resistance strengths for SHAKE128 are 204 min(d/2,128) and min(d,128) bits, respectively (Appendix A.1 [SHA3]). 205 And the corresponding collision and second-preimage-resistance 206 strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, 207 respectively. 209 A SHAKE can be used as the message digest function (to hash the 210 message to be signed) in RSASSA-PSS [RFC8017] and ECDSA [X9.62] and 211 as the hash in the mask generation function (MGF) in RSASSA-PSS. 213 3. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 4. Identifiers 223 This section defines four new object identifiers (OIDs), for RSASSA- 224 PSS and ECDSA with each of SHAKE128 and SHAKE256. The same algorithm 225 identifiers can be used for identifying a public key in RSASSA-PSS. 227 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 229 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 230 identified-organization(3) dod(6) internet(1) 231 security(5) mechanisms(5) pkix(7) algorithms(6) 232 TBD1 } 234 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 235 identified-organization(3) dod(6) internet(1) 236 security(5) mechanisms(5) pkix(7) algorithms(6) 237 TBD2 } 239 The new algorithm identifiers of ECDSA signatures using SHAKEs are 240 below. 242 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 243 identified-organization(3) dod(6) internet(1) 244 security(5) mechanisms(5) pkix(7) algorithms(6) 245 TBD3 } 247 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 248 identified-organization(3) dod(6) internet(1) 249 security(5) mechanisms(5) pkix(7) algorithms(6) 250 TBD4 } 252 The parameters for the four identifiers above MUST be absent. That 253 is, the identifier SHALL be a SEQUENCE of one component, the OID. 255 Section 5.1.1 and Section 5.1.2 specify the required output length 256 for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In 257 summary, when hashing messages to be signed, output lengths of 258 SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the 259 SHAKEs are used as mask generation functions RSASSA-PSS, their output 260 length is (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, 261 respectively, where n is the RSA modulus size in bits. 263 5. Use in PKIX 265 5.1. Signatures 267 Signatures are used in a number of different ASN.1 structures. As 268 shown in the ASN.1 representation from [RFC5280] below, in an X.509 269 certificate, a signature is encoded with an algorithm identifier in 270 the signatureAlgorithm attribute and a signatureValue attribute that 271 contains the actual signature. 273 Certificate ::= SEQUENCE { 274 tbsCertificate TBSCertificate, 275 signatureAlgorithm AlgorithmIdentifier, 276 signatureValue BIT STRING } 278 The identifiers defined in Section 4 can be used as the 279 AlgorithmIdentifier in the signatureAlgorithm field in the sequence 280 Certificate and the signature field in the sequence TBSCertificate in 281 X.509 [RFC5280]. The parameters of these signature algorithms are 282 absent as explained in Section 4. 284 Conforming CA implementations MUST specify the algorithms explicitly 285 by using the OIDs specified in Section 4 when encoding RSASSA-PSS or 286 ECDSA with SHAKE signatures in certificates and CRLs. Conforming 287 client implementations that process certificates and CRLs using 288 RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs. 290 Encoding rules for RSASSA-PSS and ECDSA signature values are 291 specified in [RFC4055] and [RFC5480], respectively. 293 When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA 294 curve order SHOULD be chosen in line with the SHAKE output length. 295 Refer to Section 7 for more details. 297 5.1.1. RSASSA-PSS Signatures 299 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 300 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is 301 used, the encoding MUST omit the parameters field. That is, the 302 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 303 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 304 PSS-params that are used to define the algorithms and inputs to the 305 algorithm. This specification does not use parameters because the 306 hash, mask generation algorithm, trailer and salt are embedded in the 307 OID definition. 309 The hash algorithm to hash a message being signed and the hash 310 algorithm used as the mask generation function in RSASSA-PSS MUST be 311 the same: both SHAKE128 or both SHAKE256. The output length of the 312 hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or 313 64 bytes (for SHAKE256). 315 The mask generation function takes an octet string of variable length 316 and a desired output length as input, and outputs an octet string of 317 the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be 318 used natively as the MGF function, instead of the MGF1 algorithm that 319 uses the hash function in multiple iterations as specified in 320 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 321 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 322 SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is 323 the seed from which mask is generated, an octet string [RFC8017]. As 324 explained in Step 9 of section 9.1.1 of [RFC8017], the output length 325 of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 326 length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 327 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, 328 respectively. Thus when SHAKE is used as the MGF, the SHAKE output 329 length maskLen is (8*emLen - 264) or (8*emLen - 520) bits, 330 respectively. For example, when RSA modulus n is 2048, the output 331 length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits 332 when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, 333 respectively. 335 The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 336 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField 337 MUST be 1, which represents the trailer field with hexadecimal value 338 0xBC [RFC8017]. 340 5.1.2. ECDSA Signatures 342 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 343 [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 344 (specified in Section 4) algorithm identifier appears, the respective 345 SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The 346 encoding MUST omit the parameters field. That is, the 347 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 348 ecdsa-with-shake128 or id-ecdsa-with-shake256. 350 For simplicity and compliance with the ECDSA standard specification, 351 the output length of the hash function must be explicitly determined. 352 The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 353 256 or 512 bits, respectively. 355 Conforming CA implementations that generate ECDSA with SHAKE 356 signatures in certificates or CRLs SHOULD generate such signatures 357 with a deterministically generated, non-random k in accordance with 358 all the requirements specified in [RFC6979]. They MAY also generate 359 such signatures in accordance with all other recommendations in 360 [X9.62] or [SEC1] if they have a stated policy that requires 361 conformance to those standards. Those standards have not specified 362 SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 363 and SHAKE256 with output length being 32 and 64 octets, respectively, 364 can be used instead of 256 and 512-bit output hash algorithms such as 365 SHA256 and SHA512. 367 5.2. Public Keys 369 Certificates conforming to [RFC5280] can convey a public key for any 370 public key algorithm. The certificate indicates the public key 371 algorithm through an algorithm identifier. This algorithm identifier 372 is an OID and optionally associated parameters. The conventions and 373 encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers 374 are as specified in Section 2.3.1 and 2.3.5 of [RFC3279], Section 3.1 375 of [RFC4055] and Section 2.1 of [RFC5480]. 377 Traditionally, the rsaEncryption object identifier is used to 378 identify RSA public keys. The rsaEncryption object identifier 379 continues to identify the subject public key when the RSA private key 380 owner does not wish to limit the use of the public key exclusively to 381 RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to 382 limit the use of the public key exclusively to RSASSA-PSS with 383 SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 384 SHOULD be used as the algorithm field in the SubjectPublicKeyInfo 385 sequence [RFC5280]. Conforming client implementations that process 386 RSASSA-PSS with SHAKE public keys when processing certificates and 387 CRLs MUST recognize the corresponding OIDs. 389 Conforming CA implementations MUST specify the X.509 public key 390 algorithm explicitly by using the OIDs specified in Section 4 when 391 encoding ECDSA with SHAKE public keys in certificates and CRLs. 392 Conforming client implementations that process ECDSA with SHAKE 393 public keys when processing certificates and CRLs MUST recognize the 394 corresponding OIDs. 396 The identifier parameters, as explained in Section 4, MUST be absent. 398 6. IANA Considerations 400 One object identifier for the ASN.1 module in Appendix A is requested 401 for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) 402 registry: 404 +---------+--------------------------+--------------------+ 405 | Decimal | Description | References | 406 +---------+--------------------------+--------------------+ 407 | TBD | id-mod-pkix1-shakes-2019 | [EDNOTE: THIS RFC] | 408 +---------+--------------------------+--------------------+ 410 IANA is requested to update the SMI Security for PKIX Algorithms 411 [SMI-PKIX] (1.3.6.1.5.5.7.6) registry with four additional entries: 413 +---------+------------------------+--------------------+ 414 | Decimal | Description | References | 415 +---------+------------------------+--------------------+ 416 | TBD1 | id-RSASSA-PSS-SHAKE128 | [EDNOTE: THIS RFC] | 417 | TBD2 | id-RSASSA-PSS-SHAKE256 | [EDNOTE: THIS RFC] | 418 | TBD3 | id-ecdsa-with-shake128 | [EDNOTE: THIS RFC] | 419 | TBD4 | id-ecdsa-with-shake256 | [EDNOTE: THIS RFC] | 420 +---------+------------------------+--------------------+ 422 IANA is also requested to update the Hash Function Textual Names 423 Registry [Hash-Texts] with two additional entries for SHAKE128 and 424 SHAKE256: 426 +--------------------+-------------------------+--------------------+ 427 | Hash Function Name | OID | Reference | 428 +--------------------+-------------------------+--------------------+ 429 | shake128 | 2.16.840.1.101.3.4.2.11 | [EDNOTE: THIS RFC] | 430 | shake256 | 2.16.840.1.101.3.4.2.12 | [EDNOTE: THIS RFC] | 431 +--------------------+-------------------------+--------------------+ 433 7. Security Considerations 435 This document updates [RFC3279]. The security considerations section 436 of that document applies to this specification as well. 438 NIST has defined appropriate use of the hash functions in terms of 439 the algorithm strengths and expected time frames for secure use in 440 Special Publications (SPs) [SP800-78-4] and [SP800-107]. These 441 documents can be used as guides to choose appropriate key sizes for 442 various security scenarios. 444 SHAKE128 with output length of 256-bits offers 128-bits of collision 445 and 256-bits of preimage resistance. Thus, SHAKE128 OIDs in this 446 specification are RECOMMENDED with 2048 (112-bit security) or 447 3072-bit (128-bit security) RSA modulus or curves with group order of 448 256-bits (128-bit security). SHAKE256 with 512-bits output length 449 offers 256-bits of collision and 512-bits of preimage resistance. 450 Thus, the SHAKE256 OIDs in this specification are RECOMMENDED with 451 4096-bit RSA modulus or higher or curves with group order of 384-bits 452 (256-bit security) or higher. Note that we recommended 4096-bit RSA 453 because we would need 15360-bit modulus for 256-bits of security 454 which is impractical for today's technology. 456 8. Acknowledgements 458 We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for 459 their valuable contributions to this document. 461 The authors would like to thank Russ Housley for his guidance and 462 very valuable contributions with the ASN.1 module. 464 9. References 466 9.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 474 Identifiers for the Internet X.509 Public Key 475 Infrastructure Certificate and Certificate Revocation List 476 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 477 2002, . 479 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 480 Algorithms and Identifiers for RSA Cryptography for use in 481 the Internet X.509 Public Key Infrastructure Certificate 482 and Certificate Revocation List (CRL) Profile", RFC 4055, 483 DOI 10.17487/RFC4055, June 2005, 484 . 486 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 487 Housley, R., and W. Polk, "Internet X.509 Public Key 488 Infrastructure Certificate and Certificate Revocation List 489 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 490 . 492 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 493 "Elliptic Curve Cryptography Subject Public Key 494 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 495 . 497 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 498 "PKCS #1: RSA Cryptography Specifications Version 2.2", 499 RFC 8017, DOI 10.17487/RFC8017, November 2016, 500 . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 [SHA3] National Institute of Standards and Technology (NIST), 507 "SHA-3 Standard - Permutation-Based Hash and Extendable- 508 Output Functions FIPS PUB 202", August 2015, 509 . 512 9.2. Informative References 514 [Hash-Texts] 515 IANA, "Hash Function Textual Names", July 2017, 516 . 519 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 520 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 521 DOI 10.17487/RFC5912, June 2010, 522 . 524 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 525 Algorithm (DSA) and Elliptic Curve Digital Signature 526 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 527 2013, . 529 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 530 Elliptic Curve Cryptography", May 2009, 531 . 533 [SMI-PKIX] 534 IANA, "SMI Security for PKIX Algorithms", March 2019, 535 . 538 [SP800-107] 539 National Institute of Standards and Technology (NIST), 540 "SP800-107: Recommendation for Applications Using Approved 541 Hash Algorithms", May 2014, 542 . 545 [SP800-78-4] 546 National Institute of Standards and Technology (NIST), 547 "SP800-78-4: Cryptographic Algorithms and Key Sizes for 548 Personal Identity Verification", May 2014, 549 . 552 [X9.62] American National Standard for Financial Services (ANSI), 553 "X9.62-2005: Public Key Cryptography for the Financial 554 Services Industry: The Elliptic Curve Digital Signature 555 Standard (ECDSA)", November 2005. 557 Appendix A. ASN.1 module 559 This appendix includes the ASN.1 module for SHAKEs in X.509. This 560 module does not come from any existing RFC. 562 PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) 563 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 564 id-mod-pkix1-shakes-2019(TBD) } 566 DEFINITIONS EXPLICIT TAGS ::= 568 BEGIN 570 -- EXPORTS ALL; 571 IMPORTS 573 -- FROM [RFC5912] 575 PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS 576 FROM AlgorithmInformation-2009 577 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 578 mechanisms(5) pkix(7) id-mod(0) 579 id-mod-algorithmInformation-02(58) } 581 -- FROM [RFC5912] 583 RSAPublicKey, rsaEncryption, pk-rsa, pk-ec, 584 CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value 585 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 586 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 587 id-mod-pkix1-algorithms2008-02(56) } 588 ; 590 -- 591 -- Message Digest Algorithms (mda-) 592 -- 593 DigestAlgorithms DIGEST-ALGORITHM ::= { 594 -- This expands DigestAlgorithms from [RFC5912] 595 mda-shake128 | 596 mda-shake256, 597 ... 598 } 600 -- 601 -- One-Way Hash Functions 602 -- 604 -- SHAKE128 605 mda-shake128 DIGEST-ALGORITHM ::= { 606 IDENTIFIER id-shake128 -- with output length 32 bytes. 607 } 608 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 609 us(840) organization(1) gov(101) 610 csor(3) nistAlgorithm(4) 611 hashAlgs(2) 11 } 613 -- SHAKE256 614 mda-shake256 DIGEST-ALGORITHM ::= { 615 IDENTIFIER id-shake256 -- with output length 64 bytes. 616 } 617 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 618 us(840) organization(1) gov(101) 619 csor(3) nistAlgorithm(4) 620 hashAlgs(2) 12 } 622 -- 623 -- Public Key (pk-) Algorithms 624 -- 625 PublicKeys PUBLIC-KEY ::= { 626 -- This expands PublicKeys from [RFC5912] 627 pk-rsaSSA-PSS-SHAKE128 | 628 pk-rsaSSA-PSS-SHAKE256, 629 ... 630 } 632 -- The hashAlgorithm is mda-shake128 633 -- The maskGenAlgorithm is id-shake128 634 -- Mask Gen Algorithm is SHAKE128 with output length 635 -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 636 -- modulus in bits. 637 -- The saltLength is 32. The trailerField is 1. 638 pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { 639 IDENTIFIER id-RSASSA-PSS-SHAKE128 640 KEY RSAPublicKey 641 PARAMS ARE absent 642 -- Private key format not in this module -- 643 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 644 keyCertSign, cRLSign } 645 } 647 -- The hashAlgorithm is mda-shake256 648 -- The maskGenAlgorithm is id-shake256 649 -- Mask Gen Algorithm is SHAKE256 with output length 650 -- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA 651 -- modulus in bits. 652 -- The saltLength is 64. The trailerField is 1. 653 pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { 654 IDENTIFIER id-RSASSA-PSS-SHAKE256 655 KEY RSAPublicKey 656 PARAMS ARE absent 657 -- Private key format not in this module -- 658 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 659 keyCertSign, cRLSign } 660 } 662 -- 663 -- Signature Algorithms (sa-) 664 -- 665 SignatureAlgs SIGNATURE-ALGORITHM ::= { 666 -- This expands SignatureAlgorithms from [RFC5912] 667 sa-rsassapssWithSHAKE128 | 668 sa-rsassapssWithSHAKE256 | 669 sa-ecdsaWithSHAKE128 | 670 sa-ecdsaWithSHAKE256, 671 ... 672 } 674 -- 675 -- SMIME Capabilities (sa-) 676 -- 677 SMimeCaps SMIME-CAPS ::= { 678 -- The expands SMimeCaps from [RFC5912] 679 sa-rsassapssWithSHAKE128.&smimeCaps | 680 sa-rsassapssWithSHAKE256.&smimeCaps | 681 sa-ecdsaWithSHAKE128.&smimeCaps | 682 sa-ecdsaWithSHAKE256.&smimeCaps, 683 ... 684 } 686 -- RSASSA-PSS with SHAKE128 687 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { 688 IDENTIFIER id-RSASSA-PSS-SHAKE128 689 PARAMS ARE absent 690 -- The hashAlgorithm is mda-shake128 691 -- The maskGenAlgorithm is id-shake128 692 -- Mask Gen Algorithm is SHAKE128 with output length 693 -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 694 -- modulus in bits. 695 -- The saltLength is 32. The trailerField is 1 696 HASHES { mda-shake128 } 697 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } 698 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } 699 } 700 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 701 identified-organization(3) dod(6) internet(1) 702 security(5) mechanisms(5) pkix(7) algorithms(6) 703 TBD1 } 705 -- RSASSA-PSS with SHAKE256 706 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { 707 IDENTIFIER id-RSASSA-PSS-SHAKE256 708 PARAMS ARE absent 709 -- The hashAlgorithm is mda-shake256 710 -- The maskGenAlgorithm is id-shake256 711 -- Mask Gen Algorithm is SHAKE256 with output length 712 -- (8*ceil((n-1)/8) - 520)-bits, where n is the 713 -- RSA modulus in bits. 714 -- The saltLength is 64. The trailerField is 1. 716 HASHES { mda-shake256 } 717 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } 718 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } 719 } 720 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 721 identified-organization(3) dod(6) internet(1) 722 security(5) mechanisms(5) pkix(7) algorithms(6) 723 TBD2 } 725 -- ECDSA with SHAKE128 726 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { 727 IDENTIFIER id-ecdsa-with-shake128 728 VALUE ECDSA-Sig-Value 729 PARAMS ARE absent 730 HASHES { mda-shake128 } 731 PUBLIC-KEYS { pk-ec } 732 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } 733 } 734 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 735 identified-organization(3) dod(6) internet(1) 736 security(5) mechanisms(5) pkix(7) algorithms(6) 737 TBD3 } 739 -- ECDSA with SHAKE256 740 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { 741 IDENTIFIER id-ecdsa-with-shake256 742 VALUE ECDSA-Sig-Value 743 PARAMS ARE absent 744 HASHES { mda-shake256 } 745 PUBLIC-KEYS { pk-ec } 746 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } 747 } 748 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 749 identified-organization(3) dod(6) internet(1) 750 security(5) mechanisms(5) pkix(7) algorithms(6) 751 TBD4 } 753 END 755 Authors' Addresses 757 Panos Kampanakis 758 Cisco Systems 760 Email: pkampana@cisco.com 761 Quynh Dang 762 NIST 763 100 Bureau Drive, Stop 8930 764 Gaithersburg, MD 20899-8930 765 USA 767 Email: quynh.dang@nist.gov