idnits 2.17.1 draft-ietf-lamps-cms-hash-sig-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([HASHSIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 86 has weird spacing: '... larger numbe...' -- The document date (22 February 2019) is 1889 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 302 -- Looks like a reference, but probably isn't: '1' on line 258 == Missing Reference: 'Nspk-2' is mentioned on line 198, but not defined == Missing Reference: 'Nspk-1' is mentioned on line 199, but not defined == Unused Reference: 'PQC' is defined on line 551, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1-B' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1-E' -- Possible downref: Non-RFC (?) normative reference: ref. 'HASHSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 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: 22 August 2019 22 February 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 the HSS/LMS 14 hash-based signature algorithm with the Cryptographic Message Syntax 15 (CMS). In addition, the algorithm identifier and public key syntax 16 are provided. The HSS/LMS algorithm is one form of hash-based 17 digital signature; it is described in [HASHSIG]. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 3 61 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 62 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 4 63 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 5 64 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 6 65 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7 66 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6.1. Implementation Security Considerations . . . . . . . . . . 9 69 6.2. Algorithm Security Considerations . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 This document specifies the conventions for using the HSS/LMS hash- 81 based signature algorithm with the Cryptographic Message Syntax (CMS) 82 [CMS] signed-data content type. The Leighton-Micali Signature (LMS) 83 system provides a one-time digital signature that is a variant of 84 Merkle Tree Signatures (MTS). The Hierarchical Signature System 85 (HSS) is built on top of the LMS system to efficiently scale for a 86 larger numbers of signatures. The HSS/LMS algorithm is one form of 87 hash-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. 97 Well, yes, there is quite a range of possible time/memory trade-offs 98 available when storing the private key; if you need to, the private 99 key can be expressed in quite a small amount of space (albeit at the 100 expense of making the signature generation operation expensive). 102 1.1. ASN.1 104 CMS values are generated using ASN.1 [ASN1-B], using the Basic 105 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 106 [ASN1-E]. 108 1.2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 1.3. Algorithm Considerations 118 At Black Hat USA 2013, some researchers gave a presentation on the 119 current state of public key cryptography. They said: "Current 120 cryptosystems depend on discrete logarithm and factoring which has 121 seen some major new developments in the past 6 months" [BH2013]. 122 They encouraged preparation for a day when RSA and DSA cannot be 123 depended upon. 125 A post-quantum cryptosystem is a system that is secure against 126 quantum computers that have more than a trivial number of quantum 127 bits. It is open to conjecture when it will be feasible to build 128 such a machine. RSA, DSA, and ECDSA are not post-quantum secure. 130 The LM-OTS one-time signature, LMS, and HSS do not depend on discrete 131 logarithm or factoring, as a result these algorithms are considered 132 to be post-quantum secure. 134 Hash-based signatures [HASHSIG] are currently defined to use 135 exclusively SHA-256 [SHS]. An IANA registry is defined so that other 136 hash functions could be used in the future. LM-OTS signature 137 generation prepends a random string as well as other metadata before 138 computing the hash value. The inclusion of the random value reduces 139 the chances of an attacker being able to find collisions, even if the 140 attacker has a large-scale quantum computer. 142 Today, RSA is often used to digitally sign software updates. This 143 means that the distribution of software updates could be compromised 144 if a significant advance is made in factoring or a quantum computer 145 is invented. The use of HSS/LMS hash-based signatures to protect 146 software update distribution, perhaps using the format described in 147 [FWPROT], will allow the deployment of software that implements new 148 cryptosystems. 150 2. HSS/LMS Hash-based Signature Algorithm Overview 152 Merkle Tree Signatures (MTS) are a method for signing a large but 153 fixed number of messages. An MTS system depends on a one-time 154 signature method and a collision-resistant hash function. 156 This specification makes use of the hash-based algorithm specified in 157 [HASHSIG], which is the Leighton and Micali adaptation [LM] of the 158 original Lamport-Diffie-Winternitz-Merkle one-time signature system 159 [M1979][M1987][M1989a][M1989b]. 161 As implied by the name, the hash-based signature algorithm depends on 162 a collision-resistant hash function. The hash-based signature 163 algorithm specified in [HASHSIG] currently uses only the SHA-256 one- 164 way hash function [SHS], but it also establishes an IANA registry to 165 permit the registration of additional one-way hash functions in the 166 future. 168 2.1. Hierarchical Signature System (HSS) 170 The MTS system specified in [HASHSIG] uses a hierarchy of trees. The 171 Hierarchical N-time Signature System (HSS) allows subordinate trees 172 to be generated when needed by the signer. Otherwise, generation of 173 the entire tree might take weeks or longer. 175 An HSS signature as specified in [HASHSIG] carries the number of 176 signed public keys (Nspk), followed by that number of signed public 177 keys, followed by the LMS signature as described in Section 2.2. The 178 public key for the top-most LMS tree is the public key of the HSS 179 system. The LMS private key in the parent tree signs the LMS public 180 key in the child tree, and the LMS private key in the bottom-most 181 tree signs the actual message. The signature over the public key and 182 the signature over the actual message are LMS signatures as described 183 in Section 2.2. 185 The elements of the HSS signature value for a stand-alone tree (a top 186 tree with no children) can be summarized as: 188 u32str(0) || 189 lms_signature /* signature of message */ 191 The elements of the HSS signature value for a tree with Nspk signed 192 public keys can be summarized as: 194 u32str(Nspk) || 195 signed_public_key[0] || 196 signed_public_key[1] || 197 ... 198 signed_public_key[Nspk-2] || 199 signed_public_key[Nspk-1] || 200 lms_signature /* signature of message */ 202 where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is 203 the lms_signature over the public key followed by the public key 204 itself. Note that Nspk is the number of levels in the hierarchy of 205 trees minus 1. 207 2.2. Leighton-Micali Signature (LMS) 209 Each tree in the system specified in [HASHSIG] uses the Leighton- 210 Micali Signature (LMS) system. LMS systems have two parameters. The 211 first parameter is the height of the tree, h, which is the number of 212 levels in the tree minus one. The [HASHSIG] specification supports 213 five values for this parameter: h=5; h=10; h=15; h=20; and h=25. 214 Note that there are 2^h leaves in the tree. The second parameter is 215 the number of bytes output by the hash function, m, which is the 216 amount of data associated with each node in the tree. The [HASHSIG] 217 specification supports only the SHA-256 hash function [SHS], with 218 m=32. 220 The [HASHSIG] specification supports five tree sizes: 222 LMS_SHA256_M32_H5; 223 LMS_SHA256_M32_H10; 224 LMS_SHA256_M32_H15; 225 LMS_SHA256_M32_H20; and 226 LMS_SHA256_M32_H25. 228 The [HASHSIG] specification establishes an IANA registry to permit 229 the registration of additional tree sizes in the future. 231 The LMS public key is the string consists of four elements: the 232 lms_algorithm_type from the list above, the otstype to identify the 233 LM-OTS type as discussed in Section 2.3, the private key identifier 234 (I) as described in Section 5.3 of [HASHSIG], and the m-byte string 235 associated with the root node of the tree. 237 The LMS public key can be summarized as: 239 u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] 241 An LMS signature consists of four elements: the number of the leaf 242 (q) associated with the LM-OTS signature, an LM-OTS signature as 243 described in Section 2.3, a typecode indicating the particular LMS 244 algorithm, and an array of values that is associated with the path 245 through the tree from the leaf associated with the LM-OTS signature 246 to the root. The array of values contains the siblings of the nodes 247 on the path from the leaf to the root but does not contain the nodes 248 on the path itself. The array for a tree with height h will have h 249 values. The first value is the sibling of the leaf, the next value 250 is the sibling of the parent of the leaf, and so on up the path to 251 the root. 253 The four elements of the LMS signature value can be summarized as: 255 u32str(q) || 256 ots_signature || 257 u32str(type) || 258 path[0] || path[1] || ... || path[h-1] 260 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) 262 Merkle Tree Signatures (MTS) depend on a one-time signature method. 263 [HASHSIG] specifies the use of the LM-OTS. An LM-OTS has five 264 parameters. 266 n - The number of bytes associated with the hash function. 267 [HASHSIG] supports only SHA-256 [SHS], with n=32. 269 H - A preimage-resistant hash function that accepts byte strings 270 of any length, and returns an n-byte string. 272 w - The width in bits of the Winternitz coefficients. [HASHSIG] 273 supports four values for this parameter: w=1; w=2; w=4; and 274 w=8. 276 p - The number of n-byte string elements that make up the LM-OTS 277 signature. 279 ls - The number of left-shift bits used in the checksum function, 280 which is defined in Section 4.4 of [HASHSIG]. 282 The values of p and ls are dependent on the choices of the parameters 283 n and w, as described in Appendix B of [HASHSIG]. 285 The [HASHSIG] specification supports four LM-OTS variants: 287 LMOTS_SHA256_N32_W1; 288 LMOTS_SHA256_N32_W2; 289 LMOTS_SHA256_N32_W4; and 290 LMOTS_SHA256_N32_W8. 292 The [HASHSIG] specification establishes an IANA registry to permit 293 the registration of additional variants in the future. 295 Signing involves the generation of C, an n-byte random value. 297 The LM-OTS signature value can be summarized as the identifier of the 298 LM-OTS variant, the random value, and a sequence of hash values that 299 correspond to the elements of the public key as described in Section 300 4.5 of [HASHSIG]: 302 u32str(otstype) || C || y[0] || ... || y[p-1] 304 3. Algorithm Identifiers and Parameters 306 The algorithm identifier for an HSS/LMS hash-based signatures is: 308 id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) 309 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 310 smime(16) alg(3) 17 } 312 When this object identifier is used for a HSS/LMS signature, the 313 AlgorithmIdentifier parameters field MUST be absent (that is, the 314 parameters are not present; the parameters are not set to NULL). 316 The signature value is a large OCTET STRING. The signature format is 317 designed for easy parsing. Each format includes a counter and type 318 codes that indirectly providing all of the information that is needed 319 to parse the value during signature validation. 321 The signature value identifies the hash function used in the HSS/LMS 322 tree. In [HASHSIG] only the SHA-256 hash function [SHS] is 323 supported, but it also establishes an IANA registry to permit the 324 registration of additional hash functions in the future. 326 4. HSS/LMS Public Key Identifier 328 The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- 329 hss-lms-hashsig object identifier, and the parameters field MUST be 330 absent. 332 When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo 333 field of an X.509 certificate [RFC5280], the certificate key usage 334 extension MAY contain digitalSignature, nonRepudiation, keyCertSign, 335 and cRLSign; however, it MUST NOT contain other values. 337 pk-HSS-LMS-HashSig PUBLIC-KEY ::= { 338 IDENTIFIER id-alg-hss-lms-hashsig 339 KEY HSS-LMS-HashSig-PublicKey 340 PARAMS ARE absent 341 CERT-KEY-USAGE 342 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } 344 HSS-LMS-HashSig-PublicKey ::= OCTET STRING 346 Note that the id-alg-hss-lms-hashsig algorithm identifier is also 347 referred to as id-alg-mts-hashsig. This synonym is based on the 348 terminology used in an early draft of the document that became 349 [HASHSIG]. 351 The public key value is an OCTET STRING. Like the signature format, 352 it is designed for easy parsing. The value is the number of levels 353 in the public key, L, followed by the LMS public key. 355 The HSS/LMS public key value can be summarized as: 357 u32str(L) || lms_public_key 359 Note that the public key for the top-most LMS tree is the public key 360 of the HSS system. When L=1, the HSS system is a single tree. 362 5. Signed-data Conventions 364 As specified in [CMS], the digital signature is produced from the 365 message digest and the signer's private key. The signature is 366 computed over different value depending on whether signed attributes 367 are absent or present. When signed attributes are absent, the 368 HSS/LMS signature is computed over the content. When signed 369 attributes are present, a hash is computed over the content using the 370 same hash function that is used in the HSS/LMS tree, and then a 371 message-digest attribute is constructed with the resulting hash 372 value, and then DER encode the set of signed attributes, which MUST 373 include a content-type attribute and a message-digest attribute, and 374 then the HSS/LMS signature is computed over the output of the DER- 375 encode operation. In summary: 377 IF (signed attributes are absent) 378 THEN HSS_LMS_Sign(content) 379 ELSE message-digest attribute = Hash(content); 380 HSS_LMS_Sign(DER(SignedAttributes)) 382 When using [HASHSIG], the fields in the SignerInfo are used as 383 follows: 385 digestAlgorithm MUST contain the one-way hash function used to in 386 the HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported 387 hash function, but other hash functions might be registered in 388 the future. For convenience, the AlgorithmIdentifier for 389 SHA-256 from [PKIXASN1] is repeated here: 391 mda-sha256 DIGEST-ALGORITHM ::= { 392 IDENTIFIER id-sha256 393 PARAMS TYPE NULL ARE preferredAbsent } 395 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 396 country(16) us(840) organization(1) gov(101) csor(3) 397 nistAlgorithms(4) hashalgs(2) 1 } 399 signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the 400 algorithm parameters field MUST be absent. 402 signature contains the single HSS signature value resulting from 403 the signing operation as specified in [HASHSIG]. 405 6. Security Considerations 407 Implementations MUST protect the private keys. Compromise of the 408 private keys may result in the ability to forge signatures. Along 409 with the private key, the implementation MUST keep track of which 410 leaf nodes in the tree have been used. Loss of integrity of this 411 tracking data can cause an one-time key to be used more than once. 412 As a result, when a private key and the tracking data are stored on 413 non-volatile media or stored in a virtual machine environment, care 414 must be taken to preserve confidentiality and integrity. 416 When generating a LMS key pair, an implementation MUST generate each 417 key pair independently of all other key pairs in the HSS tree. 419 An implementation MUST ensure that a LM-OTS private key is used to 420 generate a signature only one time, and ensure that it cannot be used 421 for any other purpose. 423 The generation of private keys relies on random numbers. The use of 424 inadequate pseudo-random number generators (PRNGs) to generate these 425 values can result in little or no security. An attacker may find it 426 much easier to reproduce the PRNG environment that produced the keys, 427 searching the resulting small set of possibilities, rather than brute 428 force searching the whole key space. The generation of quality 429 random numbers is difficult, and [RFC4086] offers important guidance 430 in this area. 432 The generation of hash-based signatures also depends on random 433 numbers. While the consequences of an inadequate pseudo-random 434 number generator (PRNGs) to generate these values is much less severe 435 than the generation of private keys, the guidance in [RFC4086] 436 remains important. 438 When computing signatures, the same hash function SHOULD be used to 439 compute the message digest of the content and the signed attributes, 440 if they are present. 442 7. IANA Considerations 444 SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) 445 registry, change the reference for value 64 to point to this 446 document. 448 In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) 449 registry, change the description for value 17 to 450 "id-alg-hss-lms-hashsig" and change the reference to point to this 451 document. 453 Also, add the following note to the registry: 455 Value 17, "id-alg-hss-lms-hashsig", is also referred to as 456 "id-alg-mts-hashsig". 458 8. Acknowledgements 460 Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, Jim 461 Schaad, Sean Turner, and Daniel Van Geest for their careful review 462 and comments. 464 9. References 466 9.1. Normative References 468 [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation 469 One (ASN.1): Specification of basic notation", ITU-T 470 Recommendation X.680, 2015. 472 [ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: 473 Specification of Basic Encoding Rules (BER), Canonical 474 Encoding Rules (CER) and Distinguished Encoding Rules 475 (DER)", ITU-T Recommendation X.690, 2015. 477 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 478 RFC 5652, DOI 10.17487/RFC5652, September 2009, 479 . 481 [HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based 482 Signatures", Work in progress. 483 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, DOI 487 10.17487/RFC2119, March 1997, . 490 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 491 Housley, R., and W. Polk, "Internet X.509 Public Key 492 Infrastructure Certificate and Certificate Revocation List 493 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 494 . 496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 497 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 498 10.17487/RFC8174, May 2017, . 501 [SHS] National Institute of Standards and Technology (NIST), 502 FIPS Publication 180-3: Secure Hash Standard, October 503 2008. 505 9.2. Informative References 507 [BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The 508 Factoring Dead: Preparing for the Cryptopocalypse", August 509 2013. 512 [CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 513 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 514 DOI 10.17487/RFC5911, June 2010, . 517 [CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 518 for the Cryptographic Message Syntax (CMS) and the Public 519 Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 520 10.17487/RFC6268, July 2011, . 523 [FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to 524 Protect Firmware Packages", RFC 4108, DOI 525 10.17487/RFC4108, August 2005, . 528 [LM] Leighton, T. and S. Micali, "Large provably fast and 529 secure digital signature schemes from secure hash 530 functions", U.S. Patent 5,432,852, July 1995. 532 [M1979] Merkle, R., "Secrecy, Authentication, and Public Key 533 Systems", Stanford University Information Systems 534 Laboratory Technical Report 1979-1, 1979. 536 [M1987] Merkle, R., "A Digital Signature Based on a Conventional 537 Encryption Function", Lecture Notes in Computer Science 538 crypto87, 1988. 540 [M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes 541 in Computer Science crypto89, 1990. 543 [M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture Notes 544 in Computer Science crypto89, 1990. 546 [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 547 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 548 DOI 10.17487/RFC5912, June 2010, . 551 [PQC] Bernstein, D., "Introduction to post-quantum 552 cryptography", 2009. 553 556 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 557 "Randomness Requirements for Security", BCP 106, RFC 4086, 558 DOI 10.17487/RFC4086, June 2005, . 561 Appendix: ASN.1 Module 563 MTS-HashSig-2013 564 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 565 id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } 567 DEFINITIONS IMPLICIT TAGS ::= BEGIN 569 EXPORTS ALL; 571 IMPORTS 572 PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS 573 FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1] 574 { iso(1) identified-organization(3) dod(6) internet(1) 575 security(5) mechanisms(5) pkix(7) id-mod(0) 576 id-mod-algorithmInformation-02(58) } 577 mda-sha256 578 FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1] 579 { iso(1) identified-organization(3) dod(6) 580 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 581 id-mod-pkix1-rsa-pkalgs-02(54) } ; 583 -- 584 -- Object Identifiers 585 -- 587 id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) 588 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 589 smime(16) alg(3) 17 } 591 id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig 592 -- 593 -- Signature Algorithm and Public Key 594 -- 596 sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= { 597 IDENTIFIER id-alg-hss-lms-hashsig 598 PARAMS ARE absent 599 HASHES { mda-sha256 } 600 PUBLIC-KEYS { pk-HSS-LMS-HashSig } 601 SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } } 603 pk-HSS-LMS-HashSig PUBLIC-KEY ::= { 604 IDENTIFIER id-alg-hss-lms-hashsig 605 KEY HSS-LMS-HashSig-PublicKey 606 PARAMS ARE absent 607 CERT-KEY-USAGE 608 { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } 610 HSS-LMS-HashSig-PublicKey ::= OCTET STRING 612 -- 613 -- Expand the signature algorithm set used by CMS [CMSASN1U] 614 -- 616 SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= 617 { sa-HSS-LMS-HashSig, ... } 619 -- 620 -- Expand the S/MIME capabilities set used by CMS [CMSASN1] 621 -- 623 SMimeCaps SMIME-CAPS ::= 624 { sa-HSS-LMS-HashSig.&smimeCaps, ... } 626 END 628 Author's Address 630 Russ Housley 631 Vigil Security, LLC 632 516 Dranesville Road 633 Herndon, VA 20170 634 USA 636 EMail: housley@vigilsec.com