idnits 2.17.1 draft-ietf-lamps-pkix-shake-06.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 (December 18, 2018) is 1953 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 6979 ** Downref: Normative reference to an Informational RFC: RFC 8017 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA3' Summary: 2 errors (**), 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: June 21, 2019 NIST 6 December 18, 2018 8 Internet X.509 Public Key Infrastructure: Additional Algorithm 9 Identifiers for RSASSA-PSS and ECDSA using SHAKEs 10 draft-ietf-lamps-pkix-shake-06 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 June 21, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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. Deterministic ECDSA Signatures . . . . . . . . . . . 7 64 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Change Log 76 [ EDNOTE: Remove this section before publication. ] 78 o draft-ietf-lamps-pkix-shake-06: 80 * Added informative references. 82 * Updated ASN.1 so it compiles. 84 * Updated IANA considerations. 86 o draft-ietf-lamps-pkix-shake-05: 88 * Added RFC8174 reference and text. 90 * Explicitly explained why RSASSA-PSS-params are omitted in 91 section 5.1.1. 93 * Simplified Public Keys section by removing redundand info from 94 RFCs. 96 o draft-ietf-lamps-pkix-shake-04: 98 * Removed paragraph suggesting KMAC to be used in generating k in 99 Deterministric ECDSA. That should be RFC6979-bis. 101 * Removed paragraph from Security Considerations that talks about 102 randomness of k because we are using deterministric ECDSA. 104 * Various ASN.1 fixes. 106 * Text fixes. 108 o draft-ietf-lamps-pkix-shake-03: 110 * Updates based on suggestions and clarifications by Jim. 112 * Added ASN.1. 114 o draft-ietf-lamps-pkix-shake-02: 116 * Significant reorganization of the sections to simplify the 117 introduction, the new OIDs and their use in PKIX. 119 * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, 120 according the WG consensus. 122 * Updated Public Key section to use the new RSASSA-PSS OIDs and 123 clarify the algorithm identifier usage. 125 * Removed the no longer used SHAKE OIDs from section 3.1. 127 * Consolidated subsection for message digest algorithms. 129 * Text fixes. 131 o draft-ietf-lamps-pkix-shake-01: 133 * Changed titles and section names. 135 * Removed DSA after WG discussions. 137 * Updated shake OID names and parameters, added MGF1 section. 139 * Updated RSASSA-PSS section. 141 * Added Public key algorithm OIDs. 143 * Populated Introduction and IANA sections. 145 o draft-ietf-lamps-pkix-shake-00: 147 * Initial version 149 2. Introduction 151 This document describes cryptographic algorithm identifiers for 152 several cryptographic algorithms which use variable length output 153 SHAKE functions introduced in [SHA3] which can be used with the 154 Internet X.509 Certificate and CRL profile [RFC5280]. 156 In the SHA-3 family, two extendable-output functions (SHAKEs), 157 SHAKE128 and SHAKE256, are defined. Four other hash function 158 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also 159 defined but are out of scope for this document. A SHAKE is a 160 variable length hash function. The output length, in bits, of a 161 SHAKE is defined by the d parameter. The corresponding collision and 162 second preimage resistance strengths for SHAKE128 are min(d/2,128) 163 and min(d,128) bits respectively. And, the corresponding collision 164 and second preimage resistance strengths for SHAKE256 are 165 min(d/2,256) and min(d,256) bits respectively. 167 A SHAKE can be used as the message digest function (to hash the 168 message to be signed) in RSASSA-PSS and ECDSA and as the hash in the 169 mask generating function in RSASSA-PSS. This specification describes 170 the identifiers for SHAKEs to be used in X.509 and their meaning. 172 3. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 4. Identifiers 182 This section defines four new OIDs for RSASSA-PSS and ECDSA when 183 SHAKE128 and SHAKE256 are used. The same algorithm identifiers are 184 used for identifying a public key in RSASSA-PSS. 186 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 188 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 190 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 192 [ EDNOTE: "TBD" will be specified by NIST later. ] 194 The new algorithm identifiers of ECDSA signatures using SHAKEs are 195 below. 197 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 198 country(16) us(840) organization(1) gov(101) 199 csor(3) algorithms(4) id-ecdsa-with-shake(3) 200 TBD } 202 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 203 country(16) us(840) organization(1) gov(101) 204 csor(3) algorithms(4) id-ecdsa-with-shake(3) 205 TBD } 207 [ EDNOTE: "TBD" will be specified by NIST later. ] 209 The parameters for the four identifiers above MUST be absent. That 210 is, the identifier SHALL be a SEQUENCE of one component, the OID. 212 Section 5.1.1 and Section 5.1.2 specify the required output length 213 for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In 214 summary, when hashing messages to be signed, output lengths of 215 SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the 216 SHAKEs are used as mask generation functions RSASSA-PSS, their output 217 length is (n - 264) or (n - 520) bits respectively, where n is a RSA 218 modulus size in bits. 220 5. Use in PKIX 222 5.1. Signatures 224 Signatures can be placed in a number of different ASN.1 structures. 225 The top level structure for an X.509 certificate, to illustrate how 226 signatures are frequently encoded with an algorithm identifier and a 227 location for the signature, is 229 Certificate ::= SEQUENCE { 230 tbsCertificate TBSCertificate, 231 signatureAlgorithm AlgorithmIdentifier, 232 signatureValue BIT STRING } 234 The identifiers defined in Section 4 can be used as the 235 AlgorithmIdentifier in the signatureAlgorithm field in the sequence 236 Certificate and the signature field in the sequence tbsCertificate in 237 X.509 [RFC5280]. 239 Conforming CA implementations MUST specify the algorithms explicitly 240 by using the OIDs specified in Section 4 when encoding RSASSA-PSS or 241 ECDSA with SHAKE signatures in certificates and CRLs. Conforming 242 client implementations that process RSASSA-PSS or ECDSA with SHAKE 243 signatures when processing certificates and CRLs MUST recognize the 244 corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA 245 signature values are specified in [RFC4055] and [RFC5480] 246 respectively. 248 5.1.1. RSASSA-PSS Signatures 250 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 251 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is 252 used, the encoding MUST omit the parameters field. That is, the 253 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 254 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 255 PSS-params that are used to define the algorithms and inputs to the 256 algorithm. This specification does not use parameters because the 257 hash and mask generating algorithsm and trailer and salt are embedded 258 in the OID definition. 260 The hash algorithm to hash a message being signed and the hash 261 algorithm as the mask generation function used in RSASSA-PSS MUST be 262 the same, SHAKE128 or SHAKE256 respectively. The output-length of 263 the hash algorithm which hashes the message SHALL be 32 or 64 bytes 264 respectively. 266 The mask generation function takes an octet string of variable length 267 and a desired output length as input, and outputs an octet string of 268 the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be 269 used natively as the MGF function, instead of the MGF1 algorithm that 270 uses the hash function in multiple iterations as specified in 271 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 272 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 273 SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the 274 seed from which mask is generated, an octet string [RFC8017]. The 275 output length is (n - 264)/8 or (n - 520)/8 bytes respectively, where 276 n is the RSA modulus in bits. For example, when RSA modulus n is 277 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 278 223 or 191-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 279 is used respectively. 281 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 282 Finally, the trailerField MUST be 1, which represents the trailer 283 field with hexadecimal value 0xBC [RFC8017]. 285 5.1.2. Deterministic ECDSA Signatures 287 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 288 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 289 (specified in Section 4) algorithm identifier appears, the respective 290 SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The 291 encoding MUST omit the parameters field. That is, the 292 AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- 293 ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256. 295 For simplicity and compliance with the ECDSA standard specification, 296 the output length of the hash function must be explicitly determined. 297 The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 298 256 or 512 bits respectively. 300 Conforming CA implementations that generate ECDSA with SHAKE 301 signatures in certificates or CRLs MUST generate such signatures with 302 a deterministicly generated, non-random k in accordance with all the 303 requirements specified in [RFC6979]. They MAY also generate such 304 signatures in accordance with all other recommendations in [X9.62] or 305 [SEC1] if they have a stated policy that requires conformance to 306 these standards. These standards may have not specified SHAKE128 and 307 SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 308 with output length being 32 and 64 octets respectively are 309 subtitutions for 256 and 512-bit output hash algorithms such as 310 SHA256 and SHA512 used in the standards. 312 5.2. Public Keys 314 Certificates conforming to [RFC5280] can convey a public key for any 315 public key algorithm. The certificate indicates the public key 316 algorithm through an algorithm identifier. This algorithm identifier 317 is an OID and optionally associated parameters. 319 Conforming CA implementations MUST specify the X.509 public key 320 algorithm explicitly by using the OIDs specified in Section 4 when 321 encoding RSASSA-PSS or ECDSA with SHAKE public keys in certificates 322 and CRLs. Conforming client implementations that process RSASSA-PSS 323 or ECDSA with SHAKE public key when processing certificates and CRLs 324 MUST recognize the corresponding OIDs. The conventions and encoding 325 for RSASSA-PSS and ECDSA public keys algorithm identifiers are as 326 specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and 327 Section 2.1 of [RFC5480]. 329 When the RSA private key owner wishes to limit the use of the public 330 key exclusively to RSASSA-PSS, the AlgorithmIdentifiers for RSASSA- 331 PSS defined in Section 4 can be used as the algorithm field in the 332 SubjectPublicKeyInfo sequence [RFC5280]. The identifier parameters, 333 as explained in section Section 4, MUST be absent. The RSASSA-PSS 334 algorithm functions and output lengths are the same as defined in 335 Section 5.1.1. 337 6. IANA Considerations 339 One object identifier for the ASN.1 module in Appendix A was assigned 340 in the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) 341 registry: 343 PKIXAlgsForSHAKE-2018 { iso(1) identified-organization(3) dod(6) 344 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 345 id-mod-pkix1-shake-2018(TBD) } 347 7. Security Considerations 349 The SHAKEs are deterministic functions. Like any other deterministic 350 function, executing multiple times with the same input will produce 351 the same output. Therefore, users should not expect unrelated 352 outputs (with the same or different output lengths) from running a 353 SHAKE function with the same input multiple times. The shorter of 354 any two outputs produced from a SHAKE with the same input is a prefix 355 of the longer one. It is a similar situation as truncating a 512-bit 356 output of SHA-512 by taking its 256 left-most bits. These 256 left- 357 most bits are a prefix of the 512-bit output. 359 Implementations must protect the signer's private key. Compromise of 360 the signer's private key permits masquerade attacks. 362 Implementers should be aware that cryptographic algorithms may become 363 weaker with time. As new cryptanalysis techniques are developed and 364 computing power increases, the work factor or time required to break 365 a particular cryptographic algorithm may decrease. Therefore, 366 cryptographic algorithm implementations should be modular allowing 367 new algorithms to be readily inserted. That is, implementers should 368 be prepared to regularly update the set of algorithms in their 369 implementations. 371 8. Acknowledgements 373 We would like to thank Sean Turner and Jim Schaad for their valuable 374 contributions to this document. 376 The authors would like to thank Russ Housley for his guidance and 377 very valuable contributions with the ASN.1 module. 379 9. References 381 9.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 389 Algorithms and Identifiers for RSA Cryptography for use in 390 the Internet X.509 Public Key Infrastructure Certificate 391 and Certificate Revocation List (CRL) Profile", RFC 4055, 392 DOI 10.17487/RFC4055, June 2005, 393 . 395 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 396 Housley, R., and W. Polk, "Internet X.509 Public Key 397 Infrastructure Certificate and Certificate Revocation List 398 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 399 . 401 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 402 "Elliptic Curve Cryptography Subject Public Key 403 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 404 . 406 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 407 Algorithm (DSA) and Elliptic Curve Digital Signature 408 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 409 2013, . 411 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 412 "PKCS #1: RSA Cryptography Specifications Version 2.2", 413 RFC 8017, DOI 10.17487/RFC8017, November 2016, 414 . 416 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 417 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 418 May 2017, . 420 [SHA3] National Institute of Standards and Technology, "SHA-3 421 Standard - Permutation-Based Hash and Extendable-Output 422 Functions FIPS PUB 202", August 2015, 423 . 426 9.2. Informative References 428 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 429 Identifiers for the Internet X.509 Public Key 430 Infrastructure Certificate and Certificate Revocation List 431 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 432 2002, . 434 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 435 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 436 DOI 10.17487/RFC5912, June 2010, 437 . 439 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 440 Elliptic Curve Cryptography", May 2009, 441 . 443 [X9.62] American National Standard for Financial Services (ANSI), 444 "X9.62-2005 Public Key Cryptography for the Financial 445 Services Industry: The Elliptic Curve Digital Signature 446 Standard (ECDSA)", November 2005. 448 Appendix A. ASN.1 module 450 This appendix includes the ASN.1 module for SHAKEs in X.509. This 451 module does not come from any existing RFC. 453 PKIXAlgsForSHAKE-2018 { iso(1) identified-organization(3) dod(6) 454 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 455 id-mod-pkix1-shake-2018(TBD) } 457 DEFINITIONS EXPLICIT TAGS ::= 459 BEGIN 461 -- EXPORTS ALL; 463 IMPORTS 465 -- FROM [RFC5912] 467 PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS 468 FROM AlgorithmInformation-2009 469 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 470 mechanisms(5) pkix(7) id-mod(0) 471 id-mod-algorithmInformation-02(58) } 473 -- FROM [RFC5912] 474 RSAPublicKey, rsaEncryption, pk-rsa, pk-ec, 475 CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value 476 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 477 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 478 id-mod-pkix1-algorithms2008-02(56) } 479 ; 481 -- 482 -- Message Digest Algorithms (mda-) 483 -- 484 DigestAlgorithms DIGEST-ALGORITHM ::= { 485 -- This expands DigestAlgorithms from [RFC5912] 486 mda-shake128 | 487 mda-shake256, 488 ... 489 } 491 -- 492 -- One-Way Hash Functions 493 -- 495 -- SHAKE128 496 mda-shake128 DIGEST-ALGORITHM ::= { 497 IDENTIFIER id-shake128 -- with output length 32 bytes. 498 } 499 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 500 us(840) organization(1) gov(101) 501 csor(3) nistAlgorithm(4) 502 hashAlgs(2) 11 } 504 -- SHAKE-256 505 mda-shake256 DIGEST-ALGORITHM ::= { 506 IDENTIFIER id-shake256 -- with output length 64 bytes. 507 } 508 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 509 us(840) organization(1) gov(101) 510 csor(3) nistAlgorithm(4) 511 hashAlgs(2) 12 } 513 -- 514 -- Public Key (pk-) Algorithms 515 -- 516 PublicKeys PUBLIC-KEY ::= { 517 -- This expands PublicKeys from [RFC5912] 518 pk-rsaSSA-PSS-SHAKE128 | 519 pk-rsaSSA-PSS-SHAKE256, 520 ... 521 } 522 -- The hashAlgorithm is mda-shake128 523 -- The maskGenAlgorithm is id-shake128 524 -- Mask Gen Algorithm is SHAKE128 with output length 525 -- (n - 264)/8, where n is the RSA modulus in bits. 526 -- the saltLength is 32 527 -- the trailerField is 1 528 pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { 529 IDENTIFIER id-RSASSA-PSS-SHAKE128 530 KEY RSAPublicKey 531 PARAMS TYPE NULL ARE absent 532 -- Private key format not in this module -- 533 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 534 keyCertSign, cRLSign } 535 } 537 -- The hashAlgorithm is mda-shake256 538 -- The maskGenAlgorithm is id-shake256 539 -- Mask Gen Algorithm is SHAKE256 with output length 540 -- (n - 520)/8, where n is the RSA modulus in bits. 541 -- the saltLength is 64 542 -- the trailerField is 1 543 pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { 544 IDENTIFIER id-RSASSA-PSS-SHAKE256 545 KEY RSAPublicKey 546 PARAMS TYPE NULL ARE absent 547 -- Private key format not in this module -- 548 CERT-KEY-USAGE { nonRepudiation, digitalSignature, 549 keyCertSign, cRLSign } 550 } 552 -- 553 -- Signature Algorithms (sa-) 554 -- 555 SignatureAlgs SIGNATURE-ALGORITHM ::= { 556 -- This expands SignatureAlgorithms from [RFC5912] 557 sa-rsassapssWithSHAKE128 | 558 sa-rsassapssWithSHAKE256 | 559 sa-ecdsaWithSHAKE128 | 560 sa-ecdsaWithSHAKE256, 561 ... 562 } 564 -- 565 -- SMIME Capabilities (sa-) 566 -- 567 SMimeCaps SMIME-CAPS ::= { 568 -- The expands SMimeCaps from [RFC5912] 569 sa-rsassapssWithSHAKE128.&smimeCaps | 570 sa-rsassapssWithSHAKE256.&smimeCaps | 571 sa-ecdsaWithSHAKE128.&smimeCaps | 572 sa-ecdsaWithSHAKE256.&smimeCaps, 573 ... 574 } 576 -- RSASSA-PSS with SHAKE128 577 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { 578 IDENTIFIER id-RSASSA-PSS-SHAKE128 579 PARAMS TYPE NULL ARE absent 580 -- The hashAlgorithm is mda-shake128 581 -- The maskGenAlgorithm is id-shake128 582 -- Mask Gen Algorithm is SHAKE128 with output length 583 -- (n - 264)/8, where n is the RSA modulus in bits. 584 -- the saltLength is 32 585 -- the trailerField is 1 586 HASHES { mda-shake128 } 587 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } 588 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } 589 } 590 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 592 -- RSASSA-PSS with SHAKE256 593 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { 594 IDENTIFIER id-RSASSA-PSS-SHAKE256 595 PARAMS TYPE NULL ARE absent 596 -- The hashAlgorithm is mda-shake256 597 -- The maskGenAlgorithm is id-shake256 598 -- Mask Gen Algorithm is SHAKE256 with output length 599 -- (n - 520)/8, where n is the RSA modulus in bits. 600 -- the saltLength is 64 601 -- the trailerField is 1 602 HASHES { mda-shake256 } 603 PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } 604 SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } 605 } 606 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 608 -- Determinstic ECDSA with SHAKE128 609 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { 610 IDENTIFIER id-ecdsa-with-shake128 611 VALUE ECDSA-Sig-Value 612 PARAMS TYPE NULL ARE absent 613 HASHES { mda-shake128 } 614 PUBLIC-KEYS { pk-ec } 615 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } 616 } 617 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 618 country(16) us(840) organization(1) 619 gov(101) csor(3) nistAlgorithm(4) 620 sigAlgs(3) TBD } 622 -- Determinstic ECDSA with SHAKE256 623 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { 624 IDENTIFIER id-ecdsa-with-shake256 625 VALUE ECDSA-Sig-Value 626 PARAMS TYPE NULL ARE absent 627 HASHES { mda-shake256 } 628 PUBLIC-KEYS { pk-ec } 629 SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } 630 } 631 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 632 country(16) us(840) organization(1) 633 gov(101) csor(3) nistAlgorithm(4) 634 sigAlgs(3) TBD } 636 END 638 Authors' Addresses 640 Panos Kampanakis 641 Cisco Systems 643 Email: pkampana@cisco.com 645 Quynh Dang 646 NIST 647 100 Bureau Drive, Stop 8930 648 Gaithersburg, MD 20899-8930 649 USA 651 Email: quynh.dang@nist.gov