idnits 2.17.1 draft-ietf-lamps-cms-shakes-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 (December 18, 2018) is 1949 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 Q. Dang 3 Internet-Draft NIST 4 Intended status: Standards Track P. Kampanakis 5 Expires: June 21, 2019 Cisco Systems 6 December 18, 2018 8 Use of the SHAKE One-way Hash Functions in the Cryptographic Message 9 Syntax (CMS) 10 draft-ietf-lamps-cms-shakes-05 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 June 21, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . 6 63 4.2.2. Deterministic ECDSA Signatures . . . . . . . . . . . 7 64 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.4. Message Authentication Codes . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Change Log 77 [ EDNOTE: Remove this section before publication. ] 79 o draft-ietf-lamps-cms-shake-05: 81 * Added informative references. 83 * Updated ASN.1 so it compiles. 85 * Updated IANA considerations. 87 o draft-ietf-lamps-cms-shake-04: 89 * Added RFC8174 reference and text. 91 * Explicitly explained why RSASSA-PSS-params are omitted in 92 section 4.2.1. 94 * Simplified Public Keys section by removing redundand info from 95 RFCs. 97 o draft-ietf-lamps-cms-shake-03: 99 * Removed paragraph suggesting KMAC to be used in generating k in 100 Deterministric ECDSA. That should be RFC6979-bis. 102 * Removed paragraph from Security Considerations that talks about 103 randomness of k because we are using deterministric ECDSA. 105 * Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's 106 feedback. 108 * Text fixes. 110 o draft-ietf-lamps-cms-shake-02: 112 * Updates based on suggestions and clarifications by Jim. 114 * Started ASN.1 module. 116 o draft-ietf-lamps-cms-shake-01: 118 * Significant reorganization of the sections to simplify the 119 introduction, the new OIDs and their use in CMS. 121 * Added new OIDs for RSASSA-PSS that hardcodes hash, salt and 122 MGF, according the WG consensus. 124 * Updated Public Key section to use the new RSASSA-PSS OIDs and 125 clarify the algorithm identifier usage. 127 * Removed the no longer used SHAKE OIDs from section 3.1. 129 o draft-ietf-lamps-cms-shake-00: 131 * Various updates to title and section names. 133 * Content changes filling in text and references. 135 o draft-dang-lamps-cms-shakes-hash-00: 137 * Initial version 139 2. Introduction 141 The Cryptographic Message Syntax (CMS) [RFC5652] is used to digitally 142 sign, digest, authenticate, or encrypt arbitrary message contents. 143 This specification describes the use of the SHAKE128 and SHAKE256 144 specified in [SHA3] as new hash functions in CMS. In addition, it 145 describes the use of these functions with the RSASSA-PSS signature 146 algorithm [RFC8017] and the Elliptic Curve Digital Signature 147 Algorithm (ECDSA) [X9.62] with the CMS signed-data content type. 149 In the SHA-3 family, two extendable-output functions (SHAKEs), 150 SHAKE128 and SHAKE256, are defined. Four other hash function 151 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also 152 defined but are out of scope for this document. A SHAKE is a 153 variable length hash function. The output length, in bits, of a 154 SHAKE is defined by the d parameter. The corresponding collision and 155 second preimage resistance strengths for SHAKE128 are min(d/2,128) 156 and min(d,128) bits respectively. And, the corresponding collision 157 and second preimage resistance strengths for SHAKE256 are 158 min(d/2,256) and min(d,256) bits respectively. 160 A SHAKE can be used in CMS as the message digest function (to hash 161 the message to be signed) in RSASSA-PSS and deterministic ECDSA, 162 message authentication code and as the mask generating function in 163 RSASSA-PSS. This specification describes the identifiers for SHAKEs 164 to be used in CMS and their meaning. 166 2.1. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 3. Identifiers 176 This section defines six new OIDs for using SHAKE128 and SHAKE256 in 177 CMS. 179 EDNOTE: If PKIX draft is standardized first maybe we should not say 180 the identifiers are new for the RSASSA-PSS and ECDSA. 182 Two object identifiers for SHAKE128 and SHAKE256 hash functions are 183 defined in [shake-nist-oids] and we include them here for 184 convenience. 186 id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 187 country(16) us(840) organization(1) gov(101) csor(3) 188 nistAlgorithm(4) 2 17 } 190 id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 191 country(16) us(840) organization(1) gov(101) csor(3) 192 nistAlgorithm(4) 2 18 } 194 In this specification, when using the id-shake128-len or id- 195 shake256-len algorithm identifiers, the parameters MUST be absent. 196 That is, the identifier SHALL be a SEQUENCE of one component, the 197 OID. 199 We define two new identifiers for RSASSA-PSS signatures using SHAKEs. 201 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 203 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 205 [ EDNOTE: "TBD" will be specified by NIST later. ] 207 The same RSASSA-PSS algorithm identifiers can be used for identifying 208 public keys and signatures. 210 We define two new algorithm identifiers of ECDSA signatures using 211 SHAKEs. 213 id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 214 country(16) us(840) organization(1) gov(101) csor(3) 215 nistAlgorithm(4) 3 TBD } 217 id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 218 country(16) us(840) organization(1) gov(101) csor(3) 219 nistAlgorithm(4) 3 TBD } 221 [ EDNOTE: "TBD" will be specified by NIST. ] 223 The parameters for the four RSASSA-PSS and deterministic ECDSA 224 identifiers MUST be absent. That is, each identifier SHALL be a 225 SEQUENCE of one component, the OID. 227 Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are 228 define elow. 230 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 231 country(16) us(840) organization(1) gov(101) csor(3) 232 nistAlgorithm(4) 2 19 } 234 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 235 country(16) us(840) organization(1) gov(101) csor(3) 236 nistAlgorithm(4) 2 20 } 238 The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST 239 be absent. That is, each identifier SHALL be a SEQUENCE of one 240 component, the OID. 242 Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the 243 required output length for each use of SHAKE128 or SHAKE256 in 244 message digests, RSASSA-PSS, determinstic ECDSA and KMAC. 246 4. Use in CMS 248 4.1. Message Digests 250 The id-shake128-len and id-shake256-len OIDs (Section 3) can be used 251 as the digest algorithm identifiers located in the SignedData, 252 SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm 253 fields in CMS [RFC5652]. The encoding MUST omit the parameters field 254 and the output size, d, for the SHAKE128 or SHAKE256 message digest 255 MUST be 256 or 512 bits respectively. 257 The digest values are located in the DigestedData field and the 258 Message Digest authenticated attribute included in the 259 signedAttributes of the SignedData signerInfo. In addition, digest 260 values are input to signature algorithms. The digest algorithm MUST 261 be the same as the message hash algorithms used in signatures. 263 4.2. Signatures 265 In CMS, signature algorithm identifiers are located in the SignerInfo 266 signatureAlgorithm field of SignedData content type and 267 countersignature attribute. Signature values are located in the 268 SignerInfo signature field of SignedData and countersignature. 270 Conforming implementations that process RSASSA-PSS and deterministic 271 ECDSA with SHAKE signatures when processing CMS data MUST recognize 272 the corresponding OIDs specified in Section 3. 274 4.2.1. RSASSA-PSS Signatures 276 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 277 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is 278 used, the encoding MUST omit the parameters field. That is, the 279 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 280 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- 281 PSS-params that are used to define the algorithms and inputs to the 282 algorithm. This specification does not use parameters because the 283 hash and mask generating algorithsm and trailer and salt are embedded 284 in the OID definition. 286 The hash algorithm to hash a message being signed and the hash and 287 the hash algorithm as the mask generation function used in RSASSA-PSS 288 MUST be the same, SHAKE128 or SHAKE256 respectively. The output- 289 length of the hash algorithm which hashes the message SHALL be 32 or 290 64 bytes respectively. 292 The mask generation function takes an octet string of variable length 293 and a desired output length as input, and outputs an octet string of 294 the desired length. In RSASSA-PSS with SHAKES, the SHAKEs MUST be 295 used natively as the MGF function, instead of the MGF1 algorithm that 296 uses the hash function in multiple iterations as specified in 297 Section B.2.1 of [RFC8017]. In other words, the MGF is defined as 298 the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- 299 SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the 300 seed from which mask is generated, an octet string [RFC8017]. The 301 output length is (n - 264)/8 or (n - 520)/8 bytes respectively, where 302 n is the RSA modulus in bits. For example, when RSA modulus n is 303 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 304 223 or 191-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 305 is used respectively. 307 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 308 Finally, the trailerField MUST be 1, which represents the trailer 309 field with hexadecimal value 0xBC [RFC8017]. 311 4.2.2. Deterministic ECDSA Signatures 313 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 314 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 315 (specified in Section 3) algorithm identifier appears, the respective 316 SHAKE function is used as the hash. The encoding MUST omit the 317 parameters field. That is, the AlgorithmIdentifier SHALL be a 318 SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id- 319 ecdsa-with-SHAKE256. 321 For simplicity and compliance with the ECDSA standard specification, 322 the output size of the hash function must be explicitly determined. 323 The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 324 256 or 512 bits respectively. 326 Conforming implementations that generate ECDSA with SHAKE signatures 327 in CMS MUST generate such signatures with a deterministicly 328 generated, non-random k in accordance with all the requirements 329 specified in [RFC6979]. They MAY also generate such signatures in 330 accordance with all other recommendations in [X9.62] or [SEC1] if 331 they have a stated policy that requires conformance to these 332 standards. 334 4.3. Public Keys 336 In CMS, the signer's public key algorithm identifiers are located in 337 the OriginatorPublicKey's algorithm attribute. 339 Conforming implementations MUST specify the algorithms explicitly by 340 using the OIDs specified in Section 3 when encoding RSASSA-PSS with 341 SHAKE public keys in CMS messages. The conventions and encoding for 342 RSASSA-PSS and ECDSA public keys algorithm identifiers are as 343 specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and 344 Section 2.1 of [RFC5480]. 346 When the RSA private key owner wishes to limit the use of the public 347 key exclusively to RSASSA-PSS, the AlgorithmIdentifier for RSASSA-PSS 348 defined in Section 3 can be used as the algorithm attribute in the 349 OriginatorPublicKey sequence. The identifier parameters, as 350 explained in Section 3, MUST be absent. The RSASSA-PSS algorithm 351 functions and output lengths are the same as defined in 352 Section 4.2.1. 354 4.4. Message Authentication Codes 356 KMAC message authentication code (KMAC) is specified in [SP800-185]. 357 In CMS, KMAC algorithm identifiers are located in the 358 AuthenticatedData macAlgorithm field. The KMAC values are located in 359 the AuthenticatedData mac field. 361 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm 362 identifier is used as the MAC algorithm identifier, the parameters 363 field is optional (absent or present). If absent, the SHAKE256 364 output length used in KMAC is 256 or 512 bits respectively and the 365 customization string is an empty string by default. 367 Conforming implementations that process KMACs with the SHAKEs when 368 processing CMS data MUST recognize these identifiers. 370 When calculating the KMAC output, the variable N is 0xD2B282C2, S is 371 an empty string, and L, the integer representing the requested output 372 length in bits, is 256 or 512 for KmacWithSHAKE128 or 373 KmacWithSHAKE256 respectively in this specification. 375 5. IANA Considerations 377 One object identifier for the ASN.1 module in Appendix A was assigned 378 in the SMI Security for S/MIME Module Identifiers 379 (1.2.840.113549.1.9.16.0) registry: 381 CMSAlgsForSHAKE-2018 { { iso(1) member-body(2) us(840) 382 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 383 id-mod-cms-shakes(TBD) } 385 6. Security Considerations 387 The SHAKEs are deterministic functions. Like any other deterministic 388 function, executing each function with the same input multiple times 389 will produce the same output. Therefore, users should not expect 390 unrelated outputs (with the same or different output lengths) from 391 excuting a SHAKE function with the same input multiple times. The 392 shorter one of any 2 outputs produced from a SHAKE with the same 393 input is a prefix of the longer one. It is a similar situation as 394 truncating a 512-bit output of SHA-512 by taking its 256 left-most 395 bits. These 256 left-most bits are a prefix of the 512-bit output. 397 Implementations must protect the signer's private key. Compromise of 398 the signer's private key permits masquerade. 400 When more than two parties share the same message-authentication key, 401 data origin authentication is not provided. Any party that knows the 402 message-authentication key can compute a valid MAC, therefore the 403 content could originate from any one of the parties. 405 Implementers should be aware that cryptographic algorithms may become 406 weaker with time. As new cryptanalysis techniques are developed and 407 computing power increases, the work factor or time required to break 408 a particular cryptographic algorithm may decrease. Therefore, 409 cryptographic algorithm implementations should be modular allowing 410 new algorithms to be readily inserted. That is, implementers should 411 be prepared to regularly update the set of algorithms in their 412 implementations. 414 7. Acknowledgements 416 This document is based on Russ Housley's draft 417 [I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions 418 by SHAKE128 and SHAKE256 as the LAMPS WG agreed. 420 The authors would like to thank Russ Housley for his guidance and 421 very valuable contributions with the ASN.1 module. 423 8. References 424 8.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 432 Algorithms and Identifiers for RSA Cryptography for use in 433 the Internet X.509 Public Key Infrastructure Certificate 434 and Certificate Revocation List (CRL) Profile", RFC 4055, 435 DOI 10.17487/RFC4055, June 2005, 436 . 438 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 439 "Elliptic Curve Cryptography Subject Public Key 440 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 441 . 443 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 444 RFC 5652, DOI 10.17487/RFC5652, September 2009, 445 . 447 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 448 "PKCS #1: RSA Cryptography Specifications Version 2.2", 449 RFC 8017, DOI 10.17487/RFC8017, November 2016, 450 . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 [SHA3] National Institute of Standards and Technology, U.S. 457 Department of Commerce, "SHA-3 Standard - Permutation- 458 Based Hash and Extendable-Output Functions", FIPS PUB 202, 459 August 2015. 461 [SP800-185] 462 National Institute of Standards and Technology, "SHA-3 463 Derived Functions: cSHAKE, KMAC, TupleHash and 464 ParallelHash. NIST SP 800-185", December 2016, 465 . 468 8.2. Informative References 470 [I-D.housley-lamps-cms-sha3-hash] 471 Housley, R., "Use of the SHA3 One-way Hash Functions in 472 the Cryptographic Message Syntax (CMS)", draft-housley- 473 lamps-cms-sha3-hash-00 (work in progress), March 2017. 475 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 476 Identifiers for the Internet X.509 Public Key 477 Infrastructure Certificate and Certificate Revocation List 478 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 479 2002, . 481 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 482 Cryptography (ECC) Algorithms in Cryptographic Message 483 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 484 2010, . 486 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 487 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 488 DOI 10.17487/RFC5911, June 2010, 489 . 491 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 492 for the Cryptographic Message Syntax (CMS) and the Public 493 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 494 DOI 10.17487/RFC6268, July 2011, 495 . 497 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 498 Algorithm (DSA) and Elliptic Curve Digital Signature 499 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 500 2013, . 502 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 503 Elliptic Curve Cryptography", May 2009, 504 . 506 [shake-nist-oids] 507 National Institute of Standards and Technology, "Computer 508 Security Objects Register", October 2017, 509 . 512 [X9.62] American National Standard for Financial Services (ANSI), 513 "X9.62-2005 Public Key Cryptography for the Financial 514 Services Industry: The Elliptic Curve Digital Signature 515 Standard (ECDSA)", November 2005. 517 Appendix A. ASN.1 Module 519 This appendix includes the ASN.1 modules for SHAKEs in CMS. This 520 module includes some ASN.1 from other standards for reference. 522 CMSAlgsForSHAKE-2018 { iso(1) member-body(2) us(840) 523 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 524 id-mod-cms-shakes(TBD) } 526 DEFINITIONS EXPLICIT TAGS ::= 528 BEGIN 530 -- EXPORTS ALL; 532 IMPORTS 534 DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS 535 FROM AlgorithmInformation-2009 536 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 537 mechanisms(5) pkix(7) id-mod(0) 538 id-mod-algorithmInformation-02(58) } 540 RSAPublicKey, rsaEncryption, id-ecPublicKey 541 FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) 542 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 543 id-mod-pkix1-algorithms2008-02(56) } ; 545 -- 546 -- Message Digest Algorithms (mda-) 547 -- used in SignedData, SignerInfo, DigestedData, 548 -- and the AuthenticatedData digestAlgorithm 549 -- fields in CMS 550 -- 551 MessageDigestAlgs DIGEST-ALGORITHM ::= { 552 -- This expands MessageAuthAlgs from [RFC5652] 553 -- and MessageDigestAlgs in [RFC5753] 554 mda-shake128 | 555 mda-shake256, 556 ... 557 } 559 -- 560 -- One-Way Hash Functions 561 -- SHAKE128 562 mda-shake128 DIGEST-ALGORITHM ::= { 563 IDENTIFIER id-shake128 -- with output length 32 bytes. 564 } 565 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 566 us(840) organization(1) gov(101) 567 csor(3) nistAlgorithm(4) 568 hashAlgs(2) 11 } 570 -- SHAKE-256 571 mda-shake256 DIGEST-ALGORITHM ::= { 572 IDENTIFIER id-shake256 -- with output length 64 bytes. 573 } 574 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 575 us(840) organization(1) gov(101) 576 csor(3) nistAlgorithm(4) 577 hashAlgs(2) 12 } 579 -- 580 -- Public key algorithm identifiers located in the 581 -- OriginatorPublicKey's algorithm attribute in CMS. 582 -- And Signature identifiers used in SignerInfo 583 -- signatureAlgorithm field of SignedData content 584 -- type and countersignature attribute in CMS. 585 -- 586 -- From RFC5280, for reference. 587 -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 588 -- When the rsaEncryption algorithm identifier is used 589 -- for a public key, the AlgorithmIdentifier parameters 590 -- field MUST contain NULL. 591 -- 592 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 593 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 595 -- When the id-RSASSA-PSS-* algorithm identifiers are used 596 -- for a public key or signature in CMS, the AlgorithmIdentifier 597 -- parameters field MUST be absent. The message digest algorithm 598 -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or 599 -- 64 byte outout length respectively. The mask generating 600 -- function MUST be SHAKE128 or SHAKE256 with an output length 601 -- of (n - 264)/8 or (n - 520)/8 bytes respectively, where n 602 -- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST 603 -- be 32 or 64 bytes respectively. In both cases, the RSA 604 -- public key, MUST be encoded using the RSAPublicKey type. 605 -- From RFC4055, for reference. 606 -- RSAPublicKey ::= SEQUENCE { 607 -- modulus INTEGER, -- -- n 608 -- publicExponent INTEGER } -- -- e 610 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 611 country(16) us(840) organization(1) 612 gov(101) csor(3) nistAlgorithm(4) 613 sigAlgs(3) TBD } 614 id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 615 country(16) us(840) organization(1) 616 gov(101) csor(3) nistAlgorithm(4) 617 sigAlgs(3) TBD } 618 -- When the id-ecdsa-with-shake* algorithm identifiers are 619 -- used in CMS, the AlgorithmIdentifier parameters field 620 -- MUST be absent and the signature algorithm should 621 -- Deterministric ECDSA [RFC6979]. The message digest MUST 622 -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout 623 -- length respectively. In both cases, the ECDSA public key, 624 -- MUST be encoded using the id-ecPublicKey type. 625 -- From RFC5480, for reference. 626 -- id-ecPublicKey OBJECT IDENTIFIER ::= { 627 -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 628 -- The id-ecPublicKey parameters must be absent or present 629 -- and are defined as 630 -- ECParameters ::= CHOICE { 631 -- namedCurve OBJECT IDENTIFIER 632 -- -- -- implicitCurve NULL 633 -- -- -- specifiedCurve SpecifiedECDomain 634 -- } 636 -- 637 -- Message Authentication (maca-) Algorithms 638 -- used in AuthenticatedData macAlgorithm in CMS 639 -- 640 MessageAuthAlgs MAC-ALGORITHM ::= { 641 -- This expands MessageAuthAlgs from [RFC5652] and [RFC6268] 642 maca-KMACwithSHAKE128 | 643 maca-KMACwithSHAKE256, 644 ... 645 } 647 SMimeCaps SMIME-CAPS ::= { 648 -- The expands SMimeCaps from [RFC5911] 649 maca-KMACwithSHAKE128.&smimeCaps | 650 maca-KMACwithSHAKE256.&smimeCaps, 651 ... 652 } 654 -- 655 -- KMAC with SHAKE128 656 maca-KMACwithSHAKE128 MAC-ALGORITHM ::= { 657 IDENTIFIER id-KMACWithSHAKE128 658 PARAMS TYPE KMACwithSHAKE128-params ARE optional 659 -- If KMACwithSHAKE128-params parameters are absent 660 -- the SHAKE128 output length used in KMAC is 256 bits 661 -- and the customization string is an empty string. 662 IS-KEYED-MAC TRUE 663 SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE128} 664 } 665 id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 666 country(16) us(840) organization(1) 667 gov(101) csor(3) nistAlgorithm(4) 668 hashAlgs(2) 19 } 669 KMACwithSHAKE128-params ::= SEQUENCE { 670 kMACOutputLength INTEGER DEFAULT 256, -- Output length in bits 671 customizationString OCTET STRING DEFAULT ''H 672 } 674 -- KMAC with SHAKE256 675 maca-KMACwithSHAKE256 MAC-ALGORITHM ::= { 676 IDENTIFIER id-KMACWithSHAKE256 677 PARAMS TYPE KMACwithSHAKE256-params ARE optional 678 -- If KMACwithSHAKE256-params parameters are absent 679 -- the SHAKE256 output length used in KMAC is 512 bits 680 -- and the customization string is an empty string. 681 IS-KEYED-MAC TRUE 682 SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE256} 683 } 684 id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 685 country(16) us(840) organization(1) 686 gov(101) csor(3) nistAlgorithm(4) 687 hashAlgs(2) 20 } 688 KMACwithSHAKE256-params ::= SEQUENCE { 689 kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits 690 customizationString OCTET STRING DEFAULT ''H 691 } 693 END 695 Authors' Addresses 697 Quynh Dang 698 NIST 699 100 Bureau Drive 700 Gaithersburg, MD 20899 702 Email: quynh.Dang@nist.gov 704 Panos Kampanakis 705 Cisco Systems 707 Email: pkampana@cisco.com