idnits 2.17.1 draft-ietf-lamps-pkix-shake-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2019) is 1912 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS WG P. Kampanakis 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Q. Dang 5 Expires: August 4, 2019 NIST 6 January 31, 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-08 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 August 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 6 63 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 7 64 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Change Log 76 [ EDNOTE: Remove this section before publication. ] 78 o draft-ietf-lamps-pkix-shake-08: 80 * Small nits from Russ while in WGLC. 82 o draft-ietf-lamps-pkix-shake-07: 84 * Incorporated Eric's suggestion from WGLC. 86 o draft-ietf-lamps-pkix-shake-06: 88 * Added informative references. 90 * Updated ASN.1 so it compiles. 92 * Updated IANA considerations. 94 o draft-ietf-lamps-pkix-shake-05: 96 * Added RFC8174 reference and text. 98 * Explicitly explained why RSASSA-PSS-params are omitted in 99 section 5.1.1. 101 * Simplified Public Keys section by removing redundand info from 102 RFCs. 104 o draft-ietf-lamps-pkix-shake-04: 106 * Removed paragraph suggesting KMAC to be used in generating k in 107 Deterministric ECDSA. That should be RFC6979-bis. 109 * Removed paragraph from Security Considerations that talks about 110 randomness of k because we are using deterministric ECDSA. 112 * Various ASN.1 fixes. 114 * Text fixes. 116 o draft-ietf-lamps-pkix-shake-03: 118 * Updates based on suggestions and clarifications by Jim. 120 * Added ASN.1. 122 o draft-ietf-lamps-pkix-shake-02: 124 * Significant reorganization of the sections to simplify the 125 introduction, the new OIDs and their use in PKIX. 127 * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, 128 according the WG consensus. 130 * Updated Public Key section to use the new RSASSA-PSS OIDs and 131 clarify the algorithm identifier usage. 133 * Removed the no longer used SHAKE OIDs from section 3.1. 135 * Consolidated subsection for message digest algorithms. 137 * Text fixes. 139 o draft-ietf-lamps-pkix-shake-01: 141 * Changed titles and section names. 143 * Removed DSA after WG discussions. 145 * Updated shake OID names and parameters, added MGF1 section. 147 * Updated RSASSA-PSS section. 149 * Added Public key algorithm OIDs. 151 * Populated Introduction and IANA sections. 153 o draft-ietf-lamps-pkix-shake-00: 155 * Initial version 157 2. Introduction 159 This document describes cryptographic algorithm identifiers for 160 several cryptographic algorithms which use variable length output 161 SHAKE functions introduced in [SHA3] which can be used with the 162 Internet X.509 Certificate and CRL profile [RFC5280]. 164 In the SHA-3 family, two extendable-output functions (SHAKEs), 165 SHAKE128 and SHAKE256, are defined. Four other hash function 166 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also 167 defined but are out of scope for this document. A SHAKE is a 168 variable length hash function defined as SHAKE(M, d) where the output 169 is a d-bits long digest of message M. The corresponding collision 170 and second preimage resistance strengths for SHAKE128 are 171 min(d/2,128) and min(d,128) bits respectively. And, the 172 corresponding collision and second preimage resistance strengths for 173 SHAKE256 are min(d/2,256) and min(d,256) bits respectively. 175 A SHAKE can be used as the message digest function (to hash the 176 message to be signed) in RSASSA-PSS and ECDSA and as the hash in the 177 mask generating function in RSASSA-PSS. This specification describes 178 the identifiers for SHAKEs to be used in X.509 and their meaning. 180 3. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 4. Identifiers 190 This section defines four new object identifiers (OIDs), for RSASSA- 191 PSS and ECDSA with each of SHAKE-128 and SHAKE-256. The same 192 algorithm identifiers can be used for identifying a public key in 193 RSASSA-PSS. 195 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 197 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 199 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 201 [ EDNOTE: "TBD" will be specified by NIST later. ] 203 The new algorithm identifiers of ECDSA signatures using SHAKEs are 204 below. 206 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 207 country(16) us(840) organization(1) gov(101) 208 csor(3) algorithms(4) id-ecdsa-with-shake(3) 209 TBD } 211 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 212 country(16) us(840) organization(1) gov(101) 213 csor(3) algorithms(4) id-ecdsa-with-shake(3) 214 TBD } 216 [ EDNOTE: "TBD" will be specified by NIST later. ] 218 The parameters for the four identifiers above MUST be absent. That 219 is, the identifier SHALL be a SEQUENCE of one component, the OID. 221 Section 5.1.1 and Section 5.1.2 specify the required output length 222 for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In 223 summary, when hashing messages to be signed, output lengths of 224 SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the 225 SHAKEs are used as mask generation functions RSASSA-PSS, their output 226 length is (n - 264) or (n - 520) bits respectively, where n is the 227 RSA modulus size in bits. 229 5. Use in PKIX 231 5.1. Signatures 233 Signatures are used in a number of different ASN.1 structures. In an 234 X.509 certificate a signature is encoded with an algorithm identifier 235 in the signatureAlgorithm attribute and a signatureValue that 236 contains the actual signature. 238 Certificate ::= SEQUENCE { 239 tbsCertificate TBSCertificate, 240 signatureAlgorithm AlgorithmIdentifier, 241 signatureValue BIT STRING } 243 The identifiers defined in Section 4 can be used as the 244 AlgorithmIdentifier in the signatureAlgorithm field in the sequence 245 Certificate and the signature field in the sequence tbsCertificate in 246 X.509 [RFC5280]. The parameters of these signature algorithms are 247 absent as explained in Section 4. 249 Conforming CA implementations MUST specify the algorithms explicitly 250 by using the OIDs specified in Section 4 when encoding RSASSA-PSS or 251 ECDSA with SHAKE signatures in certificates and CRLs. Conforming 252 client implementations that process RSASSA-PSS or ECDSA with SHAKE 253 signatures when processing certificates and CRLs MUST recognize the 254 corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA 255 signature values are specified in [RFC4055] and [RFC5480] 256 respectively. 258 5.1.1. RSASSA-PSS Signatures 260 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 261 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is 262 used, the encoding MUST omit the parameters field. That is, the 263 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 264 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 265 PSS-params that are used to define the algorithms and inputs to the 266 algorithm. This specification does not use parameters because the 267 hash and mask generating algorithsm and trailer and salt are embedded 268 in the OID definition. 270 The hash algorithm to hash a message being signed and the hash 271 algorithm as the mask generation function used in RSASSA-PSS MUST be 272 the same, SHAKE128 or SHAKE256 respectively. The output-length of 273 the hash algorithm which hashes the message SHALL be 32 or 64 bytes 274 respectively. 276 The mask generation function takes an octet string of variable length 277 and a desired output length as input, and outputs an octet string of 278 the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be 279 used natively as the MGF function, instead of the MGF1 algorithm that 280 uses the hash function in multiple iterations as specified in 281 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 282 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 283 SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the 284 seed from which mask is generated, an octet string [RFC8017]. As 285 explained in Step 9 of section 9.1.1 of [RFC8017], the output length 286 of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 287 length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 288 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 289 respectively. Thus when SHAKE is used as the MGF, the SHAKE output 290 length maskLen is (n - 264) or (n - 520) bits respectively. For 291 example, when RSA modulus n is 2048, the output length of SHAKE128 or 292 SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- 293 SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. 295 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 296 Finally, the trailerField MUST be 1, which represents the trailer 297 field with hexadecimal value 0xBC [RFC8017]. 299 5.1.2. ECDSA Signatures 301 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 302 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 303 (specified in Section 4) algorithm identifier appears, the respective 304 SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The 305 encoding MUST omit the parameters field. That is, the 306 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 307 ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256. 309 For simplicity and compliance with the ECDSA standard specification, 310 the output length of the hash function must be explicitly determined. 311 The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 312 256 or 512 bits respectively. 314 It is RECOMMENDED that conforming CA implementations that generate 315 ECDSA with SHAKE signatures in certificates or CRLs generate such 316 signatures with a deterministically generated, non-random k in 317 accordance with all the requirements specified in [RFC6979]. They 318 MAY also generate such signatures in accordance with all other 319 recommendations in [X9.62] or [SEC1] if they have a stated policy 320 that requires conformance to these standards. These standards may 321 have not specified SHAKE128 and SHAKE256 as hash algorithm options. 322 However, SHAKE128 and SHAKE256 with output length being 32 and 64 323 octets respectively are subtitutions for 256 and 512-bit output hash 324 algorithms such as SHA256 and SHA512 used in the standards. 326 5.2. Public Keys 328 Certificates conforming to [RFC5280] can convey a public key for any 329 public key algorithm. The certificate indicates the public key 330 algorithm through an algorithm identifier. This algorithm identifier 331 is an OID and optionally associated parameters. The conventions and 332 encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers 333 are as specified in Section 2.3 of [RFC3279], Section 3.1 of 334 [RFC4055] and Section 2.1 of [RFC5480]. 336 Traditionally, the rsaEncryption object identifier is used to 337 identify RSA public keys. The rsaEncryption object identifier 338 continues to identify the subject public key when the RSA private key 339 owner does not wish to limit the use of the public key exclusively to 340 RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to 341 limit the use of the public key exclusively to RSASSA-PSS with 342 SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 343 SHOULD be used as the algorithm field in the SubjectPublicKeyInfo 344 sequence [RFC5280]. Conforming client implementations that process 345 RSASSA-PSS with SHAKE public keys when processing certificates and 346 CRLs MUST recognize the corresponding OIDs. 348 Conforming CA implementations MUST specify the X.509 public key 349 algorithm explicitly by using the OIDs specified in Section 4 when 350 encoding ECDSA with SHAKE public keys in certificates and CRLs. 351 Conforming client implementations that process ECDSA with SHAKE 352 public keys when processing certificates and CRLs MUST recognize the 353 corresponding OIDs. 355 The identifier parameters, as explained in section Section 4, MUST be 356 absent. 358 6. IANA Considerations 360 One object identifier for the ASN.1 module in Appendix A was assigned 361 in the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) 362 registry: 364 PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) 365 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 366 id-mod-pkix1-shakes-2019(TBD) } 368 7. Security Considerations 370 The SHAKEs are deterministic functions. Like any other deterministic 371 function, executing multiple times with the same input will produce 372 the same output. Therefore, users should not expect unrelated 373 outputs (with the same or different output lengths) from running a 374 SHAKE function with the same input multiple times. The shorter of 375 any two outputs produced from a SHAKE with the same input is a prefix 376 of the longer one. It is a similar situation as truncating a 512-bit 377 output of SHA-512 by taking its 256 left-most bits. These 256 left- 378 most bits are a prefix of the 512-bit output. 380 When using ECDSA with SHAKEs, the ECDSA curve order SHOULD be chosen 381 in line with the SHAKE output length. NIST has defined appropriate 382 use of the hash functions in terms of the algorithm strengths and 383 expected time frames for secure use in Special Publications (SPs) 384 [SP800-78-4] and [SP800-107]. These documents can be used as guides 385 to choose appropriate key sizes for various security scenarios. In 386 the context of this document id-ecdsa-with-shake128 is RECOMMENDED 387 for curves with group order of 256-bits. id-ecdsa-with-shake256 is 388 RECOMMENDED for curves with group order of 384-bits or more. 390 8. Acknowledgements 392 We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for 393 their valuable contributions to this document. 395 The authors would like to thank Russ Housley for his guidance and 396 very valuable contributions with the ASN.1 module. 398 9. References 400 9.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 408 Algorithms and Identifiers for RSA Cryptography for use in 409 the Internet X.509 Public Key Infrastructure Certificate 410 and Certificate Revocation List (CRL) Profile", RFC 4055, 411 DOI 10.17487/RFC4055, June 2005, 412 . 414 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 415 Housley, R., and W. Polk, "Internet X.509 Public Key 416 Infrastructure Certificate and Certificate Revocation List 417 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 418 . 420 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 421 "Elliptic Curve Cryptography Subject Public Key 422 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 423 . 425 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 426 "PKCS #1: RSA Cryptography Specifications Version 2.2", 427 RFC 8017, DOI 10.17487/RFC8017, November 2016, 428 . 430 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 431 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 432 May 2017, . 434 [SHA3] National Institute of Standards and Technology (NIST), 435 "SHA-3 Standard - Permutation-Based Hash and Extendable- 436 Output Functions FIPS PUB 202", August 2015, 437 . 440 9.2. Informative References 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 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 449 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 450 DOI 10.17487/RFC5912, June 2010, 451 . 453 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 454 Algorithm (DSA) and Elliptic Curve Digital Signature 455 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 456 2013, . 458 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 459 Elliptic Curve Cryptography", May 2009, 460 . 462 [SP800-107] 463 National Institute of Standards and Technology (NIST), 464 "SP800-107: Recommendation for Applications Using Approved 465 Hash Algorithms", May 2014, 466 . 469 [SP800-78-4] 470 National Institute of Standards and Technology (NIST), 471 "SP800-78-4: Cryptographic Algorithms and Key Sizes for 472 Personal Identity Verification", May 2014, 473 . 476 [X9.62] American National Standard for Financial Services (ANSI), 477 "X9.62-2005: Public Key Cryptography for the Financial 478 Services Industry: The Elliptic Curve Digital Signature 479 Standard (ECDSA)", November 2005. 481 Appendix A. ASN.1 module 483 This appendix includes the ASN.1 module for SHAKEs in X.509. This 484 module does not come from any existing RFC. 486 PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) 487 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 488 id-mod-pkix1-shakes-2019(TBD) } 490 DEFINITIONS EXPLICIT TAGS ::= 492 BEGIN 494 -- EXPORTS ALL; 496 IMPORTS 498 -- FROM [RFC5912] 500 PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS 501 FROM AlgorithmInformation-2009 502 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 503 mechanisms(5) pkix(7) id-mod(0) 504 id-mod-algorithmInformation-02(58) } 506 -- FROM [RFC5912] 508 RSAPublicKey, rsaEncryption, pk-rsa, pk-ec, 509 CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value 510 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 511 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 512 id-mod-pkix1-algorithms2008-02(56) } 513 ; 515 -- 516 -- Message Digest Algorithms (mda-) 517 -- 518 DigestAlgorithms DIGEST-ALGORITHM ::= { 519 -- This expands DigestAlgorithms from [RFC5912] 520 mda-shake128 | 521 mda-shake256, 522 ... 523 } 525 -- 526 -- One-Way Hash Functions 527 -- 529 -- SHAKE128 530 mda-shake128 DIGEST-ALGORITHM ::= { 531 IDENTIFIER id-shake128 -- with output length 32 bytes. 532 } 533 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 534 us(840) organization(1) gov(101) 535 csor(3) nistAlgorithm(4) 536 hashAlgs(2) 11 } 538 -- SHAKE-256 539 mda-shake256 DIGEST-ALGORITHM ::= { 540 IDENTIFIER id-shake256 -- with output length 64 bytes. 541 } 542 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 543 us(840) organization(1) gov(101) 544 csor(3) nistAlgorithm(4) 545 hashAlgs(2) 12 } 547 -- 548 -- Public Key (pk-) Algorithms 549 -- 550 PublicKeys PUBLIC-KEY ::= { 551 -- This expands PublicKeys from [RFC5912] 552 pk-rsaSSA-PSS-SHAKE128 | 553 pk-rsaSSA-PSS-SHAKE256, 554 ... 555 } 557 -- The hashAlgorithm is mda-shake128 558 -- The maskGenAlgorithm is id-shake128 559 -- Mask Gen Algorithm is SHAKE128 with output length 560 -- (n - 264) bits, where n is the RSA modulus in bits. 561 -- the saltLength is 32 562 -- the trailerField is 1 563 pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { 564 IDENTIFIER id-RSASSA-PSS-SHAKE128 565 KEY RSAPublicKey 566 PARAMS ARE absent 567 -- Private key format not in this module -- 568 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 569 keyCertSign, cRLSign } 570 } 572 -- The hashAlgorithm is mda-shake256 573 -- The maskGenAlgorithm is id-shake256 574 -- Mask Gen Algorithm is SHAKE256 with output length 575 -- (n - 520)-bits, where n is the RSA modulus in bits. 576 -- the saltLength is 64 577 -- the trailerField is 1 578 pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { 579 IDENTIFIER id-RSASSA-PSS-SHAKE256 580 KEY RSAPublicKey 581 PARAMS ARE absent 582 -- Private key format not in this module -- 583 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 584 keyCertSign, cRLSign } 585 } 587 -- 588 -- Signature Algorithms (sa-) 589 -- 590 SignatureAlgs SIGNATURE-ALGORITHM ::= { 591 -- This expands SignatureAlgorithms from [RFC5912] 592 sa-rsassapssWithSHAKE128 | 593 sa-rsassapssWithSHAKE256 | 594 sa-ecdsaWithSHAKE128 | 595 sa-ecdsaWithSHAKE256, 596 ... 597 } 599 -- 600 -- SMIME Capabilities (sa-) 601 -- 602 SMimeCaps SMIME-CAPS ::= { 603 -- The expands SMimeCaps from [RFC5912] 604 sa-rsassapssWithSHAKE128.&smimeCaps | 605 sa-rsassapssWithSHAKE256.&smimeCaps | 606 sa-ecdsaWithSHAKE128.&smimeCaps | 607 sa-ecdsaWithSHAKE256.&smimeCaps, 608 ... 609 } 611 -- RSASSA-PSS with SHAKE128 612 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { 613 IDENTIFIER id-RSASSA-PSS-SHAKE128 614 PARAMS ARE absent 615 -- The hashAlgorithm is mda-shake128 616 -- The maskGenAlgorithm is id-shake128 617 -- Mask Gen Algorithm is SHAKE128 with output length 618 -- (n - 264) bits, where n is the RSA modulus in bits. 619 -- the saltLength is 32 620 -- the trailerField is 1 621 HASHES { mda-shake128 } 622 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } 623 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } 624 } 625 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 627 -- RSASSA-PSS with SHAKE256 628 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { 629 IDENTIFIER id-RSASSA-PSS-SHAKE256 630 PARAMS ARE absent 631 -- The hashAlgorithm is mda-shake256 632 -- The maskGenAlgorithm is id-shake256 633 -- Mask Gen Algorithm is SHAKE256 with output length 634 -- (n - 520)-bits, where n is the RSA modulus in bits. 635 -- the saltLength is 64 636 -- the trailerField is 1 637 HASHES { mda-shake256 } 638 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } 639 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } 640 } 641 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 643 -- Determinstic ECDSA with SHAKE128 644 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { 645 IDENTIFIER id-ecdsa-with-shake128 646 VALUE ECDSA-Sig-Value 647 PARAMS ARE absent 648 HASHES { mda-shake128 } 649 PUBLIC-KEYS { pk-ec } 650 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } 651 } 652 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 653 country(16) us(840) organization(1) 654 gov(101) csor(3) nistAlgorithm(4) 655 sigAlgs(3) TBD } 657 -- Determinstic ECDSA with SHAKE256 658 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { 659 IDENTIFIER id-ecdsa-with-shake256 660 VALUE ECDSA-Sig-Value 661 PARAMS ARE absent 662 HASHES { mda-shake256 } 663 PUBLIC-KEYS { pk-ec } 664 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } 665 } 666 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 667 country(16) us(840) organization(1) 668 gov(101) csor(3) nistAlgorithm(4) 669 sigAlgs(3) TBD } 671 END 673 Authors' Addresses 675 Panos Kampanakis 676 Cisco Systems 678 Email: pkampana@cisco.com 680 Quynh Dang 681 NIST 682 100 Bureau Drive, Stop 8930 683 Gaithersburg, MD 20899-8930 684 USA 686 Email: quynh.dang@nist.gov