idnits 2.17.00 (12 Aug 2021) /tmp/idnits20397/draft-ietf-cose-hash-sig-06.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 (November 01, 2019) is 932 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 293 -- Looks like a reference, but probably isn't: '1' on line 245 == Missing Reference: 'Nspk-2' is mentioned on line 181, but not defined == Missing Reference: 'Nspk-1' is mentioned on line 182, but not defined ** 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 (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Standards Track November 01, 2019 5 Expires: May 4, 2020 7 Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object 8 Signing and Encryption (COSE) 9 draft-ietf-cose-hash-sig-06 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 CBOR Object Signing and Encryption 16 (COSE) syntax. The HSS/LMS algorithm is one form of hash-based 17 digital signature; it is described in RFC 8554. 19 Status of This Memo 21 This Internet-Draft is submitted 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). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on May 4, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. LMS Digital Signature Algorithm Overview . . . . . . . . . . 3 57 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 58 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 59 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6 60 3. Hash-based Signature Algorithm Identifiers . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 4.1. Implementation Security Considerations . . . . . . . . . 7 63 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. COSE Algorithms Registry Entry . . . . . . . . . . . . . 9 66 6.2. COSE Key Types Registry Entry . . . . . . . . . . . . . . 9 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 71 A.1. Example COSE Full Message Signature . . . . . . . . . . . 11 72 A.2. Example COSE_Sign0 Message . . . . . . . . . . . . . . . 13 73 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 This document specifies the conventions for using the Hierarchical 79 Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based 80 signature algorithm with with the CBOR Object Signing and Encryption 81 (COSE) [RFC8152] syntax. The LMS system provides a one-time digital 82 signature that is a variant of Merkle Tree Signatures (MTS). The HSS 83 is built on top of the LMS system to efficiently scale for a larger 84 numbers of signatures. The HSS/LMS algorithm is one form of hash- 85 based digital signature, and it is described in [HASHSIG]. The HSS/ 86 LMS signature algorithm can only be used for a fixed number of 87 signing operations. The number of signing operations depends upon 88 the size of the tree. The HSS/LMS signature algorithm uses small 89 public keys, and it has low computational cost; however, the 90 signatures are quite large. The HSS/LMS private key can be very 91 small when the signer is willing to perform additional computation at 92 signing time; alternatively, the private key can consume additional 93 memory and provide a faster signing time. The HSS/LMS signatures 94 [HASHSIG] are currently defined to use exclusively SHA-256 [SHS]. 96 1.1. Motivation 98 Recent advances in cryptanalysis [BH2013] and progress in the 99 development of quantum computers [NAS2019] pose a threat to widely 100 deployed digital signature algorithms. As a result, there is a need 101 to prepare for a day that cryptosystems such as RSA and DSA that 102 depend on discrete logarithm and factoring cannot be depended upon. 104 If large-scale quantum computers are ever built, these computers will 105 be able to break many of the public-key cryptosystems currently in 106 use. A post-quantum cryptosystem [PQC] is a system that is secure 107 against quantum computers that have more than a trivial number of 108 quantum bits (qubits). It is open to conjecture when it will be 109 feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA 110 are all vulnerable if large-scale quantum computers come to pass. 112 Since the HSS/LMS signature algorithm does not depend on the 113 difficulty of discrete logarithm or factoring, the HSS/LMS signature 114 algorithm is considered to be post-quantum secure. The use of HSS/ 115 LMS hash-based signatures to protect software update distribution, 116 perhaps using the format that is being specified by the IETF SUIT 117 Working Group, will allow the deployment of software that implements 118 new cryptosystems. 120 1.2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. LMS Digital Signature Algorithm Overview 130 This specification makes use of the hash-based signature algorithm 131 specified in [HASHSIG], which is the Leighton and Micali adaptation 132 [LM] of the original Lamport-Diffie-Winternitz-Merkle one-time 133 signature system [M1979][M1987][M1989a][M1989b]. 135 The hash-based signature algorithm has three major components: 137 o Hierarchical Signature System (HSS) -- see Section 2.1; 139 o Leighton-Micali Signature (LMS) -- see Section 2.2; and 141 o Leighton-Micali One-time Signature Algorithm (LM-OTS) -- see 142 Section 2.3. 144 As implied by the name, the hash-based signature algorithm depends on 145 a collision-resistant hash function. The the hash-based signature 146 algorithm specified in [HASHSIG] currently makes use of the SHA-256 147 one-way hash function [SHS], but it also establishes an IANA registry 148 to permit the registration of additional one-way hash functions in 149 the future. 151 2.1. Hierarchical Signature System (HSS) 153 The hash-based signature algorithm specified in [HASHSIG] uses a 154 hierarchy of trees. The Hierarchical N-time Signature System (HSS) 155 allows subordinate trees to be generated when needed by the signer. 156 Otherwise, generation of the entire tree might take weeks or longer. 158 An HSS signature as specified in [HASHSIG] carries the number of 159 signed public keys (Nspk), followed by that number of signed public 160 keys, followed by the LMS signature as described in Section 2.2. The 161 public key for the top-most LMS tree is the public key of the HSS 162 system. The LMS private key in the parent tree signs the LMS public 163 key in the child tree, and the LMS private key in the bottom-most 164 tree signs the actual message. The signature over the public key and 165 the signature over the actual message are LMS signatures as described 166 in Section 2.2. 168 The elements of the HSS signature value for a stand-alone tree (a top 169 tree with no children) can be summarized as: 171 u32str(0) || 172 lms_signature /* signature of message */ 174 The elements of the HSS signature value for a tree with Nspk signed 175 public keys can be summarized as: 177 u32str(Nspk) || 178 signed_public_key[0] || 179 signed_public_key[1] || 180 ... 181 signed_public_key[Nspk-2] || 182 signed_public_key[Nspk-1] || 183 lms_signature /* signature of message */ 185 where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is 186 the lms_signature over the public key followed by the public key 187 itself. Note that Nspk is the number of levels in the hierarchy of 188 trees minus 1. 190 2.2. Leighton-Micali Signature (LMS) 192 Each tree in the hash-based signature algorithm specified in 193 [HASHSIG] uses the Leighton-Micali Signature (LMS) system. LMS 194 systems have two parameters. The first parameter is the height of 195 the tree, h, which is the number of levels in the tree minus one. 196 The [HASHSIG] includes support for five values of this parameter: 197 h=5; h=10; h=15; h=20; and h=25. Note that there are 2^h leaves in 198 the tree. The second parameter is the number of bytes output by the 199 hash function, m, which is the amount of data associated with each 200 node in the tree. This specification supports only SHA-256, with 201 m=32. An IANA registry is defined so that other hash functions could 202 be used in the future. 204 The [HASHSIG] specification supports five tree sizes: 206 LMS_SHA256_M32_H5; 207 LMS_SHA256_M32_H10; 208 LMS_SHA256_M32_H15; 209 LMS_SHA256_M32_H20; and 210 LMS_SHA256_M32_H25. 212 The [HASHSIG] specification establishes an IANA registry to permit 213 the registration of additional hash functions and additional tree 214 sizes in the future. 216 The [HASHSIG] specification defines the value I as the private key 217 identifier, and the same I value is used for all computations with 218 the same LMS tree. In addition, the [HASHSIG] specification defines 219 the value T[i] as the m-byte string associated with the ith node in 220 the LMS tree, where and the nodes are indexed from 1 to 2^(h+1)-1. 221 Thus, T[1] is the m-byte string associated with the root of the LMS 222 tree. 224 The LMS public key can be summarized as: 226 u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] 228 As specified in [HASHSIG], the LMS signature consists of four 229 elements: the number of the leaf associated with the LM-OTS 230 signature, an LM-OTS signature as described in Section 2.3, a 231 typecode indicating the particular LMS algorithm, and an array of 232 values that is associated with the path through the tree from the 233 leaf associated with the LM-OTS signature to the root. The array of 234 values contains the siblings of the nodes on the path from the leaf 235 to the root but does not contain the nodes on the path itself. The 236 array for a tree with height h will have h values. The first value 237 is the sibling of the leaf, the next value is the sibling of the 238 parent of the leaf, and so on up the path to the root. 240 The four elements of the LMS signature value can be summarized as: 242 u32str(q) || 243 ots_signature || 244 u32str(type) || 245 path[0] || path[1] || ... || path[h-1] 247 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) 249 The hash-based signature algorithm depends on a one-time signature 250 method. This specification makes use of the Leighton-Micali One-time 251 Signature Algorithm (LM-OTS) [HASHSIG]. An LM-OTS has five 252 parameters: 254 n - The number of bytes output by the hash function. This 255 specification 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. This 259 specification supports only SHA-256 [SHS]. 261 w - The width in bits of the Winternitz coefficients. [HASHSIG] 262 supports four values for this parameter: w=1; w=2; w=4; and 263 w=8. 265 p - The number of n-byte string elements that make up the LM-OTS 266 signature. 268 ls - The number of left-shift bits used in the checksum function, 269 which is defined in Section 4.5 of [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 to permit 282 the registration of additional hash functions and additional 283 parameter sets in the future. 285 Signing involves the generation of C, which is an n-byte random 286 value. 288 The LM-OTS signature value can be summarized as the identifier of the 289 LM-OTS variant, the random value, and a sequence of hash values (y[0] 290 through y[p-1]) that correspond to the elements of the public key as 291 described in Section 4.5 of [HASHSIG]: 293 u32str(otstype) || C || y[0] || ... || y[p-1] 295 3. Hash-based Signature Algorithm Identifiers 297 The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two 298 signature algorithm schemes. This specification makes use of the 299 signature with appendix scheme for hash-based signatures. 301 The signature value is a large byte string as described in Section 2. 302 The byte string is designed for easy parsing. The HSS, LMS, and 303 LMOTS components of the signature value format include counters and 304 type codes that indirectly provide all of the information that is 305 needed to parse the byte string during signature validation. 307 When using a COSE key for this algorithm, the following checks are 308 made: 310 o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. 312 o If the 'alg' field is present, and it MUST be 'HSS-LMS'. 314 o If the 'key_ops' field is present, it MUST include 'sign' when 315 creating a hash-based signature. 317 o If the 'key_ops' field is present, it MUST include 'verify' 318 when verifying a hash-based signature. 320 o If the 'kid' field is present, it MAY be used to identify the 321 top of the HSS tree. In [HASHSIG], this identifier is called 322 'I', and it is the 16-byte identifier of the LMS public key 323 for the tree. 325 4. Security Considerations 327 4.1. Implementation Security Considerations 329 Implementations MUST protect the private keys. Compromise of the 330 private keys may result in the ability to forge signatures. Along 331 with the private key, the implementation MUST keep track of which 332 leaf nodes in the tree have been used. Loss of integrity of this 333 tracking data can cause a one-time key to be used more than once. As 334 a result, when a private key and the tracking data are stored on non- 335 volatile media or stored in a virtual machine environment, failed 336 writes, virtual machine snapshotting or cloning, and other 337 operational concerns must be considered to ensure confidentiality and 338 integrity. 340 When generating an LMS key pair, an implementation MUST generate each 341 key pair independently of all other key pairs in the HSS tree. 343 An implementation MUST ensure that a LM-OTS private key is used to 344 generate a signature only one time, and ensure that it cannot be used 345 for any other purpose. 347 The generation of private keys relies on random numbers. The use of 348 inadequate pseudo-random number generators (PRNGs) to generate these 349 values can result in little or no security. An attacker may find it 350 much easier to reproduce the PRNG environment that produced the keys, 351 searching the resulting small set of possibilities, rather than brute 352 force searching the whole key space. The generation of quality 353 random numbers is difficult, and [RFC4086] offers important guidance 354 in this area. 356 The generation of hash-based signatures also depends on random 357 numbers. While the consequences of an inadequate pseudo-random 358 number generator (PRNG) to generate these values is much less severe 359 than in the generation of private keys, the guidance in [RFC4086] 360 remains important. 362 5. Operational Considerations 364 The public key for the hash-based signature is the key at the root of 365 Hierarchical Signature System (HSS). In the absence of a public key 366 infrastructure [RFC5280], this public key is a trust anchor, and the 367 number of signatures that can be generated is bounded by the size of 368 the overall HSS set of trees. When all of the LM-OTS signatures have 369 been used to produce a signature, then the establishment of a new 370 trust anchor is required. 372 To ensure that none of tree nodes are used to generate more than one 373 signature, the signer maintains state across different invocations of 374 the signing algorithm. Section 12.2 of [HASHSIG] offers some 375 practical implementation approaches around this statefulness. In 376 some of these approaches, nodes are sacrificed to ensure that none 377 are used more than once. As a result, the total number of signatures 378 that can be generated might be less than the overall HSS set of 379 trees. 381 6. IANA Considerations 383 IANA is requested to add entries for hash-based signatures in the 384 "COSE Algorithms" registry and hash-based public keys in the "COSE 385 Key Types" registry. 387 6.1. COSE Algorithms Registry Entry 389 The new entry in the "COSE Algorithms" registry has the following 390 columns: 392 Name: HSS-LMS 394 Value: TBD (Value between -256 and 255 to be assigned by IANA) 396 Description: HSS/LMS hash-based digital signature 398 Reference: This document (Number to be assigned by RFC Editor) 400 Recommended: Yes 402 6.2. COSE Key Types Registry Entry 404 The new entry in the "COSE Key Types" registry has the following 405 columns: 407 Name: HSS-LMS 409 Value: TBD (Value to be assigned by IANA) 411 Description: Public key for HSS/LMS hash-based digital signature 413 Reference: This document (Number to be assigned by RFC Editor) 415 7. References 417 7.1. Normative References 419 [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali 420 Hash-Based Signatures", RFC 8554, April 2019, 421 . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 429 RFC 8152, DOI 10.17487/RFC8152, July 2017, 430 . 432 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 433 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 434 May 2017, . 436 [SHS] National Institute of Standards and Technology (NIST), 437 "Secure Hash Standard", FIPS Publication 180-3, 2008. 439 7.2. Informative References 441 [BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The 442 Factoring Dead: Preparing for the Cryptopocalypse", August 443 2013, . 446 [LM] Leighton, F. and S. Micali, "Large provably fast and 447 secure digital signature schemes from secure hash 448 functions", U.S. Patent 5,432,852, July 1995. 450 [M1979] Merkle, R., "Secrecy, Authentication, and Public Key 451 Systems", Stanford University Information Systems 452 Laboratory Technical Report 1979-1, 1979. 454 [M1987] Merkle, R., "A Digital Signature Based on a Conventional 455 Encryption Function", Lecture Notes in Computer 456 Science crypto87, 1988. 458 [M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes 459 in Computer Science crypto89, 1990. 461 [M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture 462 Notes in Computer Science crypto89, 1990. 464 [NAS2019] National Academies of Sciences, Engineering, and Medicine, 465 "Quantum Computing: Progress and Prospects", 2019, 466 . 468 [PQC] Bernstein, D., "Introduction to post-quantum 469 cryptography", 2009, 470 . 473 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 474 "Randomness Requirements for Security", BCP 106, RFC 4086, 475 DOI 10.17487/RFC4086, June 2005, 476 . 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 Appendix A. Examples 486 This appendix provides a non-normative example of a COSE full message 487 signature and an example of a COSE_Sign0 message. This section 488 follows the formatting used in [RFC8152]. 490 The programs that were used to generate the examples can be found at 491 https://github.com/cose-wg/Examples. 493 A.1. Example COSE Full Message Signature 495 This section provides an example of a COSE full message signature. 497 Size of binary file is 2560 bytes. 499 98( 500 [ 501 / protected / h'a10300' / { 502 \ content type \ 3:0 503 } / , 504 / unprotected / {}, 505 / payload / 'This is the content.', 506 / signatures / [ 507 [ 508 / protected / h'a101382d' / { 509 \ alg \ 1:-46 \ HSS-LMS \ 510 } / , 511 / unprotected / { 512 / kid / 4:'ItsBig' 513 }, 514 / signature / h'00000000000000010000000391291de76ce6e24d1e2a 515 9b60266519bc8ce889f814deb0fc00edd3129de3ab9b6bfa3bf47d007d844af7db74 516 9ea97215e82f456cbdd473812c6a042ae39539898752c89b60a276ec8a9feab900e2 517 5bdfe0ab8e773aa1c36ae214d67c65bb68630450a5db2c7c6403b77f6a9bf4d30a02 518 19db5cced884d7514f3cbd19220020bf3045b0e5c6955b32864f16f97da02f0cbfea 519 70458b07032e30b0342d75b8f3dc6871442e6384b10f559f5dc594a214924c48ccc3 520 37078665653fc740340428138b0fb5154f2f2cb291ad05ace7acae60031b2d09b2f4 521 17712d1c01e34b165af2e070f5a521a85a5fb3dd2a6288947bcbd5e2265d3670bd61 522 92eb2bf643964e2783d84aec343f8e3571e4fcf09cbeea94e80470aa7252d1c733a5 523 535907e66c7b9f0b88b159dc2a7370ee47f13e7e134d3d05e5f53fac640b784a9b0f 524 183fe14217325626f487cc8d8cb9eaf0abb174ee0b7076cf39c45037cefdf3f1e61b 525 5174581214c09870b72c39737ec4c46a96199b66cad2990bcbe5bb1abfde99107c7f 526 7289395bf2a433598ede0b1969f23db949afb5b4d33831dae6c641a6355f8f9bf16c 527 dffc4bf86891b93a557c2152ac8a1de51c995344cc10cc4bc9ecfbb4e418bed0f334 528 af165339e6725dc4fc1e995521e1be8a566d59b57cd130903b42d07087d63646ef8f 529 c1e9e9071bb67a123fdec3f37638cdaf0f4bf3084074069171c17885b9431ad908d3 530 6a6f8a826256d2aa34f8aa0731a357c060db8e80fefd61b1c323890e640633b98d17 531 5d4d6ebff800a71cfc864ec02837de9d0e079f0f400acafd56805cb273e631ba395d 532 23e86acf6eae63181a5afe1f0a361cbbd5fefeb7db0c95591ec3128e80dfbea9ca0f 533 89fc035d761c05d41e7a010892c42e8e2af62aa604f4e214c0bb08075481f9cc307a 534 555adf333b9424f209b89f161032e413b047ae5ab0aa15643bb4c643446d2c9829eb 535 256e7375ce9639047a24a44f4da446b7359556f3ab3484c56511c68a140dc0531f65 536 3105800d9f20990d4ebdc5ceea918d7ae95c0d7ec69a00d6a936b25fc19b9dfc5561 537 400f046191136c367038d6a9d0e0ae30dcdc4733712cbd5a2aee35315eff5c1a7e08 538 5b68c5cf0c64c495df2ca6f030db04480a2e11d4a0a0dbf29d9463d5b9e41e346e49 539 c894d5e43993c834c4746309c886d6131f2f92155ca1160bac9660802a947b5aba94 540 b35357d13fdf02d2aeabef568912f68ae5d3a60214f6d00c4dd9f0af09eb0bf961cd 541 9f27251d46899c28d87080ba2ead3e8193f51a789706ec32aacee9f4b14eeca91a25 542 2fe894b30dc3938abbbe7d217948cae79ce3adb4d7d7df6756f3099f2543ed3b522b 543 acab257503c9e07fcd32cc32fa9aa17977ec05bc5fe0f5954d51f160f52d33f93166 544 af68aa90261b3f5ad273adacf2d0cb5b0c5402bfa62da67a52dcddfa463e72d2c005 545 f1ac0ea3cb62364ee3419333612e07bf685006137a592e2fcd58398265c4ff9e11e7 546 0c2b79152e4604b4f94676e955bcff4dfc429a8a88728b95bfc2826e25ba6eab9cfb 547 066c9911693efff242f7b51c3cb88546143b8ab2142dd3c9bda55d16fe3084a86b74 548 3f294dd9d0aa84f3ce3b083a5879a4762a756e9b41f4bdf8b71418073b0a0d4a9c13 549 1882455ece23e50324c5feea217920b0f3109dcbdc81762e41b7ca271efac8e39cc2 550 6ebe085abdbf6b314a38929799fb7feebee2e20b97056ed17ef3881e6e89330314dd 551 7e9c629c46dfdb925c7c5f5d243f159d964691745cd46579fd0696479e1c49cbd2af 552 879a2bce8576619cca7b6e516e6c94c1087441a81f11b9a83535b24ddc725a81a9d1 553 ff62da2804c8d84c6e382065574282ea1f23eaf648cfa9767afb098fd81654d76133 554 f5f39bcc762c9bc31f7f4665cc0efa929b5c05dedd76143c63dc7018ab130c108ea9 555 01be32b9d911b66da13a1528c32a9694c899a772f8e1fe00c17eceb343e737d72cba 556 06cf5ddac9a4d3df7ef391cf6595a6d8c14b0d80f93023b1b3d4371239da98b67a1b 557 6a379422616282a16e8d1f97a130baf21e572bcca91abb760eac6957f9b1b05e49e2 558 d181874ac6dd160d1c717b73bd28ef55f08d47466d5aef754814c7e206fa9e2ec533 559 85d14d52f7769d95ea50524ffb20dc7275b04d71d1967e3bbc6ed481f1fc5a15e78a 560 1fd967d96045625645dbd173cccdd97661e995ce47d6b3ead96ee6d006a5ce6f4c97 561 77fe2e3f91bebe877cac8c6486dfce0315dc71bbb93879759b8981c5ff2e11deb809 562 abf4280ee93d1711e73645b410acb518538ce3d4bda1e355c988f068165668e99d6a 563 8de356b4b13298036ad05d526c4a5e2591612a477b7e86550adde128cd71ee651d44 564 99699000a02979e42bbccf32c83b1eb0ff99aa4d352e20e0b3382422df2c2ed4ce90 565 c94cf1a359e92ef971dc6db06047a333c2ebe827eb6d5f2811fdbe0bf0f12bf2094e 566 0dcd8e418f3f691a60ceb0cefb6f45f47883d6b9f320950e91266740c6dbfad6b3cf 567 e56de0aa6658b0dc893bb6e49e6294537a7878e86cfc8e6c150675db1a89d188ea6e 568 fe7d88ff57b39b8610e392811ee097ca61c4841e0fbd346ed3ff6a5e412acb0d9f13 569 022df2e7fdaa8e0face7366c8ffe6f446995b564fc3d59c70fecdb60a25e28650417 570 157f43f3e72c3afc601509641cfd099a78130e1f7ba8333502ad4f036f46411a43d0 571 35e2ca0ed0c346d9aac5df05196c95c38e6e52763ed896b6d02464a910dda6cca340 572 24e3b9c3723d26e2886ad724dd56ea285e8e4b60beec924d55dd700c38877b74552f 573 ea1f8741579b02061416131db390f628522885236b51f7aef23167d3a5fe5eadcd88 574 b0e99b2b6bc56b0dea4fb22146294766c28e5e7c834dbdcb6bfdd7bd8455252522ff 575 2e974f6fd3fda176749b7cdced5b9aba092b2982c89cb7d2b36348928c8f01170618 576 ecff14d9e0eed9d88d97e38bcf7a837f674be5243fc624c8afd3d105f462bfa939b8 577 143a3a98f78fbb8c915e00bdbbf707b12c45784f4d1cb1426b583a0d5fbec1f5ea6d 578 0067c090168cb788e532aca770c7be366ec07e7808f1892b00000006ed1ce8c6e437 579 918d43fba7bd9385694c41182703f6b7f704deedd9384ba6f8bc362c948646b3c984 580 8803e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e 581 7c81a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc5 582 6211d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d26 583 246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0ba 584 e71696cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c 585 29d4f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c10 586 7362f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9 587 ce949be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931b 588 a7b3bd0d824a4570' 589 ] 590 ] 591 ] 592 ) 594 A.2. Example COSE_Sign0 Message 596 This section provides an example of a COSE_Sign0 message. 598 Size of binary file is 2552 bytes. 600 18( 601 [ 602 / protected / h'a101382d' / { 603 \ alg \ 1:-46 \ HSS-LMS \ 604 } / , 605 / unprotected / { 606 / kid / 4:'ItsBig' 607 }, 608 / payload / 'This is the content.', 609 / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60 610 266519bc8ce889f814deb0fc00edd3129de3ab9b9aa5b5ac783bdf0fe689f57fb204 611 f1992dbc1ce2484f316c74bce3f2094cfa8e96a4a9548cead0f78ee5d549510d1910 612 f647320448ae27ecce77249802a0c39c645bf8db08573af52c93d91fd0e217f245c7 613 52c176b81514eb6e3067e0fbb329225eaa88c7d21635e32ae84213f89018cb06f1b8 614 4e61eac348b690d7c6265c19f9d868952d99826aecd417b5279dd674cd951c306016 615 cfee4fee3bfcf5ee5a5ad08b5b4f53bc93995f26cfe7c0c1c5ba2574c1f2d8470993 616 e8bd47ef9b9cf309ef895226e92be60683459009611defbb9a43217956a0ab2959bb 617 da0feca39de37e7c4a6cd8a5314d6b02b377406d5a5e589e91feaa9f2e4ec1682ba1 618 f633c7784499323e40da651f71d3c19e38c634d898b0c508324c0bfcf7c5f0a8c014 619 b4af200a739f96cddba94daf86ce80c76158d4f5cf3cd2ba9f1393df47e556887f91 620 68540485242a05ec6bcc76659ec3d0d2fedae3fd1608a701c226f5fd83c9b1ed3152 621 ddac7426c30e3390bec8f1da6174abe8d3568c9b76b149eb077d61ac15b8fb11b8ce 622 5f9d14e448e216f375e1f96a52d39619459b131026143e8809bad408f5ef66cd3da2 623 27431e68670c0b4b2c3801e1e9025b1ebed218e0956967158ccc274c704adcd8cc23 624 c149a89eda25478742dadc15f233844535e4021000b5d557313d4f271875680e6d5e 625 7f6681fdd19f8b9a748cabb2377aac1387fdb80e618eb7d69a368729ca9a092af91e 626 be1c584c35fe62734d1d53d10b35dd02093a201c889ad37a558b610f1ab00179a11f 627 881600e944cedc47a7ae6d828009d7c61ffea9dd5aa5406408e2e85dc056e47b5758 628 9eaba18e792f4631af62d4588a1818167274273c69e7a0735be5dada7e224e3b178b 629 3b093212eb74e762f564a26d577aa22ebd8c7b4a999419908e2f2d9c8689dc923905 630 c198b9ee335d1e0de6d689655f446dffea997b6e58f5f648415233ede3b9d8a2db29 631 e8c3dde5d8dbd55e6348cd9f421783db090e087de46425d62d513597b00d7de32fad 632 87752a79cee8b2a38b1e0f2562836721cbbfba20f131130c009a436b93a0bb44fcbb 633 86228b1bf1a35f4fc626817924eaebd5b78d64a7970d18dade90cf0ad759b1c45d95 634 3c08cd1189685077c5a56069da0944669d797496f8f886fea6f792598db2ac66b657 635 af838ed3c3a914dffbb164170a1f63250b125eda53ecaeaf6ee0d2b8a3c804104d7e 636 d575b66469bc59f37eec6c6f6fb19e0f7ea02d7c85306230063adb58950589f6ffaf 637 f1407233828ae0dfbe5889e5de00bb640a4bc24c3f704488fa669676a9ebbbed399b 638 8a9ac0ee4cc944f864b21f642e04f610319ac9271f8bd820e77e41dac6553d234d94 639 80e26142c0fa37416651d6450e1f2082bd0213d6783e1ae3cc5c5af677c3316e173b 640 a4716d6bc8a9d89383f8b025a0859b99a43daeaf8ddaed46d223b9b503651a67560b 641 feb2f35ba544722620ec4086dcc77e6e87bb53f1f18c38368662be460ede31325cae 642 aebf018a6fa9d32e3c3a6898e15fe114dcce51241c61afabc36de3608b4d342712a8 643 33615c6131e89e1d46b713d9638a08b5a768d53af0298b9c874ded7084358223840c 644 2e78cd6fbfca695279a4c1883bb7de81b04a069de8277f7f5109c16938347a643713 645 c9ac36fffc8bf141e899f48bc25c7b636d43bebcfa7742d4e1462263e56732ad2021 646 eef8ce84023c4959cfd250343d62074724907de9d49ea2f6c968fd9e9bf28feafcdc 647 81702108805dec60f2781272d2425a6ee29c66122d2c557867c1a5aed82131e06fc3 648 84ecf49017e1c9d6cf63b9f2285ccf890cbb9bbf796e0fd02101948b7ef663849367 649 7b33fd787d9d3fc2c7cc7babc21af8c748afb80cf86b45dc89f0b9c7959621e85b98 650 b542dc263db9255273bb9054a7f194748f28373ba123d73fc71fef43e7e2ac9a8000 651 8e85cf2f04aa433075dfc54c4de24a341ebf7cf1e6b383dbba85898fdc368017fd67 652 c153e7a991a3a3cee6dae4fbe2fe6f25a8df314140a8176c8e6fd0c6f042ca66eb6a 653 bba9a2502bb6dfa52960ae86a942a673e4e45439594fefcd2974e20554d1dc70b8e0 654 34fd1787801343d5f6edc95ce0348c25727c771526e3fd4effb5f16e25a1ea3dcd82 655 82e778e91ae9b339a5013c77fd6ea2432704e293f5e82a24121c73900bea4b4ef14a 656 2adc1ab3c68224bae1de9c61a48b84e84c1b0e83701be3d988012a24fa40268c8d6e 657 f1fd2818ae8e4b6f52f89beab6bfdd1ff1b7ecd573edff3703b800b5b2a206f451f1 658 bf2713b4ae9085bd7fe34ad4306a290e4cdb7817ee9ab7ccfb816d002b619f77d46d 659 7dd0f8eefe10f5c0f9723ffdb14ca75a185543770f41508b9983d5eed78225bc6e21 660 f876bfdd08fe8bc63e0cb253c7dfc67c330897c515244f3f631682f2141eba48ca86 661 dfff9206f78edcb9dec4b2371aeddbe141ef96a10957e29a94747c4438fb30b14d37 662 e7428eb7fbe4f9d870e72f35f55847f230374bdf56dcae6c129b4468ebaedc340ff4 663 cc160c6b410e2d8989488ac8ef9a9febbf65ad4fdfba532a8122ef82dc1a4ffc361c 664 bf9f752b36aa9821683d5f3f5842f90134eb423d5cbc76858b4c0a7ba798ec94a089 665 fdb24b5b25f42d7b6bb8192f07b98eb2de1fe7bc8b6c740fa5cde6fb4890d2f17916 666 64a96c25a0a71a541025b5ec825eed91f393505473e21d0620177993982e6c1b6bf9 667 1b777b5ab5739b84946c518c7e6aa0e689e9ad1d34e6ef6ca0e709c4aefecd6f2594 668 b017940742aceb72c5a52d7d47a3a74f9d09eb84cf82b349de32278a771cebc31ebc 669 580c09b11799b1f0e6d11d75b17e389d259c531f957a1e699250711df2e36f64f21c 670 92eff698a392d92df0b2f91991408a076b83149e025a9ffba1ff1caed916a2fc1ac5 671 d3081c30b5c64b7d677c314b6e76ac20ed8bb4a4c0eb465ae5c0c265969264b27e6d 672 54c266f79e58e2fa6a381069090bec00189562abcf831adc86a05a2fc7ffaa70dbd3 673 fa60e09d447cd76b2ff2b851c38e72650ade093ba8bd000000067b95de445abf8916 674 1dff4b91a4a9e3bf156a39a4660f98f06bf3f017686d9dfc362c948646b3c9848803 675 e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e7c81 676 a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc56211 677 d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465 678 95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0bae716 679 96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4 680 f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362 681 f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94 682 9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3 683 bd0d824a4570' 684 ] 685 ) 687 Appendix B. Acknowledgements 689 Many thanks to Roman Danyliw, Scott Fluhrer, Laurence Lundblade, John 690 Mattsson, Jim Schaad, and Tony Putman for their valuable review and 691 insights. In addition, an extra special thank you to Jim Schaad for 692 generating the examples in Appendix A. 694 Author's Address 696 Russ Housley 697 Vigil Security, LLC 698 516 Dranesville Road 699 Herndon, VA 20170 700 US 702 Email: housley@vigilsec.com