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