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)


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

Copyright Notice

Copyright © 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 ( 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
   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
   p:    The number of n-byte string elements that make up the LM-OTS
   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, <>.
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.
   [SHS]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard", FIPS Publication 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,

7.2. Informative References

   [BH2013]   Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The
              Factoring Dead: Preparing for the Cryptopocalypse", August
              2013, <
   [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,
   [IANA]     IANA, "CBOR Object Signing and Encryption (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,
   [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,
   [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,
   [NAS2019]  National Academies of Sciences, Engineering, and Medicine,
              "Quantum Computing: Progress and Prospects", The National
              Academies Press, DOI 10.17226/25196, 2019,
   [PQC]      Bernstein, D., "Introduction to post-quantum
              cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009,
   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
   [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,
   [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,
   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
   [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, <>.

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 <>.

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.

       / 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

A.2. Example COSE_Sign1 Message

This section provides an example of a COSE_Sign1 message.

The size of binary file is 2552 bytes.

       / protected / h'a101382d' / {
           \ alg \ 1:-46 \ HSS-LMS \
         } / ,
       / unprotected / {
         / kid / 4:'ItsBig'
       / payload / 'This is the content.',
       / signature / h'00000000000000000000000391291de76ce6e24d1e2a9b60


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