idnits 2.17.1 draft-ietf-lamps-cms-hash-sig-09.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 (10 August 2019) is 1718 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 294 -- Looks like a reference, but probably isn't: '1' on line 249 == Missing Reference: 'Nspk-2' is mentioned on line 189, but not defined == Missing Reference: 'Nspk-1' is mentioned on line 190, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1-B' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1-E' ** Downref: Normative reference to an Informational RFC: RFC 8554 (ref. 'HASHSIG') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Internet Engineering Task Force (IETF) Vigil Security 4 Intended Status: Proposed Standard 5 Expires: 10 February 2020 10 August 2019 7 Use of the HSS/LMS Hash-based Signature Algorithm 8 in the Cryptographic Message Syntax (CMS) 9 11 Abstract 13 This document specifies the conventions for using the Hierarchical 14 Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based 15 signature algorithm with the Cryptographic Message Syntax (CMS). In 16 addition, the algorithm identifier and public key syntax are 17 provided. The HSS/LMS algorithm is one form of hash-based digital 18 signature; it is described in RFC 8554. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 4 63 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 64 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 65 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6 66 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 7 67 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 8 68 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13 75 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 This document specifies the conventions for using the Hierarchical 81 Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based 82 signature algorithm with the Cryptographic Message Syntax (CMS) [CMS] 83 signed-data content type. The LMS system provides a one-time digital 84 signature that is a variant of Merkle Tree Signatures (MTS). The HSS 85 is built on top of the LMS system to efficiently scale for a larger 86 numbers of signatures. The HSS/LMS algorithm is one form of hash- 87 based digital signature, and it is described in [HASHSIG]. The 88 HSS/LMS signature algorithm can only be used for a fixed number of 89 signing operations. The number of signing operations depends upon 90 the size of the tree. The HSS/LMS signature algorithm uses small 91 public keys, and it has low computational cost; however, the 92 signatures are quite large. The HSS/LMS private key can be very 93 small when the signer is willing to perform additional computation at 94 signing time; alternatively, the private key can consume additional 95 memory and provide a faster signing time. The HSS/LMS signatures 96 [HASHSIG] are currently defined to use exclusively SHA-256 [SHS]. 98 1.1. ASN.1 100 CMS values are generated using ASN.1 [ASN1-B], using the Basic 101 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 102 [ASN1-E]. 104 1.2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 1.3. Motivation 114 There have been recent advances in cryptanalysis and advances in the 115 development of quantum computers. Each of these advances pose a 116 threat to widely deployed digital signature algorithms. 118 Recent advances in cryptoanalysis [BH2013] and progress in the 119 development of quantum computers [NAS2019] pose a threat to widely 120 deployed digital signature algorithms. As a result, there is a need 121 to prepare for a day that cryptosystems such as RSA and DSA that 122 depend on discrete logarithm and factoring cannot be depended upon. 124 If large-scale quantum computers are ever built, these computers will 125 be able to break many of the public-key cryptosystems currently in 126 use. A post-quantum cryptosystem [PQC] is a system that is secure 127 against quantum computers that have more than a trivial number of 128 quantum bits (qu-bits). It is open to conjecture when it will be 129 feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA 130 are all vulnerable if large-scale quantum computers come to pass. 132 The HSS/LMS signature algorithm does not depend on the difficulty of 133 discrete logarithm or factoring, as a result these algorithms are 134 considered to be post-quantum secure. One use of post-quantum secure 135 signatures is the protection of software updates, perhaps using the 136 format described in [FWPROT], to enable deployment of software that 137 implements new cryptosystems. 139 2. HSS/LMS Hash-based Signature Algorithm Overview 141 Merkle Tree Signatures (MTS) are a method for signing a large but 142 fixed number of messages. An MTS system depends on a one-time 143 signature method and a collision-resistant hash function. 145 This specification makes use of the hash-based algorithm specified in 146 [HASHSIG], which is the Leighton and Micali adaptation [LM] of the 147 original Lamport-Diffie-Winternitz-Merkle one-time signature system 148 [M1979][M1987][M1989a][M1989b]. 150 As implied by the name, the hash-based signature algorithm depends on 151 a collision-resistant hash function. The hash-based signature 152 algorithm specified in [HASHSIG] currently uses only the SHA-256 one- 153 way hash function [SHS], but it also establishes an IANA registry 154 [IANA-LMS] to permit the registration of additional one-way hash 155 functions in the future. 157 2.1. Hierarchical Signature System (HSS) 159 The MTS system specified in [HASHSIG] uses a hierarchy of trees. The 160 Hierarchical N-time Signature System (HSS) allows subordinate trees 161 to be generated when needed by the signer. Otherwise, generation of 162 the entire tree might take weeks or longer. 164 An HSS signature as specified in [HASHSIG] carries the number of 165 signed public keys (Nspk), followed by that number of signed public 166 keys, followed by the LMS signature as described in Section 2.2. The 167 public key for the top-most LMS tree is the public key of the HSS 168 system. The LMS private key in the parent tree signs the LMS public 169 key in the child tree, and the LMS private key in the bottom-most 170 tree signs the actual message. The signature over the public key and 171 the signature over the actual message are LMS signatures as described 172 in Section 2.2. 174 The elements of the HSS signature value for a stand-alone tree (a top 175 tree with no children) can be summarized as: 177 u32str(0) || 178 lms_signature /* signature of message */ 180 where, u32str() and || are used as defined in [HASHSIG]. 182 The elements of the HSS signature value for a tree with Nspk signed 183 public keys can be summarized as: 185 u32str(Nspk) || 186 signed_public_key[0] || 187 signed_public_key[1] || 188 ... 189 signed_public_key[Nspk-2] || 190 signed_public_key[Nspk-1] || 191 lms_signature /* signature of message */ 193 where, as defined in Section 3.3 of [HASHSIG], the signed_public_key 194 structure contains the lms_signature over the public key followed by 195 the public key itself. Note that Nspk is the number of levels in the 196 hierarchy of trees minus 1. 198 2.2. Leighton-Micali Signature (LMS) 200 Each tree in the system specified in [HASHSIG] uses the Leighton- 201 Micali Signature (LMS) system. LMS systems have two parameters. The 202 first parameter is the height of the tree, h, which is the number of 203 levels in the tree minus one. The [HASHSIG] specification supports 204 five values for this parameter: h=5; h=10; h=15; h=20; and h=25. 205 Note that there are 2^h leaves in the tree. The second parameter is 206 the number of bytes output by the hash function, m, which is the 207 amount of data associated with each node in the tree. The [HASHSIG] 208 specification supports only the SHA-256 hash function [SHS], with 209 m=32. As a result, the [HASHSIG] specification supports five tree 210 sizes; they are identified as: 212 LMS_SHA256_M32_H5; 213 LMS_SHA256_M32_H10; 214 LMS_SHA256_M32_H15; 215 LMS_SHA256_M32_H20; and 216 LMS_SHA256_M32_H25. 218 The [HASHSIG] specification establishes an IANA registry [IANA-LMS] 219 to permit the registration of additional hash functions and 220 additional tree sizes in the future. 222 As specified in [HASHSIG], the LMS public key consists of four 223 elements: the lms_algorithm_type from the list above, the otstype to 224 identify the LM-OTS type as discussed in Section 2.3, the private key 225 identifier (I) as described in Section 5.3 of [HASHSIG], and the m- 226 byte string associated with the root node of the tree (T[1]). 228 The LMS public key can be summarized as: 230 u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] 232 As specified in [HASHSIG], an LMS signature consists of four 233 elements: the number of the leaf (q) associated with the LM-OTS 234 signature, an LM-OTS signature as described in Section 2.3, a 235 typecode indicating the particular LMS algorithm, and an array of 236 values that is associated with the path through the tree from the 237 leaf associated with the LM-OTS signature to the root. The array of 238 values contains the siblings of the nodes on the path from the leaf 239 to the root but does not contain the nodes on the path itself. The 240 array for a tree with height h will have h values. The first value 241 is the sibling of the leaf, the next value is the sibling of the 242 parent of the leaf, and so on up the path to the root. 244 The four elements of the LMS signature value can be summarized as: 246 u32str(q) || 247 ots_signature || 248 u32str(type) || 249 path[0] || path[1] || ... || path[h-1] 251 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) 253 Merkle Tree Signatures (MTS) depend on a one-time signature method, 254 and [HASHSIG] specifies the use of the LM-OTS, which has five 255 parameters: 257 n - The length in bytes of the hash function output. [HASHSIG] 258 supports only SHA-256 [SHS], with n=32. 260 H - A preimage-resistant hash function that accepts byte strings 261 of any length, and returns an n-byte string. 263 w - The width in bits of the Winternitz coefficients. [HASHSIG] 264 supports four values for this parameter: w=1; w=2; w=4; and 265 w=8. 267 p - The number of n-byte string elements that make up the LM-OTS 268 signature. 270 ls - The number of bits that are left-shifted in the final step of 271 the checksum function, which is defined in Section 4.4 of 272 [HASHSIG]. 274 The values of p and ls are dependent on the choices of the parameters 275 n and w, as described in Appendix B of [HASHSIG]. 277 The [HASHSIG] specification supports four LM-OTS variants: 279 LMOTS_SHA256_N32_W1; 280 LMOTS_SHA256_N32_W2; 281 LMOTS_SHA256_N32_W4; and 282 LMOTS_SHA256_N32_W8. 284 The [HASHSIG] specification establishes an IANA registry [IANA-LMS] 285 to permit the registration of additional variants in the future. 287 Signing involves the generation of C, an n-byte random value. 289 The LM-OTS signature value can be summarized as the identifier of the 290 LM-OTS variant, the random value, and a sequence of hash values (y[0] 291 through y[p-1]) that correspond to the elements of the public key as 292 described in Section 4.5 of [HASHSIG]: 294 u32str(otstype) || C || y[0] || ... || y[p-1] 296 3. Algorithm Identifiers and Parameters 298 The algorithm identifier for an HSS/LMS hash-based signatures is: 300 id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) 301 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 302 smime(16) alg(3) 17 } 304 When this object identifier is used for an HSS/LMS signature, the 305 AlgorithmIdentifier parameters field MUST be absent (that is, the 306 parameters are not present; the parameters are not set to NULL). 308 The signature value is a large OCTET STRING. The signature format is 309 designed for easy parsing. Each format includes a counter and type 310 codes that indirectly providing all of the information that is needed 311 to parse the value during signature validation. 313 The signature value identifies the hash function used in the HSS/LMS 314 tree. In [HASHSIG] only the SHA-256 hash function [SHS] is 315 supported, but it also establishes an IANA registry [IANA-LMS] to 316 permit the registration of additional hash functions in the future. 318 4. HSS/LMS Public Key Identifier 320 The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- 321 hss-lms-hashsig object identifier, and the parameters field MUST be 322 absent. 324 When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo 325 field of an X.509 certificate [RFC5280], the certificate key usage 326 extension MAY contain digitalSignature, nonRepudiation, keyCertSign, 327 and cRLSign; however, it MUST NOT contain other values. 329 pk-HSS-LMS-HashSig PUBLIC-KEY ::= { 330 IDENTIFIER id-alg-hss-lms-hashsig 331 KEY HSS-LMS-HashSig-PublicKey 332 PARAMS ARE absent 333 CERT-KEY-USAGE 334 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } 336 HSS-LMS-HashSig-PublicKey ::= OCTET STRING 338 Note that the id-alg-hss-lms-hashsig algorithm identifier is also 339 referred to as id-alg-mts-hashsig. This synonym is based on the 340 terminology used in an early draft of the document that became 341 [HASHSIG]. 343 The public key value is an OCTET STRING. Like the signature format, 344 it is designed for easy parsing. The value is the number of levels 345 in the public key, L, followed by the LMS public key. 347 The HSS/LMS public key value can be summarized as: 349 u32str(L) || lms_public_key 351 Note that the public key for the top-most LMS tree is the public key 352 of the HSS system. When L=1, the HSS system is a single tree. 354 5. Signed-data Conventions 356 As specified in [CMS], the digital signature is produced from the 357 message digest and the signer's private key. The signature is 358 computed over different values depending on whether signed attributes 359 are absent or present. 361 When signed attributes are absent, the HSS/LMS signature is computed 362 over the content. When signed attributes are present, a hash is 363 computed over the content using the same hash function that is used 364 in the HSS/LMS tree, and then a message-digest attribute is 365 constructed to contain the resulting hash value, and then the result 366 of DER encoding the set of signed attributes (which MUST include a 367 content-type attribute and a message-digest attribute, and then the 368 HSS/LMS signature is computed over the DER-encoded output. In 369 summary: 371 IF (signed attributes are absent) 372 THEN HSS_LMS_Sign(content) 373 ELSE message-digest attribute = Hash(content); 374 HSS_LMS_Sign(DER(SignedAttributes)) 376 When using [HASHSIG], the fields in the SignerInfo are used as 377 follows: 379 digestAlgorithm MUST contain the one-way hash function used to in 380 the HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported 381 hash function, but other hash functions might be registered in 382 the future. For convenience, the AlgorithmIdentifier for 383 SHA-256 from [PKIXASN1] is repeated here: 385 mda-sha256 DIGEST-ALGORITHM ::= { 386 IDENTIFIER id-sha256 387 PARAMS TYPE NULL ARE preferredAbsent } 389 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 390 country(16) us(840) organization(1) gov(101) csor(3) 391 nistAlgorithms(4) hashalgs(2) 1 } 393 signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the 394 algorithm parameters field MUST be absent. 396 signature contains the single HSS signature value resulting from 397 the signing operation as specified in [HASHSIG]. 399 6. Security Considerations 401 Implementations MUST protect the private keys. Compromise of the 402 private keys may result in the ability to forge signatures. Along 403 with the private key, the implementation MUST keep track of which 404 leaf nodes in the tree have been used. Loss of integrity of this 405 tracking data can cause a one-time key to be used more than once. As 406 a result, when a private key and the tracking data are stored on non- 407 volatile media or stored in a virtual machine environment, care must 408 be taken to preserve confidentiality and integrity. 410 When generating an LMS key pair, an implementation MUST generate each 411 key pair independently of all other key pairs in the HSS tree. 413 An implementation MUST ensure that a LM-OTS private key is used to 414 generate a signature only one time, and ensure that it cannot be used 415 for any other purpose. 417 The generation of private keys relies on random numbers. The use of 418 inadequate pseudo-random number generators (PRNGs) to generate these 419 values can result in little or no security. An attacker may find it 420 much easier to reproduce the PRNG environment that produced the keys, 421 searching the resulting small set of possibilities, rather than brute 422 force searching the whole key space. The generation of quality 423 random numbers is difficult, and [RFC4086] offers important guidance 424 in this area. 426 The generation of hash-based signatures also depends on random 427 numbers. While the consequences of an inadequate pseudo-random 428 number generator (PRNGs) to generate these values is much less severe 429 than the generation of private keys, the guidance in [RFC4086] 430 remains important. 432 When computing signatures, the same hash function SHOULD be used to 433 compute the message digest of the content and the signed attributes, 434 if they are present. 436 7. IANA Considerations 438 SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) 439 registry, change the reference for value 64 to point to this 440 document. 442 In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) 443 registry, change the description for value 17 to 444 "id-alg-hss-lms-hashsig" and change the reference to point to this 445 document. 447 Also, add the following note to the registry: 449 Value 17, "id-alg-hss-lms-hashsig", is also referred to as 450 "id-alg-mts-hashsig". 452 8. References 454 8.1. Normative References 456 [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation 457 One (ASN.1): Specification of basic notation", ITU-T 458 Recommendation X.680, 2015. 460 [ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: 461 Specification of Basic Encoding Rules (BER), Canonical 462 Encoding Rules (CER) and Distinguished Encoding Rules 463 (DER)", ITU-T Recommendation X.690, 2015. 465 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 466 RFC 5652, DOI 10.17487/RFC5652, September 2009, 467 . 469 [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali 470 Hash-Based Signatures", RFC 8554, April 2019, 471 . 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, DOI 475 10.17487/RFC2119, March 1997, . 478 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 479 Housley, R., and W. Polk, "Internet X.509 Public Key 480 Infrastructure Certificate and Certificate Revocation List 481 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 482 . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 485 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 486 10.17487/RFC8174, May 2017, . 489 [SHS] National Institute of Standards and Technology (NIST), 490 FIPS Publication 180-3: Secure Hash Standard, October 491 2008. 493 8.2. Informative References 495 [BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The 496 Factoring Dead: Preparing for the Cryptopocalypse", August 497 2013. 500 [CMSASN1] 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, . 505 [CMSASN1U] 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, DOI 508 10.17487/RFC6268, July 2011, . 511 [FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to 512 Protect Firmware Packages", RFC 4108, DOI 513 10.17487/RFC4108, August 2005, . 516 [IANA-LMS] IANA Registry for Leighton-Micali Signatures (LMS). 517 . 520 [LM] Leighton, T. and S. Micali, "Large provably fast and 521 secure digital signature schemes from secure hash 522 functions", U.S. Patent 5,432,852, July 1995. 524 [M1979] Merkle, R., "Secrecy, Authentication, and Public Key 525 Systems", Stanford University Information Systems 526 Laboratory Technical Report 1979-1, 1979. 528 [M1987] Merkle, R., "A Digital Signature Based on a Conventional 529 Encryption Function", Lecture Notes in Computer Science 530 crypto87, 1988. 532 [M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes 533 in Computer Science crypto89, 1990. 535 [M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture Notes 536 in Computer Science crypto89, 1990. 538 [NAS2019] National Academies of Sciences, Engineering, and Medicine, 539 "Quantum Computing: Progress and Prospects", The National 540 Academies Press, DOI 10.17226/25196, 2019. 542 [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 543 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 544 DOI 10.17487/RFC5912, June 2010, . 547 [PQC] Bernstein, D., "Introduction to post-quantum 548 cryptography", 2009. 549 552 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 553 "Randomness Requirements for Security", BCP 106, RFC 4086, 554 DOI 10.17487/RFC4086, June 2005, . 557 Appendix: ASN.1 Module 559 561 MTS-HashSig-2013 562 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 563 id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } 565 DEFINITIONS IMPLICIT TAGS ::= BEGIN 567 EXPORTS ALL; 569 IMPORTS 570 PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS 571 FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1] 572 { iso(1) identified-organization(3) dod(6) internet(1) 573 security(5) mechanisms(5) pkix(7) id-mod(0) 574 id-mod-algorithmInformation-02(58) } ; 576 -- 577 -- Object Identifiers 578 -- 580 id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) 581 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 582 smime(16) alg(3) 17 } 584 id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig 586 -- 587 -- Signature Algorithm and Public Key 588 -- 590 sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= { 591 IDENTIFIER id-alg-hss-lms-hashsig 592 PARAMS ARE absent 593 PUBLIC-KEYS { pk-HSS-LMS-HashSig } 594 SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } } 596 pk-HSS-LMS-HashSig PUBLIC-KEY ::= { 597 IDENTIFIER id-alg-hss-lms-hashsig 598 KEY HSS-LMS-HashSig-PublicKey 599 PARAMS ARE absent 600 CERT-KEY-USAGE 601 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } 603 HSS-LMS-HashSig-PublicKey ::= OCTET STRING 605 -- 606 -- Expand the signature algorithm set used by CMS [CMSASN1U] 607 -- 609 SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= 610 { sa-HSS-LMS-HashSig, ... } 612 -- 613 -- Expand the S/MIME capabilities set used by CMS [CMSASN1] 614 -- 616 SMimeCaps SMIME-CAPS ::= 617 { sa-HSS-LMS-HashSig.&smimeCaps, ... } 619 END 621 623 Acknowledgements 625 Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, 626 John Mattsson, Jim Schaad, Sean Turner, Daniel Van Geest, Roman 627 Danyliw, Dale Worley, and Joe Clarke for their careful review and 628 comments. 630 Author's Address 632 Russ Housley 633 Vigil Security, LLC 634 516 Dranesville Road 635 Herndon, VA 20170 636 USA 638 EMail: housley@vigilsec.com