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