idnits 2.17.1 draft-ietf-lamps-cms-shakes-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 (January 14, 2019) is 1923 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-185' == Outdated reference: A later version (-02) exists of draft-housley-lamps-cms-sha3-hash-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 Use of the SHAKE One-way Hash Functions in the Cryptographic Message 9 Syntax (CMS) 10 draft-ietf-lamps-cms-shakes-06 12 Abstract 14 This document describes the conventions for using the SHAKE family of 15 hash functions with the Cryptographic Message Syntax (CMS) as one-way 16 hash functions with the RSA Probabilistic signature and ECDSA 17 signature algorithms, as message digests and message authentication 18 codes. The conventions for the associated signer public keys in CMS 19 are also described. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 18, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 63 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 7 64 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.4. Message Authentication Codes . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Change Log 77 [ EDNOTE: Remove this section before publication. ] 79 o draft-ietf-lamps-pkix-shake-06: 81 * Incorporated Eric's suggestion from WGLC. 83 o draft-ietf-lamps-cms-shake-05: 85 * Added informative references. 87 * Updated ASN.1 so it compiles. 89 * Updated IANA considerations. 91 o draft-ietf-lamps-cms-shake-04: 93 * Added RFC8174 reference and text. 95 * Explicitly explained why RSASSA-PSS-params are omitted in 96 section 4.2.1. 98 * Simplified Public Keys section by removing redundand info from 99 RFCs. 101 o draft-ietf-lamps-cms-shake-03: 103 * Removed paragraph suggesting KMAC to be used in generating k in 104 Deterministric ECDSA. That should be RFC6979-bis. 106 * Removed paragraph from Security Considerations that talks about 107 randomness of k because we are using deterministric ECDSA. 109 * Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's 110 feedback. 112 * Text fixes. 114 o draft-ietf-lamps-cms-shake-02: 116 * Updates based on suggestions and clarifications by Jim. 118 * Started ASN.1 module. 120 o draft-ietf-lamps-cms-shake-01: 122 * Significant reorganization of the sections to simplify the 123 introduction, the new OIDs and their use in CMS. 125 * Added new OIDs for RSASSA-PSS that hardcodes hash, salt and 126 MGF, according the WG consensus. 128 * Updated Public Key section to use the new RSASSA-PSS OIDs and 129 clarify the algorithm identifier usage. 131 * Removed the no longer used SHAKE OIDs from section 3.1. 133 o draft-ietf-lamps-cms-shake-00: 135 * Various updates to title and section names. 137 * Content changes filling in text and references. 139 o draft-dang-lamps-cms-shakes-hash-00: 141 * Initial version 143 2. Introduction 145 The Cryptographic Message Syntax (CMS) [RFC5652] is used to digitally 146 sign, digest, authenticate, or encrypt arbitrary message contents. 147 This specification describes the use of the SHAKE128 and SHAKE256 148 specified in [SHA3] as new hash functions in CMS. In addition, it 149 describes the use of these functions with the RSASSA-PSS signature 150 algorithm [RFC8017] and the Elliptic Curve Digital Signature 151 Algorithm (ECDSA) [X9.62] with the CMS signed-data content type. 153 In the SHA-3 family, two extendable-output functions (SHAKEs), 154 SHAKE128 and SHAKE256, are defined. Four other hash function 155 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also 156 defined but are out of scope for this document. A SHAKE is a 157 variable length hash function defined as SHAKE(M, d) where the output 158 is a d-bits long digest of message M. The corresponding collision 159 and second preimage resistance strengths for SHAKE128 are 160 min(d/2,128) and min(d,128) bits respectively. And, the 161 corresponding collision and second preimage resistance strengths for 162 SHAKE256 are min(d/2,256) and min(d,256) bits respectively. 164 A SHAKE can be used in CMS as the message digest function (to hash 165 the message to be signed) in RSASSA-PSS and ECDSA, message 166 authentication code and as the mask generating function in RSASSA- 167 PSS. This specification describes the identifiers for SHAKEs to be 168 used in CMS and their meaning. 170 2.1. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 3. Identifiers 180 This section defines six new OIDs for using SHAKE128 and SHAKE256 in 181 CMS. 183 EDNOTE: If PKIX draft is standardized first maybe we should not say 184 the identifiers are new for the RSASSA-PSS and ECDSA. 186 Two object identifiers for SHAKE128 and SHAKE256 hash functions are 187 defined in [shake-nist-oids] and we include them here for 188 convenience. 190 id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 191 country(16) us(840) organization(1) gov(101) csor(3) 192 nistAlgorithm(4) 2 17 } 194 id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 195 country(16) us(840) organization(1) gov(101) csor(3) 196 nistAlgorithm(4) 2 18 } 198 In this specification, when using the id-shake128-len or id- 199 shake256-len algorithm identifiers, the parameters MUST be absent. 200 That is, the identifier SHALL be a SEQUENCE of one component, the 201 OID. 203 We define two new identifiers for RSASSA-PSS signatures using SHAKEs. 205 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 207 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 209 [ EDNOTE: "TBD" will be specified by NIST later. ] 211 The same RSASSA-PSS algorithm identifiers can be used for identifying 212 public keys and signatures. 214 We define two new algorithm identifiers of ECDSA signatures using 215 SHAKEs. 217 id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 218 country(16) us(840) organization(1) gov(101) csor(3) 219 nistAlgorithm(4) 3 TBD } 221 id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 222 country(16) us(840) organization(1) gov(101) csor(3) 223 nistAlgorithm(4) 3 TBD } 225 [ EDNOTE: "TBD" will be specified by NIST. ] 227 The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be 228 absent. That is, each identifier SHALL be a SEQUENCE of one 229 component, the OID. 231 Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are 232 defined below. 234 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 235 country(16) us(840) organization(1) gov(101) csor(3) 236 nistAlgorithm(4) 2 19 } 238 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 239 country(16) us(840) organization(1) gov(101) csor(3) 240 nistAlgorithm(4) 2 20 } 242 The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST 243 be absent. That is, each identifier SHALL be a SEQUENCE of one 244 component, the OID. 246 Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the 247 required output length for each use of SHAKE128 or SHAKE256 in 248 message digests, RSASSA-PSS, ECDSA and KMAC. 250 4. Use in CMS 252 4.1. Message Digests 254 The id-shake128-len and id-shake256-len OIDs (Section 3) can be used 255 as the digest algorithm identifiers located in the SignedData, 256 SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm 257 fields in CMS [RFC5652]. The encoding MUST omit the parameters field 258 and the output size, d, for the SHAKE128 or SHAKE256 message digest 259 MUST be 256 or 512 bits respectively. 261 The digest values are located in the DigestedData field and the 262 Message Digest authenticated attribute included in the 263 signedAttributes of the SignedData signerInfo. In addition, digest 264 values are input to signature algorithms. The digest algorithm MUST 265 be the same as the message hash algorithms used in signatures. 267 4.2. Signatures 269 In CMS, signature algorithm identifiers are located in the SignerInfo 270 signatureAlgorithm field of SignedData content type and 271 countersignature attribute. Signature values are located in the 272 SignerInfo signature field of SignedData and countersignature. 274 Conforming implementations that process RSASSA-PSS and ECDSA with 275 SHAKE signatures when processing CMS data MUST recognize the 276 corresponding OIDs specified in Section 3. 278 4.2.1. RSASSA-PSS Signatures 280 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 281 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is 282 used, the encoding MUST omit the parameters field. That is, the 283 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 284 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 285 PSS-params that are used to define the algorithms and inputs to the 286 algorithm. This specification does not use parameters because the 287 hash and mask generating algorithsm and trailer and salt are embedded 288 in the OID definition. 290 The hash algorithm to hash a message being signed and the hash and 291 the hash algorithm as the mask generation function used in RSASSA-PSS 292 MUST be the same, SHAKE128 or SHAKE256 respectively. The output- 293 length of the hash algorithm which hashes the message SHALL be 32 or 294 64 bytes respectively. 296 The mask generation function takes an octet string of variable length 297 and a desired output length as input, and outputs an octet string of 298 the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be 299 used natively as the MGF function, instead of the MGF1 algorithm that 300 uses the hash function in multiple iterations as specified in 301 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 302 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 303 SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the 304 seed from which mask is generated, an octet string [RFC8017]. As 305 explained in Step 9 of section 9.1.1 of [RFC8017], the output length 306 of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 307 length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 308 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 309 respectively. Thus when SHAKE is used as the MGF, the SHAKE output 310 length maskLen is (n - 264) or (n - 520) bits respectively. For 311 example, when RSA modulus n is 2048, the output length of SHAKE128 or 312 SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- 313 SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. 315 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 316 Finally, the trailerField MUST be 1, which represents the trailer 317 field with hexadecimal value 0xBC [RFC8017]. 319 4.2.2. ECDSA Signatures 321 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 322 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 323 (specified in Section 3) algorithm identifier appears, the respective 324 SHAKE function is used as the hash. The encoding MUST omit the 325 parameters field. That is, the AlgorithmIdentifier SHALL be a 326 SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id- 327 ecdsa-with-SHAKE256. 329 For simplicity and compliance with the ECDSA standard specification, 330 the output size of the hash function must be explicitly determined. 331 The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 332 256 or 512 bits respectively. 334 It is RECOMMENDED that conforming implementations that generate ECDSA 335 with SHAKE signatures in CMS generate such signatures with a 336 deterministically generated, non-random k in accordance with all the 337 requirements specified in [RFC6979]. They MAY also generate such 338 signatures in accordance with all other recommendations in [X9.62] or 339 [SEC1] if they have a stated policy that requires conformance to 340 these standards. 342 4.3. Public Keys 344 In CMS, the signer's public key algorithm identifiers are located in 345 the OriginatorPublicKey's algorithm attribute. The conventions and 346 encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers 347 are as specified in Section 2.3 of [RFC3279], Section 3.1 of 348 [RFC4055] and Section 2.1 of [RFC5480]. 350 Traditionally, the rsaEncryption object identifier is used to 351 identify RSA public keys. The rsaEncryption object identifier 352 continues to identify the public key when the RSA private key owner 353 does not wish to limit the use of the public key exclusively to 354 RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to 355 limit the use of the public key exclusively to RSASSA-PSS, the 356 AlgorithmIdentifier for RSASSA-PSS defined in Section 3 SHOULD be 357 used as the algorithm attribute in the OriginatorPublicKey sequence. 358 Conforming client implementations that process RSASSA-PSS with SHAKE 359 public keys in CMS message MUST recognize the corresponding OIDs in 360 Section 3. 362 Conforming implementations MUST specify and process the algorithms 363 explicitly by using the OIDs specified in Section 3 when encoding 364 ECDSA with SHAKE public keys in CMS messages. 366 The identifier parameters, as explained in Section 3, MUST be absent. 368 4.4. Message Authentication Codes 370 KMAC message authentication code (KMAC) is specified in [SP800-185]. 371 In CMS, KMAC algorithm identifiers are located in the 372 AuthenticatedData macAlgorithm field. The KMAC values are located in 373 the AuthenticatedData mac field. 375 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm 376 identifier is used as the MAC algorithm identifier, the parameters 377 field is optional (absent or present). If absent, the SHAKE256 378 output length used in KMAC is 256 or 512 bits respectively and the 379 customization string is an empty string by default. 381 Conforming implementations that process KMACs with the SHAKEs when 382 processing CMS data MUST recognize these identifiers. 384 When calculating the KMAC output, the variable N is 0xD2B282C2, S is 385 an empty string, and L, the integer representing the requested output 386 length in bits, is 256 or 512 for KmacWithSHAKE128 or 387 KmacWithSHAKE256 respectively in this specification. 389 5. IANA Considerations 391 One object identifier for the ASN.1 module in Appendix A was assigned 392 in the SMI Security for S/MIME Module Identifiers 393 (1.2.840.113549.1.9.16.0) registry: 395 CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) 396 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 397 id-mod-cms-shakes-2019(TBD) } 399 6. Security Considerations 401 The SHAKEs are deterministic functions. Like any other deterministic 402 function, executing each function with the same input multiple times 403 will produce the same output. Therefore, users should not expect 404 unrelated outputs (with the same or different output lengths) from 405 excuting a SHAKE function with the same input multiple times. The 406 shorter one of any 2 outputs produced from a SHAKE with the same 407 input is a prefix of the longer one. It is a similar situation as 408 truncating a 512-bit output of SHA-512 by taking its 256 left-most 409 bits. These 256 left-most bits are a prefix of the 512-bit output. 411 When more than two parties share the same message-authentication key, 412 data origin authentication is not provided. Any party that knows the 413 message-authentication key can compute a valid MAC, therefore the 414 content could originate from any one of the parties. 416 When using ECDSA with SHAKEs, the ECDSA curve order SHOULD be chosen 417 in line with the SHAKE output length. NIST has defined appropriate 418 use of the hash functions in terms of the algorithm strengths and 419 expected time frames for secure use in Special Publications (SPs) 420 [SP800-78-4] and [SP800-107]. These documents can be used as guides 421 to choose appropriate key sizes for various security scenarios. In 422 the context of this document id-ecdsa-with-shake128 is RECOMMENDED 423 for curves with group order of 256-bits. id-ecdsa-with-shake256 is 424 RECOMMENDED for curves with group order of 384-bits or more. 426 7. Acknowledgements 428 This document is based on Russ Housley's draft 429 [I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions 430 by SHAKE128 and SHAKE256 as the LAMPS WG agreed. 432 The authors would like to thank Russ Housley for his guidance and 433 very valuable contributions with the ASN.1 module. Valuable feedback 434 was also provided by Eric Rescorla. 436 8. References 438 8.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 446 Algorithms and Identifiers for RSA Cryptography for use in 447 the Internet X.509 Public Key Infrastructure Certificate 448 and Certificate Revocation List (CRL) Profile", RFC 4055, 449 DOI 10.17487/RFC4055, June 2005, 450 . 452 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 453 "Elliptic Curve Cryptography Subject Public Key 454 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 455 . 457 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 458 RFC 5652, DOI 10.17487/RFC5652, September 2009, 459 . 461 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 462 "PKCS #1: RSA Cryptography Specifications Version 2.2", 463 RFC 8017, DOI 10.17487/RFC8017, November 2016, 464 . 466 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 467 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 468 May 2017, . 470 [SHA3] National Institute of Standards and Technology, U.S. 471 Department of Commerce, "SHA-3 Standard - Permutation- 472 Based Hash and Extendable-Output Functions", FIPS PUB 202, 473 August 2015. 475 [SP800-185] 476 National Institute of Standards and Technology, "SHA-3 477 Derived Functions: cSHAKE, KMAC, TupleHash and 478 ParallelHash. NIST SP 800-185", December 2016, 479 . 482 8.2. Informative References 484 [I-D.housley-lamps-cms-sha3-hash] 485 Housley, R., "Use of the SHA3 One-way Hash Functions in 486 the Cryptographic Message Syntax (CMS)", draft-housley- 487 lamps-cms-sha3-hash-00 (work in progress), March 2017. 489 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 490 Identifiers for the Internet X.509 Public Key 491 Infrastructure Certificate and Certificate Revocation List 492 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 493 2002, . 495 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 496 Cryptography (ECC) Algorithms in Cryptographic Message 497 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 498 2010, . 500 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 501 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 502 DOI 10.17487/RFC5911, June 2010, 503 . 505 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 506 for the Cryptographic Message Syntax (CMS) and the Public 507 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 508 DOI 10.17487/RFC6268, July 2011, 509 . 511 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 512 Algorithm (DSA) and Elliptic Curve Digital Signature 513 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 514 2013, . 516 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 517 Elliptic Curve Cryptography", May 2009, 518 . 520 [shake-nist-oids] 521 National Institute of Standards and Technology, "Computer 522 Security Objects Register", October 2017, 523 . 526 [SP800-107] 527 National Institute of Standards and Technology (NIST), 528 "SP800-107: Recommendation for Applications Using Approved 529 Hash Algorithms", May 2014, 530 . 533 [SP800-78-4] 534 National Institute of Standards and Technology (NIST), 535 "SP800-78-4: Cryptographic Algorithms and Key Sizes for 536 Personal Identity Verification", May 2014, 537 . 540 [X9.62] American National Standard for Financial Services (ANSI), 541 "X9.62-2005 Public Key Cryptography for the Financial 542 Services Industry: The Elliptic Curve Digital Signature 543 Standard (ECDSA)", November 2005. 545 Appendix A. ASN.1 Module 547 This appendix includes the ASN.1 modules for SHAKEs in CMS. This 548 module includes some ASN.1 from other standards for reference. 550 CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) 551 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 552 id-mod-cms-shakes-2019(TBD) } 554 DEFINITIONS EXPLICIT TAGS ::= 556 BEGIN 558 -- EXPORTS ALL; 560 IMPORTS 562 DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS 563 FROM AlgorithmInformation-2009 564 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 565 mechanisms(5) pkix(7) id-mod(0) 566 id-mod-algorithmInformation-02(58) } 568 RSAPublicKey, rsaEncryption, id-ecPublicKey 569 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 570 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 571 id-mod-pkix1-algorithms2008-02(56) } ; 573 -- 574 -- Message Digest Algorithms (mda-) 575 -- used in SignedData, SignerInfo, DigestedData, 576 -- and the AuthenticatedData digestAlgorithm 577 -- fields in CMS 578 -- 579 MessageDigestAlgs DIGEST-ALGORITHM ::= { 580 -- This expands MessageAuthAlgs from [RFC5652] 581 -- and MessageDigestAlgs in [RFC5753] 582 mda-shake128 | 583 mda-shake256, 584 ... 585 } 587 -- 588 -- One-Way Hash Functions 589 -- SHAKE128 590 mda-shake128 DIGEST-ALGORITHM ::= { 591 IDENTIFIER id-shake128 -- with output length 32 bytes. 592 } 593 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 594 us(840) organization(1) gov(101) 595 csor(3) nistAlgorithm(4) 596 hashAlgs(2) 11 } 598 -- SHAKE-256 599 mda-shake256 DIGEST-ALGORITHM ::= { 600 IDENTIFIER id-shake256 -- with output length 64 bytes. 601 } 602 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 603 us(840) organization(1) gov(101) 604 csor(3) nistAlgorithm(4) 605 hashAlgs(2) 12 } 607 -- 608 -- Public key algorithm identifiers located in the 609 -- OriginatorPublicKey's algorithm attribute in CMS. 610 -- And Signature identifiers used in SignerInfo 611 -- signatureAlgorithm field of SignedData content 612 -- type and countersignature attribute in CMS. 613 -- 614 -- From RFC5280, for reference. 615 -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 616 -- When the rsaEncryption algorithm identifier is used 617 -- for a public key, the AlgorithmIdentifier parameters 618 -- field MUST contain NULL. 619 -- 620 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 621 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 623 -- When the id-RSASSA-PSS-* algorithm identifiers are used 624 -- for a public key or signature in CMS, the AlgorithmIdentifier 625 -- parameters field MUST be absent. The message digest algorithm 626 -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or 627 -- 64 byte outout length respectively. The mask generating 628 -- function MUST be SHAKE128 or SHAKE256 with an output length 629 -- of (n - 264) or (n - 520) bits respectively, where n 630 -- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST 631 -- be 32 or 64 bytes respectively. The trailerField MUST be 1, 632 -- which represents the trailer field with hexadecimal value 633 -- 0xBC. Regardless of id-RSASSA-PSS-* or rsaEncryption being 634 -- used as the AlgorithmIdentifier of the OriginatorPublicKey, 635 -- the RSA public key MUST be encoded using the RSAPublicKey 636 -- type. 637 -- From RFC4055, for reference. 638 -- RSAPublicKey ::= SEQUENCE { 639 -- modulus INTEGER, -- -- n 640 -- publicExponent INTEGER } -- -- e 642 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 643 country(16) us(840) organization(1) 644 gov(101) csor(3) nistAlgorithm(4) 645 sigAlgs(3) TBD } 646 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 647 country(16) us(840) organization(1) 648 gov(101) csor(3) nistAlgorithm(4) 649 sigAlgs(3) TBD } 650 -- When the id-ecdsa-with-shake* algorithm identifiers are 651 -- used in CMS, the AlgorithmIdentifier parameters field 652 -- MUST be absent and the signature algorithm should be 653 -- deterministric ECDSA [RFC6979]. The message digest MUST 654 -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout 655 -- length respectively. In both cases, the ECDSA public key, 656 -- MUST be encoded using the id-ecPublicKey type. 657 -- From RFC5480, for reference. 658 -- id-ecPublicKey OBJECT IDENTIFIER ::= { 659 -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 660 -- The id-ecPublicKey parameters must be absent or present 661 -- and are defined as 662 -- ECParameters ::= CHOICE { 663 -- namedCurve OBJECT IDENTIFIER 664 -- -- -- implicitCurve NULL 665 -- -- -- specifiedCurve SpecifiedECDomain 666 -- } 668 -- 669 -- Message Authentication (maca-) Algorithms 670 -- used in AuthenticatedData macAlgorithm in CMS 671 -- 672 MessageAuthAlgs MAC-ALGORITHM ::= { 673 -- This expands MessageAuthAlgs from [RFC5652] and [RFC6268] 674 maca-KMACwithSHAKE128 | 675 maca-KMACwithSHAKE256, 676 ... 677 } 679 SMimeCaps SMIME-CAPS ::= { 680 -- The expands SMimeCaps from [RFC5911] 681 maca-KMACwithSHAKE128.&smimeCaps | 682 maca-KMACwithSHAKE256.&smimeCaps, 683 ... 684 } 686 -- 687 -- KMAC with SHAKE128 688 maca-KMACwithSHAKE128 MAC-ALGORITHM ::= { 689 IDENTIFIER id-KMACWithSHAKE128 690 PARAMS TYPE KMACwithSHAKE128-params ARE optional 691 -- If KMACwithSHAKE128-params parameters are absent 692 -- the SHAKE128 output length used in KMAC is 256 bits 693 -- and the customization string is an empty string. 694 IS-KEYED-MAC TRUE 695 SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE128} 696 } 697 id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 698 country(16) us(840) organization(1) 699 gov(101) csor(3) nistAlgorithm(4) 700 hashAlgs(2) 19 } 701 KMACwithSHAKE128-params ::= SEQUENCE { 702 kMACOutputLength INTEGER DEFAULT 256, -- Output length in bits 703 customizationString OCTET STRING DEFAULT ''H 704 } 706 -- KMAC with SHAKE256 707 maca-KMACwithSHAKE256 MAC-ALGORITHM ::= { 708 IDENTIFIER id-KMACWithSHAKE256 709 PARAMS TYPE KMACwithSHAKE256-params ARE optional 710 -- If KMACwithSHAKE256-params parameters are absent 711 -- the SHAKE256 output length used in KMAC is 512 bits 712 -- and the customization string is an empty string. 713 IS-KEYED-MAC TRUE 714 SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE256} 715 } 716 id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 717 country(16) us(840) organization(1) 718 gov(101) csor(3) nistAlgorithm(4) 719 hashAlgs(2) 20 } 720 KMACwithSHAKE256-params ::= SEQUENCE { 721 kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits 722 customizationString OCTET STRING DEFAULT ''H 723 } 725 END 727 Authors' Addresses 729 Panos Kampanakis 730 Cisco Systems 732 Email: pkampana@cisco.com 734 Quynh Dang 735 NIST 736 100 Bureau Drive 737 Gaithersburg, MD 20899 739 Email: quynh.Dang@nist.gov