summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8778.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8778.txt')
-rw-r--r--doc/rfc/rfc8778.txt772
1 files changed, 772 insertions, 0 deletions
diff --git a/doc/rfc/rfc8778.txt b/doc/rfc/rfc8778.txt
new file mode 100644
index 0000000..c4f4793
--- /dev/null
+++ b/doc/rfc/rfc8778.txt
@@ -0,0 +1,772 @@
+
+
+
+
+Internet Engineering Task Force (IETF) R. Housley
+Request for Comments: 8778 Vigil Security
+Category: Standards Track April 2020
+ISSN: 2070-1721
+
+
+ Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object
+ Signing and Encryption (COSE)
+
+Abstract
+
+ This document specifies the conventions for using the Hierarchical
+ Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
+ signature algorithm with the CBOR Object Signing and Encryption
+ (COSE) syntax. The HSS/LMS algorithm is one form of hash-based
+ digital signature; it is described in RFC 8554.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8778.
+
+Copyright Notice
+
+ Copyright (c) 2020 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Motivation
+ 1.2. Terminology
+ 2. LMS Digital Signature Algorithm Overview
+ 2.1. Hierarchical Signature System (HSS)
+ 2.2. Leighton-Micali Signature (LMS)
+ 2.3. Leighton-Micali One-Time Signature (LM-OTS) Algorithm
+ 3. Hash-Based Signature Algorithm Identifiers
+ 4. Security Considerations
+ 5. Operational Considerations
+ 6. IANA Considerations
+ 6.1. COSE Algorithms Registry Entry
+ 6.2. COSE Key Types Registry Entry
+ 6.3. COSE Key Type Parameters Registry Entry
+ 7. References
+ 7.1. Normative References
+ 7.2. Informative References
+ Appendix A. Examples
+ A.1. Example COSE Full Message Signature
+ A.2. Example COSE_Sign1 Message
+ Acknowledgements
+ Author's Address
+
+1. Introduction
+
+ This document specifies the conventions for using the Hierarchical
+ Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
+ signature algorithm with the CBOR Object Signing and Encryption
+ (COSE) [RFC8152] syntax. The LMS system provides a one-time digital
+ signature that is a variant of Merkle Tree Signatures (MTS). The HSS
+ is built on top of the LMS system to efficiently scale for a larger
+ number of signatures. The HSS/LMS algorithm is one form of a hash-
+ based digital signature, and it is described in [HASHSIG]. The HSS/
+ LMS signature algorithm can only be used for a fixed number of
+ signing operations. The number of signing operations depends upon
+ the size of the tree. The HSS/LMS signature algorithm uses small
+ public keys, and it has low computational cost; however, the
+ signatures are quite large. The HSS/LMS private key can be very
+ small when the signer is willing to perform additional computation at
+ signing time; alternatively, the private key can consume additional
+ memory and provide a faster signing time. The HSS/LMS signatures
+ [HASHSIG] are currently defined to use exclusively SHA-256 [SHS].
+
+1.1. Motivation
+
+ Recent advances in cryptanalysis [BH2013] and progress in the
+ development of quantum computers [NAS2019] pose a threat to widely
+ deployed digital signature algorithms. As a result, there is a need
+ to prepare for a day that cryptosystems, such as RSA and DSA, that
+ depend on discrete logarithm and factoring cannot be depended upon.
+
+ If large-scale quantum computers are ever built, these computers will
+ have more than a trivial number of quantum bits (qubits), and they
+ will be able to break many of the public-key cryptosystems currently
+ in use. A post-quantum cryptosystem [PQC] is a system that is secure
+ against such large-scale quantum computers. When it will be feasible
+ to build such computers is open to conjecture; however, RSA
+ [RFC8017], DSA [DSS], Elliptic Curve Digital Signature Algorithm
+ (ECDSA) [DSS], and Edwards-curve Digital Signature Algorithm (EdDSA)
+ [RFC8032] are all vulnerable if large-scale quantum computers come to
+ pass.
+
+ Since the HSS/LMS signature algorithm does not depend on the
+ difficulty of discrete logarithm or factoring, the HSS/LMS signature
+ algorithm is considered to be post-quantum secure. The use of HSS/
+ LMS hash-based signatures to protect software update distribution
+ will allow the deployment of future software that implements new
+ cryptosystems. By deploying HSS/LMS today, authentication and
+ integrity protection of the future software can be provided, even if
+ advances break current digital-signature mechanisms.
+
+1.2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. LMS Digital Signature Algorithm Overview
+
+ This specification makes use of the hash-based signature algorithm
+ specified in [HASHSIG], which is the Leighton and Micali adaptation
+ [LM] of the original Lamport-Diffie-Winternitz-Merkle one-time
+ signature system [M1979][M1987][M1989a][M1989b].
+
+ The hash-based signature algorithm has three major components:
+
+ * Hierarchical Signature System (HSS) -- see Section 2.1
+
+ * Leighton-Micali Signature (LMS) -- see Section 2.2
+
+ * Leighton-Micali One-time Signature (LM-OTS) Algorithm-- see
+ Section 2.3
+
+ As implied by the name, the hash-based signature algorithm depends on
+ a collision-resistant hash function. The hash-based signature
+ algorithm specified in [HASHSIG] currently makes use of the SHA-256
+ one-way hash function [SHS], but it also establishes an IANA registry
+ to permit the registration of additional one-way hash functions in
+ the future.
+
+2.1. Hierarchical Signature System (HSS)
+
+ The hash-based signature algorithm specified in [HASHSIG] uses a
+ hierarchy of trees. The N-time Hierarchical Signature System (HSS)
+ allows subordinate trees to be generated when needed by the signer.
+ Otherwise, generation of the entire tree might take weeks or longer.
+
+ An HSS signature, as specified in [HASHSIG], carries the number of
+ signed public keys (Nspk), followed by that number of signed public
+ keys, followed by the LMS signature, as described in Section 2.2.
+ The public key for the topmost LMS tree is the public key of the HSS
+ system. The LMS private key in the parent tree signs the LMS public
+ key in the child tree, and the LMS private key in the bottom-most
+ tree signs the actual message. The signature over the public key and
+ the signature over the actual message are LMS signatures, as
+ described in Section 2.2.
+
+ The elements of the HSS signature value for a stand-alone tree (a top
+ tree with no children) can be summarized as:
+
+ u32str(0) ||
+ lms_signature /* signature of message */
+
+ where the notation comes from [HASHSIG].
+
+ The elements of the HSS signature value for a tree with Nspk signed
+ public keys can be summarized as:
+
+ u32str(Nspk) ||
+ signed_public_key[0] ||
+ signed_public_key[1] ||
+ ...
+ signed_public_key[Nspk-2] ||
+ signed_public_key[Nspk-1] ||
+ lms_signature /* signature of message */
+
+ As defined in Section 3.3 of [HASHSIG], a signed_public_key is the
+ lms_signature over the public key followed by the public key itself.
+ Note that Nspk is the number of levels in the hierarchy of trees
+ minus 1.
+
+2.2. Leighton-Micali Signature (LMS)
+
+ Subordinate LMS trees are placed in the HSS structure, as discussed
+ in Section 2.1. Each tree in the hash-based signature algorithm
+ specified in [HASHSIG] uses the Leighton-Micali Signature (LMS)
+ system. LMS systems have two parameters. The first parameter is the
+ height of the tree, h, which is the number of levels in the tree
+ minus one. The [HASHSIG] includes support for five values of this
+ parameter: h=5, h=10, h=15, h=20, and h=25. Note that there are 2^h
+ leaves in the tree. The second parameter is the number of bytes
+ output by the hash function, m, which is the amount of data
+ associated with each node in the tree. The [HASHSIG] specification
+ supports only SHA-256 with m=32. An IANA registry is defined so that
+ other hash functions could be used in the future.
+
+ The [HASHSIG] specification supports five tree sizes:
+
+ * LMS_SHA256_M32_H5
+
+ * LMS_SHA256_M32_H10
+
+ * LMS_SHA256_M32_H15
+
+ * LMS_SHA256_M32_H20
+
+ * LMS_SHA256_M32_H25
+
+ The [HASHSIG] specification establishes an IANA registry to permit
+ the registration of additional hash functions and additional tree
+ sizes in the future.
+
+ The [HASHSIG] specification defines the value I as the private key
+ identifier, and the same I value is used for all computations with
+ the same LMS tree. The value I is also available in the public key.
+ In addition, the [HASHSIG] specification defines the value T[r] as
+ the m-byte string associated with the ith node in the LMS tree, and
+ the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the m-byte
+ string associated with the root of the LMS tree.
+
+ The LMS public key can be summarized as:
+
+ u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
+
+ As specified in [HASHSIG], the LMS signature consists of four
+ elements:
+
+ * the number of the leaf associated with the LM-OTS signature,
+
+ * an LM-OTS signature, as described in Section 2.3,
+
+ * a type code indicating the particular LMS algorithm, and
+
+ * an array of values that is associated with the path through the
+ tree from the leaf associated with the LM-OTS signature to the
+ root.
+
+ The array of values contains the siblings of the nodes on the path
+ from the leaf to the root but does not contain the nodes on the path
+ itself. The array for a tree with height h will have h values. The
+ first value is the sibling of the leaf, the next value is the sibling
+ of the parent of the leaf, and so on up the path to the root.
+
+ The four elements of the LMS signature value can be summarized as:
+
+ u32str(q) ||
+ ots_signature ||
+ u32str(type) ||
+ path[0] || path[1] || ... || path[h-1]
+
+2.3. Leighton-Micali One-Time Signature (LM-OTS) Algorithm
+
+ The hash-based signature algorithm depends on a one-time signature
+ method. This specification makes use of the Leighton-Micali One-time
+ Signature (LM-OTS) Algorithm [HASHSIG]. An LM-OTS has five
+ parameters:
+
+ n: The number of bytes output by the hash function. For SHA-256
+ [SHS], n=32.
+
+ H: A preimage-resistant hash function that accepts byte strings of
+ any length and returns an n-byte string.
+
+ w: The width in bits of the Winternitz coefficients. [HASHSIG]
+ supports four values for this parameter: w=1, w=2, w=4, and
+ w=8.
+
+ p: The number of n-byte string elements that make up the LM-OTS
+ signature.
+
+ ls: The number of left-shift bits used in the checksum function,
+ which is defined in Section 4.4 of [HASHSIG].
+
+ The values of p and ls are dependent on the choices of the parameters
+ n and w, as described in Appendix B of [HASHSIG].
+
+ The [HASHSIG] specification supports four LM-OTS variants:
+
+ * LMOTS_SHA256_N32_W1
+
+ * LMOTS_SHA256_N32_W2
+
+ * LMOTS_SHA256_N32_W4
+
+ * LMOTS_SHA256_N32_W8
+
+ The [HASHSIG] specification establishes an IANA registry to permit
+ the registration of additional hash functions and additional
+ parameter sets in the future.
+
+ Signing involves the generation of C, which is an n-byte random
+ value.
+
+ The LM-OTS signature value can be summarized as the identifier of the
+ LM-OTS variant, the random value, and a sequence of hash values (y[0]
+ through y[p-1]), as described in Section 4.5 of [HASHSIG]:
+
+ u32str(otstype) || C || y[0] || ... || y[p-1]
+
+3. Hash-Based Signature Algorithm Identifiers
+
+ The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two
+ signature algorithm schemes. This specification makes use of the
+ signature with appendix scheme for hash-based signatures.
+
+ The signature value is a large byte string, as described in
+ Section 2. The byte string is designed for easy parsing. The HSS,
+ LMS, and LM-OTS components of the signature value format include
+ counters and type codes that indirectly provide all of the
+ information that is needed to parse the byte string during signature
+ validation.
+
+ When using a COSE key for this algorithm, the following checks are
+ made:
+
+ * The 'kty' field MUST be 'HSS-LMS'.
+
+ * If the 'alg' field is present, it MUST be 'HSS-LMS'.
+
+ * If the 'key_ops' field is present, it MUST include 'sign' when
+ creating a hash-based signature.
+
+ * If the 'key_ops' field is present, it MUST include 'verify' when
+ verifying a hash-based signature.
+
+ * If the 'kid' field is present, it MAY be used to identify the top
+ of the HSS tree. In [HASHSIG], this identifier is called 'I', and
+ it is the 16-byte identifier of the LMS public key for the tree.
+
+4. Security Considerations
+
+ The security considerations from [RFC8152] and [HASHSIG] are relevant
+ to implementations of this specification.
+
+ There are a number of security considerations that need to be taken
+ into account by implementers of this specification.
+
+ Implementations MUST protect the private keys. Compromise of the
+ private keys may result in the ability to forge signatures. Along
+ with the private key, the implementation MUST keep track of which
+ leaf nodes in the tree have been used. Loss of integrity of this
+ tracking data can cause a one-time key to be used more than once. As
+ a result, when a private key and the tracking data are stored on
+ nonvolatile media or in a virtual machine environment, failed writes,
+ virtual machine snapshotting or cloning, and other operational
+ concerns must be considered to ensure confidentiality and integrity.
+
+ When generating an LMS key pair, an implementation MUST generate each
+ key pair independently of all other key pairs in the HSS tree.
+
+ An implementation MUST ensure that an LM-OTS private key is used to
+ generate a signature only one time and ensure that it cannot be used
+ for any other purpose.
+
+ The generation of private keys relies on random numbers. The use of
+ inadequate pseudorandom number generators (PRNGs) to generate these
+ values can result in little or no security. An attacker may find it
+ much easier to reproduce the PRNG environment that produced the keys,
+ searching the resulting small set of possibilities rather than brute-
+ force searching the whole key space. The generation of quality
+ random numbers is difficult, and [RFC4086] offers important guidance
+ in this area.
+
+ The generation of hash-based signatures also depends on random
+ numbers. While the consequences of an inadequate PRNG to generate
+ these values is much less severe than in the generation of private
+ keys, the guidance in [RFC4086] remains important.
+
+5. Operational Considerations
+
+ The public key for the hash-based signature is the key at the root of
+ Hierarchical Signature System (HSS). In the absence of a public key
+ infrastructure [RFC5280], this public key is a trust anchor, and the
+ number of signatures that can be generated is bounded by the size of
+ the overall HSS set of trees. When all of the LM-OTS signatures have
+ been used to produce a signature, then the establishment of a new
+ trust anchor is required.
+
+ To ensure that none of the tree nodes are used to generate more than
+ one signature, the signer maintains state across different
+ invocations of the signing algorithm. Section 9.2 of [HASHSIG]
+ offers some practical implementation approaches around this
+ statefulness. In some of these approaches, nodes are sacrificed to
+ ensure that none are used more than once. As a result, the total
+ number of signatures that can be generated might be less than the
+ overall HSS set of trees.
+
+ A COSE Key Type Parameter for encoding the HSS/LMS private key and
+ the state about which tree nodes have been used is deliberately not
+ defined. It was not defined to avoid creating the ability to save
+ the private key and state, generate one or more signatures, and then
+ restore the private key and state. Such a restoration operation
+ provides disastrous opportunities for tree node reuse.
+
+6. IANA Considerations
+
+ IANA has added entries for the HSS/LMS hash-based signature algorithm
+ in the "COSE Algorithms" registry and added HSS/LMS hash-based
+ signature public keys in the "COSE Key Types" registry and the "COSE
+ Key Type Parameters" registry.
+
+6.1. COSE Algorithms Registry Entry
+
+ The new entry in the "COSE Algorithms" registry [IANA] appears as
+ follows:
+
+ Name: HSS-LMS
+ Value: -46
+ Description: HSS/LMS hash-based digital signature
+ Reference: RFC 8778
+ Recommended: Yes
+
+6.2. COSE Key Types Registry Entry
+
+ The new entry in the "COSE Key Types" registry [IANA] appears as
+ follows:
+
+ Name: HSS-LMS
+ Value: 5
+ Description: Public key for HSS/LMS hash-based digital signature
+ Reference: RFC 8778
+
+6.3. COSE Key Type Parameters Registry Entry
+
+ The new entry in the "COSE Key Type Parameters" registry [IANA]
+ appears as follows:
+
+ Key Type: 5
+ Name: pub
+ Label: -1
+ CBOR Type: bstr
+ Description: Public key for HSS/LMS hash-based digital signature
+ Reference: RFC 8778
+
+7. References
+
+7.1. Normative References
+
+ [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
+ Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
+ April 2019, <https://www.rfc-editor.org/info/rfc8554>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
+ RFC 8152, DOI 10.17487/RFC8152, July 2017,
+ <https://www.rfc-editor.org/info/rfc8152>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [SHS] National Institute of Standards and Technology (NIST),
+ "Secure Hash Standard", FIPS Publication 180-4,
+ DOI 10.6028/NIST.FIPS.180-4, August 2015,
+ <https://doi.org/10.6028/NIST.FIPS.180-4>.
+
+7.2. Informative References
+
+ [BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The
+ Factoring Dead: Preparing for the Cryptopocalypse", August
+ 2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-
+ Factoring-Dead.pdf>.
+
+ [DSS] National Institute of Standards and Technology (NIST),
+ "Digital Signature Standard (DSS)", FIPS
+ Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013,
+ <https://doi.org/10.6028/NIST.FIPS.186-4>.
+
+ [IANA] IANA, "CBOR Object Signing and Encryption (COSE)",
+ <https://www.iana.org/assignments/cose>.
+
+ [LM] Leighton, F. and S. Micali, "Large provably fast and
+ secure digital signature schemes from secure hash
+ functions", U.S. Patent 5,432,852, July 1995.
+
+ [M1979] Merkle, R., "Secrecy, Authentication, and Public Key
+ Systems", Information Systems Laboratory, Stanford
+ University, Technical Report No. 1979-1, June 1979.
+
+ [M1987] Merkle, R., "A Digital Signature Based on a Conventional
+ Encryption Function", Advances in Cryptology -- CRYPTO '87
+ Proceedings, Lecture Notes in Computer Science, Volume
+ 291, DOI 10.1007/3-540-48184-2_32, 1988,
+ <https://doi.org/10.1007/3-540-48184-2_32>.
+
+ [M1989a] Merkle, R., "A Certified Digital Signature", Advances in
+ Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in
+ Computer Science, Volume 435,
+ DOI 10.1007/0-387-34805-0_21, 1990,
+ <https://doi.org/10.1007/0-387-34805-0_21>.
+
+ [M1989b] Merkle, R., "One Way Hash Functions and DES", Advances in
+ Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in
+ Computer Science, Volume 435,
+ DOI 10.1007/0-387-34805-0_40, 1990,
+ <https://doi.org/10.1007/0-387-34805-0_40>.
+
+ [NAS2019] National Academies of Sciences, Engineering, and Medicine,
+ "Quantum Computing: Progress and Prospects", The National
+ Academies Press, DOI 10.17226/25196, 2019,
+ <http://dx.doi.org/10.17226/25196>.
+
+ [PQC] Bernstein, D., "Introduction to post-quantum
+ cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009,
+ <http://www.pqcrypto.org/www.springer.com/cda/content/
+ document/cda_downloaddocument/9783540887010-c1.pdf>.
+
+ [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086,
+ DOI 10.17487/RFC4086, June 2005,
+ <https://www.rfc-editor.org/info/rfc4086>.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+ <https://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
+ "PKCS #1: RSA Cryptography Specifications Version 2.2",
+ RFC 8017, DOI 10.17487/RFC8017, November 2016,
+ <https://www.rfc-editor.org/info/rfc8017>.
+
+ [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+ Signature Algorithm (EdDSA)", RFC 8032,
+ DOI 10.17487/RFC8032, January 2017,
+ <https://www.rfc-editor.org/info/rfc8032>.
+
+ [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
+ Definition Language (CDDL): A Notational Convention to
+ Express Concise Binary Object Representation (CBOR) and
+ JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
+ June 2019, <https://www.rfc-editor.org/info/rfc8610>.
+
+Appendix A. Examples
+
+ This appendix provides a non-normative example of a COSE full message
+ signature and an example of a COSE_Sign1 message. This section is
+ formatted according to the extended CBOR diagnostic format defined by
+ [RFC8610].
+
+ The programs that were used to generate the examples can be found at
+ <https://github.com/cose-wg/Examples>.
+
+A.1. Example COSE Full Message Signature
+
+ This section provides an example of a COSE full message signature.
+
+ The size of binary file is 2560 bytes.
+
+ 98(
+ [
+ / protected / h'a10300' / {
+ \ content type \ 3:0
+ } / ,
+ / unprotected / {},
+ / payload / 'This is the content.',
+ / signatures / [
+ [
+ / protected / h'a101382d' / {
+ \ alg \ 1:-46 \ HSS-LMS \
+ } / ,
+ / unprotected / {
+ / kid / 4:'ItsBig'
+ },
+ / signature / h'00000000000000010000000391291de76ce6e24d1e2a
+ 9b60266519bc8ce889f814deb0fc00edd3129de3ab9b6bfa3bf47d007d844af7db74
+ 9ea97215e82f456cbdd473812c6a042ae39539898752c89b60a276ec8a9feab900e2
+ 5bdfe0ab8e773aa1c36ae214d67c65bb68630450a5db2c7c6403b77f6a9bf4d30a02
+ 19db5cced884d7514f3cbd19220020bf3045b0e5c6955b32864f16f97da02f0cbfea
+ 70458b07032e30b0342d75b8f3dc6871442e6384b10f559f5dc594a214924c48ccc3
+ 37078665653fc740340428138b0fb5154f2f2cb291ad05ace7acae60031b2d09b2f4
+ 17712d1c01e34b165af2e070f5a521a85a5fb3dd2a6288947bcbd5e2265d3670bd61
+ 92eb2bf643964e2783d84aec343f8e3571e4fcf09cbeea94e80470aa7252d1c733a5
+ 535907e66c7b9f0b88b159dc2a7370ee47f13e7e134d3d05e5f53fac640b784a9b0f
+ 183fe14217325626f487cc8d8cb9eaf0abb174ee0b7076cf39c45037cefdf3f1e61b
+ 5174581214c09870b72c39737ec4c46a96199b66cad2990bcbe5bb1abfde99107c7f
+ 7289395bf2a433598ede0b1969f23db949afb5b4d33831dae6c641a6355f8f9bf16c
+ dffc4bf86891b93a557c2152ac8a1de51c995344cc10cc4bc9ecfbb4e418bed0f334
+ af165339e6725dc4fc1e995521e1be8a566d59b57cd130903b42d07087d63646ef8f
+ c1e9e9071bb67a123fdec3f37638cdaf0f4bf3084074069171c17885b9431ad908d3
+ 6a6f8a826256d2aa34f8aa0731a357c060db8e80fefd61b1c323890e640633b98d17
+ 5d4d6ebff800a71cfc864ec02837de9d0e079f0f400acafd56805cb273e631ba395d
+ 23e86acf6eae63181a5afe1f0a361cbbd5fefeb7db0c95591ec3128e80dfbea9ca0f
+ 89fc035d761c05d41e7a010892c42e8e2af62aa604f4e214c0bb08075481f9cc307a
+ 555adf333b9424f209b89f161032e413b047ae5ab0aa15643bb4c643446d2c9829eb
+ 256e7375ce9639047a24a44f4da446b7359556f3ab3484c56511c68a140dc0531f65
+ 3105800d9f20990d4ebdc5ceea918d7ae95c0d7ec69a00d6a936b25fc19b9dfc5561
+ 400f046191136c367038d6a9d0e0ae30dcdc4733712cbd5a2aee35315eff5c1a7e08
+ 5b68c5cf0c64c495df2ca6f030db04480a2e11d4a0a0dbf29d9463d5b9e41e346e49
+ c894d5e43993c834c4746309c886d6131f2f92155ca1160bac9660802a947b5aba94
+ b35357d13fdf02d2aeabef568912f68ae5d3a60214f6d00c4dd9f0af09eb0bf961cd
+ 9f27251d46899c28d87080ba2ead3e8193f51a789706ec32aacee9f4b14eeca91a25
+ 2fe894b30dc3938abbbe7d217948cae79ce3adb4d7d7df6756f3099f2543ed3b522b
+ acab257503c9e07fcd32cc32fa9aa17977ec05bc5fe0f5954d51f160f52d33f93166
+ af68aa90261b3f5ad273adacf2d0cb5b0c5402bfa62da67a52dcddfa463e72d2c005
+ f1ac0ea3cb62364ee3419333612e07bf685006137a592e2fcd58398265c4ff9e11e7
+ 0c2b79152e4604b4f94676e955bcff4dfc429a8a88728b95bfc2826e25ba6eab9cfb
+ 066c9911693efff242f7b51c3cb88546143b8ab2142dd3c9bda55d16fe3084a86b74
+ 3f294dd9d0aa84f3ce3b083a5879a4762a756e9b41f4bdf8b71418073b0a0d4a9c13
+ 1882455ece23e50324c5feea217920b0f3109dcbdc81762e41b7ca271efac8e39cc2
+ 6ebe085abdbf6b314a38929799fb7feebee2e20b97056ed17ef3881e6e89330314dd
+ 7e9c629c46dfdb925c7c5f5d243f159d964691745cd46579fd0696479e1c49cbd2af
+ 879a2bce8576619cca7b6e516e6c94c1087441a81f11b9a83535b24ddc725a81a9d1
+ ff62da2804c8d84c6e382065574282ea1f23eaf648cfa9767afb098fd81654d76133
+ f5f39bcc762c9bc31f7f4665cc0efa929b5c05dedd76143c63dc7018ab130c108ea9
+ 01be32b9d911b66da13a1528c32a9694c899a772f8e1fe00c17eceb343e737d72cba
+ 06cf5ddac9a4d3df7ef391cf6595a6d8c14b0d80f93023b1b3d4371239da98b67a1b
+ 6a379422616282a16e8d1f97a130baf21e572bcca91abb760eac6957f9b1b05e49e2
+ d181874ac6dd160d1c717b73bd28ef55f08d47466d5aef754814c7e206fa9e2ec533
+ 85d14d52f7769d95ea50524ffb20dc7275b04d71d1967e3bbc6ed481f1fc5a15e78a
+ 1fd967d96045625645dbd173cccdd97661e995ce47d6b3ead96ee6d006a5ce6f4c97
+ 77fe2e3f91bebe877cac8c6486dfce0315dc71bbb93879759b8981c5ff2e11deb809
+ abf4280ee93d1711e73645b410acb518538ce3d4bda1e355c988f068165668e99d6a
+ 8de356b4b13298036ad05d526c4a5e2591612a477b7e86550adde128cd71ee651d44
+ 99699000a02979e42bbccf32c83b1eb0ff99aa4d352e20e0b3382422df2c2ed4ce90
+ c94cf1a359e92ef971dc6db06047a333c2ebe827eb6d5f2811fdbe0bf0f12bf2094e
+ 0dcd8e418f3f691a60ceb0cefb6f45f47883d6b9f320950e91266740c6dbfad6b3cf
+ e56de0aa6658b0dc893bb6e49e6294537a7878e86cfc8e6c150675db1a89d188ea6e
+ fe7d88ff57b39b8610e392811ee097ca61c4841e0fbd346ed3ff6a5e412acb0d9f13
+ 022df2e7fdaa8e0face7366c8ffe6f446995b564fc3d59c70fecdb60a25e28650417
+ 157f43f3e72c3afc601509641cfd099a78130e1f7ba8333502ad4f036f46411a43d0
+ 35e2ca0ed0c346d9aac5df05196c95c38e6e52763ed896b6d02464a910dda6cca340
+ 24e3b9c3723d26e2886ad724dd56ea285e8e4b60beec924d55dd700c38877b74552f
+ ea1f8741579b02061416131db390f628522885236b51f7aef23167d3a5fe5eadcd88
+ b0e99b2b6bc56b0dea4fb22146294766c28e5e7c834dbdcb6bfdd7bd8455252522ff
+ 2e974f6fd3fda176749b7cdced5b9aba092b2982c89cb7d2b36348928c8f01170618
+ ecff14d9e0eed9d88d97e38bcf7a837f674be5243fc624c8afd3d105f462bfa939b8
+ 143a3a98f78fbb8c915e00bdbbf707b12c45784f4d1cb1426b583a0d5fbec1f5ea6d
+ 0067c090168cb788e532aca770c7be366ec07e7808f1892b00000006ed1ce8c6e437
+ 918d43fba7bd9385694c41182703f6b7f704deedd9384ba6f8bc362c948646b3c984
+ 8803e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e
+ 7c81a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc5
+ 6211d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d26
+ 246595c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0ba
+ e71696cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c
+ 29d4f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c10
+ 7362f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9
+ ce949be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931b
+ a7b3bd0d824a4570'
+ ]
+ ]
+ ]
+ )
+
+A.2. Example COSE_Sign1 Message
+
+ This section provides an example of a COSE_Sign1 message.
+
+ The size of binary file is 2552 bytes.
+
+ 18(
+ [
+ / protected / h'a101382d' / {
+ \ alg \ 1:-46 \ HSS-LMS \
+ } / ,
+ / unprotected / {
+ / kid / 4:'ItsBig'
+ },
+ / payload / 'This is the content.',
+ / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60
+ 266519bc8ce889f814deb0fc00edd3129de3ab9b9aa5b5ac783bdf0fe689f57fb204
+ f1992dbc1ce2484f316c74bce3f2094cfa8e96a4a9548cead0f78ee5d549510d1910
+ f647320448ae27ecce77249802a0c39c645bf8db08573af52c93d91fd0e217f245c7
+ 52c176b81514eb6e3067e0fbb329225eaa88c7d21635e32ae84213f89018cb06f1b8
+ 4e61eac348b690d7c6265c19f9d868952d99826aecd417b5279dd674cd951c306016
+ cfee4fee3bfcf5ee5a5ad08b5b4f53bc93995f26cfe7c0c1c5ba2574c1f2d8470993
+ e8bd47ef9b9cf309ef895226e92be60683459009611defbb9a43217956a0ab2959bb
+ da0feca39de37e7c4a6cd8a5314d6b02b377406d5a5e589e91feaa9f2e4ec1682ba1
+ f633c7784499323e40da651f71d3c19e38c634d898b0c508324c0bfcf7c5f0a8c014
+ b4af200a739f96cddba94daf86ce80c76158d4f5cf3cd2ba9f1393df47e556887f91
+ 68540485242a05ec6bcc76659ec3d0d2fedae3fd1608a701c226f5fd83c9b1ed3152
+ ddac7426c30e3390bec8f1da6174abe8d3568c9b76b149eb077d61ac15b8fb11b8ce
+ 5f9d14e448e216f375e1f96a52d39619459b131026143e8809bad408f5ef66cd3da2
+ 27431e68670c0b4b2c3801e1e9025b1ebed218e0956967158ccc274c704adcd8cc23
+ c149a89eda25478742dadc15f233844535e4021000b5d557313d4f271875680e6d5e
+ 7f6681fdd19f8b9a748cabb2377aac1387fdb80e618eb7d69a368729ca9a092af91e
+ be1c584c35fe62734d1d53d10b35dd02093a201c889ad37a558b610f1ab00179a11f
+ 881600e944cedc47a7ae6d828009d7c61ffea9dd5aa5406408e2e85dc056e47b5758
+ 9eaba18e792f4631af62d4588a1818167274273c69e7a0735be5dada7e224e3b178b
+ 3b093212eb74e762f564a26d577aa22ebd8c7b4a999419908e2f2d9c8689dc923905
+ c198b9ee335d1e0de6d689655f446dffea997b6e58f5f648415233ede3b9d8a2db29
+ e8c3dde5d8dbd55e6348cd9f421783db090e087de46425d62d513597b00d7de32fad
+ 87752a79cee8b2a38b1e0f2562836721cbbfba20f131130c009a436b93a0bb44fcbb
+ 86228b1bf1a35f4fc626817924eaebd5b78d64a7970d18dade90cf0ad759b1c45d95
+ 3c08cd1189685077c5a56069da0944669d797496f8f886fea6f792598db2ac66b657
+ af838ed3c3a914dffbb164170a1f63250b125eda53ecaeaf6ee0d2b8a3c804104d7e
+ d575b66469bc59f37eec6c6f6fb19e0f7ea02d7c85306230063adb58950589f6ffaf
+ f1407233828ae0dfbe5889e5de00bb640a4bc24c3f704488fa669676a9ebbbed399b
+ 8a9ac0ee4cc944f864b21f642e04f610319ac9271f8bd820e77e41dac6553d234d94
+ 80e26142c0fa37416651d6450e1f2082bd0213d6783e1ae3cc5c5af677c3316e173b
+ a4716d6bc8a9d89383f8b025a0859b99a43daeaf8ddaed46d223b9b503651a67560b
+ feb2f35ba544722620ec4086dcc77e6e87bb53f1f18c38368662be460ede31325cae
+ aebf018a6fa9d32e3c3a6898e15fe114dcce51241c61afabc36de3608b4d342712a8
+ 33615c6131e89e1d46b713d9638a08b5a768d53af0298b9c874ded7084358223840c
+ 2e78cd6fbfca695279a4c1883bb7de81b04a069de8277f7f5109c16938347a643713
+ c9ac36fffc8bf141e899f48bc25c7b636d43bebcfa7742d4e1462263e56732ad2021
+ eef8ce84023c4959cfd250343d62074724907de9d49ea2f6c968fd9e9bf28feafcdc
+ 81702108805dec60f2781272d2425a6ee29c66122d2c557867c1a5aed82131e06fc3
+ 84ecf49017e1c9d6cf63b9f2285ccf890cbb9bbf796e0fd02101948b7ef663849367
+ 7b33fd787d9d3fc2c7cc7babc21af8c748afb80cf86b45dc89f0b9c7959621e85b98
+ b542dc263db9255273bb9054a7f194748f28373ba123d73fc71fef43e7e2ac9a8000
+ 8e85cf2f04aa433075dfc54c4de24a341ebf7cf1e6b383dbba85898fdc368017fd67
+ c153e7a991a3a3cee6dae4fbe2fe6f25a8df314140a8176c8e6fd0c6f042ca66eb6a
+ bba9a2502bb6dfa52960ae86a942a673e4e45439594fefcd2974e20554d1dc70b8e0
+ 34fd1787801343d5f6edc95ce0348c25727c771526e3fd4effb5f16e25a1ea3dcd82
+ 82e778e91ae9b339a5013c77fd6ea2432704e293f5e82a24121c73900bea4b4ef14a
+ 2adc1ab3c68224bae1de9c61a48b84e84c1b0e83701be3d988012a24fa40268c8d6e
+ f1fd2818ae8e4b6f52f89beab6bfdd1ff1b7ecd573edff3703b800b5b2a206f451f1
+ bf2713b4ae9085bd7fe34ad4306a290e4cdb7817ee9ab7ccfb816d002b619f77d46d
+ 7dd0f8eefe10f5c0f9723ffdb14ca75a185543770f41508b9983d5eed78225bc6e21
+ f876bfdd08fe8bc63e0cb253c7dfc67c330897c515244f3f631682f2141eba48ca86
+ dfff9206f78edcb9dec4b2371aeddbe141ef96a10957e29a94747c4438fb30b14d37
+ e7428eb7fbe4f9d870e72f35f55847f230374bdf56dcae6c129b4468ebaedc340ff4
+ cc160c6b410e2d8989488ac8ef9a9febbf65ad4fdfba532a8122ef82dc1a4ffc361c
+ bf9f752b36aa9821683d5f3f5842f90134eb423d5cbc76858b4c0a7ba798ec94a089
+ fdb24b5b25f42d7b6bb8192f07b98eb2de1fe7bc8b6c740fa5cde6fb4890d2f17916
+ 64a96c25a0a71a541025b5ec825eed91f393505473e21d0620177993982e6c1b6bf9
+ 1b777b5ab5739b84946c518c7e6aa0e689e9ad1d34e6ef6ca0e709c4aefecd6f2594
+ b017940742aceb72c5a52d7d47a3a74f9d09eb84cf82b349de32278a771cebc31ebc
+ 580c09b11799b1f0e6d11d75b17e389d259c531f957a1e699250711df2e36f64f21c
+ 92eff698a392d92df0b2f91991408a076b83149e025a9ffba1ff1caed916a2fc1ac5
+ d3081c30b5c64b7d677c314b6e76ac20ed8bb4a4c0eb465ae5c0c265969264b27e6d
+ 54c266f79e58e2fa6a381069090bec00189562abcf831adc86a05a2fc7ffaa70dbd3
+ fa60e09d447cd76b2ff2b851c38e72650ade093ba8bd000000067b95de445abf8916
+ 1dff4b91a4a9e3bf156a39a4660f98f06bf3f017686d9dfc362c948646b3c9848803
+ e6d9ba1f7d3967f709cddd35dc77d60356f0c36808900b491cb4ecbbabec128e7c81
+ a46e62a67b57640a0a78be1cbf7dd9d419a10cd8686d16621a80816bfdb5bdc56211
+ d72ca70b81f1117d129529a7570cf79cf52a7028a48538ecdd3b38d3d5d62d262465
+ 95c4fb73a525a5ed2c30524ebb1d8cc82e0c19bc4977c6898ff95fd3d310b0bae716
+ 96cef93c6a552456bf96e9d075e383bb7543c675842bafbfc7cdb88483b3276c29d4
+ f0a341c2d406e40d4653b7e4d045851acf6a0a0ea9c710b805cced4635ee8c107362
+ f0fc8d80c14d0ac49c516703d26d14752f34c1c0d2c4247581c18c2cf4de48e9ce94
+ 9be7c888e9caebe4a415e291fd107d21dc1f084b1158208249f28f4f7c7e931ba7b3
+ bd0d824a4570'
+ ]
+ )
+
+Acknowledgements
+
+ Many thanks to Roman Danyliw, Elwyn Davies, Scott Fluhrer, Ben Kaduk,
+ Laurence Lundblade, John Mattsson, Jim Schaad, and Tony Putman for
+ their valuable review and insights. In addition, an extra special
+ thank you to Jim Schaad for generating the examples in Appendix A.
+
+Author's Address
+
+ Russ Housley
+ Vigil Security, LLC
+ 516 Dranesville Road
+ Herndon, VA 20170
+ United States of America
+
+ Email: housley@vigilsec.com