rfc8708xml2.original.xml   rfc8708.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5652.xml">
<!ENTITY RFC8554 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8554.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5280.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC5911 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5911.xml">
<!ENTITY RFC6268 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6268.xml">
<!ENTITY RFC4108 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4108.xml">
<!ENTITY RFC5912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5912.xml">
<!ENTITY RFC4086 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4086.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-lamps-cms-hash-sig-10" category="
std" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2019-10-23T17:15:15Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="Use of the HSS/LMS Hash-based Signature ">Use of the HSS/L
MS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)</tit
le>
<author fullname="Russ Housley" initials="R." surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address><postal><street>516 Dranesville Road</street>
<city>Herndon</city> <region>VA</region> <code>20170</code>
<country>USA</country>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<date month="October" year="2019"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<abstract><t> category="std" consensus="true"
docName="draft-ietf-lamps-cms-hash-sig-10" number="8708"
ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true"
symRefs="true" tocInclude="true" version="3">
<!-- xml2rfc v2v3 conversion 2.34.0 -->
<!-- Generated by id2xml 1.5.0 on 2019-10-23T17:15:15Z -->
<front>
<title abbrev="Use of the HSS/LMS Hash-Based Signature">Use of the HSS/LMS
Hash-Based Signature Algorithm in the Cryptographic Message Syntax
(CMS)</title>
<seriesInfo name="RFC" value="8708"/>
<author fullname="Russ Housley" initials="R." surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address>
<postal>
<street>516 Dranesville Road</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>United States of America</country>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<date month="January" year="2020"/>
<abstract>
<t>
This document specifies the conventions for using the Hierarchical This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with the Cryptographic Message Syntax (CMS). In signature algorithm with the Cryptographic Message Syntax (CMS). In
addition, the algorithm identifier and public key syntax are addition, the algorithm identifier and public key syntax are
provided. The HSS/LMS algorithm is one form of hash-based digital provided. The HSS/LMS algorithm is one form of hash-based digital
signature; it is described in RFC 8554.</t> signature; it is described in RFC 8554.</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
</abstract> <t>
</front>
<middle>
<section title="Introduction" anchor="sect-1"><t>
This document specifies the conventions for using the Hierarchical This document specifies the conventions for using the Hierarchical
Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
signature algorithm with the Cryptographic Message Syntax (CMS) <xref target= "CMS"/> signature algorithm with the Cryptographic Message Syntax (CMS) <xref target= "RFC5652" format="default"/>
signed-data content type. The LMS system provides a one-time digital signed-data content type. The LMS system provides a one-time digital
signature that is a variant of Merkle Tree Signatures (MTS). The HSS 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 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- numbers of signatures. The HSS/LMS algorithm is one form of hash-based digit
based digital signature, and it is described in <xref target="HASHSIG"/>. Th al signature, and it is described in <xref target="RFC8554" format="default"/>.
e The
HSS/LMS signature algorithm can only be used for a fixed number of 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 with a given private key, and the number of
signing operations depends upon the size of the tree. The HSS/LMS signing operations depends upon the size of the tree. The HSS/LMS
signature algorithm uses small public keys, and it has low signature algorithm uses small public keys, and it has low
computational cost; however, the signatures are quite large. The computational cost; however, the signatures are quite large. The
HSS/LMS private key can be very small when the signer is willing to HSS/LMS private key can be very small when the signer is willing to
perform additional computation at signing time; alternatively, the perform additional computation at signing time; alternatively, the
private key can consume additional memory and provide a faster private key can consume additional memory and provide a faster
signing time. The HSS/LMS signatures <xref target="HASHSIG"/> are currently signing time. The HSS/LMS signatures <xref target="RFC8554" format="default"
defined /> are currently defined
to use exclusively SHA-256 <xref target="SHS"/>.</t> to exclusively use SHA-256 <xref target="SHS" format="default"/>.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="ASN.1" anchor="sect-1.1"><t> <name>ASN.1</name>
CMS values are generated using ASN.1 <xref target="ASN1-B"/>, using the Basic <t>
CMS values are generated using ASN.1 <xref target="ASN1-B" format="default"/>
, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
<xref target="ASN1-E"/>.</t> <xref target="ASN1-E" format="default"/>.</t>
</section>
</section> <section anchor="sect-1.2" numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology" anchor="sect-1.2"><t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Motivation" anchor="sect-1.3"><t> </section>
Recent advances in cryptanalysis <xref target="BH2013"/> and progress in the <section anchor="sect-1.3" numbered="true" toc="default">
development of quantum computers <xref target="NAS2019"/> pose a threat to wi <name>Motivation</name>
dely <t>
Recent advances in cryptanalysis <xref target="BH2013" format="default"/> and
progress in the
development of quantum computers <xref target="NAS2019" format="default"/> po
se a threat to widely
deployed digital signature algorithms. As a result, there is a need deployed digital signature algorithms. As a result, there is a need
to prepare for a day that cryptosystems such as RSA and DSA that to prepare for a day when cryptosystems such as RSA and DSA that
depend on discrete logarithm and factoring cannot be depended upon.</t> depend on discrete logarithms and factoring cannot be depended upon.</t>
<t>
<t>
If large-scale quantum computers are ever built, these computers will If large-scale quantum computers are ever built, these computers will
be able to break many of the public-key cryptosystems currently in be able to break many of the public key cryptosystems currently in
use. A post-quantum cryptosystem <xref target="PQC"/> is a system that is se use. A post-quantum cryptosystem <xref target="PQC" format="default"/> is a
cure system that is secure
against quantum computers that have more than a trivial number of against quantum computers that have more than a trivial number of
quantum bits (qubits). It is open to conjecture when it will be quantum bits (qubits). It is open to conjecture when it will be
feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA feasible to build such computers; however, RSA, DSA, Elliptic Curve Digital
are all vulnerable if large-scale quantum computers come to pass.</t> Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (E
dDSA)
<t> are all vulnerable if large-scale quantum computers are ever developed.</t>
<t>
Since the HSS/LMS signature algorithm does not depend on the Since the HSS/LMS signature algorithm does not depend on the
difficulty of discrete logarithm or factoring, the HSS/LMS signature difficulty of discrete logarithms or factoring, the HSS/LMS signature
algorithm is considered to be post-quantum secure. One use of post- algorithm is considered to be post-quantum secure. One use of post-quantum-s
quantum secure signatures is the protection of software updates, ecure signatures is the protection of software updates,
perhaps using the format described in <xref target="FWPROT"/>, to enable depl perhaps using the format described in <xref target="RFC4108" format="default"
oyment />, to enable deployment
of software that implements new cryptosystems.</t> of software that implements new cryptosystems.</t>
</section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>HSS/LMS Hash-Based Signature Algorithm Overview</name>
<t>
<section title="HSS/LMS Hash-based Signature Algorithm Overview" anchor="
sect-2"><t>
Merkle Tree Signatures (MTS) are a method for signing a large but Merkle Tree Signatures (MTS) are a method for signing a large but
fixed number of messages. An MTS system depends on a one-time fixed number of messages. An MTS system depends on a one-time
signature method and a collision-resistant hash function.</t> signature method and a collision-resistant hash function.</t>
<t>
<t>
This specification makes use of the hash-based algorithm specified in This specification makes use of the hash-based algorithm specified in
<xref target="HASHSIG"/>, which is the Leighton and Micali adaptation <xref t arget="LM"/> of the <xref target="RFC8554" format="default"/>, which is the Leighton and Micali a daptation <xref target="LM" format="default"/> of the
original Lamport-Diffie-Winternitz-Merkle one-time signature system original Lamport-Diffie-Winternitz-Merkle one-time signature system
<xref target="M1979"/><xref target="M1987"/><xref target="M1989a"/><xref targ <xref target="M1979" format="default"/> <xref target="M1987"
et="M1989b"/>.</t> format="default"/> <xref target="M1989a" format="default"/> <xref target="M19
89b" format="default"/>.</t>
<t> <t>
As implied by the name, the hash-based signature algorithm depends on As implied by the name, the hash-based signature algorithm depends on
a collision-resistant hash function. The hash-based signature a collision-resistant hash function. The hash-based signature
algorithm specified in <xref target="HASHSIG"/> uses only the SHA-256 one-way algorithm specified in <xref target="RFC8554" format="default"/> uses only th
hash e SHA-256 one-way hash
function <xref target="SHS"/>, but it establishes an IANA registry <xref targ function <xref target="SHS" format="default"/>, but it establishes an IANA re
et="IANA-LMS"/> to gistry <xref target="IANA-LMS" format="default"/> to
permit the registration of additional one-way hash functions in the permit the registration of additional one-way hash functions in the
future.</t> future.</t>
<section anchor="sect-2.1" numbered="true" toc="default">
<section title="Hierarchical Signature System (HSS)" anchor="sect-2.1"><t <name>Hierarchical Signature System (HSS)</name>
> <t>
The MTS system specified in <xref target="HASHSIG"/> uses a hierarchy of tree The MTS system specified in <xref target="RFC8554" format="default"/> uses a
s. The hierarchy of trees. The
Hierarchical N-time Signature System (HSS) allows subordinate trees N-time Hierarchical Signature System (HSS) allows subordinate trees
to be generated when needed by the signer. Otherwise, generation of to be generated when needed by the signer. Otherwise, generation of
the entire tree might take weeks or longer.</t> the entire tree might take weeks or longer.</t>
<t>
<t> An HSS signature as specified in <xref target="RFC8554" format="default"/> ca
An HSS signature as specified in <xref target="HASHSIG"/> carries the number rries the number of
of
signed public keys (Nspk), followed by that number of signed public signed public keys (Nspk), followed by that number of signed public
keys, followed by the LMS signature as described in <xref target="sect-2.2"/> keys, followed by the LMS signature as described in <xref target="sect-2.2" f
. The ormat="default"/>. The
public key for the top-most LMS tree is the public key of the HSS 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 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 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 tree signs the actual message. The signature over the public key and
the signature over the actual message are LMS signatures as described the signature over the actual message are LMS signatures as described
in <xref target="sect-2.2"/>.</t> in <xref target="sect-2.2" format="default"/>.</t>
<t>
<t> The elements of the HSS signature value for a standalone tree (a top
The elements of the HSS signature value for a stand-alone tree (a top
tree with no children) can be summarized as:</t> tree with no children) can be summarized as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(0) || u32str(0) ||
lms_signature /* signature of message */ lms_signature /* signature of message */
where, u32str() and || are used as defined in [HASHSIG].
]]></artwork> ]]></artwork>
</figure>
<t> <t>where, u32str() and || are used as defined in <xref target="RFC8554" format="
default"/>.</t>
<t>
The elements of the HSS signature value for a tree with Nspk signed The elements of the HSS signature value for a tree with Nspk signed
public keys can be summarized as:</t> public keys can be summarized as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(Nspk) || u32str(Nspk) ||
signed_public_key[0] || signed_public_key[0] ||
signed_public_key[1] || signed_public_key[1] ||
... ...
signed_public_key[Nspk-2] || signed_public_key[Nspk-2] ||
signed_public_key[Nspk-1] || signed_public_key[Nspk-1] ||
lms_signature /* signature of message */ lms_signature /* signature of message */
]]></artwork> ]]></artwork>
</figure> <t>
<t> where, as defined in <xref target="RFC8554"
where, as defined in Section 3.3 of <xref target="HASHSIG"/>, the signed_publ sectionFormat="of" section="3.3"/>, the signed_public_key
ic_key structure contains the lms_signature over the public key, followed by
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 the public key itself. Note that Nspk is the number of levels in the
hierarchy of trees minus 1.</t> hierarchy of trees minus 1.</t>
</section>
<section anchor="sect-2.2" numbered="true" toc="default">
<name>Leighton-Micali Signature (LMS)</name>
</section> <t>
Each tree in the system specified in <xref target="RFC8554" format="default"/
<section title="Leighton-Micali Signature (LMS)" anchor="sect-2.2"><t> > uses the Leighton-Micali Signature (LMS) system. LMS systems have two paramet
Each tree in the system specified in <xref target="HASHSIG"/> uses the Leight ers. The
on-
Micali Signature (LMS) system. LMS systems have two parameters. The
first parameter is the height of the tree, h, which is the number of first parameter is the height of the tree, h, which is the number of
levels in the tree minus one. The <xref target="HASHSIG"/> specification sup levels in the tree minus one. The <xref target="RFC8554" format="default"/>
ports specification supports
five values for this parameter: h=5; h=10; h=15; h=20; and h=25. 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, 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 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 <xref target="HASH amount of data associated with each node in the tree. The <xref target="RFC8
SIG"/> 554" format="default"/>
specification supports only the SHA-256 hash function <xref target="SHS"/>, w specification supports only the SHA-256 hash function <xref target="SHS" form
ith at="default"/>, with
m=32. As a result, the <xref target="HASHSIG"/> specification supports five m=32. As a result, the <xref target="RFC8554" format="default"/> specificati
tree on supports five tree
sizes; they are identified as:</t> sizes; they are identified as:</t>
<figure><artwork><![CDATA[ <ul>
LMS_SHA256_M32_H5; <li>LMS_SHA256_M32_H5</li>
LMS_SHA256_M32_H10; <li>LMS_SHA256_M32_H10</li>
LMS_SHA256_M32_H15; <li>LMS_SHA256_M32_H15</li>
LMS_SHA256_M32_H20; and <li>LMS_SHA256_M32_H20</li>
LMS_SHA256_M32_H25. <li>LMS_SHA256_M32_H25</li>
]]></artwork> </ul>
</figure>
<t> <t>
The <xref target="HASHSIG"/> specification establishes an IANA registry <xref The <xref target="RFC8554" format="default"/> specification establishes an IA
target="IANA-LMS"/> NA registry <xref target="IANA-LMS" format="default"/>
to permit the registration of additional hash functions and to permit the registration of additional hash functions and
additional tree sizes in the future.</t> additional tree sizes in the future.</t>
<t>
<t> As specified in <xref target="RFC8554" format="default"/>, the LMS public key
As specified in <xref target="HASHSIG"/>, the LMS public key consists of four consists of four
elements: the lms_algorithm_type from the list above, the otstype to elements: the lms_algorithm_type from the list above, the otstype to
identify the LM-OTS type as discussed in <xref target="sect-2.3"/>, the priva identify the Leighton-Micali One-Time Signature (LM-OTS) type as discussed in
te key <xref target="sect-2.3" format="default"/>, the private key
identifier (I) as described in Section 5.3 of <xref target="HASHSIG"/>, and t identifier (I) as described in <xref target="RFC8554"
he m- sectionFormat="of" section="5.3"/>, and the m-byte string associated with the
byte string associated with the root node of the tree (T[1]).</t> root node of the tree (T[1]).</t>
<t>
<t>
The LMS public key can be summarized as:</t> The LMS public key can be summarized as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
]]></artwork> ]]></artwork>
</figure> <t>
As specified in <xref target="RFC8554" format="default"/>,
<t> an LMS signature consists of four
As specified in <xref target="HASHSIG"/>, an LMS signature consists of four elements: the number of the leaf (q) associated with the LM-OTS
elements: the number of the leaf (q) associated with the LM-OTS signature value, an LM-OTS signature value as described in
signature, an LM-OTS signature as described in <xref target="sect-2.3"/>, a <xref target="sect-2.3" format="default"/>, a
typecode indicating the particular LMS algorithm, and an array of typecode indicating the particular LMS algorithm, and an array of
values that is associated with the path through the tree from the 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 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 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 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 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 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.</t> parent of the leaf, and so on up the path to the root.
</t>
<t> <t>
The four elements of the LMS signature value can be summarized as:</t> The four elements of the LMS signature value can be summarized as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(q) || u32str(q) ||
ots_signature || ots_signature ||
u32str(type) || u32str(type) ||
path[0] || path[1] || ... || path[h-1] path[0] || path[1] || ... || path[h-1]
]]></artwork> ]]></artwork>
</figure> </section>
</section> <section anchor="sect-2.3" numbered="true" toc="default">
<name>Leighton-Micali One-Time Signature (LM-OTS) Algorithm</name>
<section title="Leighton-Micali One-time Signature Algorithm (LM-OTS)" an <t>
chor="sect-2.3"><t>
Merkle Tree Signatures (MTS) depend on a one-time signature method, Merkle Tree Signatures (MTS) depend on a one-time signature method,
and <xref target="HASHSIG"/> specifies the use of the LM-OTS, which has five and <xref target="RFC8554" format="default"/> specifies the use of the LM-OTS , which has five
parameters:</t> parameters:</t>
<figure><artwork><![CDATA[ <dl indent="5">
n - The length in bytes of the hash function output. [HASHSIG] <dt>n:</dt><dd>The length in bytes of the hash function output. <xref
supports only SHA-256 [SHS], with n=32. target="RFC8554" format="default"/> supports only SHA-256 <xref target="SHS" for
mat="default"/>, with n=32.</dd>
H - A preimage-resistant hash function that accepts byte strings <dt>H:</dt><dd>A preimage-resistant hash function that accepts byte strings of a
of any length, and returns an n-byte string. ny length and returns an n-byte string.</dd>
w - The width in bits of the Winternitz coefficients. [HASHSIG] <dt>w:</dt><dd>The width in bits of the Winternitz coefficients. <xref
supports four values for this parameter: w=1; w=2; w=4; and target="RFC8554" format="default"/> supports four values for this parameter: w=1
w=8. , w=2, w=4, and w=8.</dd>
p - The number of n-byte string elements that make up the LM-OTS <dt>p:</dt><dd>The number of n-byte string elements that make up the LM-OTS sign
signature. ature value.</dd>
ls - The number of bits that are left-shifted in the final step of <dt>ls:</dt><dd>The number of bits that are left-shifted in the final step of
the checksum function, which is defined in Section 4.4 of the checksum function, which is defined in <xref target="RFC8554"
[HASHSIG]. sectionFormat="of" section="4.4"/>.</dd>
]]></artwork> </dl>
</figure>
<t>
The values of p and ls are dependent on the choices of the parameters
n and w, as described in Appendix B of <xref target="HASHSIG"/>.</t>
<t> <t>
The [HASHSIG] specification supports four LM-OTS variants:</t> The values of p and ls are dependent on the choices of the parameters
n and w, as described in <xref target="RFC8554"
sectionFormat="of" section="B"/>.</t>
<t>
The <xref target="RFC8554"/> specification supports four LM-OTS variants:</t>
<figure><artwork><![CDATA[ <ul>
LMOTS_SHA256_N32_W1; <li>LMOTS_SHA256_N32_W1</li>
LMOTS_SHA256_N32_W2; <li>LMOTS_SHA256_N32_W2</li>
LMOTS_SHA256_N32_W4; and <li>LMOTS_SHA256_N32_W4</li>
LMOTS_SHA256_N32_W8. <li>LMOTS_SHA256_N32_W8</li>
]]></artwork> </ul>
</figure>
<t> <t>
The <xref target="HASHSIG"/> specification establishes an IANA registry <xref The <xref target="RFC8554" format="default"/> specification establishes an IA
target="IANA-LMS"/> NA registry <xref target="IANA-LMS" format="default"/>
to permit the registration of additional variants in the future.</t> to permit the registration of additional variants in the future.</t>
<t>
<t>
Signing involves the generation of C, an n-byte random value.</t> Signing involves the generation of C, an n-byte random value.</t>
<t>
<t>
The LM-OTS signature value can be summarized as the identifier of the 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] 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 through y[p-1]) that correspond to the elements of the public key, as
described in Section 4.5 of <xref target="HASHSIG"/>:</t> described in <xref target="RFC8554" sectionFormat="of" section="4.5"/>:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(otstype) || C || y[0] || ... || y[p-1] u32str(otstype) || C || y[0] || ... || y[p-1]
]]></artwork> ]]></artwork>
</figure> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
</section> <name>Algorithm Identifiers and Parameters</name>
<t>
<section title="Algorithm Identifiers and Parameters" anchor="sect-3"> The algorithm identifier for an HSS/LMS hash-based signature is: </t>
<t>
The algorithm identifier for an HSS/LMS hash-based signatures is: </t>
<figure><artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) 17 } smime(16) alg(3) 17 }
]]></artwork> ]]></sourcecode>
</figure>
<t>
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; the parameters are not set to NULL).</t>
<t> <t>
The signature value is a large OCTET STRING as described in Section 2 When this object identifier is used for an HSS/LMS signature, the
AlgorithmIdentifier parameters field <bcp14>MUST</bcp14> be absent (that is,
the
parameters are not present, and the parameters are not set to NULL).</t>
<t>
The signature value is a large OCTET STRING, as described in <xref target="se
ct-2"/>
of this document. The signature format is designed for easy parsing. of this document. The signature format is designed for easy parsing.
The HSS, LMS, and LMOTS component of the signature value each format The HSS, LMS, and LM-OTS components of the signature value each
include a counter and a type code that indirectly provide all of the include a counter and a typecode that indirectly provide all of the
information that is needed to parse the value during signature information
validation.</t> that is needed to parse the value during signature validation.
</t>
<t> <t>
The signature value identifies the hash function used in the HSS/LMS The signature value identifies the hash function used in the HSS/LMS
tree. In <xref target="HASHSIG"/> uses only the SHA-256 hash function <xref tree. <xref target="RFC8554" format="default"/> uses only the SHA-256 hash f
target="SHS"/>, but it unction <xref target="SHS" format="default"/>, but it
establishes an IANA registry <xref target="IANA-LMS"/> to permit the registra establishes an IANA registry <xref target="IANA-LMS" format="default"/> to pe
tion of rmit the registration of
additional hash functions in the future.</t> additional hash functions in the future.</t>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>HSS/LMS Public Key Identifier</name>
<section title="HSS/LMS Public Key Identifier" anchor="sect-4"><t> <t>
The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg-hss-lms-has
hss-lms-hashsig object identifier, and the parameters field MUST be hsig object identifier, and the parameters field <bcp14>MUST</bcp14> be
absent.</t> absent.</t>
<t>
<t>
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of an X.509 certificate <xref target="RFC5280"/>, the certificate key u field of an X.509 certificate <xref target="RFC5280" format="default"/>, the
sage certificate key usage
extension MAY contain digitalSignature, nonRepudiation, keyCertSign, extension <bcp14>MAY</bcp14> contain digitalSignature, nonRepudiation, keyCer
and cRLSign; however, it MUST NOT contain other values.</t> tSign,
and cRLSign; however, it <bcp14>MUST NOT</bcp14> contain other values.</t>
<figure><artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
pk-HSS-LMS-HashSig PUBLIC-KEY ::= { pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
IDENTIFIER id-alg-hss-lms-hashsig IDENTIFIER id-alg-hss-lms-hashsig
KEY HSS-LMS-HashSig-PublicKey KEY HSS-LMS-HashSig-PublicKey
PARAMS ARE absent PARAMS ARE absent
CERT-KEY-USAGE CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } } { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
HSS-LMS-HashSig-PublicKey ::= OCTET STRING HSS-LMS-HashSig-PublicKey ::= OCTET STRING
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
Note that the id-alg-hss-lms-hashsig algorithm identifier is also 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 referred to as id-alg-mts-hashsig. This synonym is based on the
terminology used in an early draft of the document that became terminology used in an early draft version of the document that became
<xref target="HASHSIG"/>.</t> <xref target="RFC8554" format="default"/>.</t>
<t>
<t>
The public key value is an OCTET STRING. Like the signature format, 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 it is designed for easy parsing. The value is the number of levels
in the public key, L, followed by the LMS public key.</t> in the public key, L, followed by the LMS public key.</t>
<t>
<t>
The HSS/LMS public key value can be described as:</t> The HSS/LMS public key value can be described as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
u32str(L) || lms_public_key u32str(L) || lms_public_key
]]></artwork> ]]></artwork>
</figure> <t>
Note that the public key for the topmost LMS tree is the public key
<t>
Note that the public key for the top-most LMS tree is the public key
of the HSS system. When L=1, the HSS system is a single tree.</t> of the HSS system. When L=1, the HSS system is a single tree.</t>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>Signed-Data Conventions</name>
<section title="Signed-data Conventions" anchor="sect-5"><t> <t>
As specified in <xref target="CMS"/>, the digital signature is produced from As specified in <xref target="RFC5652" format="default"/>, the digital signat
the ure is produced from the
message digest and the signer's private key. The signature is message digest and the signer's private key. The signature is
computed over different values depending on whether signed attributes computed over different values depending on whether signed attributes
are absent or present.</t> are absent or present.</t>
<t>
<t>
When signed attributes are absent, the HSS/LMS signature is computed When signed attributes are absent, the HSS/LMS signature is computed
over the content. When signed attributes are present, a hash is over the content. When signed attributes are present, a hash is
computed over the content using the same hash function that is used computed over the content using the same hash function that is used
in the HSS/LMS tree, and then a message-digest attribute is in the HSS/LMS tree, then a message-digest attribute is constructed with
constructed with the hash of the content, and then the HSS/LMS the hash of the content, and then the HSS/LMS
signature is computed over the DER-encoded set of signed attributes signature is computed over the DER-encoded set of signed attributes
(which MUST include a content-type attribute and a message-digest (which <bcp14>MUST</bcp14> include a content-type attribute and a message-dig est
attribute). In summary:</t> attribute). In summary:</t>
<sourcecode name="pseudocode" type=""><![CDATA[
<figure><artwork><![CDATA[
IF (signed attributes are absent) IF (signed attributes are absent)
THEN HSS_LMS_Sign(content) THEN HSS_LMS_Sign(content)
ELSE message-digest attribute = Hash(content); ELSE message-digest attribute = Hash(content);
HSS_LMS_Sign(DER(SignedAttributes)) HSS_LMS_Sign(DER(SignedAttributes))
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> When using <xref target="RFC8554" format="default"/>, the fields in the Signe
When using <xref target="HASHSIG"/>, the fields in the SignerInfo are used as rInfo are used as
follows:</t> follows:</t>
<ul>
<t><list hangIndent="3" style="hanging"><t> <li>
digestAlgorithm MUST contain the one-way hash function used in the digestAlgorithm <bcp14>MUST</bcp14> contain the one-way hash function used
HSS/LMS tree. In <xref target="HASHSIG"/>, SHA-256 is the only supported in the
hash HSS/LMS tree. In <xref target="RFC8554" format="default"/>, SHA-256 is th
e only supported hash
function, but other hash functions might be registered in the function, but other hash functions might be registered in the
future. For convenience, the AlgorithmIdentifier for SHA-256 future. For convenience, the AlgorithmIdentifier for SHA-256
from <xref target="PKIXASN1"/> is repeated here:</t> from <xref target="RFC5912" format="default"/> is repeated here:</li></ul>
</list>
</t>
<figure><artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
mda-sha256 DIGEST-ALGORITHM ::= { mda-sha256 DIGEST-ALGORITHM ::= {
IDENTIFIER id-sha256 IDENTIFIER id-sha256
PARAMS TYPE NULL ARE preferredAbsent } PARAMS TYPE NULL ARE preferredAbsent }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithms(4) hashalgs(2) 1 } nistAlgorithms(4) hashalgs(2) 1 }
]]></artwork> ]]></sourcecode>
</figure> <ul>
<t><list hangIndent="3" style="hanging"><t> <li>
signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the signatureAlgorithm <bcp14>MUST</bcp14> contain id-alg-hss-lms-hashsig, and
algorithm parameters field MUST be absent.</t> the
algorithm parameters field <bcp14>MUST</bcp14> be absent.</li>
</list> <li>
</t>
<t><list hangIndent="3" style="hanging"><t>
signature contains the single HSS signature value resulting from signature contains the single HSS signature value resulting from
the signing operation as specified in <xref target="HASHSIG"/>.</t> the signing operation as specified in <xref target="RFC8554" format="defau
lt"/>.</li>
</list> </ul>
</t> </section>
<section anchor="sect-6" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>
<section title="Security Considerations" anchor="sect-6"><t> Implementations <bcp14>MUST</bcp14> protect the private keys. Compromise of
Implementations MUST protect the private keys. Compromise of the the
private keys may result in the ability to forge signatures. Along private keys may result in the ability to forge signatures. Along
with the private key, the implementation MUST keep track of which with the private key, the implementation <bcp14>MUST</bcp14> keep track of wh ich
leaf nodes in the tree have been used. Loss of integrity of this 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 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- a result, when a private key and the tracking data are stored on non-volatile
volatile media or stored in a virtual machine environment, failed media or in a virtual machine environment, failed
writes, virtual machine snapshotting or cloning, and other writes, virtual machine snapshotting or cloning, and other
operational concerns must be considered to ensure confidentiality and operational concerns must be considered to ensure confidentiality and
integrity.</t> integrity.</t>
<t>
<t> When generating an LMS key pair, an implementation <bcp14>MUST</bcp14> genera
When generating an LMS key pair, an implementation MUST generate each te each
key pair independently of all other key pairs in the HSS tree.</t> key pair independently of all other key pairs in the HSS tree.</t>
<t>
<t> An implementation <bcp14>MUST</bcp14> ensure that an LM-OTS private key is us
An implementation MUST ensure that a LM-OTS private key is used to ed to
generate a signature only one time, and ensure that it cannot be used generate a signature only one time and ensure that it cannot be used
for any other purpose.</t> for any other purpose.</t>
<t>
<t>
The generation of private keys relies on random numbers. The use of The generation of private keys relies on random numbers. The use of
inadequate pseudo-random number generators (PRNGs) to generate these inadequate pseudorandom number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys, much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute searching the resulting small set of possibilities, rather than brute-force s
force searching the whole key space. The generation of quality earching the whole key space. The generation of quality
random numbers is difficult, and <xref target="RFC4086"/> offers important gu random numbers is difficult, and <xref target="RFC4086" format="default"/> of
idance fers important guidance
in this area.</t> in this area.</t>
<t>
<t>
The generation of hash-based signatures also depends on random The generation of hash-based signatures also depends on random
numbers. While the consequences of an inadequate pseudo-random numbers. While the consequences of an inadequate pseudorandom
number generator (PRNG) to generate these values is much less severe number generator (PRNG) to generate these values is much less severe
than in the generation of private keys, the guidance in <xref target="RFC4086 "/> than in the generation of private keys, the guidance in <xref target="RFC4086 " format="default"/>
remains important.</t> remains important.</t>
<t>
<t> When computing signatures, the same hash function <bcp14>SHOULD</bcp14> be us
When computing signatures, the same hash function SHOULD be used to ed to
compute the message digest of the content and the signed attributes, compute the message digest of the content and the signed attributes, if they
if they are present.</t> are present.</t>
</section>
</section> <section anchor="sect-7" numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations" anchor="sect-7"><t> <t>
SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) In the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
registry, change the reference for value 64 to point to this registry, IANA has updated the reference for value 64 to point to this
document.</t> document.</t>
<t>
<t> In the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)"
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
registry, change the description for value 17 to "id-alg-hss-lms-hashsig" and updated the reference to point to this
"id-alg-hss-lms-hashsig" and change the reference to point to this
document.</t> document.</t>
<t>
IANA has also added the following note to the "SMI Security for S/&wj;MIME
Algorithms (1.2.840.113549.1.9.16.3)" registry:</t>
<t> <ul empty="true">
Also, add the following note to the registry:</t> <li>Value 17, "id-alg-hss-lms-hashsig", is also referred to as
"id-alg-mts-hashsig".</li>
<t><list style="hanging" hangIndent="3"><t> </ul>
Value 17, "id-alg-hss-lms-hashsig", is also referred to as </section>
"id-alg-mts-hashsig". </middle>
</t> <back>
<displayreference target="RFC8554" to="HASHSIG"/>
</list> <displayreference target="RFC5652" to="CMS"/>
</t> <displayreference target="RFC5911" to="CMSASN1"/>
<displayreference target="RFC6268" to="CMSASN1U"/>
</section> <displayreference target="RFC4108" to="FWPROT"/>
<displayreference target="RFC5912" to="PKIXASN1"/>
</middle>
<back>
<references title="Normative References">
<reference anchor="ASN1-B"><front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1): Sp
ecification of basic notation</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation X.680"/>
</reference>
<reference anchor="ASN1-E"><front>
<title>Information technology -- ASN.1 encoding rules: Specification of B
asic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Enco
ding Rules (DER)</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation X.690"/>
</reference>
<reference anchor="CMS" target="http://www.rfc-editor.org/info/rfc5652"><
front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley">
</author>
<date month="September" year="2009"/>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="HASHSIG" target="https://rfc-editor.org/rfc/rfc8554.tx
t"><front>
<title>Leighton-Micali Hash-Based Signatures</title>
<author fullname="D. McGrew" initials="D." surname="McGrew">
</author>
<author fullname="M. Curcio" initials="M." surname="Curcio">
</author>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer">
</author>
<date month="April" year="2019"/>
</front>
<seriesInfo name="RFC" value="8554"/>
</reference>
&RFC2119;
&RFC5280;
&RFC8174;
<reference anchor="SHS"><front>
<title>FIPS Publication 180-3: Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</orga
nization>
</author>
<date month="October" year="2008"/>
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="BH2013" target="https://media.blackhat.com/us-13/us-13
-Stamos-The-Factoring-Dead.pdf"><front>
<title>The Factoring Dead: Preparing for the Cryptopocalypse</title>
<author>
<organization>Ptacek, T., T. Ritter, J. Samuel, and A. Stamos</organizati
on>
</author>
<date month="August" year="2013"/>
</front>
</reference>
<reference anchor="CMSASN1" target="http://www.rfc-editor.org/info/rfc591
1"><front>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIM
E</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
</author>
<author fullname="J. Schaad" initials="J." surname="Schaad">
</author>
<date month="June" year="2010"/>
</front>
<seriesInfo name="RFC" value="5911"/>
<seriesInfo name="DOI" value="10.17487/RFC5911"/>
</reference>
<reference anchor="CMSASN1U" target="http://www.rfc-editor.org/info/rfc62
68"><front>
<title>Additional New ASN.1 Modules for the Cryptographic Message Syntax
(CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad">
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
</author>
<date month="July" year="2011"/>
</front>
<seriesInfo name="RFC" value="6268"/>
<seriesInfo name="DOI" value="10.17487/RFC6268"/>
</reference>
<reference anchor="FWPROT" target="http://www.rfc-editor.org/info/rfc4108
"><front>
<title>Using Cryptographic Message Syntax (CMS) to Protect Firmware Packa
ges</title>
<author fullname="R. Housley" initials="R." surname="Housley">
</author>
<date month="August" year="2005"/>
</front>
<seriesInfo name="RFC" value="4108"/>
<seriesInfo name="DOI" value="10.17487/RFC4108"/>
</reference>
<reference anchor="IANA-LMS" target="https://www.iana.org/assignments/lei
ghton-micali-signatures/leighton-micali-signatures.xhtml"><front>
<title>IANA Registry for Leighton-Micali Signatures (LMS) </title>
<author>
</author>
<date/>
</front>
</reference> <references>
<reference anchor="LM"><front> <name>References</name>
<title>Large provably fast and secure digital signature schemes from secu <references>
re hash functions</title> <name>Normative References</name>
<author fullname="T. Leighton" initials="T." surname="Leighton">
</author>
<author fullname="S. Micali" initials="S." surname="Micali"> <reference anchor="ASN1-B">
</author> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1
): Specification of basic notation</title>
<seriesInfo name="ITU-T" value="Recommendation X.680"/>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
</reference>
<date month="July" year="1995"/> <reference anchor="ASN1-E">
</front> <front>
<title>Information technology -- ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)</title>
<seriesInfo name="ITU-T" value="Recommendation X.690"/>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
</reference>
<seriesInfo name="U.S." value="Patent 5,432,852"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.5652.xml"/>
<reference anchor="M1979"><front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Secrecy, Authentication, and Public Key Systems</title> FC.8554.xml"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<date year="1979"/> <reference anchor="SHS">
</front> <front>
<title>Secure Hash Standard (SHS)</title>
<seriesInfo name="FIPS PUB" value="180-3"/>
<author>
<organization>National Institute of Standards and Technology (NIST
)</organization>
</author>
<date month="October" year="2008"/>
</front>
</reference>
</references>
<seriesInfo name="Stanford" value="University Information Systems Laborat <references>
ory Technical Report 1979-1"/> <name>Informative References</name>
</reference>
<reference anchor="M1987"><front>
<title>A Digital Signature Based on a Conventional Encryption Function</t
itle>
<author fullname="R. Merkle" initials="R." surname="Merkle">
</author>
<date year="1988"/> <reference anchor="BH2013" target="https://media.blackhat.com/us-13/us-1
</front> 3-Stamos-The-Factoring-Dead.pdf">
<front>
<title>The Factoring Dead: Preparing for the Cryptopocalypse</title>
<author fullname="Thomas Ptacek" initials="T." surname="Ptacek"/>
<author fullname="Tom Ritter" initials="T." surname="Ritter"/>
<author fullname="Javed Samuel" initials="J." surname="Samuel"/>
<author fullname="Alex Stamos" initials="A." surname="Stamos"/>
<date month="August" year="2013"/>
</front>
</reference>
<seriesInfo name="Lecture" value="Notes in Computer Science crypto87"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.5911.xml"/>
<reference anchor="M1989a"><front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>A Certified Digital Signature</title> FC.6268.xml"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.4108.xml"/>
<date year="1990"/> <reference anchor="IANA-LMS" target="https://www.iana.org/assignments/le
</front> ighton-micali-signatures/">
<front>
<title>Leighton-Micali Signatures (LMS)</title>
<author><organization>IANA</organization></author>
<date/>
</front>
</reference>
<seriesInfo name="Lecture" value="Notes in Computer Science crypto89"/> <reference anchor="LM">
</reference> <front>
<reference anchor="M1989b"><front> <title>Large provably fast and secure digital signature schemes
<title>One Way Hash Functions and DES</title> based on secure hash functions</title>
<author fullname="R. Merkle" initials="R." surname="Merkle"> <seriesInfo name="U.S." value="Patent 5,432,852"/>
</author> <author fullname="T. Leighton" initials="T." surname="Leighton"/>
<author fullname="S. Micali" initials="S." surname="Micali"/>
<date month="July" year="1995"/>
</front>
</reference>
<date year="1990"/> <reference anchor="M1979">
</front> <front>
<title>Secrecy, Authentication, and Public Key Systems</title>
<seriesInfo name="Technical Report" value="No. 1979-1"/>
<seriesInfo name="Information Systems Laboratory," value="Stanford University"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"/>
<date year="1979"/>
</front>
</reference>
<seriesInfo name="Lecture" value="Notes in Computer Science crypto89"/> <reference anchor="M1987">
</reference> <front>
<reference anchor="NAS2019"><front> <title>A Digital Signature Based on a Conventional Encryption
<title>Quantum Computing: Progress and Prospects</title> Function</title>
<author> <seriesInfo name="DOI" value="10.1007/3-540-48184-2_32"/>
<organization>National Academies of Sciences, Engineering, and Medicine</ <author fullname="R. Merkle" initials="R." surname="Merkle"/>
organization> <date year="1988"/>
</author> </front>
<refcontent>Advances in Cryptology -- CRYPTO '87 Proceedings</refcontent>
<refcontent>Lecture Notes in Computer Science Vol. 293</refcontent>
</reference>
<date year="2019"/> <reference anchor="M1989a">
</front> <front>
<title>A Certified Digital Signature</title>
<seriesInfo name="DOI" value="10.1007/0-387-34805-0_21"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"/>
<date year="1990"/>
</front>
<refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refcontent>
<refcontent>Lecture Notes in Computer Science Vol. 435</refcontent>
</reference>
<seriesInfo name="The National Academies Press," value="DOI 10.17226/2519 <reference anchor="M1989b">
6"/> <front>
</reference> <title>One Way Hash Functions and DES</title>
<reference anchor="PKIXASN1" target="http://www.rfc-editor.org/info/rfc59 <seriesInfo name="DOI" value="10.1007/0-387-34805-0_40"/>
12"><front> <author fullname="R. Merkle" initials="R." surname="Merkle"/>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (P <date year="1990"/>
KIX)</title> </front>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"> <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refcontent>
</author> <refcontent>Lecture Notes in Computer Science Vol. 435</refcontent>
</reference>
<author fullname="J. Schaad" initials="J." surname="Schaad"> <reference anchor="NAS2019">
</author> <front>
<title>Quantum Computing: Progress and Prospects</title>
<seriesInfo name="DOI" value="10.17226/25196"/>
<author>
<organization>National Academies of Sciences, Engineering, and Med
icine</organization>
</author>
<date year="2019"/>
</front>
<refcontent>The National Academies Press</refcontent>
</reference>
<date month="June" year="2010"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.5912.xml"/>
<seriesInfo name="RFC" value="5912"/> <reference anchor="PQC" target="http://www.springer.com/cda/content/docu
<seriesInfo name="DOI" value="10.17487/RFC5912"/> ment/cda_downloaddocument/9783540887010-c1.pdf">
</reference> <front>
<reference anchor="PQC" target="http://www.pqcrypto.org/www.springer.com/ <title>Introduction to post-quantum cryptography</title>
cda/content/document/cda_downloaddocument/9783540887010-c1.pdf"><front> <seriesInfo name="DOI" value="10.1007/978-3-540-88702-7_1"/>
<title>Introduction to post-quantum cryptography</title> <author fullname="D. Bernstein" initials="D." surname="Bernstein"/>
<author fullname="D. Bernstein" initials="D." surname="Bernstein"> <date year="2009"/>
</author> </front>
</reference>
<date year="2009"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.4086.xml"/>
</reference> </references>
&RFC4086; </references>
</references>
<section title="ASN.1 Module" anchor="sect-appendix">
<figure><artwork><![CDATA[ <section anchor="sect-appendix" numbered="true" toc="default">
<name>ASN.1 Module</name>
<sourcecode name="" type="asn.1"><![CDATA[
<CODE STARTS> <CODE STARTS>
MTS-HashSig-2013 MTS-HashSig-2013
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { 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) } id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
skipping to change at line 798 skipping to change at line 693
-- --
-- Expand the S/MIME capabilities set used by CMS [CMSASN1] -- Expand the S/MIME capabilities set used by CMS [CMSASN1]
-- --
SMimeCaps SMIME-CAPS ::= SMimeCaps SMIME-CAPS ::=
{ sa-HSS-LMS-HashSig.&smimeCaps, ... } { sa-HSS-LMS-HashSig.&smimeCaps, ... }
END END
<CODE ENDS> <CODE ENDS>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section>
<section title="Acknowledgements" numbered="no" anchor="acknowledgements"
><t>
Many thanks to Scott Fluhrer, Jonathan Hammell, Ben Kaduk, Panos
Kampanakis, Barry Leiba, John Mattsson, Jim Schaad, Sean Turner,
Daniel Van Geest, Roman Danyliw, Dale Worley, and Joe Clarke for
their careful review and comments.</t>
</section>
</back> <section numbered="false" anchor="acknowledgements" toc="default">
<name>Acknowledgements</name>
<t>
Many thanks to <contact fullname="Joe Clarke" />, <contact fullname="Roman
Danyliw" />, <contact fullname="Scott Fluhrer" />, <contact
fullname="Jonathan Hammell" />, <contact fullname="Ben Kaduk" />, <contact
fullname="Panos Kampanakis" />, <contact fullname="Barry Leiba" />,
<contact fullname="John Mattsson" />, <contact fullname="Jim Schaad" />,
<contact fullname="Sean Turner" />, <contact fullname="Daniel Van Geest"
/>, and <contact fullname="Dale Worley" /> for their careful review and
comments.</t>
</section>
</rfc> </back>
</rfc>
 End of changes. 112 change blocks. 
631 lines changed or deleted 533 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/