doc: Add RFC documents

1 files changed, 649 insertions, 0 deletions

diff --git a/doc/rfc/rfc8708.txt b/doc/rfc/rfc8708.txt
new file mode 100644
index 0000000..ce206e3
--- /dev/null
+++ b/doc/rfc/rfc8708.txt
@@ -0,0 +1,649 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 8708                                Vigil Security
+Category: Standards Track                                  February 2020
+ISSN: 2070-1721
+
+
+ Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic
+                          Message Syntax (CMS)
+
+Abstract
+
+   This document specifies the conventions for using the Hierarchical
+   Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
+   signature algorithm with the Cryptographic Message Syntax (CMS).  In
+   addition, the algorithm identifier and public key syntax are
+   provided.  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/rfc8708.
+
+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.  ASN.1
+     1.2.  Terminology
+     1.3.  Motivation
+   2.  HSS/LMS Hash-Based 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.  Algorithm Identifiers and Parameters
+   4.  HSS/LMS Public Key Identifier
+   5.  Signed-Data Conventions
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Appendix A.  ASN.1 Module
+   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 Cryptographic Message Syntax (CMS) [CMS]
+   signed-data content type.  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
+   numbers of signatures.  The HSS/LMS algorithm is one form of 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 with a given private key, and 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 exclusively use SHA-256 [SHS].
+
+1.1.  ASN.1
+
+   CMS values are generated using ASN.1 [ASN1-B], using the Basic
+   Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
+   [ASN1-E].
+
+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.
+
+1.3.  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 when cryptosystems such as RSA and DSA that
+   depend on discrete logarithms and factoring cannot be depended upon.
+
+   If large-scale quantum computers are ever built, these computers 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 quantum computers that have more than a trivial number of
+   quantum bits (qubits).  It is open to conjecture when it will be
+   feasible to build such computers; however, RSA, DSA, Elliptic Curve
+   Digital Signature Algorithm (ECDSA), and Edwards-curve Digital
+   Signature Algorithm (EdDSA) are all vulnerable if large-scale quantum
+   computers are ever developed.
+
+   Since the HSS/LMS signature algorithm does not depend on the
+   difficulty of discrete logarithms or factoring, the HSS/LMS signature
+   algorithm is considered to be post-quantum secure.  One use of post-
+   quantum-secure signatures is the protection of software updates,
+   perhaps using the format described in [FWPROT], to enable deployment
+   of software that implements new cryptosystems.
+
+2.  HSS/LMS Hash-Based Signature Algorithm Overview
+
+   Merkle Tree Signatures (MTS) are a method for signing a large but
+   fixed number of messages.  An MTS system depends on a one-time
+   signature method and a collision-resistant hash function.
+
+   This specification makes use of the hash-based 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].
+
+   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] uses only the SHA-256 one-way hash
+   function [SHS], but it establishes an IANA registry [IANA-LMS] to
+   permit the registration of additional one-way hash functions in the
+   future.
+
+2.1.  Hierarchical Signature System (HSS)
+
+   The MTS system 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 standalone tree (a top
+   tree with no children) can be summarized as:
+
+      u32str(0) ||
+      lms_signature  /* signature of message */
+
+   where, u32str() and || are used as defined in [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 */
+
+   where, as defined in Section 3.3 of [HASHSIG], the signed_public_key
+   structure contains 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)
+
+   Each tree in the system 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] specification supports
+   five values for 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, m,
+   is the number of bytes output by the hash function, and it is the
+   amount of data associated with each node in the tree.  The [HASHSIG]
+   specification supports only the SHA-256 hash function [SHS], with
+   m=32.  As a result, the [HASHSIG] specification supports five tree
+   sizes; they are identified as:
+
+   *  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 [IANA-LMS]
+   to permit the registration of additional hash functions and
+   additional tree sizes in the future.
+
+   As specified in [HASHSIG], the LMS public key consists of four
+   elements: the lms_algorithm_type from the list above, the otstype to
+   identify the Leighton-Micali One-Time Signature (LM-OTS) type as
+   discussed in Section 2.3, the private key identifier (I) as described
+   in Section 5.3 of [HASHSIG], and the m-byte string associated with
+   the root node of the tree (T[1]).
+
+   The LMS public key can be summarized as:
+
+      u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
+
+   As specified in [HASHSIG], an LMS signature consists of four
+   elements: the number of the leaf (q) associated with the LM-OTS
+   signature value, an LM-OTS signature value as described in
+   Section 2.3, a typecode 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 value 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
+
+   Merkle Tree Signatures (MTS) depend on a one-time signature method,
+   and [HASHSIG] specifies the use of the LM-OTS, which has five
+   parameters:
+
+   n:   The length in bytes of the hash function output.  [HASHSIG]
+        supports only SHA-256 [SHS], with 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 value.
+
+   ls:  The number of bits that are left-shifted in the final step of
+        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 [IANA-LMS]
+   to permit the registration of additional variants in the future.
+
+   Signing involves the generation of C, 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]) that correspond to the elements of the public key, as
+   described in Section 4.5 of [HASHSIG]:
+
+      u32str(otstype) || C || y[0] || ... || y[p-1]
+
+3.  Algorithm Identifiers and Parameters
+
+   The algorithm identifier for an HSS/LMS hash-based signature is:
+
+      id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
+          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+          smime(16) alg(3) 17 }
+
+   When this object identifier is used for an HSS/LMS signature, the
+   AlgorithmIdentifier parameters field MUST be absent (that is, the
+   parameters are not present, and the parameters are not set to NULL).
+
+   The signature value is a large OCTET STRING, as described in
+   Section 2 of this document.  The signature format is designed for
+   easy parsing.  The HSS, LMS, and LM-OTS components of the signature
+   value each include a counter and a typecode that indirectly provide
+   all of the information that is needed to parse the value during
+   signature validation.
+
+   The signature value identifies the hash function used in the HSS/LMS
+   tree.  [HASHSIG] uses only the SHA-256 hash function [SHS], but it
+   establishes an IANA registry [IANA-LMS] to permit the registration of
+   additional hash functions in the future.
+
+4.  HSS/LMS Public Key Identifier
+
+   The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg-
+   hss-lms-hashsig object identifier, and the parameters field MUST be
+   absent.
+
+   When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
+   field of an X.509 certificate [RFC5280], the certificate key usage
+   extension MAY contain digitalSignature, nonRepudiation, keyCertSign,
+   and cRLSign; however, it MUST NOT contain other values.
+
+      pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
+          IDENTIFIER id-alg-hss-lms-hashsig
+          KEY HSS-LMS-HashSig-PublicKey
+          PARAMS ARE absent
+          CERT-KEY-USAGE
+            { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
+
+      HSS-LMS-HashSig-PublicKey ::= OCTET STRING
+
+   Note that the id-alg-hss-lms-hashsig algorithm identifier is also
+   referred to as id-alg-mts-hashsig.  This synonym is based on the
+   terminology used in an early draft version of the document that
+   became [HASHSIG].
+
+   The public key value is an OCTET STRING.  Like the signature format,
+   it is designed for easy parsing.  The value is the number of levels
+   in the public key, L, followed by the LMS public key.
+
+   The HSS/LMS public key value can be described as:
+
+         u32str(L) || lms_public_key
+
+   Note that the public key for the topmost LMS tree is the public key
+   of the HSS system.  When L=1, the HSS system is a single tree.
+
+5.  Signed-Data Conventions
+
+   As specified in [CMS], the digital signature is produced from the
+   message digest and the signer's private key.  The signature is
+   computed over different values depending on whether signed attributes
+   are absent or present.
+
+   When signed attributes are absent, the HSS/LMS signature is computed
+   over the content.  When signed attributes are present, a hash is
+   computed over the content using the same hash function that is used
+   in the HSS/LMS tree, then a message-digest attribute is constructed
+   with the hash of the content, and then the HSS/LMS signature is
+   computed over the DER-encoded set of signed attributes (which MUST
+   include a content-type attribute and a message-digest attribute).  In
+   summary:
+
+      IF (signed attributes are absent)
+      THEN HSS_LMS_Sign(content)
+      ELSE message-digest attribute = Hash(content);
+           HSS_LMS_Sign(DER(SignedAttributes))
+
+   When using [HASHSIG], the fields in the SignerInfo are used as
+   follows:
+
+   *  digestAlgorithm MUST contain the one-way hash function used in the
+      HSS/LMS tree.  In [HASHSIG], SHA-256 is the only supported hash
+      function, but other hash functions might be registered in the
+      future.  For convenience, the AlgorithmIdentifier for SHA-256 from
+      [PKIXASN1] is repeated here:
+
+            mda-sha256 DIGEST-ALGORITHM ::= {
+                IDENTIFIER id-sha256
+                PARAMS TYPE NULL ARE preferredAbsent }
+
+            id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+                country(16) us(840) organization(1) gov(101) csor(3)
+                nistAlgorithms(4) hashalgs(2) 1 }
+
+   *  signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the
+      algorithm parameters field MUST be absent.
+
+   *  signature contains the single HSS signature value resulting from
+      the signing operation as specified in [HASHSIG].
+
+6.  Security Considerations
+
+   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 non-
+   volatile 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 pseudorandom number
+   generator (PRNG) to generate these values is much less severe than in
+   the generation of private keys, the guidance in [RFC4086] remains
+   important.
+
+   When computing signatures, the same hash function SHOULD be used to
+   compute the message digest of the content and the signed attributes,
+   if they are present.
+
+7.  IANA Considerations
+
+   In the "SMI Security for S/MIME Module Identifier
+   (1.2.840.113549.1.9.16.0)" registry, IANA has updated the reference
+   for value 64 to point to this document.
+
+   In the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)"
+   registry, IANA has updated the description for value 17 to "id-alg-
+   hss-lms-hashsig" and updated the reference to point to this document.
+
+   IANA has also added the following note to the "SMI Security for
+   S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry:
+
+      Value 17, "id-alg-hss-lms-hashsig", is also referred to as "id-
+      alg-mts-hashsig".
+
+8.  References
+
+8.1.  Normative References
+
+   [ASN1-B]   ITU-T, "Information technology -- Abstract Syntax Notation
+              One (ASN.1): Specification of basic notation",
+              ITU-T Recommendation X.680, August 2015.
+
+   [ASN1-E]   ITU-T, "Information technology -- ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", ITU-T Recommendation X.690, August 2015.
+
+   [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <https://www.rfc-editor.org/info/rfc5652>.
+
+   [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>.
+
+   [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>.
+
+   [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 (SHS)", FIPS PUB 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://doi.org/10.6028/NIST.FIPS.180-4>.
+
+8.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>.
+
+   [CMSASN1]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for
+              Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
+              DOI 10.17487/RFC5911, June 2010,
+              <https://www.rfc-editor.org/info/rfc5911>.
+
+   [CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
+              for the Cryptographic Message Syntax (CMS) and the Public
+              Key Infrastructure Using X.509 (PKIX)", RFC 6268,
+              DOI 10.17487/RFC6268, July 2011,
+              <https://www.rfc-editor.org/info/rfc6268>.
+
+   [FWPROT]   Housley, R., "Using Cryptographic Message Syntax (CMS) to
+              Protect Firmware Packages", RFC 4108,
+              DOI 10.17487/RFC4108, August 2005,
+              <https://www.rfc-editor.org/info/rfc4108>.
+
+   [IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
+              <https://www.iana.org/assignments/leighton-micali-
+              signatures/>.
+
+   [LM]       Leighton, T. and S. Micali, "Large provably fast and
+              secure digital signature schemes based on secure hash
+              functions", U.S. Patent 5,432,852, July 1995.
+
+   [M1979]    Merkle, R., "Secrecy, Authentication, and Public Key
+              Systems", Technical Report No. 1979-1, Information Systems
+              Laboratory, Stanford University, 1979.
+
+   [M1987]    Merkle, R., "A Digital Signature Based on a Conventional
+              Encryption Function", Advances in Cryptology -- CRYPTO '87
+              Proceedings, Lecture Notes in Computer Science Vol. 293,
+              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 Vol. 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 Vol. 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,
+              <https://doi.org/10.17226/25196>.
+
+   [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
+              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
+              DOI 10.17487/RFC5912, June 2010,
+              <https://www.rfc-editor.org/info/rfc5912>.
+
+   [PQC]      Bernstein, D., "Introduction to post-quantum
+              cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009,
+              <http://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>.
+
+Appendix A.  ASN.1 Module
+
+   <CODE STARTS>
+
+   MTS-HashSig-2013
+     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+       id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
+
+   DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+   EXPORTS ALL;
+
+   IMPORTS
+     PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
+       FROM AlgorithmInformation-2009  -- RFC 5911 [CMSASN1]
+         { iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) mechanisms(5) pkix(7) id-mod(0)
+           id-mod-algorithmInformation-02(58) } ;
+
+   --
+   -- Object Identifiers
+   --
+
+   id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
+       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+       smime(16) alg(3) 17 }
+
+   id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig
+
+   --
+   -- Signature Algorithm and Public Key
+   --
+
+   sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= {
+       IDENTIFIER id-alg-hss-lms-hashsig
+       PARAMS ARE absent
+       PUBLIC-KEYS { pk-HSS-LMS-HashSig }
+       SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } }
+
+   pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
+       IDENTIFIER id-alg-hss-lms-hashsig
+       KEY HSS-LMS-HashSig-PublicKey
+       PARAMS ARE absent
+       CERT-KEY-USAGE
+           { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
+
+   HSS-LMS-HashSig-PublicKey ::= OCTET STRING
+
+   --
+   -- Expand the signature algorithm set used by CMS [CMSASN1U]
+   --
+
+   SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
+       { sa-HSS-LMS-HashSig, ... }
+
+   --
+   -- Expand the S/MIME capabilities set used by CMS [CMSASN1]
+   --
+
+   SMimeCaps SMIME-CAPS ::=
+       { sa-HSS-LMS-HashSig.&smimeCaps, ... }
+
+   END
+
+   <CODE ENDS>
+
+Acknowledgements
+
+   Many thanks to Joe Clarke, Roman Danyliw, Scott Fluhrer, Jonathan
+   Hammell, Ben Kaduk, Panos Kampanakis, Barry Leiba, John Mattsson, Jim
+   Schaad, Sean Turner, Daniel Van Geest, and Dale Worley for their
+   careful review and comments.
+
+Author's Address
+
+   Russ Housley
+   Vigil Security, LLC
+   516 Dranesville Road
+   Herndon, VA 20170
+   United States of America
+
+   Email: housley@vigilsec.com