idnits 2.17.1 draft-ietf-lamps-pkix-shake-11.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 mention this, which it should. 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 9, 2019) is 1773 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: December 11, 2019 June 9, 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-11 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 function family in Internet X.509 17 certificates and CRLs as one-way hash functions with the RSA 18 Probabilistic signature and ECDSA signature algorithms. The 19 conventions for the associated subject public keys are also 20 described. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 11, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 63 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 7 64 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Change Log 76 [ EDNOTE: Remove this section before publication. ] 78 o draft-ietf-lamps-pkix-shake-11: 80 * Nits identified by Roman in AD Review. 82 o draft-ietf-lamps-pkix-shake-10: 84 * Updated IANA considerations section to request for OID 85 assignments. 87 o draft-ietf-lamps-pkix-shake-09: 89 * Fixed minor text nits. 91 * Added text name allocation for SHAKEs in IANA considerations. 93 * Updates in Sec Considerations section. 95 o draft-ietf-lamps-pkix-shake-08: 97 * Small nits from Russ while in WGLC. 99 o draft-ietf-lamps-pkix-shake-07: 101 * Incorporated Eric's suggestion from WGLC. 103 o draft-ietf-lamps-pkix-shake-06: 105 * Added informative references. 107 * Updated ASN.1 so it compiles. 109 * Updated IANA considerations. 111 o draft-ietf-lamps-pkix-shake-05: 113 * Added RFC8174 reference and text. 115 * Explicitly explained why RSASSA-PSS-params are omitted in 116 section 5.1.1. 118 * Simplified Public Keys section by removing redundant info from 119 RFCs. 121 o draft-ietf-lamps-pkix-shake-04: 123 * Removed paragraph suggesting KMAC to be used in generating k in 124 Deterministic ECDSA. That should be RFC6979-bis. 126 * Removed paragraph from Security Considerations that talks about 127 randomness of k because we are using deterministic ECDSA. 129 * Various ASN.1 fixes. 131 * Text fixes. 133 o draft-ietf-lamps-pkix-shake-03: 135 * Updates based on suggestions and clarifications by Jim. 137 * Added ASN.1. 139 o draft-ietf-lamps-pkix-shake-02: 141 * Significant reorganization of the sections to simplify the 142 introduction, the new OIDs and their use in PKIX. 144 * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, 145 according the WG consensus. 147 * Updated Public Key section to use the new RSASSA-PSS OIDs and 148 clarify the algorithm identifier usage. 150 * Removed the no longer used SHAKE OIDs from section 3.1. 152 * Consolidated subsection for message digest algorithms. 154 * Text fixes. 156 o draft-ietf-lamps-pkix-shake-01: 158 * Changed titles and section names. 160 * Removed DSA after WG discussions. 162 * Updated shake OID names and parameters, added MGF1 section. 164 * Updated RSASSA-PSS section. 166 * Added Public key algorithm OIDs. 168 * Populated Introduction and IANA sections. 170 o draft-ietf-lamps-pkix-shake-00: 172 * Initial version 174 2. Introduction 176 This document describes cryptographic algorithm identifiers for 177 several cryptographic algorithms which use variable length output 178 SHAKE functions introduced in [SHA3] which can be used with the 179 Internet X.509 Certificate and CRL profile [RFC5280]. 181 In the SHA-3 family, two extendable-output functions (SHAKEs), 182 SHAKE128 and SHAKE256, are defined. Four other hash function 183 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also 184 defined but are out of scope for this document. A SHAKE is a 185 variable length hash function defined as SHAKE(M, d) where the output 186 is a d-bits long digest of message M. The corresponding collision 187 and second preimage resistance strengths for SHAKE128 are 188 min(d/2,128) and min(d,128) bits respectively (Appendix A.1 [SHA3]). 189 And, the corresponding collision and second preimage resistance 190 strengths for SHAKE256 are min(d/2,256) and min(d,256) bits 191 respectively. 193 A SHAKE can be used as the message digest function (to hash the 194 message to be signed) in RSASSA-PSS [RFC8017] and ECDSA [X9.62] and 195 as the hash in the mask generation function (MGF) in RSASSA-PSS. 196 This specification describes the identifiers for SHAKEs to be used in 197 X.509 and their meaning. 199 3. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 4. Identifiers 209 This section defines four new object identifiers (OIDs), for RSASSA- 210 PSS and ECDSA with each of SHAKE128 and SHAKE256. The same algorithm 211 identifiers can be used for identifying a public key in RSASSA-PSS. 213 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 215 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 216 identified-organization(3) dod(6) internet(1) 217 security(5) mechanisms(5) pkix(7) algorithms(6) 218 TBD1 } 220 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 221 identified-organization(3) dod(6) internet(1) 222 security(5) mechanisms(5) pkix(7) algorithms(6) 223 TBD2 } 225 The new algorithm identifiers of ECDSA signatures using SHAKEs are 226 below. 228 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 229 identified-organization(3) dod(6) internet(1) 230 security(5) mechanisms(5) pkix(7) algorithms(6) 231 TBD3 } 233 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 234 identified-organization(3) dod(6) internet(1) 235 security(5) mechanisms(5) pkix(7) algorithms(6) 236 TBD4 } 238 The parameters for the four identifiers above MUST be absent. That 239 is, the identifier SHALL be a SEQUENCE of one component, the OID. 241 Section 5.1.1 and Section 5.1.2 specify the required output length 242 for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In 243 summary, when hashing messages to be signed, output lengths of 244 SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the 245 SHAKEs are used as mask generation functions RSASSA-PSS, their output 246 length is (n - 264) or (n - 520) bits respectively, where n is the 247 RSA modulus size in bits. 249 5. Use in PKIX 251 5.1. Signatures 253 Signatures are used in a number of different ASN.1 structures. As 254 shown in the ASN.1 representation from [RFC5280] below, an X.509 255 certificate a signature is encoded with an algorithm identifier in 256 the signatureAlgorithm attribute and a signatureValue attribute that 257 contains the actual signature. 259 Certificate ::= SEQUENCE { 260 tbsCertificate TBSCertificate, 261 signatureAlgorithm AlgorithmIdentifier, 262 signatureValue BIT STRING } 264 The identifiers defined in Section 4 can be used as the 265 AlgorithmIdentifier in the signatureAlgorithm field in the sequence 266 Certificate and the signature field in the sequence tbsCertificate in 267 X.509 [RFC5280]. The parameters of these signature algorithms are 268 absent as explained in Section 4. 270 Conforming CA implementations MUST specify the algorithms explicitly 271 by using the OIDs specified in Section 4 when encoding RSASSA-PSS or 272 ECDSA with SHAKE signatures in certificates and CRLs. Conforming 273 client implementations that process RSASSA-PSS or ECDSA with SHAKE 274 signatures when processing certificates and CRLs MUST recognize the 275 corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA 276 signature values are specified in [RFC4055] and [RFC5480] 277 respectively. 279 When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA 280 curve order SHOULD be chosen in line with the SHAKE output length. 281 In the context of this document SHAKE128 OIDs are RECOMMENDED for 282 2048 or 3072-bit RSA modulus or curves with group order of 256-bits. 283 SHAKE256 OIDs are RECOMMENDED for 4096-bit RSA modulus and higher or 284 curves with group order of 384-bits and higher. 286 5.1.1. RSASSA-PSS Signatures 288 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 289 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is 290 used, the encoding MUST omit the parameters field. That is, the 291 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 292 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 293 PSS-params that are used to define the algorithms and inputs to the 294 algorithm. This specification does not use parameters because the 295 hash, mask generation algorithm, trailer and salt are embedded in the 296 OID definition. 298 The hash algorithm to hash a message being signed and the hash 299 algorithm as the mask generation function used in RSASSA-PSS MUST be 300 the same, SHAKE128 or SHAKE256 respectively. The output-length of 301 the hash algorithm which hashes the message SHALL be 32 or 64 bytes 302 respectively. 304 The mask generation function takes an octet string of variable length 305 and a desired output length as input, and outputs an octet string of 306 the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be 307 used natively as the MGF function, instead of the MGF1 algorithm that 308 uses the hash function in multiple iterations as specified in 309 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 310 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 311 SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the 312 seed from which mask is generated, an octet string [RFC8017]. As 313 explained in Step 9 of section 9.1.1 of [RFC8017], the output length 314 of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 315 length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 316 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 317 respectively. Thus when SHAKE is used as the MGF, the SHAKE output 318 length maskLen is (n - 264) or (n - 520) bits respectively. For 319 example, when RSA modulus n is 2048, the output length of SHAKE128 or 320 SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- 321 SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. 323 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 324 Finally, the trailerField MUST be 1, which represents the trailer 325 field with hexadecimal value 0xBC [RFC8017]. 327 5.1.2. ECDSA Signatures 329 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 330 [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 331 (specified in Section 4) algorithm identifier appears, the respective 332 SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The 333 encoding MUST omit the parameters field. That is, the 334 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 335 ecdsa-with-shake128 or id-ecdsa-with-shake256. 337 For simplicity and compliance with the ECDSA standard specification, 338 the output length of the hash function must be explicitly determined. 339 The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 340 256 or 512 bits respectively. 342 It is RECOMMENDED that conforming CA implementations that generate 343 ECDSA with SHAKE signatures in certificates or CRLs generate such 344 signatures with a deterministically generated, non-random k in 345 accordance with all the requirements specified in [RFC6979]. They 346 MAY also generate such signatures in accordance with all other 347 recommendations in [X9.62] or [SEC1] if they have a stated policy 348 that requires conformance to these standards. These standards have 349 not specified SHAKE128 and SHAKE256 as hash algorithm options. 350 However, SHAKE128 and SHAKE256 with output length being 32 and 64 351 octets respectively can be used instead of 256 and 512-bit output 352 hash algorithms such as SHA256 and SHA512 used in the standards. 354 5.2. Public Keys 356 Certificates conforming to [RFC5280] can convey a public key for any 357 public key algorithm. The certificate indicates the public key 358 algorithm through an algorithm identifier. This algorithm identifier 359 is an OID and optionally associated parameters. The conventions and 360 encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers 361 are as specified in Section 2.3 of [RFC3279], Section 3.1 of 362 [RFC4055] and Section 2.1 of [RFC5480]. 364 Traditionally, the rsaEncryption object identifier is used to 365 identify RSA public keys. The rsaEncryption object identifier 366 continues to identify the subject public key when the RSA private key 367 owner does not wish to limit the use of the public key exclusively to 368 RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to 369 limit the use of the public key exclusively to RSASSA-PSS with 370 SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 371 SHOULD be used as the algorithm field in the SubjectPublicKeyInfo 372 sequence [RFC5280]. Conforming client implementations that process 373 RSASSA-PSS with SHAKE public keys when processing certificates and 374 CRLs MUST recognize the corresponding OIDs. 376 Conforming CA implementations MUST specify the X.509 public key 377 algorithm explicitly by using the OIDs specified in Section 4 when 378 encoding ECDSA with SHAKE public keys in certificates and CRLs. 379 Conforming client implementations that process ECDSA with SHAKE 380 public keys when processing certificates and CRLs MUST recognize the 381 corresponding OIDs. 383 The identifier parameters, as explained in Section 4, MUST be absent. 385 6. IANA Considerations 387 One object identifier for the ASN.1 module in Appendix A is requested 388 for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) 389 registry: 391 +---------+--------------------------+--------------------+ 392 | Decimal | Description | References | 393 +---------+--------------------------+--------------------+ 394 | TBD | id-mod-pkix1-shakes-2019 | [EDNOTE: THIS RFC] | 395 +---------+--------------------------+--------------------+ 397 IANA is requested to update the SMI Security for PKIX Algorithms 398 [SMI-PKIX] (1.3.6.1.5.5.7.6) registry with four additional entries: 400 +---------+------------------------+--------------------+ 401 | Decimal | Description | References | 402 +---------+------------------------+--------------------+ 403 | TBD1 | id-RSASSA-PSS-SHAKE128 | [EDNOTE: THIS RFC] | 404 | TBD2 | id-RSASSA-PSS-SHAKE256 | [EDNOTE: THIS RFC] | 405 | TBD3 | id-ecdsa-with-shake128 | [EDNOTE: THIS RFC] | 406 | TBD4 | id-ecdsa-with-shake256 | [EDNOTE: THIS RFC] | 407 +---------+------------------------+--------------------+ 409 IANA is also requested to update the Hash Function Textual Names 410 Registry [Hash-Texts] with two additional entries for SHAKE128 and 411 SHAKE256: 413 +--------------------+-------------------------+--------------------+ 414 | Hash Function Name | OID | Reference | 415 +--------------------+-------------------------+--------------------+ 416 | shake128 | 2.16.840.1.101.3.4.2.11 | [EDNOTE: THIS RFC] | 417 | shake256 | 2.16.840.1.101.3.4.2.12 | [EDNOTE: THIS RFC] | 418 +--------------------+-------------------------+--------------------+ 420 7. Security Considerations 422 This document updates [RFC3279]. The security considerations section 423 of that document applies to this specification as well. 425 NIST has defined appropriate use of the hash functions in terms of 426 the algorithm strengths and expected time frames for secure use in 427 Special Publications (SPs) [SP800-78-4] and [SP800-107]. These 428 documents can be used as guides to choose appropriate key sizes for 429 various security scenarios. 431 8. Acknowledgements 433 We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for 434 their valuable contributions to this document. 436 The authors would like to thank Russ Housley for his guidance and 437 very valuable contributions with the ASN.1 module. 439 9. References 441 9.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 449 Identifiers for the Internet X.509 Public Key 450 Infrastructure Certificate and Certificate Revocation List 451 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 452 2002, . 454 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 455 Algorithms and Identifiers for RSA Cryptography for use in 456 the Internet X.509 Public Key Infrastructure Certificate 457 and Certificate Revocation List (CRL) Profile", RFC 4055, 458 DOI 10.17487/RFC4055, June 2005, 459 . 461 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 462 Housley, R., and W. Polk, "Internet X.509 Public Key 463 Infrastructure Certificate and Certificate Revocation List 464 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 465 . 467 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 468 "Elliptic Curve Cryptography Subject Public Key 469 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 470 . 472 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 473 "PKCS #1: RSA Cryptography Specifications Version 2.2", 474 RFC 8017, DOI 10.17487/RFC8017, November 2016, 475 . 477 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 478 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 479 May 2017, . 481 [SHA3] National Institute of Standards and Technology (NIST), 482 "SHA-3 Standard - Permutation-Based Hash and Extendable- 483 Output Functions FIPS PUB 202", August 2015, 484 . 487 9.2. Informative References 489 [Hash-Texts] 490 IANA, "Hash Function Textual Names", July 2017, 491 . 494 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 495 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 496 DOI 10.17487/RFC5912, June 2010, 497 . 499 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 500 Algorithm (DSA) and Elliptic Curve Digital Signature 501 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 502 2013, . 504 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 505 Elliptic Curve Cryptography", May 2009, 506 . 508 [SMI-PKIX] 509 IANA, "SMI Security for PKIX Algorithms", March 2019, 510 . 513 [SP800-107] 514 National Institute of Standards and Technology (NIST), 515 "SP800-107: Recommendation for Applications Using Approved 516 Hash Algorithms", May 2014, 517 . 520 [SP800-78-4] 521 National Institute of Standards and Technology (NIST), 522 "SP800-78-4: Cryptographic Algorithms and Key Sizes for 523 Personal Identity Verification", May 2014, 524 . 527 [X9.62] American National Standard for Financial Services (ANSI), 528 "X9.62-2005: Public Key Cryptography for the Financial 529 Services Industry: The Elliptic Curve Digital Signature 530 Standard (ECDSA)", November 2005. 532 Appendix A. ASN.1 module 534 This appendix includes the ASN.1 module for SHAKEs in X.509. This 535 module does not come from any existing RFC. 537 PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) 538 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 539 id-mod-pkix1-shakes-2019(TBD) } 541 DEFINITIONS EXPLICIT TAGS ::= 543 BEGIN 545 -- EXPORTS ALL; 547 IMPORTS 549 -- FROM [RFC5912] 551 PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS 552 FROM AlgorithmInformation-2009 553 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 554 mechanisms(5) pkix(7) id-mod(0) 555 id-mod-algorithmInformation-02(58) } 557 -- FROM [RFC5912] 559 RSAPublicKey, rsaEncryption, pk-rsa, pk-ec, 560 CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value 561 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 562 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 563 id-mod-pkix1-algorithms2008-02(56) } 564 ; 566 -- 567 -- Message Digest Algorithms (mda-) 568 -- 569 DigestAlgorithms DIGEST-ALGORITHM ::= { 570 -- This expands DigestAlgorithms from [RFC5912] 571 mda-shake128 | 572 mda-shake256, 573 ... 574 } 576 -- 577 -- One-Way Hash Functions 578 -- 580 -- SHAKE128 581 mda-shake128 DIGEST-ALGORITHM ::= { 582 IDENTIFIER id-shake128 -- with output length 32 bytes. 583 } 584 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 585 us(840) organization(1) gov(101) 586 csor(3) nistAlgorithm(4) 587 hashAlgs(2) 11 } 589 -- SHAKE256 590 mda-shake256 DIGEST-ALGORITHM ::= { 591 IDENTIFIER id-shake256 -- with output length 64 bytes. 592 } 593 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 594 us(840) organization(1) gov(101) 595 csor(3) nistAlgorithm(4) 596 hashAlgs(2) 12 } 598 -- 599 -- Public Key (pk-) Algorithms 600 -- 601 PublicKeys PUBLIC-KEY ::= { 602 -- This expands PublicKeys from [RFC5912] 603 pk-rsaSSA-PSS-SHAKE128 | 604 pk-rsaSSA-PSS-SHAKE256, 605 ... 606 } 608 -- The hashAlgorithm is mda-shake128 609 -- The maskGenAlgorithm is id-shake128 610 -- Mask Gen Algorithm is SHAKE128 with output length 611 -- (n - 264) bits, where n is the RSA modulus in bits. 612 -- the saltLength is 32 613 -- the trailerField is 1 614 pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { 615 IDENTIFIER id-RSASSA-PSS-SHAKE128 616 KEY RSAPublicKey 617 PARAMS ARE absent 618 -- Private key format not in this module -- 619 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 620 keyCertSign, cRLSign } 621 } 623 -- The hashAlgorithm is mda-shake256 624 -- The maskGenAlgorithm is id-shake256 625 -- Mask Gen Algorithm is SHAKE256 with output length 626 -- (n - 520)-bits, where n is the RSA modulus in bits. 627 -- the saltLength is 64 628 -- the trailerField is 1 629 pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { 630 IDENTIFIER id-RSASSA-PSS-SHAKE256 631 KEY RSAPublicKey 632 PARAMS ARE absent 633 -- Private key format not in this module -- 634 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 635 keyCertSign, cRLSign } 636 } 638 -- 639 -- Signature Algorithms (sa-) 640 -- 641 SignatureAlgs SIGNATURE-ALGORITHM ::= { 642 -- This expands SignatureAlgorithms from [RFC5912] 643 sa-rsassapssWithSHAKE128 | 644 sa-rsassapssWithSHAKE256 | 645 sa-ecdsaWithSHAKE128 | 646 sa-ecdsaWithSHAKE256, 647 ... 648 } 650 -- 651 -- SMIME Capabilities (sa-) 652 -- 653 SMimeCaps SMIME-CAPS ::= { 654 -- The expands SMimeCaps from [RFC5912] 655 sa-rsassapssWithSHAKE128.&smimeCaps | 656 sa-rsassapssWithSHAKE256.&smimeCaps | 657 sa-ecdsaWithSHAKE128.&smimeCaps | 658 sa-ecdsaWithSHAKE256.&smimeCaps, 659 ... 660 } 662 -- RSASSA-PSS with SHAKE128 663 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { 664 IDENTIFIER id-RSASSA-PSS-SHAKE128 665 PARAMS ARE absent 666 -- The hashAlgorithm is mda-shake128 667 -- The maskGenAlgorithm is id-shake128 668 -- Mask Gen Algorithm is SHAKE128 with output length 669 -- (n - 264) bits, where n is the RSA modulus in bits. 670 -- the saltLength is 32 671 -- the trailerField is 1 672 HASHES { mda-shake128 } 673 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } 674 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } 675 } 676 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 677 identified-organization(3) dod(6) internet(1) 678 security(5) mechanisms(5) pkix(7) algorithms(6) 679 TBD1 } 681 -- RSASSA-PSS with SHAKE256 682 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { 683 IDENTIFIER id-RSASSA-PSS-SHAKE256 684 PARAMS ARE absent 685 -- The hashAlgorithm is mda-shake256 686 -- The maskGenAlgorithm is id-shake256 687 -- Mask Gen Algorithm is SHAKE256 with output length 688 -- (n - 520)-bits, where n is the RSA modulus in bits. 689 -- the saltLength is 64 690 -- the trailerField is 1 691 HASHES { mda-shake256 } 692 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } 693 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } 694 } 695 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 696 identified-organization(3) dod(6) internet(1) 697 security(5) mechanisms(5) pkix(7) algorithms(6) 698 TBD2 } 700 -- Deterministic ECDSA with SHAKE128 701 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { 702 IDENTIFIER id-ecdsa-with-shake128 703 VALUE ECDSA-Sig-Value 704 PARAMS ARE absent 705 HASHES { mda-shake128 } 706 PUBLIC-KEYS { pk-ec } 707 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } 708 } 709 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 710 identified-organization(3) dod(6) internet(1) 711 security(5) mechanisms(5) pkix(7) algorithms(6) 712 TBD3 } 714 -- Deterministic ECDSA with SHAKE256 715 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { 716 IDENTIFIER id-ecdsa-with-shake256 717 VALUE ECDSA-Sig-Value 718 PARAMS ARE absent 719 HASHES { mda-shake256 } 720 PUBLIC-KEYS { pk-ec } 721 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } 722 } 723 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 724 identified-organization(3) dod(6) internet(1) 725 security(5) mechanisms(5) pkix(7) algorithms(6) 726 TBD4 } 728 END 730 Authors' Addresses 732 Panos Kampanakis 733 Cisco Systems 735 Email: pkampana@cisco.com 737 Quynh Dang 738 NIST 739 100 Bureau Drive, Stop 8930 740 Gaithersburg, MD 20899-8930 741 USA 743 Email: quynh.dang@nist.gov