idnits 2.17.1 draft-ietf-lamps-cms-hash-sig-10.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 (18 September 2019) is 1680 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 291 -- Looks like a reference, but probably isn't: '1' on line 246 == Missing Reference: 'Nspk-2' is mentioned on line 186, but not defined == Missing Reference: 'Nspk-1' is mentioned on line 187, 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: 18 March 2020 18 September 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 with a given private key, and the number of 90 signing operations depends upon the size of the tree. The HSS/LMS 91 signature algorithm uses small public keys, and it has low 92 computational cost; however, the signatures are quite large. The 93 HSS/LMS private key can be very small when the signer is willing to 94 perform additional computation at signing time; alternatively, the 95 private key can consume additional memory and provide a faster 96 signing time. The HSS/LMS signatures [HASHSIG] are currently defined 97 to use exclusively SHA-256 [SHS]. 99 1.1. ASN.1 101 CMS values are generated using ASN.1 [ASN1-B], using the Basic 102 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 103 [ASN1-E]. 105 1.2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 1.3. Motivation 115 Recent advances in cryptanalysis [BH2013] and progress in the 116 development of quantum computers [NAS2019] pose a threat to widely 117 deployed digital signature algorithms. As a result, there is a need 118 to prepare for a day that cryptosystems such as RSA and DSA that 119 depend on discrete logarithm and factoring cannot be depended upon. 121 If large-scale quantum computers are ever built, these computers will 122 be able to break many of the public-key cryptosystems currently in 123 use. A post-quantum cryptosystem [PQC] is a system that is secure 124 against quantum computers that have more than a trivial number of 125 quantum bits (qubits). It is open to conjecture when it will be 126 feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA 127 are all vulnerable if large-scale quantum computers come to pass. 129 Since the HSS/LMS signature algorithm does not depend on the 130 difficulty of discrete logarithm or factoring, the HSS/LMS signature 131 algorithm is considered to be post-quantum secure. One use of post- 132 quantum secure signatures is the protection of software updates, 133 perhaps using the format described in [FWPROT], to enable deployment 134 of software that implements new cryptosystems. 136 2. HSS/LMS Hash-based Signature Algorithm Overview 138 Merkle Tree Signatures (MTS) are a method for signing a large but 139 fixed number of messages. An MTS system depends on a one-time 140 signature method and a collision-resistant hash function. 142 This specification makes use of the hash-based algorithm specified in 143 [HASHSIG], which is the Leighton and Micali adaptation [LM] of the 144 original Lamport-Diffie-Winternitz-Merkle one-time signature system 145 [M1979][M1987][M1989a][M1989b]. 147 As implied by the name, the hash-based signature algorithm depends on 148 a collision-resistant hash function. The hash-based signature 149 algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash 150 function [SHS], but it establishes an IANA registry [IANA-LMS] to 151 permit the registration of additional one-way hash functions in the 152 future. 154 2.1. Hierarchical Signature System (HSS) 156 The MTS system specified in [HASHSIG] uses a hierarchy of trees. The 157 Hierarchical N-time Signature System (HSS) allows subordinate trees 158 to be generated when needed by the signer. Otherwise, generation of 159 the entire tree might take weeks or longer. 161 An HSS signature as specified in [HASHSIG] carries the number of 162 signed public keys (Nspk), followed by that number of signed public 163 keys, followed by the LMS signature as described in Section 2.2. The 164 public key for the top-most LMS tree is the public key of the HSS 165 system. The LMS private key in the parent tree signs the LMS public 166 key in the child tree, and the LMS private key in the bottom-most 167 tree signs the actual message. The signature over the public key and 168 the signature over the actual message are LMS signatures as described 169 in Section 2.2. 171 The elements of the HSS signature value for a stand-alone tree (a top 172 tree with no children) can be summarized as: 174 u32str(0) || 175 lms_signature /* signature of message */ 177 where, u32str() and || are used as defined in [HASHSIG]. 179 The elements of the HSS signature value for a tree with Nspk signed 180 public keys can be summarized as: 182 u32str(Nspk) || 183 signed_public_key[0] || 184 signed_public_key[1] || 185 ... 186 signed_public_key[Nspk-2] || 187 signed_public_key[Nspk-1] || 188 lms_signature /* signature of message */ 190 where, as defined in Section 3.3 of [HASHSIG], the signed_public_key 191 structure contains the lms_signature over the public key followed by 192 the public key itself. Note that Nspk is the number of levels in the 193 hierarchy of trees minus 1. 195 2.2. Leighton-Micali Signature (LMS) 197 Each tree in the system specified in [HASHSIG] uses the Leighton- 198 Micali Signature (LMS) system. LMS systems have two parameters. The 199 first parameter is the height of the tree, h, which is the number of 200 levels in the tree minus one. The [HASHSIG] specification supports 201 five values for this parameter: h=5; h=10; h=15; h=20; and h=25. 202 Note that there are 2^h leaves in the tree. The second parameter, m, 203 is the number of bytes output by the hash function, and it is the 204 amount of data associated with each node in the tree. The [HASHSIG] 205 specification supports only the SHA-256 hash function [SHS], with 206 m=32. As a result, the [HASHSIG] specification supports five tree 207 sizes; they are identified as: 209 LMS_SHA256_M32_H5; 210 LMS_SHA256_M32_H10; 211 LMS_SHA256_M32_H15; 212 LMS_SHA256_M32_H20; and 213 LMS_SHA256_M32_H25. 215 The [HASHSIG] specification establishes an IANA registry [IANA-LMS] 216 to permit the registration of additional hash functions and 217 additional tree sizes in the future. 219 As specified in [HASHSIG], the LMS public key consists of four 220 elements: the lms_algorithm_type from the list above, the otstype to 221 identify the LM-OTS type as discussed in Section 2.3, the private key 222 identifier (I) as described in Section 5.3 of [HASHSIG], and the m- 223 byte string associated with the root node of the tree (T[1]). 225 The LMS public key can be summarized as: 227 u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] 229 As specified in [HASHSIG], an LMS signature consists of four 230 elements: the number of the leaf (q) associated with the LM-OTS 231 signature, an LM-OTS signature as described in Section 2.3, a 232 typecode indicating the particular LMS algorithm, and an array of 233 values that is associated with the path through the tree from the 234 leaf associated with the LM-OTS signature to the root. The array of 235 values contains the siblings of the nodes on the path from the leaf 236 to the root but does not contain the nodes on the path itself. The 237 array for a tree with height h will have h values. The first value 238 is the sibling of the leaf, the next value is the sibling of the 239 parent of the leaf, and so on up the path to the root. 241 The four elements of the LMS signature value can be summarized as: 243 u32str(q) || 244 ots_signature || 245 u32str(type) || 246 path[0] || path[1] || ... || path[h-1] 248 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) 250 Merkle Tree Signatures (MTS) depend on a one-time signature method, 251 and [HASHSIG] specifies the use of the LM-OTS, which has five 252 parameters: 254 n - The length in bytes of the hash function output. [HASHSIG] 255 supports only SHA-256 [SHS], with n=32. 257 H - A preimage-resistant hash function that accepts byte strings 258 of any length, and returns an n-byte string. 260 w - The width in bits of the Winternitz coefficients. [HASHSIG] 261 supports four values for this parameter: w=1; w=2; w=4; and 262 w=8. 264 p - The number of n-byte string elements that make up the LM-OTS 265 signature. 267 ls - The number of bits that are left-shifted in the final step of 268 the checksum function, which is defined in Section 4.4 of 269 [HASHSIG]. 271 The values of p and ls are dependent on the choices of the parameters 272 n and w, as described in Appendix B of [HASHSIG]. 274 The [HASHSIG] specification supports four LM-OTS variants: 276 LMOTS_SHA256_N32_W1; 277 LMOTS_SHA256_N32_W2; 278 LMOTS_SHA256_N32_W4; and 279 LMOTS_SHA256_N32_W8. 281 The [HASHSIG] specification establishes an IANA registry [IANA-LMS] 282 to permit the registration of additional variants in the future. 284 Signing involves the generation of C, an n-byte random value. 286 The LM-OTS signature value can be summarized as the identifier of the 287 LM-OTS variant, the random value, and a sequence of hash values (y[0] 288 through y[p-1]) that correspond to the elements of the public key as 289 described in Section 4.5 of [HASHSIG]: 291 u32str(otstype) || C || y[0] || ... || y[p-1] 293 3. Algorithm Identifiers and Parameters 295 The algorithm identifier for an HSS/LMS hash-based signatures is: 297 id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) 298 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 299 smime(16) alg(3) 17 } 301 When this object identifier is used for an HSS/LMS signature, the 302 AlgorithmIdentifier parameters field MUST be absent (that is, the 303 parameters are not present; the parameters are not set to NULL). 305 The signature value is a large OCTET STRING as described in Section 2 306 of this document. The signature format is designed for easy parsing. 307 The HSS, LMS, and LMOTS component of the signature value each format 308 include a counter and a type code that indirectly provide all of the 309 information that is needed to parse the value during signature 310 validation. 312 The signature value identifies the hash function used in the HSS/LMS 313 tree. In [HASHSIG] uses only the SHA-256 hash function [SHS], but it 314 establishes an IANA registry [IANA-LMS] to permit the registration of 315 additional hash functions in the future. 317 4. HSS/LMS Public Key Identifier 319 The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- 320 hss-lms-hashsig object identifier, and the parameters field MUST be 321 absent. 323 When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo 324 field of an X.509 certificate [RFC5280], the certificate key usage 325 extension MAY contain digitalSignature, nonRepudiation, keyCertSign, 326 and cRLSign; however, it MUST NOT contain other values. 328 pk-HSS-LMS-HashSig PUBLIC-KEY ::= { 329 IDENTIFIER id-alg-hss-lms-hashsig 330 KEY HSS-LMS-HashSig-PublicKey 331 PARAMS ARE absent 332 CERT-KEY-USAGE 333 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } 335 HSS-LMS-HashSig-PublicKey ::= OCTET STRING 337 Note that the id-alg-hss-lms-hashsig algorithm identifier is also 338 referred to as id-alg-mts-hashsig. This synonym is based on the 339 terminology used in an early draft of the document that became 340 [HASHSIG]. 342 The public key value is an OCTET STRING. Like the signature format, 343 it is designed for easy parsing. The value is the number of levels 344 in the public key, L, followed by the LMS public key. 346 The HSS/LMS public key value can be described as: 348 u32str(L) || lms_public_key 350 Note that the public key for the top-most LMS tree is the public key 351 of the HSS system. When L=1, the HSS system is a single tree. 353 5. Signed-data Conventions 355 As specified in [CMS], the digital signature is produced from the 356 message digest and the signer's private key. The signature is 357 computed over different values depending on whether signed attributes 358 are absent or present. 360 When signed attributes are absent, the HSS/LMS signature is computed 361 over the content. When signed attributes are present, a hash is 362 computed over the content using the same hash function that is used 363 in the HSS/LMS tree, and then a message-digest attribute is 364 constructed with the hash of the content, and then the HSS/LMS 365 signature is computed over the DER-encoded set of signed attributes 366 (which MUST include a content-type attribute and a message-digest 367 attribute). In summary: 369 IF (signed attributes are absent) 370 THEN HSS_LMS_Sign(content) 371 ELSE message-digest attribute = Hash(content); 372 HSS_LMS_Sign(DER(SignedAttributes)) 374 When using [HASHSIG], the fields in the SignerInfo are used as 375 follows: 377 digestAlgorithm MUST contain the one-way hash function used in the 378 HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported hash 379 function, but other hash functions might be registered in the 380 future. For convenience, the AlgorithmIdentifier for SHA-256 381 from [PKIXASN1] is repeated here: 383 mda-sha256 DIGEST-ALGORITHM ::= { 384 IDENTIFIER id-sha256 385 PARAMS TYPE NULL ARE preferredAbsent } 387 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 388 country(16) us(840) organization(1) gov(101) csor(3) 389 nistAlgorithms(4) hashalgs(2) 1 } 391 signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the 392 algorithm parameters field MUST be absent. 394 signature contains the single HSS signature value resulting from 395 the signing operation as specified in [HASHSIG]. 397 6. Security Considerations 399 Implementations MUST protect the private keys. Compromise of the 400 private keys may result in the ability to forge signatures. Along 401 with the private key, the implementation MUST keep track of which 402 leaf nodes in the tree have been used. Loss of integrity of this 403 tracking data can cause a one-time key to be used more than once. As 404 a result, when a private key and the tracking data are stored on non- 405 volatile media or stored in a virtual machine environment, failed 406 writes, virtual machine snapshotting or cloning, and other 407 operational concerns must be considered to ensure confidentiality and 408 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 (PRNG) to generate these values is much less severe 429 than in 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, Ben Kaduk, Panos 626 Kampanakis, Barry Leiba, John Mattsson, Jim Schaad, Sean Turner, 627 Daniel Van Geest, Roman Danyliw, Dale Worley, and Joe Clarke for 628 their careful review and 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