rfc9708.original.xml   rfc9708.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3"
category="std" consensus="true" docName="draft-ietf-lamps-rfc8708bis-03" <!DOCTYPE rfc [
ipr="trust200902" obsoletes="8708" sortRefs="true" submissionType="IETF" <!ENTITY nbsp "&#160;">
symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
nsus="true" docName="draft-ietf-lamps-rfc8708bis-03" number="" ipr="trust200902"
updates="" obsoletes="8708" sortRefs="true" submissionType="IETF" symRefs="true
" tocDepth="3" tocInclude="true" xml:lang="en">
<front> <front>
<title abbrev="Use of the HSS/LMS Hash-Based Signature">Use of the HSS/LMS H ash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)</title> <title abbrev="Use of the HSS/LMS Hash-Based Signature">Use of the HSS/LMS H ash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
<seriesInfo name="RFC" value="9708"/>
<author fullname="Russ Housley" initials="R." surname="Housley"> <author fullname="Russ Housley" initials="R." surname="Housley">
<organization abbrev="Vigil Security" showOnFrontPage="true">Vigil Securit y, LLC</organization> <organization abbrev="Vigil Security" showOnFrontPage="true">Vigil Securit y, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon</city> <city>Herndon</city>
<region>VA</region> <region>VA</region>
<code>20170</code> <code>20170</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date day="19" month="09" year="2024"/> <date month="December" year="2024"/>
<workgroup>LAMPS Working Group</workgroup> <area>SEC</area>
<workgroup>lamps</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
The ones from RFC 8708 are "digital signature, message content".-->
<keyword>example</keyword>
<abstract> <abstract>
<t> <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. This document obsoletes RFC 8708.</t > signature; it is described in RFC 8554. This document obsoletes RFC 8708.</t >
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t> <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) signature algorithm with the Cryptographic Message Syntax (CMS)
<xref target="RFC5652" derivedContent="CMS"/> <xref target="RFC5652"/>
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
number of signatures. The HSS/LMS algorithm is one form of number of signatures. The HSS/LMS algorithm is one form of
hash-based digital signature, and it is described in hash-based digital signature, and it is described in
<xref target="RFC8554" derivedContent="HASHSIG"/>. The <xref target="RFC8554"/>. 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 are defined in signing time. The HSS/LMS signatures are defined in
<xref target="RFC8554" derivedContent="HASHSIG"/>. Currently, parameter <xref target="RFC8554" />. Currently, parameter
sets are defined that use SHA-256 <xref target="SHS" derivedContent="SHS"/> sets are defined that use SHA-256 <xref target="SHS" />
and SHAKE256 <xref target="SHA3" derivedContent="SHA3"/>.</t> and SHAKE256 <xref target="SHA3" />.</t>
<section> <section>
<name>ASN.1</name> <name>ASN.1</name>
<t> <t>
CMS values are generated using ASN.1 <xref target="ASN1-B" derivedContent="AS N1-B"/>, CMS values are generated using ASN.1 <xref target="ASN1-B" />,
using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DE R) using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DE R)
<xref target="ASN1-E" derivedContent="ASN1-E"/>.</t> <xref target="ASN1-E" />.</t>
</section> </section>
<section> <section>
<name>Terminology</name> <name>Terminology</name>
<t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
IRED</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", ",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY< "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
/bcp14>", and "<bcp14>OPTIONAL</bcp14>" "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
in this document are to be interpreted as described in BCP 14 <xref target=" be
RFC2119" derivedContent="RFC2119"/> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<xref target="RFC8174" derivedContent="RFC8174"/> when, and only when, they target="RFC8174"/> when, and only when, they appear in all capitals, as
appear in all capitals, as shown here.</t> shown here.
</t>
</section> </section>
<section> <section>
<name>Motivation</name> <name>Motivation</name>
<t> <t>
Advances in cryptanalysis <xref target="BH2013" derivedContent="BH2013"/> and Advances in cryptanalysis <xref target="BH2013" /> and progress in the
progress in the development of quantum computers <xref target="NAS2019"/> pose a future
development of quantum computers <xref target="NAS2019" derivedContent="NAS20
19"/> pose a future
threat to widely deployed digital signature algorithms. As a result, there i s a need threat to widely deployed digital signature algorithms. As a result, there i s a need
to prepare for a day when cryptosystems such as RSA and DSA that to prepare for a day when cryptosystems such as RSA and DSA that
depend on discrete logarithms and factoring cannot be depended upon.</t> depend on discrete logarithms and factoring cannot be depended upon.</t>
<!--[rfced] May this be rephrased to avoid repetition of 'depend'?
Original:
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.
Perhaps:
As a result, there is a need to prepare
for a day when cryptosystems such as RSA and DSA that use
discrete logarithms and factoring cannot be depended upon.
-->
<t> <t>
If cryptographically relevant quantum computers (CRQCs) are ever built, these computers will If cryptographically relevant quantum computers (CRQCs) are ever built, they 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" derivedContent="PQC"/> i s a system that is secure use. A post-quantum cryptosystem <xref target="PQC" /> is a system that is s ecure
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, Elliptic Curve Digital feasible to build such computers; however, RSA, DSA, Elliptic Curve Digital
Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (E dDSA) Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (E dDSA)
are all vulnerable if CRQCs are ever developed.</t> are all vulnerable if CRQCs are ever developed.</t>
<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 logarithms or factoring, but on a difficulty of discrete logarithms or factoring, but on a
second-preimage-resistant cryptographic hash function, the HSS/LMS second-preimage-resistant cryptographic hash function, the HSS/LMS
signature algorithm is considered to be post-quantum secure. One use signature algorithm is considered to be post-quantum secure. One use
of post-quantum-secure signatures is the protection of software updates, of post-quantum-secure signatures is the protection of software updates,
perhaps using the format described in <xref target="RFC4108" derivedContent=" FWPROT"/>, perhaps using the format described in <xref target="RFC4108" />,
to enable deployment of software that implements new cryptosystems.</t> to enable deployment of software that implements new cryptosystems.</t>
</section> </section>
<section> <section>
<name>Changes Since RFC 8708</name> <name>Changes Since RFC 8708</name>
<t> <t>
At the time RFC 8708 was published, there were no plans to put an HSS/LMS pub lic key At the time RFC 8708 was published, there were no plans to put an HSS/LMS pub lic key
in a certificate. The expectation was that the HSS/LMS public key would be in a certificate. The expectation was that the HSS/LMS public key would be
distributed by some other means. Today, there are plans to put an HSS/LMS pu blic key distributed by some other means. Today, there are plans to put an HSS/LMS pu blic key
in a certificate <xref target="I-D.ietf-lamps-x509-shbs"/>. The KEY field of the in a certificate <xref target="I-D.ietf-lamps-x509-shbs"/>. The KEY field of the
skipping to change at line 128 skipping to change at line 157
pk-HSS-LMS-HashSig definition is updated to reflect no ASN.1 wrapping pk-HSS-LMS-HashSig definition is updated to reflect no ASN.1 wrapping
for the public key. These changes resolve <xref target="Err7960"/> and for the public key. These changes resolve <xref target="Err7960"/> and
<xref target="Err7963"/>.</t> <xref target="Err7963"/>.</t>
<t> <t>
Additional HSS/LMS tree sizes have been defined. The list in <xref target="s ect-2.2"/> Additional HSS/LMS tree sizes have been defined. The list in <xref target="s ect-2.2"/>
was expanded to include the recently defined ones.</t> was expanded to include the recently defined ones.</t>
<t> <t>
Additional LM-OTS Signatures have been defined. The list in <xref target="se ct-2.3"/> Additional LM-OTS Signatures have been defined. The list in <xref target="se ct-2.3"/>
was expanded to include the recently defined ones.</t> was expanded to include the recently defined ones.</t>
<t> <t>
Provide more detail in <xref target="sect-4"/> regarding allowed values in More detail has been provided in <xref target="sect-4"/> regarding allowed va lues in
the X.509 certificate key usage extension for an HSS/LMS public key.</t> the X.509 certificate key usage extension for an HSS/LMS public key.</t>
</section> </section>
</section> </section>
<section anchor="sect-2"> <section anchor="sect-2">
<name>HSS/LMS Hash-Based Signature Algorithm Overview</name> <name>HSS/LMS Hash-Based Signature Algorithm Overview</name>
<t> <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="RFC8554" derivedContent="HASHSIG"/>, which is the <xref target="RFC8554" />, which is the
Leighton and Micali adaptation <xref target="LM" derivedContent="LM"/> of the Leighton and Micali adaptation <xref target="LM" /> of the
original Lamport-Diffie-Winternitz-Merkle one-time signature system original Lamport-Diffie-Winternitz-Merkle one-time signature system
<xref target="M1979" derivedContent="M1979"/> <xref target="M1987" derivedCon <xref target="M1979" /> <xref target="M1987" />
tent="M1987"/> <xref target="M1989a" /> <xref target="M1989b" />.</t>
<xref target="M1989a" derivedContent="M1989a"/> <xref target="M1989b" derived
Content="M1989b"/>.</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="RFC8554" derivedContent="HASHSIG"/> uses algorithm specified in <xref target="RFC8554" /> uses
only the SHA-256 one-way hash function <xref target="SHS" derivedContent="SHS only the SHA-256 one-way hash function <xref target="SHS" />,
"/>,
but it establishes an IANA registry <xref target="IANA-LMS"/> to but it establishes an IANA registry <xref target="IANA-LMS"/> to
permit the registration of additional one-way hash functions in the future.</ t> permit the registration of additional one-way hash functions in the future.</ t>
<section anchor="sect-2.1"> <section anchor="sect-2.1">
<name>Hierarchical Signature System (HSS)</name> <name>Hierarchical Signature System (HSS)</name>
<t> <t>
The MTS system specified in <xref target="RFC8554" derivedContent="HASHSIG"/> The MTS system specified in <xref target="RFC8554" />
uses a hierarchy of trees. The uses a hierarchy of trees. The
N-time Hierarchical 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" derivedContent="HASHS IG"/> carries the number of An HSS signature as specified in <xref target="RFC8554" /> carries the number 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"/> . The keys, followed by the LMS signature as described in <xref target="sect-2.2"/> . The
public key for the topmost 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"/>.</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 standalone tree (a top
tree with no children) can be summarized as:</t> tree with no children) can be summarized as:</t>
<artwork align="left"> <artwork align="left">
u32str(0) || u32str(0) ||
lms_signature /* signature of message */ lms_signature /* signature of message */
</artwork> </artwork>
<t>where, u32str() and || are used as defined in <xref target="RFC8554" derivedContent="HASHSIG"/>.</t> <t>where, u32str() and || are used as defined in <xref target="RFC8554" />.</t>
<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 align="left"> <artwork align="left">
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>
<t> <t>
where, as defined in <xref target="RFC8554" sectionFormat="of" section="3.3" derivedContent="HASHSIG"/>, the signed_public_key where, as defined in <xref target="RFC8554" sectionFormat="of" section="3.3" />, the signed_public_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>
<section anchor="sect-2.2"> <section anchor="sect-2.2">
<name>Leighton-Micali Signature (LMS)</name> <name>Leighton-Micali Signature (LMS)</name>
<t> <t>
Each tree in the system specified in <xref target="RFC8554" derivedContent="H ASHSIG"/> uses the Leighton-Micali Signature (LMS) system. LMS systems have two parameters. The Each tree in the system specified in <xref target="RFC8554" /> uses the Leigh ton-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="RFC8554" derivedContent="HAS HSIG"/> specification supports levels in the tree minus one. The <xref target="RFC8554" /> specification su pports
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.
There are 2^h leaves in the tree. The second parameter, m, There are 2<sup>h</sup> 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="RFC8 amount of data associated with each node in the tree. The <xref target="RFC8
554" derivedContent="HASHSIG"/> 554" />
specification supports the SHA-256 hash function <xref target="SHS" derivedCo specification supports the SHA-256 hash function <xref target="SHS" />, with
ntent="SHS"/>, with m=32. Additional LMS Signature parameter sets have been registered at <xref
m=32. Additional, LMS Signature parameter sets have been registered at <xref target="IANA-LMS"/>.</t>
target="IANA-LMS"/>.</t>
<t> <t>
As specified in <xref target="RFC8554" derivedContent="HASHSIG"/>, the LMS pu blic key consists of four As specified in <xref target="RFC8554" />, the LMS public key consists of fou r
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 Leighton-Micali One-Time Signature (LM-OTS) type as discussed in <xref target="sect-2.3"/>, the private key identify the Leighton-Micali One-Time Signature (LM-OTS) type as discussed in <xref target="sect-2.3"/>, the private key
identifier (I) as described in <xref target="RFC8554" sectionFormat="of" sect ion="5.3" derivedContent="HASHSIG"/>, and the m-byte string identifier (I) as described in <xref target="RFC8554" sectionFormat="of" sect ion="5.3" />, and the m-byte string
associated with the root node of the tree (T[1]).</t> associated with the 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 align="left"> <artwork align="left">
u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
</artwork> </artwork>
<t> <t>
As specified in <xref target="RFC8554" derivedContent="HASHSIG"/>, an LMS sig nature consists of four As specified in <xref target="RFC8554" />, 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 <xref target="sect- 2.3"/>, a signature value, an LM-OTS signature value as described in <xref target="sect- 2.3"/>, 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 value 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>
skipping to change at line 248 skipping to change at line 277
ots_signature || ots_signature ||
u32str(type) || u32str(type) ||
path[0] || path[1] || ... || path[h-1] path[0] || path[1] || ... || path[h-1]
</artwork> </artwork>
</section> </section>
<section anchor="sect-2.3"> <section anchor="sect-2.3">
<name>Leighton-Micali One-Time Signature (LM-OTS) Algorithm</name> <name>Leighton-Micali One-Time Signature (LM-OTS) Algorithm</name>
<t> <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="RFC8554" derivedContent="HASHSIG"/> specifies the use of th e LM-OTS, which has five and <xref target="RFC8554" /> specifies the use of the LM-OTS, which has five
parameters:</t> parameters:</t>
<dl indent="5"> <dl indent="5" newline="false" spacing="normal">
<dt>n:</dt> <dt>n:</dt>
<dd>The length in bytes of the hash function output.</dd> <dd>The length in bytes of the hash function output.</dd>
<dt>H:</dt> <dt>H:</dt>
<dd>A preimage-resistant hash function that accepts byte strings of an y length and returns an n-byte string.</dd> <dd>A preimage-resistant hash function that accepts byte strings of an y length and returns an n-byte string.</dd>
<dt>w:</dt> <dt>w:</dt>
<dd>The width in bits of the Winternitz coefficients. <xref target="RF C8554" derivedContent="HASHSIG"/> supports four values for this parameter: w=1, w=2, w=4, and w=8.</dd> <dd>The width in bits of the Winternitz coefficients. <xref target="RF C8554" /> supports four values for this parameter: w=1, w=2, w=4, and w=8.</dd>
<dt>p:</dt> <dt>p:</dt>
<dd>The number of n-byte string elements that make up the LM-OTS signa ture value.</dd> <dd>The number of n-byte string elements that make up the LM-OTS signa ture value.</dd>
<dt>ls:</dt> <dt>ls:</dt>
<dd>The number of bits that are left-shifted in the final step of the checksum function, which is defined in <xref target="RFC8554" sectionFormat="of" section="4.4" derivedContent="HASHSIG"/>.</dd> <dd>The number of bits that are left-shifted in the final step of the checksum function, which is defined in <xref target="RFC8554" sectionFormat="of" section="4.4" />.</dd>
</dl> </dl>
<t> <t>
The values of p and ls are dependent on the choices of the parameters 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 n and w, as described in <xref target="RFC8554" sectionFormat="of" section="B
" derivedContent="HASHSIG"/>.</t> "/>.</t>
<!-- [rfced] For clarity, should the four variants be listed in this sentence?
(We note they were listed in RFC 8708.)
RFC 8554 [HASHSIG] contains one instance of 'variant' but not regarding
this concept. Also, perhaps drop the "The" because within this document it's
referred to as "the [HASHSIG] specification" or simply "[HASHSIG]".
Original:
The [HASHSIG] specifies four LM-OTS variants.
Perhaps (A): [or, it could be a bulleted list as in RFC 8708]
[HASHSIG] specifies four LM-OTS variants (LMOTS_SHA256_N32_W1,
LMOTS_SHA256_N32_W2, LMOTS_SHA256_N32_W4, and LMOTS_SHA256_N32_W8).
Or (B): [referring to Table 1]
[HASHSIG] specifies four LM-OTS variants (as listed in Table 1
of [HASHIG]).
-->
<t> <t>
The <xref target="RFC8554" derivedContent="HASHSIG"/> specifies four LM-OTS v ariants. Additional, The <xref target="RFC8554" /> specifies four LM-OTS variants. Additional
LM-OTS Signature parameter sets have been registered at <xref target="IANA-LM S"/>.</t> LM-OTS Signature parameter sets have been registered at <xref target="IANA-LM S"/>.</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 <xref target="RFC8554" sectionFormat="of" section="4.5" derivedC ontent="HASHSIG"/>:</t> described in <xref target="RFC8554" sectionFormat="of" section="4.5" />:</t>
<artwork align="left"> <artwork align="left">
u32str(otstype) || C || y[0] || ... || y[p-1] u32str(otstype) || C || y[0] || ... || y[p-1]
</artwork> </artwork>
</section> </section>
</section> </section>
<section> <section>
<name>Algorithm Identifiers and Parameters</name> <name>Algorithm Identifiers and Parameters</name>
<t> <t>
The algorithm identifier for an HSS/LMS hash-based signature is: </t> The algorithm identifier for an HSS/LMS hash-based signature is: </t>
skipping to change at line 314 skipping to change at line 363
<section anchor="sect-4"> <section anchor="sect-4">
<name>HSS/LMS Public Key Identifier</name> <name>HSS/LMS Public Key Identifier</name>
<t> <t>
The AlgorithmIdentifier for an HSS/LMS public key uses the The AlgorithmIdentifier for an HSS/LMS public key uses the
id-alg-hss-lms-hashsig object identifier, and the parameters id-alg-hss-lms-hashsig object identifier, and the parameters
field <bcp14>MUST</bcp14> be absent.</t> field <bcp14>MUST</bcp14> be absent.</t>
<t> <t>
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of a certification authority (CA) X.509 certificate field of a certification authority (CA) X.509 certificate
<xref target="RFC5280" derivedContent="RFC5280"/>, the <xref target="RFC5280" />, the
certificate key usage extension <bcp14>MUST</bcp14> contain at least one of t he certificate key usage extension <bcp14>MUST</bcp14> contain at least one of t he
following values: digitalSignature, nonRepudiation, keyCertSign, and cRLSign. following values: digitalSignature, nonRepudiation, keyCertSign, and cRLSign.
However, it <bcp14>MUST NOT</bcp14> contain other values.</t> However, it <bcp14>MUST NOT</bcp14> contain other values.</t>
<!--[rfced] FYI, this sentence was updated per mail from the author on
25 September 2024.
Original:
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of an end entity X.509 certificate [RFC5280], the certificate
key usage extension MUST contain at least one of the following:
digitalSignature or nonRepudiation.
Current:
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of an end-entity X.509 certificate [RFC5280], the certificate
key usage extension MUST contain at least one of the following:
digitalSignature, nonRepudiation, or cRLSign.
-->
<!--[rfced] Regarding this comment in the ASN.1 (two instances
in this document), could it be rephrased for clarity? Yes, this
comment is part of the referenced [Err7963].
(Below, two hyphens have been replaced by one in order to include
this as a comment in the XML file.)
Original:
- KEY no ASN.1 wrapping -
Perhaps (A):
- KEY has no ASN.1 wrapping -
Or (B):
- No ASN.1 wrapping for KEY -
-->
<t> <t>
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of an end entity X.509 certificate field of an end-entity X.509 certificate
<xref target="RFC5280" derivedContent="RFC5280"/>, the <xref target="RFC5280" />, the
certificate key usage extension <bcp14>MUST</bcp14> contain at least one of t he certificate key usage extension <bcp14>MUST</bcp14> contain at least one of t he
following: digitalSignature or nonRepudiation. However, it <bcp14>MUST NOT</ bcp14> following: digitalSignature, nonRepudiation, or cRLSign. However, it <bcp14> MUST NOT</bcp14>
contain other values.</t> contain other values.</t>
<sourcecode type="asn.1" markers="false"> <sourcecode type="asn.1" markers="false">
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 no ASN.1 wrapping -- -- KEY no ASN.1 wrapping --
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
</sourcecode> </sourcecode>
<t> <t>
The id-alg-hss-lms-hashsig algorithm identifier is also 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 version of the document that became terminology used in an early draft version of the document that became
<xref target="RFC8554" derivedContent="HASHSIG"/>.</t> <xref target="RFC8554" />.</t>
<t> <t>
When the public key appears outside a certificate, it is an When the public key appears outside a certificate, it is an
OCTET STRING. Like the signature format, it is designed for easy OCTET STRING. Like the signature format, it is designed for easy
parsing. The value is the number of levels in the public key, L, parsing. The value is the number of levels in the public key, L,
followed by the LMS public key.</t> 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 align="left"> <artwork align="left">
u32str(L) || lms_public_key u32str(L) || lms_public_key
</artwork> </artwork>
<t> <t>
The public key for the topmost LMS tree is the public key 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.</t> of the HSS system. When L=1, the HSS system is a single tree.</t>
</section> </section>
<section anchor="sect-5"> <section anchor="sect-5">
<name>Signed-Data Conventions</name> <name>Signed-Data Conventions</name>
<t> <t>
As specified in <xref target="RFC5652" derivedContent="CMS"/>, the digital si gnature is produced from the As specified in <xref target="RFC5652" />, the digital signature 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, then a message-digest attribute is constructed with in the HSS/LMS tree, then a message-digest attribute is 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 <bcp14>MUST</bcp14> include a content-type attribute and a message-dig est (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="" markers="false"> <sourcecode name="pseudocode" type="" markers="false">
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))
</sourcecode> </sourcecode>
<t> <t>
When using <xref target="RFC8554" derivedContent="HASHSIG"/>, the fields in t he SignerInfo are used as When using <xref target="RFC8554" />, the fields in the SignerInfo are used a s
follows:</t> follows:</t>
<ul> <ul spacing="normal">
<li> <li><t>digestAlgorithm <bcp14>MUST</bcp14> contain the one-way hash
digestAlgorithm <bcp14>MUST</bcp14> contain the one-way hash function used function used in the HSS/LMS tree. For convenience, the
in the AlgorithmIdentifier for SHA-256 from <xref target="RFC5912"/> and the Al
HSS/LMS tree. For convenience, the AlgorithmIdentifier for SHA-256 gorithmIdentifier for SHAKE256
from <xref target="RFC5912" derivedContent="PKIXASN1"/> and the from <xref target="RFC8692"/> are repeated
AlgorithmIdentifier for SHAKE256 from <xref target="RFC8692" derivedConten here:</t>
t="SHAKEASN1"/>
are repeated here:</li>
</ul>
<sourcecode type="asn.1" markers="false"> <sourcecode type="asn.1" markers="false">
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 }
mda-shake256 DIGEST-ALGORITHM ::= { mda-shake256 DIGEST-ALGORITHM ::= {
IDENTIFIER id-shake256 } IDENTIFIER id-shake256 }
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-shake256 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)
nistAlgorithm(4) hashAlgs(2) 12 } nistAlgorithm(4) hashAlgs(2) 12 }
</sourcecode> </sourcecode>
<ul> </li>
<li> <li>
signatureAlgorithm <bcp14>MUST</bcp14> contain id-alg-hss-lms-hashsig, and the signatureAlgorithm <bcp14>MUST</bcp14> contain id-alg-hss-lms-hashsig, and the
algorithm parameters field <bcp14>MUST</bcp14> be absent.</li> algorithm parameters field <bcp14>MUST</bcp14> be absent.</li>
<li> <li>
signature contains the single HSS/LMS signature value resulting from signature contains the single HSS/LMS signature value resulting from
the signing operation as specified in <xref target="RFC8554" derivedConten t="HASHSIG"/>.</li> the signing operation as specified in <xref target="RFC8554"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="sect-6"> <section anchor="sect-6">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
Implementations <bcp14>MUST</bcp14> protect the private keys. Compromise of the Implementations <bcp14>MUST</bcp14> protect the private keys. Compromise of the
private keys will result in the ability to forge signatures. Along private keys will result in the ability to forge signatures. Along
with the private key, the implementation <bcp14>MUST</bcp14> keep track of wh ich 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
skipping to change at line 441 skipping to change at line 521
<t> <t>
An implementation <bcp14>MUST</bcp14> ensure that an LM-OTS private key is us ed to An implementation <bcp14>MUST</bcp14> ensure that an LM-OTS private key is us 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 pseudorandom 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-force s earching the whole key space. The generation of quality searching the resulting small set of possibilities, rather than brute-force s earching the whole key space. The generation of quality
random numbers is difficult, and <xref target="RFC4086" derivedContent="RFC40 86"/> offers important guidance random numbers is difficult, and <xref target="RFC4086"/> offers important gu idance
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 pseudorandom 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 " derivedContent="RFC4086"/> than in the generation of private keys, the guidance in <xref target="RFC4086 "/>
remains important.</t> remains important.</t>
<t> <t>
When computing signatures, the same hash function <bcp14>SHOULD</bcp14> be us ed to When computing signatures, the same hash function <bcp14>SHOULD</bcp14> be us ed to
compute the message digest of the content and the signed attributes, if they are present.</t> compute the message digest of the content and the signed attributes, if they are present.</t>
</section> </section>
<section anchor="sect-7"> <section anchor="sect-7">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
In the "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, IANA is requested to change the reference for value 64 to point to this registry, IANA has changed the reference for value 64 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 is requested to change the reference for value 17 to registry, IANA has changed the reference for value 17 to
point to this document.</t> this document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC8554" to="HASHSIG"/> <displayreference target="RFC8554" to="HASHSIG"/>
<displayreference target="RFC5652" to="CMS"/> <displayreference target="RFC5652" to="CMS"/>
<displayreference target="RFC5911" to="CMSASN1"/> <displayreference target="RFC5911" to="CMSASN1"/>
<displayreference target="RFC6268" to="CMSASN1U"/> <displayreference target="RFC6268" to="CMSASN1U"/>
<displayreference target="RFC4108" to="FWPROT"/> <displayreference target="RFC4108" to="FWPROT"/>
<displayreference target="RFC5912" to="PKIXASN1"/> <displayreference target="RFC5912" to="PKIXASN1"/>
<displayreference target="I-D.ietf-lamps-x509-shbs" to="X.509-S-HBS"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="ASN1-B" quoteTitle="true" derivedAnchor="ASN1-B">
<!-- [rfced] [ASN1-B] references the 2015 version of ITU-T Recommendation
X.680. This ITU-T Recommendation has been superseded a new version published
in February 2021 (https://www.itu.int/rec/t-rec-x.680/en). Would you
like to update this reference to use the most current version and add that URL
to the reference?
-->
<reference anchor="ASN1-B" quoteTitle="true">
<front> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> <title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title>
<seriesInfo name="ITU-T" value="Recommendation X.680"/> <seriesInfo name="ITU-T" value="Recommendation X.680"/>
<author> <author>
<organization showOnFrontPage="true">ITU-T</organization> <organization showOnFrontPage="true">ITU-T</organization>
</author> </author>
<date month="August" year="2015"/> <date month="August" year="2015"/>
</front> </front>
</reference> </reference>
<reference anchor="ASN1-E" quoteTitle="true" derivedAnchor="ASN1-E">
<!-- [rfced] [ASN1-E] references the 2015 version of ITU-T Recommendation
X.690. This ITU-T Recommendation has been superseded by the version in
February 2021 (https://www.itu.int/rec/t-rec-x.690/en). Would you like
to update this reference to use the most current version and add that URL to
the reference?
-->
<reference anchor="ASN1-E" quoteTitle="true">
<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> <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"/> <seriesInfo name="ITU-T" value="Recommendation X.690"/>
<author> <author>
<organization showOnFrontPage="true">ITU-T</organization> <organization showOnFrontPage="true">ITU-T</organization>
</author> </author>
<date month="August" year="2015"/> <date month="August" year="2015"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5
652" quoteTitle="true" derivedAnchor="CMS"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
<front> 52.xml"/>
<title>Cryptographic Message Syntax (CMS)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
<author initials="R." surname="Housley" fullname="R. Housley"> 54.xml"/>
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
</author> 19.xml"/>
<date year="2009" month="September"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
</front> 80.xml"/>
<seriesInfo name="STD" value="70"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<seriesInfo name="RFC" value="5652"/> 74.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference> <reference anchor="SHS" quoteTitle="true" target="https://doi.org/10.602
<reference anchor="RFC8554" target="https://www.rfc-editor.org/info/rfc8 8/NIST.FIPS.180-4">
554" quoteTitle="true" derivedAnchor="HASHSIG">
<front>
<title>Leighton-Micali Hash-Based Signatures</title>
<author initials="D." surname="McGrew" fullname="D. McGrew">
<organization/>
</author>
<author initials="M." surname="Curcio" fullname="M. Curcio">
<organization/>
</author>
<author initials="S." surname="Fluhrer" fullname="S. Fluhrer">
<organization/>
</author>
<date year="2019" month="April"/>
</front>
<seriesInfo name="RFC" value="8554"/>
<seriesInfo name="DOI" value="10.17487/RFC8554"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280" quoteTitle="true" derivedAnchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="SHS" quoteTitle="true" target="https://doi.org/10.602
8/NIST.FIPS.180-4" derivedAnchor="SHS">
<front> <front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<seriesInfo name="FIPS PUB" value="180-4"/> <seriesInfo name="FIPS PUB" value="180-4"/>
<author> <author>
<organization showOnFrontPage="true">National Institute of Standar ds and Technology (NIST)</organization> <organization showOnFrontPage="true">National Institute of Standar ds and Technology</organization>
</author> </author>
<date month="August" year="2015"/> <date month="August" year="2015"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<reference anchor="SHA3" quoteTitle="true" target="https://doi.org/10.60
28/NIST.FIPS.202" derivedAnchor="SHA3"> <reference anchor="SHA3" quoteTitle="true" target="https://doi.org/10.60
28/NIST.FIPS.202">
<front> <front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
<seriesInfo name="FIPS PUB" value="202"/> <seriesInfo name="FIPS PUB" value="202"/>
<author> <author>
<organization showOnFrontPage="true">National Institute of Standar ds and Technology</organization> <organization showOnFrontPage="true">National Institute of Standar ds and Technology</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC8692" target="https://www.rfc-editor.org/in
fo/rfc8692"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
<front> 92.xml"/>
<title>Internet X.509 Public Key Infrastructure: Addition
al Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs</title>
<author fullname="P. Kampanakis" initials="P." surname="K
ampanakis"/>
<author fullname="Q. Dang" initials="Q." surname="Dang"/>
<date month="December" year="2019"/>
</front>
<seriesInfo name="RFC" value="8692"/>
<seriesInfo name="DOI" value="10.17487/RFC8692"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="Err7960" target="https://www.rfc-editor.org/errata/ei d7960" quoteTitle="false"> <reference anchor="Err7960" target="https://www.rfc-editor.org/errata/ei d7960" quoteTitle="false">
<front> <front>
<title>RFC Errata Report 7960</title> <title>RFC Errata, Erratum ID 7960</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2024" month="May" day="28"/>
</front> </front>
<seriesInfo name="RFC" value="8708"/> <seriesInfo name="RFC" value="8708"/>
</reference> </reference>
<reference anchor="Err7963" target="https://www.rfc-editor.org/errata/ei d7963" quoteTitle="false"> <reference anchor="Err7963" target="https://www.rfc-editor.org/errata/ei d7963" quoteTitle="false">
<front> <front>
<title>RFC Errata Report 7963</title> <title>RFC Errata, Erratum ID 7963</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2024" month="May" day="29"/>
</front> </front>
<seriesInfo name="RFC" value="8708"/> <seriesInfo name="RFC" value="8708"/>
</reference> </reference>
<reference anchor="I-D.ietf-lamps-x509-shbs" target="https://datatracker
.ietf.org/doc/draft-ietf-lamps-x509-shbs-04"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
<front> etf-lamps-x509-shbs.xml"/>
<title>Internet X.509 Public Key Infrastructure: Algorithm Identifie
rs for HSS and XMSS</title> <reference anchor="BH2013" target="https://media.blackhat.com/us-13/us-1
<author fullname="Daniel Van Geest" initials="D." surname="Van Geest 3-Stamos-The-Factoring-Dead.pdf" quoteTitle="true">
">
<organization>CryptoNext Security</organization>
</author>
<author fullname="Kaveh Bashiri" initials="K." surname="Bashiri">
<organization>BSI</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Stefan-Lukas Gazdag" initials="S." surname="Gazdag
">
<organization>genua GmbH</organization>
</author>
<author fullname="Stavros Kousidis" initials="S." surname="Kousidis"
>
<organization>BSI</organization>
</author>
<date day="25" month="July" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-x509-shbs-04
"/>
</reference>
<reference anchor="BH2013" target="https://media.blackhat.com/us-13/us-1
3-Stamos-The-Factoring-Dead.pdf" quoteTitle="true" derivedAnchor="BH2013">
<front> <front>
<title>The Factoring Dead: Preparing for the Cryptopocalypse</title> <title>The Factoring Dead: Preparing for the Cryptopocalypse</title>
<author fullname="Thomas Ptacek" initials="T." surname="Ptacek"/> <author fullname="Thomas Ptacek" initials="T." surname="Ptacek"/>
<author fullname="Tom Ritter" initials="T." surname="Ritter"/> <author fullname="Tom Ritter" initials="T." surname="Ritter"/>
<author fullname="Javed Samuel" initials="J." surname="Samuel"/> <author fullname="Javed Samuel" initials="J." surname="Samuel"/>
<author fullname="Alex Stamos" initials="A." surname="Stamos"/> <author fullname="Alex Stamos" initials="A." surname="Stamos"/>
<date month="August" year="2013"/> <date month="August" year="2013"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC5911" target="https://www.rfc-editor.org/info/rfc5
911" quoteTitle="true" derivedAnchor="CMSASN1"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<front> 11.xml"/>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
S/MIME</title> 68.xml"/>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.41
<organization/> 08.xml"/>
</author>
<author initials="J." surname="Schaad" fullname="J. Schaad"> <reference anchor="IANA-LMS" target="https://www.iana.org/assignments/le
<organization/> ighton-micali-signatures/" quoteTitle="true">
</author>
<date year="2010" month="June"/>
</front>
<seriesInfo name="RFC" value="5911"/>
<seriesInfo name="DOI" value="10.17487/RFC5911"/>
</reference>
<reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6
268" quoteTitle="true" derivedAnchor="CMSASN1U">
<front>
<title>Additional New ASN.1 Modules for the Cryptographic Message Sy
ntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization/>
</author>
<date year="2011" month="July"/>
</front>
<seriesInfo name="RFC" value="6268"/>
<seriesInfo name="DOI" value="10.17487/RFC6268"/>
</reference>
<reference anchor="RFC4108" target="https://www.rfc-editor.org/info/rfc4
108" quoteTitle="true" derivedAnchor="FWPROT">
<front>
<title>Using Cryptographic Message Syntax (CMS) to Protect Firmware
Packages</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<date year="2005" month="August"/>
</front>
<seriesInfo name="RFC" value="4108"/>
<seriesInfo name="DOI" value="10.17487/RFC4108"/>
</reference>
<reference anchor="IANA-LMS" target="https://www.iana.org/assignments/le
ighton-micali-signatures/" quoteTitle="true" derivedAnchor="IANA-LMS">
<front> <front>
<title>Leighton-Micali Signatures (LMS)</title> <title>Leighton-Micali Signatures (LMS)</title>
<author> <author>
<organization showOnFrontPage="true">IANA</organization> <organization showOnFrontPage="true">IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="LM" quoteTitle="true" derivedAnchor="LM">
<!-- [rfced] For [LM], we found the following URL:
https://patents.google.com/patent/US5432852A/
Would you like to add it to the reference?
-->
<reference anchor="LM" quoteTitle="true">
<front> <front>
<title>Large provably fast and secure digital signature schemes base d on secure hash functions</title> <title>Large provably fast and secure digital signature schemes base d on secure hash functions</title>
<seriesInfo name="U.S." value="Patent 5,432,852"/>
<author fullname="T. Leighton" initials="T." surname="Leighton"/> <author fullname="T. Leighton" initials="T." surname="Leighton"/>
<author fullname="S. Micali" initials="S." surname="Micali"/> <author fullname="S. Micali" initials="S." surname="Micali"/>
<date month="July" year="1995"/> <date month="July" year="1995"/>
</front> </front>
<refcontent>U.S. Patent 5,432,852</refcontent>
</reference> </reference>
<reference anchor="M1979" quoteTitle="true" derivedAnchor="M1979">
<reference anchor="M1979" quoteTitle="true">
<front> <front>
<title>Secrecy, Authentication, and Public Key Systems</title> <title>Secrecy, Authentication, and Public Key Systems</title>
<seriesInfo name="Technical Report" value="No. 1979-1"/>
<seriesInfo name="Information Systems Laboratory," value="Stanford U
niversity"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"/> <author fullname="R. Merkle" initials="R." surname="Merkle"/>
<date year="1979"/> <date year="1979"/>
</front> </front>
<seriesInfo name="Technical Report" value="No. 1979-1"/>
<refcontent>Information Systems Laboratory, Stanford University</refco
ntent>
</reference> </reference>
<reference anchor="M1987" quoteTitle="true" target="https://doi.org/10.1
007/3-540-48184-2_32" derivedAnchor="M1987"> <reference anchor="M1987" quoteTitle="true" target="https://doi.org/10.1
007/3-540-48184-2_32">
<front> <front>
<title>A Digital Signature Based on a Conventional Encryption Functi on</title> <title>A Digital Signature Based on a Conventional Encryption Functi on</title>
<seriesInfo name="DOI" value="10.1007/3-540-48184-2_32"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"/> <author fullname="R. Merkle" initials="R." surname="Merkle"/>
<date year="1988"/> <date year="1988"/>
</front> </front>
<refcontent>Advances in Cryptology -- CRYPTO '87 Proceedings</refconte nt> <refcontent>Advances in Cryptology -- CRYPTO '87 Proceedings</refconte nt>
<refcontent>Lecture Notes in Computer Science Vol. 293</refcontent> <refcontent>Lecture Notes in Computer Science, Vol. 293</refcontent>
<seriesInfo name="DOI" value="10.1007/3-540-48184-2_32"/>
</reference> </reference>
<reference anchor="M1989a" quoteTitle="true" target="https://doi.org/10.
1007/0-387-34805-0_21" derivedAnchor="M1989a"> <reference anchor="M1989a" quoteTitle="true" target="https://doi.org/10.
1007/0-387-34805-0_21">
<front> <front>
<title>A Certified Digital Signature</title> <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"/> <author fullname="R. Merkle" initials="R." surname="Merkle"/>
<date year="1990"/> <date year="1990"/>
</front> </front>
<refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refconte nt> <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refconte nt>
<refcontent>Lecture Notes in Computer Science Vol. 435</refcontent> <refcontent>Lecture Notes in Computer Science, Vol. 435</refcontent>
<seriesInfo name="DOI" value="10.1007/0-387-34805-0_21"/>
</reference> </reference>
<reference anchor="M1989b" quoteTitle="true" target="https://doi.org/10.
1007/0-387-34805-0_40" derivedAnchor="M1989b"> <reference anchor="M1989b" quoteTitle="true" target="https://doi.org/10.
1007/0-387-34805-0_40">
<front> <front>
<title>One Way Hash Functions and DES</title> <title>One Way Hash Functions and DES</title>
<seriesInfo name="DOI" value="10.1007/0-387-34805-0_40"/> <seriesInfo name="DOI" value="10.1007/0-387-34805-0_40"/>
<author fullname="R. Merkle" initials="R." surname="Merkle"/> <author fullname="R. Merkle" initials="R." surname="Merkle"/>
<date year="1990"/> <date year="1990"/>
</front> </front>
<refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refconte nt> <refcontent>Advances in Cryptology -- CRYPTO '89 Proceedings</refconte nt>
<refcontent>Lecture Notes in Computer Science Vol. 435</refcontent> <refcontent>Lecture Notes in Computer Science, Vol. 435</refcontent>
</reference> </reference>
<reference anchor="NAS2019" quoteTitle="true" target="https://doi.org/10
.17226/25196" derivedAnchor="NAS2019"> <reference anchor="NAS2019" quoteTitle="true" target="https://doi.org/10
.17226/25196">
<front> <front>
<title>Quantum Computing: Progress and Prospects</title> <title>Quantum Computing: Progress and Prospects</title>
<seriesInfo name="DOI" value="10.17226/25196"/> <seriesInfo name="DOI" value="10.17226/25196"/>
<author> <author>
<organization showOnFrontPage="true">National Academies of Science s, Engineering, and Medicine</organization> <organization showOnFrontPage="true">National Academies of Science s, Engineering, and Medicine</organization>
</author> </author>
<date year="2019"/> <date year="2019"/>
</front> </front>
<refcontent>The National Academies Press</refcontent> <refcontent>The National Academies Press</refcontent>
</reference> </reference>
<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5
912" quoteTitle="true" derivedAnchor="PKIXASN1"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<front> 12.xml"/>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.5
09 (PKIX)</title> <reference anchor="PQC" target="https://doi.org/10.1007/978-3-540-88702-
<author initials="P." surname="Hoffman" fullname="P. Hoffman"> 7_1" quoteTitle="true">
<organization/>
</author>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author>
<date year="2010" month="June"/>
</front>
<seriesInfo name="RFC" value="5912"/>
<seriesInfo name="DOI" value="10.17487/RFC5912"/>
</reference>
<reference anchor="PQC" target="https://doi.org/10.1007/978-3-540-88702-
7_1" quoteTitle="true" derivedAnchor="PQC">
<front> <front>
<title>Introduction to post-quantum cryptography</title> <title>Introduction to post-quantum cryptography</title>
<seriesInfo name="DOI" value="10.1007/978-3-540-88702-7_1"/>
<author fullname="D. Bernstein" initials="D." surname="Bernstein"/> <author fullname="D. Bernstein" initials="D." surname="Bernstein"/>
<date year="2009"/> <date year="2009"/>
</front> </front>
<refcontent>Post-Quantum Cryptography, Springer, pp. 1-14</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-540-88702-7_1"/>
</reference> </reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086" quoteTitle="true" derivedAnchor="RFC4086"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<front> 86.xml"/>
<title>Randomness Requirements for Security</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization/>
</author>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization/>
</author>
<author initials="S." surname="Crocker" fullname="S. Crocker">
<organization/>
</author>
<date year="2005" month="June"/>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
</references> </references>
</references> </references>
<section anchor="sect-appendix"> <section anchor="sect-appendix">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t> <t>
The ASN.1 module in this appendix builds upon the modules in The ASN.1 module in this appendix builds upon the modules in
<xref target="RFC5911"/> and <xref target="RFC6268"/>.</t> <xref target="RFC5911"/> and <xref target="RFC6268"/>.</t>
<sourcecode type="asn.1" markers="true"> <sourcecode type="asn.1" markers="true">
skipping to change at line 907 skipping to change at line 857
<contact fullname="Jim Schaad"/>, <contact fullname="Jim Schaad"/>,
<contact fullname="Sean Turner"/>, <contact fullname="Sean Turner"/>,
<contact fullname="Daniel Van Geest"/>, and <contact fullname="Daniel Van Geest"/>, and
<contact fullname="Dale Worley"/> for their careful review and comments.</t> <contact fullname="Dale Worley"/> for their careful review and comments.</t>
<t> <t>
Many thanks to <contact fullname="Daniel Van Geest"/> for motivating the Many thanks to <contact fullname="Daniel Van Geest"/> for motivating the
creation of this document.</t> creation of this document.</t>
</section> </section>
</back> </back>
<!--[rfced] May usage of "MTS" be updated as follows?
Original: a variant of Merkle Tree Signatures (MTS)
Perhaps: a variant of the Merkle Tree Signature (MTS) scheme.
Original: Merkle Tree Signatures (MTS) are a method
Perhaps: The Merkle Tree Signature (MTS) scheme is a method
We find zero usage of "Merkle Tree Signatures (MTS)" (with plural 'Signatures')
outside of RFC 8708, and the Wikipedia entry for "Merkle signature scheme"
does not use "MTS". [For background, we did ask about this usage during
AUTH48 for 8708; the current question is slightly different.]
-->
<!-- [rfced] Please review each artwork element and let us know if any should
be marked as sourcecode (or another element) instead.
In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 85 change blocks. 
335 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.48.