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