idnits 2.17.1 draft-ietf-lamps-cms-shakes-02.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 (October 22, 2018) is 2011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6268' is mentioned on line 546, but not defined ** 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 (~~), 3 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: April 25, 2019 Cisco Systems 6 October 22, 2018 8 Use of the SHAKE One-way Hash Functions in the Cryptographic Message 9 Syntax (CMS) 10 draft-ietf-lamps-cms-shakes-02 12 Abstract 14 This document describes the conventions for using the SHAKE family of 15 hash functions with the Cryptographic Message Syntax (CMS). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 25, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 6 59 4.2.2. Deterministic ECDSA Signatures . . . . . . . . . . . 6 60 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3.1. RSASSA-PSS Public Keys . . . . . . . . . . . . . . . 7 62 4.3.2. ECDSA Public Keys . . . . . . . . . . . . . . . . . . 8 63 4.4. Message Authentication Codes . . . . . . . . . . . . . . 8 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Change Log 75 [ EDNOTE: Remove this section before publication. ] 77 o draft-ietf-lamps-cms-shake-02: 79 * Updates based on suggestions and clarifications by Jim. 81 * Started ASN.1 module. 83 o draft-ietf-lamps-cms-shake-01: 85 * Significant reorganization of the sections to simplify the 86 introduction, the new OIDs and their use in CMS. 88 * Added new OIDs for RSASSA-PSS that hardcodes hash, salt and 89 MGF, according the WG consensus. 91 * Updated Public Key section to use the new RSASSA-PSS OIDs and 92 clarify the algorithm identifier usage. 94 * Removed the no longer used SHAKE OIDs from section 3.1. 96 o draft-ietf-lamps-cms-shake-00: 98 * Various updates to title and section names. 100 * Content changes filling in text and references. 102 o draft-dang-lamps-cms-shakes-hash-00: 104 * Initial version 106 2. Introduction 108 The Cryptographic Message Syntax (CMS) [RFC5652] is used to digitally 109 sign, digest, authenticate, or encrypt arbitrary message contents. 110 This specification describes the use of the SHAKE128 and SHAKE256 111 specified in [SHA3] as new hash functions in CMS. In addition, it 112 describes the use of these functions with the RSASSA-PSS signature 113 algorithm [RFC8017] and the Elliptic Curve Digital Signature 114 Algorithm (ECDSA) [X9.62] with the CMS signed-data content type. 116 The SHA-3 family of one-way hash functions is specified in [SHA3]. 117 In the SHA-3 family, two extendable-output functions (SHAKEs): 118 SHAKE128 and SHAKE256, are defined. Four other hash function 119 instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also 120 defined but are out of scope for this document. A SHAKE is a 121 variable length hash function. The output length, in bits, of a 122 SHAKE is defined by the d parameter. The corresponding collision and 123 second preimage resistance strengths for SHAKE128 are min(d/2,128) 124 and min(d,128) bits respectively. And, the corresponding collision 125 and second preimage resistance strengths for SHAKE256 are 126 min(d/2,256) and min(d,256) bits respectively. 128 A SHAKE can be used in CMS as the message digest function (to hash 129 the message to be signed) in RSASSA-PSS and deterministic ECDSA, 130 message authentication code and as the mask generating function in 131 RSASSA-PSS. In Section 3 of this document we define six new OIDs 132 using SHAKE128 and SHAKE256 in CMS. 134 2.1. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. Identifiers 142 The object identifiers for SHAKE128 and SHAKE256 hash functions are 143 defined in [shake-nist-oids] and we include them here for 144 convenience. 146 id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 147 country(16) us(840) organization(1) gov(101) csor(3) 148 nistAlgorithm(4) 2 17 } 150 id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 151 country(16) us(840) organization(1) gov(101) csor(3) 152 nistAlgorithm(4) 2 18 } 154 In this specification, when using the id-shake128-len or id- 155 shake256-len algorithm identifiers, the parameters MUST be absent. 156 That is, the identifier SHALL be a SEQUENCE of one component, the 157 OID. 159 The new identifiers for RSASSA-PSS signatures using SHAKEs are below. 161 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD } 163 id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD } 165 [ EDNOTE: "TBD" will be specified by NIST later. ] 167 The new algorithm identifiers of ECDSA signatures using SHAKEs are 168 below. 170 id-ecdsa-with-SHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 171 country(16) us(840) organization(1) gov(101) csor(3) 172 nistAlgorithm(4) 3 TBD } 174 id-ecdsa-with-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 175 country(16) us(840) organization(1) gov(101) csor(3) 176 nistAlgorithm(4) 3 TBD } 178 [ EDNOTE: "TBD" will be specified by NIST. ] 180 The same RSASSA-PSS and deterministric ECDSA with SHAKEs algorithm 181 identifiers are used for identifying public keys and signatures. 183 The parameters for the four RSASSA-PSS and deterministic ECDSA 184 identifiers MUST be absent. That is, each identifier SHALL be a 185 SEQUENCE of one component, the OID. 187 The new object identifiers for KMACs using SHAKE128 and SHAKE256 are 188 below. 190 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 191 country(16) us(840) organization(1) gov(101) csor(3) 192 nistAlgorithm(4) 2 TBD } 194 id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 195 country(16) us(840) organization(1) gov(101) csor(3) 196 nistAlgorithm(4) 2 TBD } 198 EDNOTE: "TBD" will be specified by NIST. 200 The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 MUST 201 be absent. That is, each identifier SHALL be a SEQUENCE of one 202 component, the OID. 204 Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the 205 required output length for each use of SHAKE128 or SHAKE256 in 206 message digests, RSASSA-PSS, determinstic ECDSA and KMAC. 208 4. Use in CMS 210 4.1. Message Digests 212 The id-shake128-len and id-shake256-len OIDs (Section 3) can be used 213 as the digest algorithm identifiers located in the SignedData, 214 SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm 215 fields in CMS [RFC5652]. The encoding MUST omit the parameters field 216 and the output size, d, for the SHAKE128 or SHAKE256 message digest 217 MUST be 256 or 512 bits respectively. 219 The digest values are located in the DigestedData field and the 220 Message Digest authenticated attribute included in the 221 signedAttributes of the SignedData signerInfo. In addition, digest 222 values are input to signature algorithms. 224 4.2. Signatures 226 In CMS, signature algorithm identifiers are located in the SignerInfo 227 signatureAlgorithm field of SignedData content type and 228 countersignature attribute. Signature values are located in the 229 SignerInfo signature field of SignedData and countersignature. 231 Conforming implementations that process RSASSA-PSS and deterministic 232 ECDSA with SHAKE signatures when processing CMS data MUST recognize 233 the corresponding OIDs specified in Section 3. 235 4.2.1. RSASSA-PSS Signatures 237 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- 238 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is 239 used, the encoding MUST omit the parameters field. That is, the 240 AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- 241 PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. 243 The hash algorithm to hash a message being signed and the hash 244 algorithm as the mask generation function "MGF(H, emLen - hLen - 1)" 245 [RFC8017] used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 246 respectively. The output-length of the SHAKE which hashes the 247 message SHALL be 32 or 64 bytes respectively. 249 In RSASSA-PSS, a mask generation function takes an octet string of 250 variable length and a desired output length as input, and outputs an 251 octet string of the desired length. In RSASSA-PSS with SHAKES, the 252 SHAKEs MUST be used natively as the MGF, instead of the MGF1 253 algorithm that uses the hash function in multiple iterations as 254 specified in Section B.2.1 of [RFC8017]. In other words, the MGF is 255 defined as 257 SHAKE128(mgfSeed, maskLen) 259 and 261 SHA256(mgfSeed, maskLen) 263 respectively for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256. 264 The mgfSeed is the seed from which mask is generated, an octet 265 string. The maskLen for SHAKE128 or SHAKE256 being used as the MGF 266 is (n - 264)/8 or (n - 520)/8 bytes respectively, where n is the RSA 267 modulus in bits. For example, when RSA modulus n is 2048, the output 268 length of SHAKE128 or SHAKE256 as the MGF will be 223 or 191 bytes 269 when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used 270 respectively. 272 The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively. 273 Finally, the trailerField MUST be 1, which represents the trailer 274 field with hexadecimal value 0xBC [RFC8017]. 276 4.2.2. Deterministic ECDSA Signatures 278 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 279 [X9.62]. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256 280 (specified in Section 3) algorithm identifier appears, the respective 281 SHAKE function is used as the hash. The encoding MUST omit the 282 parameters field. That is, the AlgorithmIdentifier SHALL be a 283 SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or id- 284 ecdsa-with-SHAKE256. 286 For simplicity and compliance with the ECDSA standard specification, 287 the output size of the hash function must be explicitly determined. 288 The output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 289 256 or 512 bits respectively. The ECDSA message hash function is 290 SHAKE128 or SHAKE256 respectively. 292 Conforming implementations that generate ECDSA with SHAKE signatures 293 in CMS MUST generate such signatures with a deterministicly 294 generated, non-random k in accordance with all the requirements 295 specified in [RFC6979]. They MAY also generate such signatures in 296 accordance with all other recommendations in [X9.62] or [SEC1] if 297 they have a stated policy that requires conformance to these 298 standards. 300 In Section 3.2 "Generation of k" of [RFC6979], HMAC is used to derive 301 the deterministic k. Conforming implementations that generate 302 deterministic ECDSA with SHAKE signatures in X.509 MUST use KMAC with 303 SHAKE128 or KMAC with SHAKE256 as specfied in [SP800-185] when 304 SHAKE128 or SHAKE256 is used as the message hashing algorithm, 305 respectively. In this situation, KMAC with SHAKE128 and KMAC with 306 SHAKE256 have 256-bit and 512-bit outputs respectively, and the 307 optional customization bit string S is an empty string. 309 4.3. Public Keys 311 In CMS, the signer's public key algorithm identifiers are located in 312 the OriginatorPublicKey's algorithm attribute. 314 Conforming implementations MUST specify the algorithms explicitly by 315 using the OIDs specified in Section 3 when encoding RSASSA-PSS and 316 ECDSA with SHAKE public keys in CMS messages. The conventions for 317 RSASSA-PSS and ECDSA public keys algorithm identifiers are as 318 specified in [RFC3279], [RFC4055] and [RFC5480] , but we include them 319 below for convenience. 321 4.3.1. RSASSA-PSS Public Keys 323 [RFC3279] defines the following OID for RSA AlgorithmIdentifier in 324 the SubjectPublicKeyInfo with NULL parameters. 326 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1} 328 Additionally, when the RSA private key owner wishes to limit the use 329 of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifier 330 for RSASSA-PSS defined in Section 3 can be used as the algorithm 331 attribute in the OriginatorPublicKey sequence. The identifier 332 parameters, as explained in Section 3, MUST be absent. The RSASSA- 333 PSS algorithm functions and output lengths are the same as defined in 334 Section 4.2.1. 336 Regardless of what public key algorithm identifier is used, the RSA 337 public key, which is composed of a modulus and a public exponent, 338 MUST be encoded using the RSAPublicKey type [RFC4055]. The output of 339 this encoding is carried in the CMS publicKey bit string. 341 RSAPublicKey ::= SEQUENCE { 342 modulus INTEGER, -- n 343 publicExponent INTEGER -- e 344 } 346 4.3.2. ECDSA Public Keys 348 When id-ecdsa-with-shake128 or id-ecdsa-with-shake256 are used as the 349 algorithm identitifier in the public key, the parameters, as 350 explained in Section 3, MUST be absent. The hash function and its 351 output-length are the same as in Section 4.2.2. 353 Additionally, the mandatory EC SubjectPublicKey is defined in 354 Section 2.1.1 and its syntax in Section 2.2 of [RFC5480]. We also 355 include them here for convenience: 357 id-ecPublicKey OBJECT IDENTIFIER ::= { 358 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 360 ECParameters ::= CHOICE { 361 namedCurve OBJECT IDENTIFIER 362 -- implicitCurve NULL 363 -- specifiedCurve SpecifiedECDomain 364 } 366 The ECParameters associated with the ECDSA public key in the signers 367 certificate SHALL apply to the verification of the signature. 369 4.4. Message Authentication Codes 371 KMAC message authentication code (KMAC) is specified in [SP800-185]. 372 In CMS, KMAC algorithm identifiers are located in the 373 AuthenticatedData macAlgorithm field. The KMAC values are located in 374 the AuthenticatedData mac field. 376 When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm 377 identifier is used as the KMAC algorithm identifier, the parameters 378 field MUST be absent. 380 Conforming implementations that process KMACs with the SHAKEs when 381 processing CMS data MUST recognize these identifiers. 383 When calculating the KMAC output, the variable N is 0xD2B282C2, S is 384 an empty string, and L, the integer representing the requested output 385 length in bits, is 256 or 512 for KmacWithSHAKE128 or 386 KmacWithSHAKE256 respectively in this specification. 388 5. IANA Considerations 390 [ EDNOTE: Update here only if there are OID allocations by IANA. ] 392 This document has no IANA actions. 394 6. Security Considerations 396 SHAKE128 and SHAKE256 are one-way extensible-output functions. Their 397 output length depends on a required length of the consuming 398 application. 400 The SHAKEs are deterministic functions. Like any other deterministic 401 functions, executing each function with the same input multiple times 402 will produce the same output. Therefore, users should not expect 403 unrelated outputs (with the same or different output lengths) from 404 excuting a SHAKE function with the same input multiple times. The 405 shorter one of any 2 outputs produced from a SHAKE with the same 406 input is a prefix of the longer one. It is a similar situation as 407 truncating a 512-bit output of SHA-512 by taking its 256 left-most 408 bits. These 256 left-most bits are a prefix of the 512-bit output. 410 Implementations must protect the signer's private key. Compromise of 411 the signer's private key permits masquerade. 413 When more than two parties share the same message-authentication key, 414 data origin authentication is not provided. Any party that knows the 415 message-authentication key can compute a valid MAC, therefore the 416 content could originate from any one of the parties. 418 Implementations must randomly generate message-authentication keys 419 and one-time values, such as the k value when generating a ECDSA 420 signature. In addition, the generation of public/private key pairs 421 relies on random numbers. The use of inadequate pseudo-random number 422 generators (PRNGs) to generate such cryptographic values can result 423 in little or no security. The generation of quality random numbers 424 is difficult. [RFC4086] offers important guidance in this area, and 425 [SP800-90A] series provide acceptable PRNGs. 427 Implementers should be aware that cryptographic algorithms may become 428 weaker with time. As new cryptanalysis techniques are developed and 429 computing power increases, the work factor or time required to break 430 a particular cryptographic algorithm may decrease. Therefore, 431 cryptographic algorithm implementations should be modular allowing 432 new algorithms to be readily inserted. That is, implementers should 433 be prepared to regularly update the set of algorithms in their 434 implementations. 436 7. Acknowledgements 438 This document is based on Russ Housley's draft 439 [I-D.housley-lamps-cms-sha3-hash] It replaces SHA3 hash functions by 440 SHAKE128 and SHAKE256 as the LAMPS WG agreed. 442 8. References 444 8.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 452 Algorithms and Identifiers for RSA Cryptography for use in 453 the Internet X.509 Public Key Infrastructure Certificate 454 and Certificate Revocation List (CRL) Profile", RFC 4055, 455 DOI 10.17487/RFC4055, June 2005, 456 . 458 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 459 "Elliptic Curve Cryptography Subject Public Key 460 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 461 . 463 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 464 RFC 5652, DOI 10.17487/RFC5652, September 2009, 465 . 467 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 468 "PKCS #1: RSA Cryptography Specifications Version 2.2", 469 RFC 8017, DOI 10.17487/RFC8017, November 2016, 470 . 472 [SHA3] National Institute of Standards and Technology, U.S. 473 Department of Commerce, "SHA-3 Standard - Permutation- 474 Based Hash and Extendable-Output Functions", FIPS PUB 202, 475 August 2015. 477 [SP800-185] 478 National Institute of Standards and Technology, "SHA-3 479 Derived Functions: cSHAKE, KMAC, TupleHash and 480 ParallelHash. NIST SP 800-185", December 2016, 481 . 484 8.2. Informative References 486 [I-D.housley-lamps-cms-sha3-hash] 487 Housley, R., "Use of the SHA3 One-way Hash Functions in 488 the Cryptographic Message Syntax (CMS)", draft-housley- 489 lamps-cms-sha3-hash-00 (work in progress), March 2017. 491 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 492 Identifiers for the Internet X.509 Public Key 493 Infrastructure Certificate and Certificate Revocation List 494 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 495 2002, . 497 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 498 "Randomness Requirements for Security", BCP 106, RFC 4086, 499 DOI 10.17487/RFC4086, June 2005, 500 . 502 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 503 Algorithm (DSA) and Elliptic Curve Digital Signature 504 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 505 2013, . 507 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 508 Elliptic Curve Cryptography", May 2009, 509 . 511 [shake-nist-oids] 512 National Institute of Standards and Technology, "Computer 513 Security Objects Register", October 2017, 514 . 517 [SP800-90A] 518 National Institute of Standards and Technology, 519 "Recommendation for Random Number Generation Using 520 Deterministic Random Bit Generators. NIST SP 800-90A", 521 June 2015, 522 . 525 [X9.62] American National Standard for Financial Services (ANSI), 526 "X9.62-2005 Public Key Cryptography for the Financial 527 Services Industry: The Elliptic Curve Digital Signature 528 Standard (ECDSA)", November 2005. 530 Appendix A. ASN.1 Module 532 [EDNOTE: Update. TBD. ] 534 PKIXAlgsForSHAKE-2018 { iso(1) identified-organization(3) dod(6) 535 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 536 id-mod-cms-shakes-2018(TBD) } 538 DEFINITIONS EXPLICIT TAGS ::= 540 BEGIN 542 -- EXPORTS ALL; 544 IMPORTS 546 -- FROM [RFC6268] 548 -- 549 -- One-Way Hash Functions 550 -- SHAKE128 551 mda-shake128 DIGEST-ALGORITHM ::= { 552 IDENTIFIER id-shake128 -- with output length 32 bytes. 553 } 554 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 555 us(840) organization(1) gov(101) 556 csor(3) nistAlgorithm(4) 557 hashAlgs(2) 11 } 559 -- SHAKE-256 560 mda-shake256 DIGEST-ALGORITHM ::= { 561 IDENTIFIER id-shake256 -- with output length 64 bytes. 562 } 563 id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 564 us(840) organization(1) gov(101) 565 csor(3) nistAlgorithm(4) 566 hashAlgs(2) 12 } 567 -- 568 -- KMAC Functions 569 -- KMAC with SHAKE128 570 KMACwithSHAKE128 MAC-ALGORITHM ::= { 571 IDENTIFIER id-KMACWithSHAKE128 572 PARAMS TYPE KMACwithSHAKE128-params ARE required 573 } 574 id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 575 country(16) us(840) organization(1) 576 gov(101) csor(3) nistAlgorithm(4) 577 hashAlgs(2) 19 } 578 KMACwithSHAKE128-params ::= SEQUENCE { 579 KMACOutputLength INTEGER DEFAULT 256, -- Output length in bits 580 customizationString OCTET STRING DEFAULT '' 581 } 583 -- KMAC with SHAKE256 584 KMACwithSHAKE256 MAC-ALGORITHM ::= { 585 IDENTIFIER id-KMACWithSHAKE256 586 PARAMS TYPE KMACwithSHAKE256-params ARE required 587 } 588 id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 589 country(16) us(840) organization(1) 590 gov(101) csor(3) nistAlgorithm(4) 591 hashAlgs(2) 20 } 592 KMACwithSHAKE256-params ::= SEQUENCE { 593 KMACOutputLength INTEGER DEFAULT 512, -- Output length in bits 594 customizationString OCTET STRING DEFAULT '' 595 } 597 END 599 Authors' Addresses 601 Quynh Dang 602 NIST 603 100 Bureau Drive 604 Gaithersburg, MD 20899 606 Email: quynh.Dang@nist.gov 607 Panos Kampanakis 608 Cisco Systems 610 Email: pkampana@cisco.com