idnits 2.17.1 draft-ietf-lamps-pkix-shake-12.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 abstract seems to contain references ([RFC3279]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 30, 2019) is 1762 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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 1, 2020 June 30, 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-12 12 Abstract 14 Digital signatures are used to sign messages, X.509 certificates and 15 CRLs. This document updates [RFC3279] and describes the conventions 16 for using the SHAKE function family in Internet X.509 certificates 17 and CRLs as one-way hash functions with the RSA Probabilistic 18 signature and ECDSA signature algorithms. The conventions for the 19 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 January 1, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 62 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8 63 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 9.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 73 1. Change Log 75 [ EDNOTE: Remove this section before publication. ] 77 o draft-ietf-lamps-pkix-shake-12: 79 * Nits identified by Roman, Eric V. Ben K., Barry L. in ballot 80 position review. 82 o draft-ietf-lamps-pkix-shake-11: 84 * Nits identified by Roman in AD Review. 86 o draft-ietf-lamps-pkix-shake-10: 88 * Updated IANA considerations section to request for OID 89 assignments. 91 o draft-ietf-lamps-pkix-shake-09: 93 * Fixed minor text nits. 95 * Added text name allocation for SHAKEs in IANA considerations. 97 * Updates in Sec Considerations section. 99 o draft-ietf-lamps-pkix-shake-08: 101 * Small nits from Russ while in WGLC. 103 o draft-ietf-lamps-pkix-shake-07: 105 * Incorporated Eric's suggestion from WGLC. 107 o draft-ietf-lamps-pkix-shake-06: 109 * Added informative references. 111 * Updated ASN.1 so it compiles. 113 * Updated IANA considerations. 115 o draft-ietf-lamps-pkix-shake-05: 117 * Added RFC8174 reference and text. 119 * Explicitly explained why RSASSA-PSS-params are omitted in 120 section 5.1.1. 122 * Simplified Public Keys section by removing redundant info from 123 RFCs. 125 o draft-ietf-lamps-pkix-shake-04: 127 * Removed paragraph suggesting KMAC to be used in generating k in 128 Deterministic ECDSA. That should be RFC6979-bis. 130 * Removed paragraph from Security Considerations that talks about 131 randomness of k because we are using deterministic ECDSA. 133 * Various ASN.1 fixes. 135 * Text fixes. 137 o draft-ietf-lamps-pkix-shake-03: 139 * Updates based on suggestions and clarifications by Jim. 141 * Added ASN.1. 143 o draft-ietf-lamps-pkix-shake-02: 145 * Significant reorganization of the sections to simplify the 146 introduction, the new OIDs and their use in PKIX. 148 * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, 149 according the WG consensus. 151 * Updated Public Key section to use the new RSASSA-PSS OIDs and 152 clarify the algorithm identifier usage. 154 * Removed the no longer used SHAKE OIDs from section 3.1. 156 * Consolidated subsection for message digest algorithms. 158 * Text fixes. 160 o draft-ietf-lamps-pkix-shake-01: 162 * Changed titles and section names. 164 * Removed DSA after WG discussions. 166 * Updated shake OID names and parameters, added MGF1 section. 168 * Updated RSASSA-PSS section. 170 * Added Public key algorithm OIDs. 172 * Populated Introduction and IANA sections. 174 o draft-ietf-lamps-pkix-shake-00: 176 * Initial version 178 2. Introduction 180 This document defines cryptographic algorithm identifiers for several 181 cryptographic algorithms that use variable length output SHAKE 182 functions introduced in [SHA3] which can be used with the Internet 183 X.509 Certificate and Certificate Revocation List (CRL) profile 184 [RFC5280]. 186 In the SHA-3 family, two extendable-output functions (SHAKEs), 187 SHAKE128 and SHAKE256, are defined. Four other hash function 188 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also 189 defined but are out of scope for this document. A SHAKE is a 190 variable length hash function defined as SHAKE(M, d) where the output 191 is a d-bits-long digest of message M. The corresponding collision 192 and second-preimage-resistance strengths for SHAKE128 are 193 min(d/2,128) and min(d,128) bits, respectively (Appendix A.1 [SHA3]). 194 And the corresponding collision and second-preimage-resistance 195 strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, 196 respectively. 198 A SHAKE can be used as the message digest function (to hash the 199 message to be signed) in RSASSA-PSS [RFC8017] and ECDSA [X9.62] and 200 as the hash in the mask generation function (MGF) in RSASSA-PSS. 202 3. Terminology 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 4. Identifiers 212 This section defines four new object identifiers (OIDs), for RSASSA- 213 PSS and ECDSA with each of SHAKE128 and SHAKE256. The same algorithm 214 identifiers can be used for identifying a public key in RSASSA-PSS. 216 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 218 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 219 identified-organization(3) dod(6) internet(1) 220 security(5) mechanisms(5) pkix(7) algorithms(6) 221 TBD1 } 223 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 224 identified-organization(3) dod(6) internet(1) 225 security(5) mechanisms(5) pkix(7) algorithms(6) 226 TBD2 } 228 The new algorithm identifiers of ECDSA signatures using SHAKEs are 229 below. 231 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 232 identified-organization(3) dod(6) internet(1) 233 security(5) mechanisms(5) pkix(7) algorithms(6) 234 TBD3 } 236 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 237 identified-organization(3) dod(6) internet(1) 238 security(5) mechanisms(5) pkix(7) algorithms(6) 239 TBD4 } 241 The parameters for the four identifiers above MUST be absent. That 242 is, the identifier SHALL be a SEQUENCE of one component, the OID. 244 Section 5.1.1 and Section 5.1.2 specify the required output length 245 for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In 246 summary, when hashing messages to be signed, output lengths of 247 SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the 248 SHAKEs are used as mask generation functions RSASSA-PSS, their output 249 length is (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, 250 respectively, where n is the RSA modulus size in bits. 252 5. Use in PKIX 254 5.1. Signatures 256 Signatures are used in a number of different ASN.1 structures. As 257 shown in the ASN.1 representation from [RFC5280] below, in an X.509 258 certificate, a signature is encoded with an algorithm identifier in 259 the signatureAlgorithm attribute and a signatureValue attribute that 260 contains the actual signature. 262 Certificate ::= SEQUENCE { 263 tbsCertificate TBSCertificate, 264 signatureAlgorithm AlgorithmIdentifier, 265 signatureValue BIT STRING } 267 The identifiers defined in Section 4 can be used as the 268 AlgorithmIdentifier in the signatureAlgorithm field in the sequence 269 Certificate and the signature field in the sequence TBSCertificate in 270 X.509 [RFC5280]. The parameters of these signature algorithms are 271 absent as explained in Section 4. 273 Conforming CA implementations MUST specify the algorithms explicitly 274 by using the OIDs specified in Section 4 when encoding RSASSA-PSS or 275 ECDSA with SHAKE signatures in certificates and CRLs. Conforming 276 client implementations that process certificates and CRLs using 277 RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs. 279 Encoding rules for RSASSA-PSS and ECDSA signature values are 280 specified in [RFC4055] and [RFC5480], respectively. 282 When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA 283 curve order SHOULD be chosen in line with the SHAKE output length. 284 In the context of this document SHAKE128 OIDs are RECOMMENDED for 285 2048 or 3072-bit RSA modulus or curves with group order of 256-bits. 286 SHAKE256 OIDs are RECOMMENDED for 4096-bit RSA modulus and higher or 287 curves with group order of 384-bits and higher. 289 5.1.1. RSASSA-PSS Signatures 291 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 292 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is 293 used, the encoding MUST omit the parameters field. That is, the 294 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 295 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 296 PSS-params that are used to define the algorithms and inputs to the 297 algorithm. This specification does not use parameters because the 298 hash, mask generation algorithm, trailer and salt are embedded in the 299 OID definition. 301 The hash algorithm to hash a message being signed and the hash 302 algorithm used as the mask generation function in RSASSA-PSS MUST be 303 the same: both SHAKE128 or both SHAKE256. The output length of the 304 hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or 305 64 bytes (for SHAKE256). 307 The mask generation function takes an octet string of variable length 308 and a desired output length as input, and outputs an octet string of 309 the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be 310 used natively as the MGF function, instead of the MGF1 algorithm that 311 uses the hash function in multiple iterations as specified in 312 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 313 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 314 SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is 315 the seed from which mask is generated, an octet string [RFC8017]. As 316 explained in Step 9 of section 9.1.1 of [RFC8017], the output length 317 of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 318 length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 319 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, 320 respectively. Thus when SHAKE is used as the MGF, the SHAKE output 321 length maskLen is (8*emLen - 264) or (8*emLen - 520) bits, 322 respectively. For example, when RSA modulus n is 2048, the output 323 length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits 324 when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, 325 respectively. 327 The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 328 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField 329 MUST be 1, which represents the trailer field with hexadecimal value 330 0xBC [RFC8017]. 332 5.1.2. ECDSA Signatures 334 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 335 [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 336 (specified in Section 4) algorithm identifier appears, the respective 337 SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The 338 encoding MUST omit the parameters field. That is, the 339 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 340 ecdsa-with-shake128 or id-ecdsa-with-shake256. 342 For simplicity and compliance with the ECDSA standard specification, 343 the output length of the hash function must be explicitly determined. 344 The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 345 256 or 512 bits, respectively. 347 Conforming CA implementations that generate ECDSA with SHAKE 348 signatures in certificates or CRLs SHOULD generate such signatures 349 with a deterministically generated, non-random k in accordance with 350 all the requirements specified in [RFC6979]. They MAY also generate 351 such signatures in accordance with all other recommendations in 352 [X9.62] or [SEC1] if they have a stated policy that requires 353 conformance to those standards. Those standards have not specified 354 SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 355 and SHAKE256 with output length being 32 and 64 octets, respectively, 356 can be used instead of 256 and 512-bit output hash algorithms such as 357 SHA256 and SHA512. 359 5.2. Public Keys 361 Certificates conforming to [RFC5280] can convey a public key for any 362 public key algorithm. The certificate indicates the public key 363 algorithm through an algorithm identifier. This algorithm identifier 364 is an OID and optionally associated parameters. The conventions and 365 encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers 366 are as specified in Section 2.3.1 and 2.3.5 of [RFC3279], Section 3.1 367 of [RFC4055] and Section 2.1 of [RFC5480]. 369 Traditionally, the rsaEncryption object identifier is used to 370 identify RSA public keys. The rsaEncryption object identifier 371 continues to identify the subject public key when the RSA private key 372 owner does not wish to limit the use of the public key exclusively to 373 RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to 374 limit the use of the public key exclusively to RSASSA-PSS with 375 SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 376 SHOULD be used as the algorithm field in the SubjectPublicKeyInfo 377 sequence [RFC5280]. Conforming client implementations that process 378 RSASSA-PSS with SHAKE public keys when processing certificates and 379 CRLs MUST recognize the corresponding OIDs. 381 Conforming CA implementations MUST specify the X.509 public key 382 algorithm explicitly by using the OIDs specified in Section 4 when 383 encoding ECDSA with SHAKE public keys in certificates and CRLs. 384 Conforming client implementations that process ECDSA with SHAKE 385 public keys when processing certificates and CRLs MUST recognize the 386 corresponding OIDs. 388 The identifier parameters, as explained in Section 4, MUST be absent. 390 6. IANA Considerations 392 One object identifier for the ASN.1 module in Appendix A is requested 393 for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) 394 registry: 396 +---------+--------------------------+--------------------+ 397 | Decimal | Description | References | 398 +---------+--------------------------+--------------------+ 399 | TBD | id-mod-pkix1-shakes-2019 | [EDNOTE: THIS RFC] | 400 +---------+--------------------------+--------------------+ 402 IANA is requested to update the SMI Security for PKIX Algorithms 403 [SMI-PKIX] (1.3.6.1.5.5.7.6) registry with four additional entries: 405 +---------+------------------------+--------------------+ 406 | Decimal | Description | References | 407 +---------+------------------------+--------------------+ 408 | TBD1 | id-RSASSA-PSS-SHAKE128 | [EDNOTE: THIS RFC] | 409 | TBD2 | id-RSASSA-PSS-SHAKE256 | [EDNOTE: THIS RFC] | 410 | TBD3 | id-ecdsa-with-shake128 | [EDNOTE: THIS RFC] | 411 | TBD4 | id-ecdsa-with-shake256 | [EDNOTE: THIS RFC] | 412 +---------+------------------------+--------------------+ 414 IANA is also requested to update the Hash Function Textual Names 415 Registry [Hash-Texts] with two additional entries for SHAKE128 and 416 SHAKE256: 418 +--------------------+-------------------------+--------------------+ 419 | Hash Function Name | OID | Reference | 420 +--------------------+-------------------------+--------------------+ 421 | shake128 | 2.16.840.1.101.3.4.2.11 | [EDNOTE: THIS RFC] | 422 | shake256 | 2.16.840.1.101.3.4.2.12 | [EDNOTE: THIS RFC] | 423 +--------------------+-------------------------+--------------------+ 425 7. Security Considerations 427 This document updates [RFC3279]. The security considerations section 428 of that document applies to this specification as well. 430 NIST has defined appropriate use of the hash functions in terms of 431 the algorithm strengths and expected time frames for secure use in 432 Special Publications (SPs) [SP800-78-4] and [SP800-107]. These 433 documents can be used as guides to choose appropriate key sizes for 434 various security scenarios. 436 8. Acknowledgements 438 We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for 439 their valuable contributions to this document. 441 The authors would like to thank Russ Housley for his guidance and 442 very valuable contributions with the ASN.1 module. 444 9. References 446 9.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 454 Identifiers for the Internet X.509 Public Key 455 Infrastructure Certificate and Certificate Revocation List 456 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 457 2002, . 459 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 460 Algorithms and Identifiers for RSA Cryptography for use in 461 the Internet X.509 Public Key Infrastructure Certificate 462 and Certificate Revocation List (CRL) Profile", RFC 4055, 463 DOI 10.17487/RFC4055, June 2005, 464 . 466 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 467 Housley, R., and W. Polk, "Internet X.509 Public Key 468 Infrastructure Certificate and Certificate Revocation List 469 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 470 . 472 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 473 "Elliptic Curve Cryptography Subject Public Key 474 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 475 . 477 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 478 "PKCS #1: RSA Cryptography Specifications Version 2.2", 479 RFC 8017, DOI 10.17487/RFC8017, November 2016, 480 . 482 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 483 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 484 May 2017, . 486 [SHA3] National Institute of Standards and Technology (NIST), 487 "SHA-3 Standard - Permutation-Based Hash and Extendable- 488 Output Functions FIPS PUB 202", August 2015, 489 . 492 9.2. Informative References 494 [Hash-Texts] 495 IANA, "Hash Function Textual Names", July 2017, 496 . 499 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 500 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 501 DOI 10.17487/RFC5912, June 2010, 502 . 504 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 505 Algorithm (DSA) and Elliptic Curve Digital Signature 506 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 507 2013, . 509 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 510 Elliptic Curve Cryptography", May 2009, 511 . 513 [SMI-PKIX] 514 IANA, "SMI Security for PKIX Algorithms", March 2019, 515 . 518 [SP800-107] 519 National Institute of Standards and Technology (NIST), 520 "SP800-107: Recommendation for Applications Using Approved 521 Hash Algorithms", May 2014, 522 . 525 [SP800-78-4] 526 National Institute of Standards and Technology (NIST), 527 "SP800-78-4: Cryptographic Algorithms and Key Sizes for 528 Personal Identity Verification", May 2014, 529 . 532 [X9.62] American National Standard for Financial Services (ANSI), 533 "X9.62-2005: Public Key Cryptography for the Financial 534 Services Industry: The Elliptic Curve Digital Signature 535 Standard (ECDSA)", November 2005. 537 Appendix A. ASN.1 module 539 This appendix includes the ASN.1 module for SHAKEs in X.509. This 540 module does not come from any existing RFC. 542 PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) 543 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 544 id-mod-pkix1-shakes-2019(TBD) } 546 DEFINITIONS EXPLICIT TAGS ::= 548 BEGIN 550 -- EXPORTS ALL; 552 IMPORTS 554 -- FROM [RFC5912] 556 PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS 557 FROM AlgorithmInformation-2009 558 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 559 mechanisms(5) pkix(7) id-mod(0) 560 id-mod-algorithmInformation-02(58) } 562 -- FROM [RFC5912] 564 RSAPublicKey, rsaEncryption, pk-rsa, pk-ec, 565 CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value 566 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 567 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 568 id-mod-pkix1-algorithms2008-02(56) } 569 ; 571 -- 572 -- Message Digest Algorithms (mda-) 573 -- 574 DigestAlgorithms DIGEST-ALGORITHM ::= { 575 -- This expands DigestAlgorithms from [RFC5912] 576 mda-shake128 | 577 mda-shake256, 578 ... 579 } 581 -- 582 -- One-Way Hash Functions 583 -- 585 -- SHAKE128 586 mda-shake128 DIGEST-ALGORITHM ::= { 587 IDENTIFIER id-shake128 -- with output length 32 bytes. 588 } 589 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 590 us(840) organization(1) gov(101) 591 csor(3) nistAlgorithm(4) 592 hashAlgs(2) 11 } 594 -- SHAKE256 595 mda-shake256 DIGEST-ALGORITHM ::= { 596 IDENTIFIER id-shake256 -- with output length 64 bytes. 597 } 598 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 599 us(840) organization(1) gov(101) 600 csor(3) nistAlgorithm(4) 601 hashAlgs(2) 12 } 603 -- 604 -- Public Key (pk-) Algorithms 605 -- 606 PublicKeys PUBLIC-KEY ::= { 607 -- This expands PublicKeys from [RFC5912] 608 pk-rsaSSA-PSS-SHAKE128 | 609 pk-rsaSSA-PSS-SHAKE256, 610 ... 611 } 613 -- The hashAlgorithm is mda-shake128 614 -- The maskGenAlgorithm is id-shake128 615 -- Mask Gen Algorithm is SHAKE128 with output length 616 -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 617 -- modulus in bits. 618 -- The saltLength is 32. The trailerField is 1. 619 pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { 620 IDENTIFIER id-RSASSA-PSS-SHAKE128 621 KEY RSAPublicKey 622 PARAMS ARE absent 623 -- Private key format not in this module -- 624 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 625 keyCertSign, cRLSign } 626 } 628 -- The hashAlgorithm is mda-shake256 629 -- The maskGenAlgorithm is id-shake256 630 -- Mask Gen Algorithm is SHAKE256 with output length 631 -- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA 632 -- modulus in bits. 633 -- The saltLength is 64. The trailerField is 1. 634 pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { 635 IDENTIFIER id-RSASSA-PSS-SHAKE256 636 KEY RSAPublicKey 637 PARAMS ARE absent 638 -- Private key format not in this module -- 639 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 640 keyCertSign, cRLSign } 641 } 643 -- 644 -- Signature Algorithms (sa-) 645 -- 646 SignatureAlgs SIGNATURE-ALGORITHM ::= { 647 -- This expands SignatureAlgorithms from [RFC5912] 648 sa-rsassapssWithSHAKE128 | 649 sa-rsassapssWithSHAKE256 | 650 sa-ecdsaWithSHAKE128 | 651 sa-ecdsaWithSHAKE256, 652 ... 653 } 655 -- 656 -- SMIME Capabilities (sa-) 657 -- 658 SMimeCaps SMIME-CAPS ::= { 659 -- The expands SMimeCaps from [RFC5912] 660 sa-rsassapssWithSHAKE128.&smimeCaps | 661 sa-rsassapssWithSHAKE256.&smimeCaps | 662 sa-ecdsaWithSHAKE128.&smimeCaps | 663 sa-ecdsaWithSHAKE256.&smimeCaps, 664 ... 665 } 667 -- RSASSA-PSS with SHAKE128 668 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { 669 IDENTIFIER id-RSASSA-PSS-SHAKE128 670 PARAMS ARE absent 671 -- The hashAlgorithm is mda-shake128 672 -- The maskGenAlgorithm is id-shake128 673 -- Mask Gen Algorithm is SHAKE128 with output length 674 -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 675 -- modulus in bits. 676 -- The saltLength is 32. The trailerField is 1 677 HASHES { mda-shake128 } 678 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } 679 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } 680 } 681 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 682 identified-organization(3) dod(6) internet(1) 683 security(5) mechanisms(5) pkix(7) algorithms(6) 684 TBD1 } 686 -- RSASSA-PSS with SHAKE256 687 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { 688 IDENTIFIER id-RSASSA-PSS-SHAKE256 689 PARAMS ARE absent 690 -- The hashAlgorithm is mda-shake256 691 -- The maskGenAlgorithm is id-shake256 692 -- Mask Gen Algorithm is SHAKE256 with output length 693 -- (8*ceil((n-1)/8) - 520)-bits, where n is the 694 -- RSA modulus in bits. 695 -- The saltLength is 64. The trailerField is 1. 696 HASHES { mda-shake256 } 697 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } 698 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } 699 } 700 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 701 identified-organization(3) dod(6) internet(1) 702 security(5) mechanisms(5) pkix(7) algorithms(6) 703 TBD2 } 705 -- ECDSA with SHAKE128 706 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { 707 IDENTIFIER id-ecdsa-with-shake128 708 VALUE ECDSA-Sig-Value 709 PARAMS ARE absent 710 HASHES { mda-shake128 } 711 PUBLIC-KEYS { pk-ec } 712 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } 713 } 714 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 715 identified-organization(3) dod(6) internet(1) 716 security(5) mechanisms(5) pkix(7) algorithms(6) 717 TBD3 } 719 -- ECDSA with SHAKE256 720 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { 721 IDENTIFIER id-ecdsa-with-shake256 722 VALUE ECDSA-Sig-Value 723 PARAMS ARE absent 724 HASHES { mda-shake256 } 725 PUBLIC-KEYS { pk-ec } 726 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } 727 } 728 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 729 identified-organization(3) dod(6) internet(1) 730 security(5) mechanisms(5) pkix(7) algorithms(6) 731 TBD4 } 733 END 735 Authors' Addresses 737 Panos Kampanakis 738 Cisco Systems 740 Email: pkampana@cisco.com 742 Quynh Dang 743 NIST 744 100 Bureau Drive, Stop 8930 745 Gaithersburg, MD 20899-8930 746 USA 748 Email: quynh.dang@nist.gov