idnits 2.17.1 draft-ietf-lamps-cms-shakes-15.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3370, but the abstract doesn't seem to directly say this. It does mention RFC3370 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3370, updated by this document, for RFC5378 checks: 2001-04-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 21, 2019) is 1741 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 == Outdated reference: A later version (-15) exists of draft-ietf-lamps-pkix-shake-12 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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 Updates: 3370 (if approved) Q. Dang 5 Intended status: Standards Track NIST 6 Expires: January 22, 2020 July 21, 2019 8 Use of the SHAKE One-way Hash Functions in the Cryptographic Message 9 Syntax (CMS) 10 draft-ietf-lamps-cms-shakes-15 12 Abstract 14 This document updates the "Cryptographic Message Syntax Algorithms" 15 (RFC3370) and describes the conventions for using the SHAKE family of 16 hash functions in the Cryptographic Message Syntax as one-way hash 17 functions with the RSA Probabilistic signature and ECDSA signature 18 algorithms. The conventions for the associated signer public keys in 19 CMS 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 January 22, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 8 63 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 9 64 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.4. Message Authentication Codes . . . . . . . . . . . . . . 10 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Change Log 77 [ EDNOTE: Remove this section before publication. ] 79 o draft-ietf-lamps-cms-shake-15: 81 * Minor editorial nits. 83 o draft-ietf-lamps-cms-shake-14: 85 * Fixing error with incorrect preimage resistance bits for SHA128 86 and SHA256. 88 o draft-ietf-lamps-cms-shake-13: 90 * Addressing comments from Dan M.'s secdir review. 92 * Addressing comment from Scott B.'s opsdir review about 93 references in the abstract. 95 o draft-ietf-lamps-cms-shake-12: 97 * Nits identified by Roman, Barry L. in ballot position review. 99 o draft-ietf-lamps-cms-shake-11: 101 * Minor nits. 103 * Nits identified by Roman in AD Review. 105 o draft-ietf-lamps-cms-shake-10: 107 * Updated IANA considerations section to request for OID 108 assignments. 110 o draft-ietf-lamps-cms-shake-09: 112 * Fixed minor text nit. 114 * Updates in Sec Considerations section. 116 o draft-ietf-lamps-cms-shake-08: 118 * id-shake128-len and id-shake256-len were replaced with id- 119 sha128 with 32 bytes output length and id-shake256 with 64 120 bytes output length. 122 * Fixed a discrepancy between section 3 and 4.4 about the KMAC 123 OIDs that have parameters as optional. 125 o draft-ietf-lamps-cms-shake-07: 127 * Small nit from Russ while in WGLC. 129 o draft-ietf-lamps-cms-shake-06: 131 * Incorporated Eric's suggestion from WGLC. 133 o draft-ietf-lamps-cms-shake-05: 135 * Added informative references. 137 * Updated ASN.1 so it compiles. 139 * Updated IANA considerations. 141 o draft-ietf-lamps-cms-shake-04: 143 * Added RFC8174 reference and text. 145 * Explicitly explained why RSASSA-PSS-params are omitted in 146 section 4.2.1. 148 * Simplified Public Keys section by removing redundant info from 149 RFCs. 151 o draft-ietf-lamps-cms-shake-03: 153 * Removed paragraph suggesting KMAC to be used in generating k in 154 Deterministic ECDSA. That should be RFC6979-bis. 156 * Removed paragraph from Security Considerations that talks about 157 randomness of k because we are using deterministic ECDSA. 159 * Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's 160 feedback. 162 * Text fixes. 164 o draft-ietf-lamps-cms-shake-02: 166 * Updates based on suggestions and clarifications by Jim. 168 * Started ASN.1 module. 170 o draft-ietf-lamps-cms-shake-01: 172 * Significant reorganization of the sections to simplify the 173 introduction, the new OIDs and their use in CMS. 175 * Added new OIDs for RSASSA-PSS that hardcodes hash, salt and 176 MGF, according the WG consensus. 178 * Updated Public Key section to use the new RSASSA-PSS OIDs and 179 clarify the algorithm identifier usage. 181 * Removed the no longer used SHAKE OIDs from section 3.1. 183 o draft-ietf-lamps-cms-shake-00: 185 * Various updates to title and section names. 187 * Content changes filling in text and references. 189 o draft-dang-lamps-cms-shakes-hash-00: 191 * Initial version 193 2. Introduction 195 The "Cryptographic Message Syntax (CMS)" [RFC5652] is used to 196 digitally sign, digest, authenticate, or encrypt arbitrary message 197 contents. "Cryptographic Message Syntax (CMS) Algorithms" [RFC3370] 198 defines the use of common cryptographic algorithms with CMS. This 199 specification updates RFC3370 and describes the use of the SHAKE128 200 and SHAKE256 specified in [SHA3] as new hash functions in CMS. In 201 addition, it describes the use of these functions with the RSASSA-PSS 202 signature algorithm [RFC8017] and the Elliptic Curve Digital 203 Signature Algorithm (ECDSA) [X9.62] with the CMS signed-data content 204 type. 206 In the SHA-3 family, two extendable-output functions (SHAKEs), 207 SHAKE128 and SHAKE256, are defined. Four other hash function 208 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also 209 defined but are out of scope for this document. A SHAKE is a 210 variable length hash function defined as SHAKE(M, d) where the output 211 is a d-bits-long digest of message M. The corresponding collision 212 and second-preimage-resistance strengths for SHAKE128 are 213 min(d/2,128) and min(d,128) bits, respectively (Appendix A.1 [SHA3]). 214 And the corresponding collision and second-preimage-resistance 215 strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, 216 respectively. In this specification we use d=256 (for SHAKE128) and 217 d=512 (for SHAKE256). 219 A SHAKE can be used in CMS as the message digest function (to hash 220 the message to be signed) in RSASSA-PSS and ECDSA, message 221 authentication code and as the mask generation function (MGF) in 222 RSASSA-PSS. This specification describes the identifiers for SHAKEs 223 to be used in CMS and their meaning. 225 2.1. Terminology 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in BCP 230 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 3. Identifiers 235 This section identifies eight new object identifiers (OIDs) for using 236 SHAKE128 and SHAKE256 in CMS. 238 Two object identifiers for SHAKE128 and SHAKE256 hash functions are 239 defined in [shake-nist-oids] and we include them here for 240 convenience. 242 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 243 country(16) us(840) organization(1) gov(101) csor(3) 244 nistAlgorithm(4) 2 11 } 246 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 247 country(16) us(840) organization(1) gov(101) csor(3) 248 nistAlgorithm(4) 2 12 } 250 In this specification, when using the id-shake128 or id-shake256 251 algorithm identifiers, the parameters MUST be absent. That is, the 252 identifier SHALL be a SEQUENCE of one component, the OID. 254 [I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC 255 when it is ready ] defines two identifiers for RSASSA-PSS signatures 256 using SHAKEs which we include here for convenience. 258 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 259 identified-organization(3) dod(6) internet(1) 260 security(5) mechanisms(5) pkix(7) algorithms(6) 261 TBD1 } 263 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 264 identified-organization(3) dod(6) internet(1) 265 security(5) mechanisms(5) pkix(7) algorithms(6) 266 TBD2 } 268 The same RSASSA-PSS algorithm identifiers can be used for identifying 269 public keys and signatures. 271 [I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC 272 when it is ready ] also defines two algorithm identifiers of ECDSA 273 signatures using SHAKEs which we include here for convenience. 275 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 276 identified-organization(3) dod(6) internet(1) 277 security(5) mechanisms(5) pkix(7) algorithms(6) 278 TBD3 } 280 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 281 identified-organization(3) dod(6) internet(1) 282 security(5) mechanisms(5) pkix(7) algorithms(6) 283 TBD4 } 285 The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be 286 absent. That is, each identifier SHALL be a SEQUENCE of one 287 component, the OID. 289 Two object identifiers for KMACs using SHAKE128 and SHAKE256 as 290 defined in by the National Institute of Standards and Technology 291 (NIST) in [shake-nist-oids] and we include them here for convenience. 293 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 294 country(16) us(840) organization(1) gov(101) csor(3) 295 nistAlgorithm(4) 2 19 } 297 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 298 country(16) us(840) organization(1) gov(101) csor(3) 299 nistAlgorithm(4) 2 20 } 301 The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 are 302 OPTIONAL. 304 Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the 305 required output length for each use of SHAKE128 or SHAKE256 in 306 message digests, RSASSA-PSS, ECDSA and KMAC. 308 4. Use in CMS 310 4.1. Message Digests 312 The id-shake128 and id-shake256 OIDs (Section 3) can be used as the 313 digest algorithm identifiers located in the SignedData, SignerInfo, 314 DigestedData, and the AuthenticatedData digestAlgorithm fields in CMS 315 [RFC5652]. The OID encoding MUST omit the parameters field and the 316 output length of SHA256 or SHAKE256 as the message digest MUST be 256 317 or 512 bits, respectively. 319 The digest values are located in the DigestedData field and the 320 Message Digest authenticated attribute included in the 321 signedAttributes of the SignedData signerInfo. In addition, digest 322 values are input to signature algorithms. The digest algorithm MUST 323 be the same as the message hash algorithms used in signatures. 325 4.2. Signatures 327 In CMS, signature algorithm identifiers are located in the SignerInfo 328 signatureAlgorithm field of SignedData content type and 329 countersignature attribute. Signature values are located in the 330 SignerInfo signature field of SignedData content type and 331 countersignature attribute. 333 Conforming implementations that process RSASSA-PSS and ECDSA with 334 SHAKE signatures when processing CMS data MUST recognize the 335 corresponding OIDs specified in Section 3. 337 When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus or ECDSA 338 curve order SHOULD be chosen in line with the SHAKE output length. 339 Refer to Section 6 for more details. 341 4.2.1. RSASSA-PSS Signatures 343 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 344 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is 345 used, the encoding MUST omit the parameters field. That is, the 346 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 347 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 348 PSS-params that are used to define the algorithms and inputs to the 349 algorithm. This specification does not use parameters because the 350 hash, mask generation algorithm, trailer and salt are embedded in the 351 OID definition. 353 The hash algorithm to hash a message being signed and the hash 354 algorithm as the mask generation function used in RSASSA-PSS MUST be 355 the same: both SHAKE128 or both SHAKE256. The output length of the 356 hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or 357 64 bytes (for SHAKE256). 359 The mask generation function takes an octet string of variable length 360 and a desired output length as input, and outputs an octet string of 361 the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be 362 used natively as the MGF function, instead of the MGF1 algorithm that 363 uses the hash function in multiple iterations as specified in 364 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 365 the SHAKE128 or SHAKE256 with input being the mgfSeed for id-RSASSA- 366 PSS- SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed 367 is the seed from which mask is generated, an octet string [RFC8017]. 368 As explained in Step 9 of section 9.1.1 of [RFC8017], the output 369 length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum 370 message length ceil((n-1)/8), where n is the RSA modulus in bits. 371 hLen is 32 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS- 372 SHAKE256, respectively. Thus when SHAKE is used as the MGF, the 373 SHAKE output length maskLen is (8*emLen - 264) or (8*emLen - 520) 374 bits, respectively. For example, when RSA modulus n is 2048, the 375 output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 376 1528-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is 377 used, respectively. 379 The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 380 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField 381 MUST be 1, which represents the trailer field with hexadecimal value 382 0xBC [RFC8017]. 384 4.2.2. ECDSA Signatures 386 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 387 [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 388 (specified in Section 3) algorithm identifier appears, the respective 389 SHAKE function is used as the hash. The encoding MUST omit the 390 parameters field. That is, the AlgorithmIdentifier SHALL be a 391 SEQUENCE of one component, the OID id-ecdsa-with-shake128 or id- 392 ecdsa-with-shake256. 394 For simplicity and compliance with the ECDSA standard specification, 395 the output length of the hash function must be explicitly determined. 396 The output length for SHAKE128 or SHAKE256 used in ECDSA MUST be 256 397 or 512 bits, respectively. 399 Conforming CA implementations that generate ECDSA with SHAKE 400 signatures in certificates or CRLs SHOULD generate such signatures 401 with a deterministically generated, non-random k in accordance with 402 all the requirements specified in [RFC6979]. They MAY also generate 403 such signatures in accordance with all other recommendations in 404 [X9.62] or [SEC1] if they have a stated policy that requires 405 conformance to those standards. Those standards have not specified 406 SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 407 and SHAKE256 with output length being 32 and 64 octets, respectively 408 can be used instead of 256 and 512-bit output hash algorithms such as 409 SHA256 and SHA512. 411 4.3. Public Keys 413 In CMS, the signer's public key algorithm identifiers are located in 414 the OriginatorPublicKey's algorithm attribute. The conventions and 415 encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers 416 are as specified in Section 2.3 of [RFC3279], Section 3.1 of 417 [RFC4055] and Section 2.1 of [RFC5480]. 419 Traditionally, the rsaEncryption object identifier is used to 420 identify RSA public keys. The rsaEncryption object identifier 421 continues to identify the public key when the RSA private key owner 422 does not wish to limit the use of the public key exclusively to 423 RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to 424 limit the use of the public key exclusively to RSASSA-PSS, the 425 AlgorithmIdentifier for RSASSA-PSS defined in Section 3 SHOULD be 426 used as the algorithm attribute in the OriginatorPublicKey sequence. 427 Conforming client implementations that process RSASSA-PSS with SHAKE 428 public keys in CMS message MUST recognize the corresponding OIDs in 429 Section 3. 431 Conforming implementations MUST specify and process the algorithms 432 explicitly by using the OIDs specified in Section 3 when encoding 433 ECDSA with SHAKE public keys in CMS messages. 435 The identifier parameters, as explained in Section 3, MUST be absent. 437 4.4. Message Authentication Codes 439 KMAC message authentication code (KMAC) is specified in [SP800-185]. 440 In CMS, KMAC algorithm identifiers are located in the 441 AuthenticatedData macAlgorithm field. The KMAC values are located in 442 the AuthenticatedData mac field. 444 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 OID is used as 445 the MAC algorithm identifier, the parameters field is optional 446 (absent or present). If absent, the SHAKE256 output length used in 447 KMAC is 256 or 512 bits, respectively, and the customization string 448 is an empty string by default. 450 Conforming implementations that process KMACs with the SHAKEs when 451 processing CMS data MUST recognize these identifiers. 453 When calculating the KMAC output, the variable N is 0xD2B282C2, S is 454 an empty string, and L, the integer representing the requested output 455 length in bits, is 256 or 512 for KmacWithSHAKE128 or 456 KmacWithSHAKE256, respectively, in this specification. 458 5. IANA Considerations 460 One object identifier for the ASN.1 module in Appendix A was 461 requested for the SMI Security for S/MIME Module Identifiers 462 (1.2.840.113549.1.9.16.0) registry: 464 +---------+----------------------+--------------------+ 465 | Decimal | Description | References | 466 +---------+----------------------+--------------------+ 467 | TBD | CMSAlgsForSHAKE-2019 | [EDNOTE: THIS RFC] | 468 +---------+----------------------+--------------------+ 470 6. Security Considerations 472 This document updates [RFC3370]. The security considerations section 473 of that document applies to this specification as well. 475 NIST has defined appropriate use of the hash functions in terms of 476 the algorithm strengths and expected time frames for secure use in 477 Special Publications (SPs) [SP800-78-4] and [SP800-107]. These 478 documents can be used as guides to choose appropriate key sizes for 479 various security scenarios. 481 SHAKE128 with output length of 256-bits offers 128-bits of collision 482 and preimage resistance. Thus, SHAKE128 OIDs in this specification 483 are RECOMMENDED with 2048 (112-bit security) or 3072-bit (128-bit 484 security) RSA modulus or curves with group order of 256-bits (128-bit 485 security). SHAKE256 with 512-bits output length offers 256-bits of 486 collision and preimage resistance. Thus, the SHAKE256 OIDs in this 487 specification are RECOMMENDED with 4096-bit RSA modulus or higher or 488 curves with group order of at least 521-bits (256-bit security). 489 Note that we recommended 4096-bit RSA because we would need 15360-bit 490 modulus for 256-bits of security which is impractical for today's 491 technology. 493 When more than two parties share the same message-authentication key, 494 data origin authentication is not provided. Any party that knows the 495 message-authentication key can compute a valid MAC, therefore the 496 content could originate from any one of the parties. 498 7. Acknowledgements 500 This document is based on Russ Housley's draft 501 [I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions 502 by SHAKE128 and SHAKE256 as the LAMPS WG agreed. 504 The authors would like to thank Russ Housley for his guidance and 505 very valuable contributions with the ASN.1 module. Valuable feedback 506 was also provided by Eric Rescorla. 508 8. References 510 8.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 518 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 519 . 521 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 522 Algorithms and Identifiers for RSA Cryptography for use in 523 the Internet X.509 Public Key Infrastructure Certificate 524 and Certificate Revocation List (CRL) Profile", RFC 4055, 525 DOI 10.17487/RFC4055, June 2005, 526 . 528 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 529 "Elliptic Curve Cryptography Subject Public Key 530 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 531 . 533 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 534 RFC 5652, DOI 10.17487/RFC5652, September 2009, 535 . 537 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 538 "PKCS #1: RSA Cryptography Specifications Version 2.2", 539 RFC 8017, DOI 10.17487/RFC8017, November 2016, 540 . 542 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 543 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 544 May 2017, . 546 [SHA3] National Institute of Standards and Technology, U.S. 547 Department of Commerce, "SHA-3 Standard - Permutation- 548 Based Hash and Extendable-Output Functions", FIPS PUB 202, 549 August 2015. 551 [SP800-185] 552 National Institute of Standards and Technology, "SHA-3 553 Derived Functions: cSHAKE, KMAC, TupleHash and 554 ParallelHash. NIST SP 800-185", December 2016, 555 . 558 8.2. Informative References 560 [I-D.housley-lamps-cms-sha3-hash] 561 Housley, R., "Use of the SHA3 One-way Hash Functions in 562 the Cryptographic Message Syntax (CMS)", draft-housley- 563 lamps-cms-sha3-hash-00 (work in progress), March 2017. 565 [I-D.ietf-lamps-pkix-shake] 566 Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 567 Infrastructure: Additional Algorithm Identifiers for 568 RSASSA-PSS and ECDSA using SHAKEs", draft-ietf-lamps-pkix- 569 shake-12 (work in progress), June 2019. 571 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 572 Identifiers for the Internet X.509 Public Key 573 Infrastructure Certificate and Certificate Revocation List 574 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 575 2002, . 577 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 578 Cryptography (ECC) Algorithms in Cryptographic Message 579 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 580 2010, . 582 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 583 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 584 DOI 10.17487/RFC5911, June 2010, 585 . 587 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 588 for the Cryptographic Message Syntax (CMS) and the Public 589 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 590 DOI 10.17487/RFC6268, July 2011, 591 . 593 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 594 Algorithm (DSA) and Elliptic Curve Digital Signature 595 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 596 2013, . 598 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 599 Elliptic Curve Cryptography", May 2009, 600 . 602 [shake-nist-oids] 603 National Institute of Standards and Technology, "Computer 604 Security Objects Register", October 2017, 605 . 608 [SP800-107] 609 National Institute of Standards and Technology (NIST), 610 "SP800-107: Recommendation for Applications Using Approved 611 Hash Algorithms", May 2014, 612 . 615 [SP800-78-4] 616 National Institute of Standards and Technology (NIST), 617 "SP800-78-4: Cryptographic Algorithms and Key Sizes for 618 Personal Identity Verification", May 2014, 619 . 622 [X9.62] American National Standard for Financial Services (ANSI), 623 "X9.62-2005 Public Key Cryptography for the Financial 624 Services Industry: The Elliptic Curve Digital Signature 625 Standard (ECDSA)", November 2005. 627 Appendix A. ASN.1 Module 629 This appendix includes the ASN.1 modules for SHAKEs in CMS. This 630 module includes some ASN.1 from other standards for reference. 632 CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) 633 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 634 id-mod-cms-shakes-2019(TBD) } 636 DEFINITIONS EXPLICIT TAGS ::= 638 BEGIN 640 -- EXPORTS ALL; 642 IMPORTS 644 DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS 645 FROM AlgorithmInformation-2009 646 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 647 mechanisms(5) pkix(7) id-mod(0) 648 id-mod-algorithmInformation-02(58) } 650 RSAPublicKey, rsaEncryption, id-ecPublicKey 651 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 652 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 653 id-mod-pkix1-algorithms2008-02(56) } ; 655 -- 656 -- Message Digest Algorithms (mda-) 657 -- used in SignedData, SignerInfo, DigestedData, 658 -- and the AuthenticatedData digestAlgorithm 659 -- fields in CMS 660 -- 661 MessageDigestAlgs DIGEST-ALGORITHM ::= { 662 -- This expands MessageAuthAlgs from [RFC5652] 663 -- and MessageDigestAlgs in [RFC5753] 664 mda-shake128 | 665 mda-shake256, 666 ... 667 } 669 -- 670 -- One-Way Hash Functions 671 -- SHAKE128 672 mda-shake128 DIGEST-ALGORITHM ::= { 673 IDENTIFIER id-shake128 -- with output length 32 bytes. 674 } 675 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 676 us(840) organization(1) gov(101) 677 csor(3) nistAlgorithm(4) 678 hashAlgs(2) 11 } 680 -- SHAKE256 681 mda-shake256 DIGEST-ALGORITHM ::= { 682 IDENTIFIER id-shake256 -- with output length 64 bytes. 683 } 684 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 685 us(840) organization(1) gov(101) 686 csor(3) nistAlgorithm(4) 687 hashAlgs(2) 12 } 689 -- 690 -- Public key algorithm identifiers located in the 691 -- OriginatorPublicKey's algorithm attribute in CMS. 692 -- And Signature identifiers used in SignerInfo 693 -- signatureAlgorithm field of SignedData content 694 -- type and countersignature attribute in CMS. 695 -- 696 -- From RFC5280, for reference. 697 -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 698 -- When the rsaEncryption algorithm identifier is used 699 -- for a public key, the AlgorithmIdentifier parameters 700 -- field MUST contain NULL. 701 -- 702 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) 703 identified-organization(3) dod(6) internet(1) 704 security(5) mechanisms(5) pkix(7) algorithms(6) 705 TBD1 } 706 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) 707 identified-organization(3) dod(6) internet(1) 708 security(5) mechanisms(5) pkix(7) algorithms(6) 709 TBD2 } 710 -- When the id-RSASSA-PSS-* algorithm identifiers are used 711 -- for a public key or signature in CMS, the AlgorithmIdentifier 712 -- parameters field MUST be absent. The message digest algorithm 713 -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or 714 -- 64 byte outout length, respectively. The mask generation 715 -- function MUST be SHAKE128 or SHAKE256 with an output length 716 -- of (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, 717 -- respectively, where n is the RSA modulus in bits. 718 -- The RSASSA-PSS saltLength MUST be 32 or 64 bytes, respectively. 719 -- The trailerField MUST be 1, which represents the trailer 720 -- field with hexadecimal value 0xBC. Regardless of 721 -- id-RSASSA-PSS-* or rsaEncryption being used as the 722 -- AlgorithmIdentifier of the OriginatorPublicKey, the RSA 723 -- public key MUST be encoded using the RSAPublicKey type. 725 -- From RFC4055, for reference. 726 -- RSAPublicKey ::= SEQUENCE { 727 -- modulus INTEGER, -- -- n 728 -- publicExponent INTEGER } -- -- e 730 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) 731 identified-organization(3) dod(6) internet(1) 732 security(5) mechanisms(5) pkix(7) algorithms(6) 733 TBD3 } 734 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) 735 identified-organization(3) dod(6) internet(1) 736 security(5) mechanisms(5) pkix(7) algorithms(6) 737 TBD4 } 738 -- When the id-ecdsa-with-shake* algorithm identifiers are 739 -- used in CMS, the AlgorithmIdentifier parameters field 740 -- MUST be absent and the signature algorithm should be 741 -- deterministic ECDSA [RFC6979]. The message digest MUST 742 -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout 743 -- length, respectively. In both cases, the ECDSA public key, 744 -- MUST be encoded using the id-ecPublicKey type. 746 -- From RFC5480, for reference. 747 -- id-ecPublicKey OBJECT IDENTIFIER ::= { 748 -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 749 -- The id-ecPublicKey parameters must be absent or present 750 -- and are defined as 751 -- ECParameters ::= CHOICE { 752 -- namedCurve OBJECT IDENTIFIER 753 -- -- -- implicitCurve NULL 754 -- -- -- specifiedCurve SpecifiedECDomain 755 -- } 757 -- 758 -- Message Authentication (maca-) Algorithms 759 -- used in AuthenticatedData macAlgorithm in CMS 760 -- 761 MessageAuthAlgs MAC-ALGORITHM ::= { 762 -- This expands MessageAuthAlgs from [RFC5652] and [RFC6268] 763 maca-KMACwithSHAKE128 | 764 maca-KMACwithSHAKE256, 765 ... 766 } 768 SMimeCaps SMIME-CAPS ::= { 769 -- The expands SMimeCaps from [RFC5911] 770 maca-KMACwithSHAKE128.&smimeCaps | 771 maca-KMACwithSHAKE256.&smimeCaps, 772 ... 773 } 775 -- 776 -- KMAC with SHAKE128 777 maca-KMACwithSHAKE128 MAC-ALGORITHM ::= { 778 IDENTIFIER id-KMACWithSHAKE128 779 PARAMS TYPE KMACwithSHAKE128-params ARE optional 780 -- If KMACwithSHAKE128-params parameters are absent 781 -- the SHAKE128 output length used in KMAC is 256 bits 782 -- and the customization string is an empty string. 783 IS-KEYED-MAC TRUE 784 SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE128} 785 } 786 id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 787 country(16) us(840) organization(1) 788 gov(101) csor(3) nistAlgorithm(4) 789 hashAlgs(2) 19 } 790 KMACwithSHAKE128-params ::= SEQUENCE { 791 kMACOutputLength INTEGER DEFAULT 256, -- Output length in bits 792 customizationString OCTET STRING DEFAULT ''H 793 } 795 -- KMAC with SHAKE256 796 maca-KMACwithSHAKE256 MAC-ALGORITHM ::= { 797 IDENTIFIER id-KMACWithSHAKE256 798 PARAMS TYPE KMACwithSHAKE256-params ARE optional 799 -- If KMACwithSHAKE256-params parameters are absent 800 -- the SHAKE256 output length used in KMAC is 512 bits 801 -- and the customization string is an empty string. 802 IS-KEYED-MAC TRUE 803 SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE256} 804 } 805 id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 806 country(16) us(840) organization(1) 807 gov(101) csor(3) nistAlgorithm(4) 808 hashAlgs(2) 20 } 809 KMACwithSHAKE256-params ::= SEQUENCE { 810 kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits 811 customizationString OCTET STRING DEFAULT ''H 812 } 814 END 816 Authors' Addresses 818 Panos Kampanakis 819 Cisco Systems 821 Email: pkampana@cisco.com 823 Quynh Dang 824 NIST 825 100 Bureau Drive 826 Gaithersburg, MD 20899 828 Email: quynh.Dang@nist.gov