rfc9814.original.xml   rfc9814.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 2.6. -ietf-lamps-cms-sphincs-plus-19" number="9814" updates="" obsoletes="" category=
10) --> "std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" s
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ymRefs="true" version="3" xml:lang="en">
-ietf-lamps-cms-sphincs-plus-19" category="std" consensus="true" submissionType=
"IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <front>
<title abbrev="SLH-DSA Signature Algorithm in CMS">Use of the SLH-DSA Signat <title abbrev="SLH-DSA Signature Algorithm in CMS">Use of the SLH-DSA
ure Algorithm in the Cryptographic Message Syntax (CMS)</title> Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-sphincs-plus-1 <seriesInfo name="RFC" value="9814"/>
9"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Fluhrer" fullname="Scott Fluhrer"> <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>sfluhrer@cisco.com</email> <email>sfluhrer@cisco.com</email>
skipping to change at line 39 skipping to change at line 39
<address> <address>
<email>kpanos@amazon.com</email> <email>kpanos@amazon.com</email>
</address> </address>
</author> </author>
<author initials="B." surname="Westerbaan" fullname="Bas Westerbaan"> <author initials="B." surname="Westerbaan" fullname="Bas Westerbaan">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>bas@westerbaan.name</email> <email>bas@westerbaan.name</email>
</address> </address>
</author> </author>
<date year="2025" month="January" day="13"/> <date year="2025" month="July"/>
<area>Security</area> <area>SEC</area>
<keyword>Internet-Draft</keyword> <workgroup>lamps</workgroup>
<abstract>
<?line 125?>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!--[rfced] We see the following similar sentences repeated throughout
the document. Please review and let us know if these should be
made uniform.
Original:
SLH-DSA is a stateless hash-based signature scheme. (Abstract)
SLH-DSA is a stateless hash-based signature algorithm. (Intro)
SLH-DSA is a hash-based signature scheme. (Section 2)
SLH-DSA is a stateless hash-based signature algorithm. (Section 2)
-->
<abstract>
<t>SLH-DSA is a stateless hash-based signature scheme. This document <t>SLH-DSA is a stateless hash-based signature scheme. This document
specifies the conventions for using the SLH-DSA signature algorithm specifies the conventions for using the SLH-DSA signature algorithm
with the Cryptographic Message Syntax (CMS). In addition, the with the Cryptographic Message Syntax (CMS). In addition, the
algorithm identifier and public key syntax are provided.</t> algorithm identifier and public key syntax are provided.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 132?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies the conventions for using the SLH-DSA hash-base d <t>This document specifies the conventions for using the SLH-DSA hash-base d
signature algorithm <xref target="FIPS205"/> with the Cryptographic Message signature algorithm <xref target="FIPS205"/> with the Cryptographic Message
Syntax (CMS) <xref target="RFC5652"/> signed-data content type.</t> Syntax (CMS) <xref target="RFC5652"/> signed-data content type.</t>
<t>SLH-DSA offers two signature modes: pure mode and pre-hash mode. SLH-D SA <t>SLH-DSA offers two signature modes: pure mode and pre-hash mode. SLH-D SA
signature operations include a context string as input. The context string signature operations include a context string as input. The context string
has a maximum length of 255 bytes. By default, the context string is the has a maximum length of 255 bytes. By default, the context string is the
empty string. This document only specifies the use of pure mode with an empty empty string. This document only specifies the use of pure mode with an empty
context string for the CMS signed-data content type.</t> context string for the CMS signed-data content type.</t>
<t>SLH-DSA offers three security levels. The parameters for each of the <t>SLH-DSA offers three security levels. The parameters for each of the
security levels were chosen to provide 128 bits of security, 192 bits of security levels were chosen to provide 128 bits of security, 192 bits of
security, and 256 bits of security. Separate algorithm identifiers have security, and 256 bits of security. Separate algorithm identifiers have
been assigned for SLH-DSA at each of these security levels.</t> been assigned for SLH-DSA at each of these security levels.</t>
<t>SLH-DSA is a stateless hash-based signature algorithm. Other hash-base d <t>SLH-DSA is a stateless hash-based signature algorithm. Other hash-base d
signature algorithms are stateful, including HSS/LMS <xref target="RFC8554"/> an signature algorithms are stateful, including Hierarchical Signature System (HSS)
d / Leighton-Micali Signatures (LMS) <xref target="RFC8554"/> and
XMSS <xref target="RFC8391"/>. Without the need for state kept by the signer, eXtended Merkle Signature Scheme (XMSS) <xref target="RFC8391"/>. Without the n
eed for state kept by the signer,
SLH-DSA is much less fragile than the stateful hash-based signature algorithms.< /t> SLH-DSA is much less fragile than the stateful hash-based signature algorithms.< /t>
<section anchor="asn1"> <section anchor="asn1">
<!--[rfced] Might we rephrase to avoid the repeated "using" in this
sentence?
Original:
CMS values are generated using ASN.1 [X680], using the Basic Encoding
Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
Perhaps:
CMS values are generated with ASN.1 [X680] using the Basic Encoding
Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
-->
<name>ASN.1</name> <name>ASN.1</name>
<t>CMS values are generated using ASN.1 <xref target="X680"/>, using the Basic <t>CMS values are generated using ASN.1 <xref target="X680"/>, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules Encoding Rules (BER) and the Distinguished Encoding Rules
(DER) <xref target="X690"/>.</t> (DER) <xref target="X690"/>.</t>
</section> </section>
<section anchor="motivation"> <section anchor="motivation">
<name>Motivation</name> <name>Motivation</name>
<t>There have been recent advances in cryptanalysis and advances in the <t>There have been recent advances in cryptanalysis and advances in the
development of quantum computers. Each of these advances pose a development of quantum computers. Each of these advances pose a
threat to widely deployed digital signature algorithms.</t> threat to widely deployed digital signature algorithms.</t>
<t>If cryptographically relevant quantum computers (CRQC) are ever built <t>If Cryptographically Relevant Quantum Computers (CRQCs) are ever buil
, they t, they
will be able to break many of the public-key cryptosystems currently in use, will be able to break many of the public key cryptosystems currently in use,
including RSA, DSA, ECDSA, and EdDSA. A post-quantum cryptosystem (PQC) is including RSA, DSA, Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwa
rds-curve Digital Signature Algorithm (EdDSA). A Post-Quantum Cryptosystem (PQC
) is
secure against quantum computers that have more than a trivial number of quantum secure against quantum computers that have more than a trivial number of quantum
bits (qu-bits). It is open to conjecture when it will be feasible to build bits (qu-bits). It is open to conjecture when it will be feasible to build
such quantum computers; however, it is prudent to use cryptographic such quantum computers; however, it is prudent to use cryptographic
algorithms that remain secure if a CRQC is invented. SLH-DSA is a PQC algorithms that remain secure if a CRQC is invented. SLH-DSA is a PQC
signature algorithm.</t> signature algorithm.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
</section>
</section>
</section> </section>
<section anchor="slh-dsa-hash-based-signature-algorithm-overview"> <section anchor="slh-dsa-hash-based-signature-algorithm-overview">
<name>SLH-DSA Hash-based Signature Algorithm Overview</name> <name>SLH-DSA Hash-Based Signature Algorithm Overview</name>
<t>SLH-DSA is a hash-based signature scheme. SLH-DSA makes use of a few <t>SLH-DSA is a hash-based signature scheme. SLH-DSA makes use of a few
time signature construction, namely Forest of Random Subsets (FORS) time signature constructions, namely Forest of Random Subsets (FORS)
and a hypertree. FORS signs a message with a private key. The and a hypertree. FORS signs a message with a private key. The
corresponding FORS public keys are the leaves in k binary trees. corresponding FORS public keys are the leaves in k binary trees.
The roots of these trees are hashed together to form a FORS root. The roots of these trees are hashed together to form a FORS root.
SLH-DSA uses a one-time signature scheme called WOTS+. The FORS SLH-DSA uses a one-time signature scheme called Winternitz One-Time Signature Pl
us (WOTS+).
<!--[rfced] As WOTS+ includes "one-time signature" in its expansion,
would this update work?
Original:
The FORS tree roots are signed by a WOTS+ one-time signature private
key.
Perhaps:
The FORS tree roots are signed by a WOTS+ private key.
-->
The FORS
tree roots are signed by a WOTS+ one-time signature private tree roots are signed by a WOTS+ one-time signature private
key. The corresponding WOTS+ public keys form the leaves in d-layers key. The corresponding WOTS+ public keys form the leaves in d-layers
of Merkle subtrees in the SLH-DSA hypertree. The bottom layer of of Merkle subtrees in the SLH-DSA hypertree. The bottom layer of
that hypertree signs the FORS roots with WOTS+. The root of the that hypertree signs the FORS roots with WOTS+.&nbsp; The roots of the
bottom Merkle subtrees are then signed with WOTS+ and the bottom Merkle subtrees are then signed with WOTS+ and the
corresponding WOTS+ public keys form the leaves of the next level up corresponding WOTS+ public keys form the leaves of the next-level-up
subtree. Subtree roots are consequently signed by their corresponding subtree. Subtree roots are consequently signed by their corresponding
subtree layers until the top subtree is reached. The top layer subtree subtree layers until the top subtree is reached. The top-layer subtree
forms the hypertree root which is trusted at the verifier.</t> forms the hypertree root, which is trusted at the verifier.</t>
<t>A SLH-DSA signature consists of the randomization string, the FORS sign <t>An SLH-DSA signature consists of the randomization string, the FORS sig
ature, nature,
the WOTS+ signature in each layer, and the path to the root of each subtree the WOTS+ signature in each layer, and the path to the root of each subtree
until the root of the hypertree is reached.</t> until the root of the hypertree is reached.</t>
<t>A SLH-DSA signature is verified by verifying the FORS signature, the
WOTS+ signatures and the path to the root of each subtree. When reaching <!--[rfced] Please review our updates to this sentence to reduce
redundancy to confirm we have maintained your intended meaning.
Original:
A SLH-DSA signature is verified by verifying the FORS signature, the
WOTS+ signatures and the path to the root of each subtree.
Current:
An SLH-DSA signature is verified using the FORS signature, the WOTS+
signatures, and the path to the root of each subtree.
-->
<t>An SLH-DSA signature is verified using the FORS signature, the
WOTS+ signatures, and the path to the root of each subtree. When reaching
the root of the hypertree, the signature verifies only if it hashes to the root of the hypertree, the signature verifies only if it hashes to
the pre-trusted root of the SLH-DSA hypertree.</t> the pre-trusted root of the SLH-DSA hypertree.</t>
<t>SLH-DSA is a stateless hash-based signature algorithm. Stateful <t>SLH-DSA is a stateless hash-based signature algorithm. Stateful
hash-based signature schemes require that the WOTS+ private key hash-based signature schemes require that the WOTS+ private key
(generated by using a state index) is never reused or the scheme (generated by using a state index) never be reused or the scheme
loses it security. Although its security decreases, FORS which is loses its security.
used at the bottom of the SLH-DSA hypertree does not collapse if
<!--[rfced] There may be text missing in this sentence. If our
suggested text does not convey your intended meaning, please let
us know how we may rephrase.
Original:
Although its security decreases, FORS which is used at the bottom of
the SLH-DSA hypertree does not collapse if the same private key used
to sign two or more different messages like in stateful hash-based
signature schemes.
Perhaps:
Although its security decreases, FORS, which is used at the bottom of
the SLH-DSA hypertree, does not collapse if the same private key used
to sign two or more different messages is used (as is the case in
stateful hash-based signature schemes).
-->
Although its security decreases, FORS, which is
used at the bottom of the SLH-DSA hypertree, does not collapse if
the same private key used to sign two or more different messages the same private key used to sign two or more different messages
like in stateful hash-based signature schemes. Without the need for like in stateful hash-based signature schemes. Without the need for
state kept by the signer to ensure it is not reused, SLH-DSA is much state kept by the signer to ensure it is not reused, SLH-DSA is much
less fragile.</t> less fragile.</t>
<t>SLH-DSA was designed to sign up to 2^64 messages and offers three
<!-- [rfced] FYI, we have used the <sup> element for superscript in
this document. Please review and let us know any objections.
-->
<t>SLH-DSA was designed to sign up to 2<sup>64</sup> messages and offers t
hree
security levels. The parameters of the SLH-DSA hypertree include the security levels. The parameters of the SLH-DSA hypertree include the
security parameter, the hash function, the tree height, the number of security parameter, the hash function, the tree height, the number of
layers of subtrees, the Winternitz parameter of WOTS+, the number of FORS layers of subtrees, the Winternitz parameter of WOTS+, and the number of FORS
trees and leaves in each. The parameters for each of the security levels trees and leaves in each. The parameters for each of the security levels
were chosen to at least as secure as a generic block cipher of 128, 192, were chosen to be at least as secure as a generic block cipher of 128, 192,
or 256 bits.</t> or 256 bits.</t>
</section> </section>
<section anchor="slh-dsa-public-key-identifier"> <section anchor="slh-dsa-public-key-identifier">
<name>SLH-DSA Public Key Identifier</name> <name>SLH-DSA Public Key Identifier</name>
<t>The AlgorithmIdentifier for a SLH-DSA public key <bcp14>MUST</bcp14> us
e one of the <!--[rfced] We note that "SHA2" does not appear in [FIPS180]. Please
review and confirm this citation:
Original:
The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the
twelve id-slh-dsa object identifiers listed below, based on the
security level used to generate the SLH-DSA hypertree, the small or
fast version of the algorithm, and the use of SHA2 [FIPS180] or SHAKE
[FIPS202].
-->
<t>The AlgorithmIdentifier for an SLH-DSA public key <bcp14>MUST</bcp14> u
se one of the
twelve id-slh-dsa object identifiers listed below, based on the twelve id-slh-dsa object identifiers listed below, based on the
security level used to generate the SLH-DSA hypertree, the small or fast security level used to generate the SLH-DSA hypertree, the small or fast
version of the algorithm, and the use of SHA2 <xref target="FIPS180"/> or version of the algorithm, and the use of SHA2 <xref target="FIPS180"/> or
SHAKE <xref target="FIPS202"/>. For example, id-slh-dsa-shake-256s SHAKE <xref target="FIPS202"/>. For example, id-slh-dsa-shake-256s
represents the 256-bit security level, the small version of the represents the 256-bit security level, the small version of the
algorithm, and the use of SHAKE256. The parameters field of the algorithm, and the use of SHAKE256. The parameters field of the
AlgorithmIdentifier for the SLH-DSA public key <bcp14>MUST</bcp14> be absent.</t > AlgorithmIdentifier for the SLH-DSA public key <bcp14>MUST</bcp14> be absent.</t >
<artwork><![CDATA[ <artwork><![CDATA[
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) 4 } country(16) us(840) organization(1) gov(101) csor(3) 4 }
skipping to change at line 282 skipping to change at line 377
SLH-DSA-PublicKey ::= OCTET STRING (SIZE (32 | 48 | 64)) SLH-DSA-PublicKey ::= OCTET STRING (SIZE (32 | 48 | 64))
SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128)) SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))
]]></artwork> ]]></artwork>
<t>No additional encoding of the SLH-DSA public key is applied in the <t>No additional encoding of the SLH-DSA public key is applied in the
SubjectPublicKeyInfo field of an X.509 certificate <xref target="RFC5280"/>.</t> SubjectPublicKeyInfo field of an X.509 certificate <xref target="RFC5280"/>.</t>
<t>No additional encoding of the SLH-DSA private key is applied in the <t>No additional encoding of the SLH-DSA private key is applied in the
PrivateKeyInfo field of the privateKey field of the OneAsymmetricKey PrivateKeyInfo field of the privateKey field of the OneAsymmetricKey
type of an Asymmetric Key Package <xref target="RFC5958"/>.</t> type of an Asymmetric Key Package <xref target="RFC5958"/>.</t>
<t>When a SLH-DSA public key appears outside of a SubjectPublicKeyInfo typ e <t>When an SLH-DSA public key appears outside of a SubjectPublicKeyInfo ty pe
in an environment that uses ASN.1 encoding, the SLH-DSA public key in an environment that uses ASN.1 encoding, the SLH-DSA public key
can be encoded as an OCTET STRING by using the SLH-DSA-PublicKey type.</t> can be encoded as an OCTET STRING by using the SLH-DSA-PublicKey type.</t>
<t>When a SLH-DSA private key appears outside of an Asymmetric Key Package <t>When an SLH-DSA private key appears outside of an Asymmetric Key Packag e
in an environment that uses ASN.1 encoding, the SLH-DSA private key in an environment that uses ASN.1 encoding, the SLH-DSA private key
can be encoded as an OCTET STRING by using the SLH-DSA-PrivateKey type.</t> can be encoded as an OCTET STRING by using the SLH-DSA-PrivateKey type.</t>
</section> </section>
<section anchor="signed-data-conventions"> <section anchor="signed-data-conventions">
<name>Signed-data Conventions</name> <name>Signed-Data Conventions</name>
<t>As specified in CMS <xref target="RFC5652"/>, the digital signature is produced from <t>As specified in CMS <xref target="RFC5652"/>, the digital signature is produced from
the message digest and the signer's private key. The signature is computed the message digest and the signer's private key. The signature is computed
over different values depending on whether signed attributes are absent or over different values depending on whether signed attributes are absent or
present.</t> present.</t>
<t>When signed attributes are absent, the SLH-DSA (pure mode) signature is computed over <t>When signed attributes are absent, the SLH-DSA (pure mode) signature is computed over
the content. When signed attributes are present, a hash <bcp14>MUST</bcp14> be computed over the content. When signed attributes are present, a hash <bcp14>MUST</bcp14> be computed over
the content using the same hash function that is used in the SLH-DSA tree. The the content using the same hash function that is used in the SLH-DSA tree. The
signed attributes <bcp14>MUST</bcp14> include a content-type attribute and a mes sage-digest signed attributes <bcp14>MUST</bcp14> include a content-type attribute and a mes sage-digest
attribute. The message-digest attribute contains the hash value of the attribute. The message-digest attribute contains the hash value of the
content. The SLH-DSA signature is computed over the DER encoding of the set content. The SLH-DSA signature is computed over the DER encoding of the set
of signed attributes. The SLH-DSA signature generation operation is called of signed attributes. The SLH-DSA signature-generation operation is called
slh_sign; see Section 10.2.1 of <xref target="FIPS205"/>. In summary:</t> slh_sign; see Section 10.2.1 of <xref target="FIPS205"/>. In summary:</t>
<artwork><![CDATA[ <artwork><![CDATA[
IF (signed attributes are absent) IF (signed attributes are absent)
THEN slh_sign(content) THEN slh_sign(content)
ELSE message-digest attribute = Hash(content); ELSE message-digest attribute = Hash(content);
slh_sign(DER(SignedAttributes)) slh_sign(DER(SignedAttributes))
]]></artwork> ]]></artwork>
<t>In some implementations, performance may be significantly improved by <t>In some implementations, performance may be significantly improved by
signing and verifying DER(SignedAttributes) when the content is large. That signing and verifying DER(SignedAttributes) when the content is large. That
is, passing an entire large message content to the signing function or the is, passing an entire large message content to the signing function or the
signature validation function can have an impact on performance. When the signature validation function can have an impact on performance. When the
signed attributes are present, <xref section="5.3" sectionFormat="of" target="RF C5652"/> requires the signed attributes are present, <xref section="5.3" sectionFormat="of" target="RF C5652"/> requires the
inclusion of the content-type attribute and the message-digest attribute. Other inclusion of the content-type attribute and the message-digest attribute. Other
attributes can also be included.</t> attributes can also be included.</t>
<t>When using SLH-DSA and signed attributes are present in the SignerInfo, the <t>When using SLH-DSA and signed attributes are present in the SignerInfo, the
digestAlgorithms field in the SignedData <bcp14>MUST</bcp14> include the identif ier for the digestAlgorithm field in the SignedData <bcp14>MUST</bcp14> include the identifi er for the
one-way hash function used to compute the message digest.</t> one-way hash function used to compute the message digest.</t>
<t>When using SLH-DSA, the fields in the SignerInfo are used as follows:</ t> <t>When using SLH-DSA, the fields in the SignerInfo are used as follows:</ t>
<dl newline="true"> <dl newline="true">
<dt>digestAlgorithm:</dt> <dt>digestAlgorithm:</dt>
<dd> <dd>
<t>The digestAlgorithm <bcp14>MUST</bcp14> identify a one-way hash fun ction. When signed <t>The digestAlgorithm <bcp14>MUST</bcp14> identify a one-way hash fun ction. When signed
attributes are absent, the digestAlgorithm identifier <bcp14>MUST</bcp14> match the hash attributes are absent, the digestAlgorithm identifier <bcp14>MUST</bcp14> match the hash
function used in the SLH-DSA tree (as shown in the list below). When signed function used in the SLH-DSA tree (as shown in the list below). When signed
attributes are present, to ensure collision resistance, the identified hash attributes are present, to ensure collision resistance, the identified hash
function <bcp14>MUST</bcp14> produce a hash value that is at least twice the siz e of the function <bcp14>MUST</bcp14> produce a hash value that is at least twice the siz e of the
hash function used in the SLH-DSA tree. The hash functions defined in hash function used in the SLH-DSA tree. The hash functions defined in
<xref target="FIPS180"/> and <xref target="FIPS202"/> <bcp14>MUST</bcp14> be sup <xref target="FIPS180"/> and <xref target="FIPS202"/> <bcp14>MUST</bcp14> be sup
ported for use with the variants of ported for use with the variants of SLH-DSA as shown below:</t>
SLH-DSA as shown below:</t>
</dd>
</dl>
<artwork><![CDATA[ <artwork><![CDATA[
id-slh-dsa-sha2-128s: SHA-256 id-slh-dsa-sha2-128s: SHA-256
id-slh-dsa-sha2-128f: SHA-256 id-slh-dsa-sha2-128f: SHA-256
id-slh-dsa-sha2-192s: SHA-512 id-slh-dsa-sha2-192s: SHA-512
id-slh-dsa-sha2-192f: SHA-512 id-slh-dsa-sha2-192f: SHA-512
id-slh-dsa-sha2-256s: SHA-512 id-slh-dsa-sha2-256s: SHA-512
id-slh-dsa-sha2-256f: SHA-512 id-slh-dsa-sha2-256f: SHA-512
id-slh-dsa-shake-128s: SHAKE128 with 256 bit output id-slh-dsa-shake-128s: SHAKE128 with 256-bit output
id-slh-dsa-shake-128f: SHAKE128 with 256 bit output id-slh-dsa-shake-128f: SHAKE128 with 256-bit output
id-slh-dsa-shake-192s: SHAKE256 with 512 bit output id-slh-dsa-shake-192s: SHAKE256 with 512-bit output
id-slh-dsa-shake-192f: SHAKE256 with 512 bit output id-slh-dsa-shake-192f: SHAKE256 with 512-bit output
id-slh-dsa-shake-256s: SHAKE256 with 512 bit output id-slh-dsa-shake-256s: SHAKE256 with 512-bit output
id-slh-dsa-shake-256f: SHAKE256 with 512 bit output id-slh-dsa-shake-256f: SHAKE256 with 512-bit output
The object identifiers for SHA-256 and SHA-512 are included
in [RFC5754]. The object identifiers for SHAKE128 and
SHAKE256 are included in [RFC8702]. In all four cases, the
AlgorithmIdentifier SHOULD NOT include parameters.
]]></artwork> ]]></artwork>
<dl newline="true">
<t> The object identifiers for SHA-256 and SHA-512 are included
in <xref target="RFC5754"/>. The object identifiers for SHAKE128 and
SHAKE256 are included in <xref target="RFC8702"/>. In all four cases, the
AlgorithmIdentifier <bcp14>SHOULD NOT</bcp14> include parameters.</t>
</dd>
<dt>signatureAlgorithm:</dt> <dt>signatureAlgorithm:</dt>
<dd> <dd>
<t>The signatureAlgorithm <bcp14>MUST</bcp14> contain one of the the S LH-DSA algorithm <t>The signatureAlgorithm <bcp14>MUST</bcp14> contain one of the SLH-D SA algorithm
identifiers, and the algorithm parameters field <bcp14>MUST</bcp14> be absent. The identifiers, and the algorithm parameters field <bcp14>MUST</bcp14> be absent. The
algorithm identifier <bcp14>MUST</bcp14> be one of the following:</t> algorithm identifier <bcp14>MUST</bcp14> be one of the following:</t>
</dd>
</dl>
<artwork><![CDATA[ <artwork><![CDATA[
id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f, id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f,
id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f, id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f,
id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f, id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f,
id-slh-dsa-shake-128s, id-slh-dsa-shake-128f, id-slh-dsa-shake-128s, id-slh-dsa-shake-128f,
id-slh-dsa-shake-192s, id-slh-dsa-shake-192f, id-slh-dsa-shake-192s, id-slh-dsa-shake-192f,
id-slh-dsa-shake-256s, id-slh-dsa-shake-256f. id-slh-dsa-shake-256s, id-slh-dsa-shake-256f.
]]></artwork> ]]></artwork>
<dl newline="true"> </dd>
<dt>signature:</dt> <dt>signature:</dt>
<dd> <dd>
<t>The signature contains the signature value resulting from the <t>The signature contains the signature value resulting from the
SLH-DSA signing operation with the parameters associated with the SLH-DSA signing operation with the parameters associated with the
selected signatureAlgorithm. The SLH-DSA signature generation selected signatureAlgorithm. The SLH-DSA signature-generation
operation is specified in Section 10.2.1 of <xref target="FIPS205"/>, and the operation is specified in Section 10.2.1 of <xref target="FIPS205"/>, and the
SLH-DSA signature verification operation is specified in SLH-DSA signature verification operation is specified in
Section 10.3 of <xref target="FIPS205"/>. Signature verification <bcp14>MUST</b cp14> include Section 10.3 of <xref target="FIPS205"/>. Signature verification <bcp14>MUST</b cp14> include
checking that the signatureAlgorithm field identifies SLH-DSA checking that the signatureAlgorithm field identifies SLH-DSA
parameters that are consistent with public key used to validate parameters that are consistent with public key used to validate
the signature.</t> the signature.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Implementations <bcp14>MUST</bcp14> protect the private keys. Compromi se of the <t>Implementations <bcp14>MUST</bcp14> protect the private keys. Compromi se of the
private keys may result in the ability to forge signatures.</t> private keys may result in the ability to forge signatures.</t>
<t>When generating an SLH-DSA key pair, an implementation <bcp14>MUST</bcp 14> generate <t>When generating an SLH-DSA key pair, an implementation <bcp14>MUST</bcp 14> generate
each key pair independently of all other key pairs in the SLH-DSA each key pair independently of all other key pairs in the SLH-DSA
hypertree.</t> hypertree.</t>
<t>A SLH-DSA tree <bcp14>MUST NOT</bcp14> be used for more than 2^64 signi ng operations.</t> <t>A SLH-DSA tree <bcp14>MUST NOT</bcp14> be used for more than 2<sup>64</ sup> signing operations.</t>
<t>The generation of private keys relies on random numbers. The use <t>The generation of private keys relies on random numbers. The use
of inadequate pseudo-random number generators (PRNGs) to generate of inadequate Pseudorandom Number Generators (PRNGs) to generate
these values can result in little or no security. An attacker may these values can result in little or no security. An attacker may
find it much easier to reproduce the PRNG environment that produced find it much easier to reproduce the PRNG environment that produced
the keys, searching the resulting small set of possibilities, rather the keys, searching the resulting small set of possibilities, rather
than brute force searching the whole key space. The generation of than brute-force searching the whole key space. The generation of
quality random numbers is difficult, and <xref target="RFC4086"/> offers quality random numbers is difficult, and <xref target="RFC4086"/> offers
important guidance in this area.</t> important guidance in this area.</t>
<t>To avoid algorithm substitution attacks, the CMSAlgorithmProtection att ribute <t>To avoid algorithm-substitution attacks, the CMSAlgorithmProtection att ribute
defined in <xref target="RFC6211"/> <bcp14>SHOULD</bcp14> be included in signed attributes.</t> defined in <xref target="RFC6211"/> <bcp14>SHOULD</bcp14> be included in signed attributes.</t>
<t>Implementers should consider their particular use cases and may <t>Implementers should consider their particular use cases and may
choose to implement optional fault attack countermeasures choose to implement optional fault-attack countermeasures
<xref target="CMP2018"/> <xref target="Ge2023"/>. Verifying a signature before releasing the <xref target="CMP2018"/> <xref target="Ge2023"/>. Verifying a signature before releasing the
signature value is a typical fault attack countermeasure; however, this signature value is a typical fault-attack countermeasure; however, this
countermeasure is not effective for SLH-DSA <xref target="Ge2023"/>. Redundancy countermeasure is not effective for SLH-DSA <xref target="Ge2023"/>. Redundancy
by replicating the signature generation process <bcp14>MAY</bcp14> be used as an by replicating the signature-generation process <bcp14>MAY</bcp14> be used as an
effective fault attack countermeasure for SLH-DSA <xref target="Ge2023"/>; effective fault-attack countermeasure for SLH-DSA <xref target="Ge2023"/>;
however, the SLH-DSA signature generation is already considered slow.</t> however, the SLH-DSA signature generation is already considered slow.</t>
<t>Likewise, Implementers should consider their particular use cases and m ay <t>Likewise, implementers should consider their particular use cases and m ay
choose to implement protections against passive power and emissions choose to implement protections against passive power and emissions
side-channel attacks <xref target="SLotH"/>.</t> side-channel attacks <xref target="SLotH"/>.</t>
</section> </section>
<section anchor="operational-considerations"> <section anchor="operational-considerations">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<t>If slh_sign is implemented in a hardware device such as hardware <t>If slh_sign is implemented in a hardware device such as Hardware
security module (HSM) or portable cryptographic token, implementations Security Module (HSM) or portable cryptographic token, implementations
can avoid sending the full content to the device. By including signed can avoid sending the full content to the device. By including signed
attributes, which necessarily include the message-digest attribute and attributes, which necessarily include the message-digest attribute and
the content-type attribute as described in <xref section="5.3" sectionFormat="of " target="RFC5652"/>, the content-type attribute as described in <xref section="5.3" sectionFormat="of " target="RFC5652"/>,
the much smaller set of signed attributes are sent to the device for signing.</t > the much smaller set of signed attributes are sent to the device for signing.</t >
<t>By including signed attributes in the SignerInfo, one can obtain simila r <t>By including signed attributes in the SignerInfo, one can obtain simila r
interface characteristics to SLH-DSA in pre-hash mode. With pre-hash mode, the interface characteristics to SLH-DSA in pre-hash mode. With pre-hash mode, the
hash of the content is passed to the SLH-DSA signature operation instead of the hash of the content is passed to the SLH-DSA signature operation instead of the
full message content. By including signed attributes in the SignerInfo, a full message content. By including signed attributes in the SignerInfo, a
relatively small to-be-signed value is passed to the SLH-DSA signature relatively small to-be-signed value is passed to the SLH-DSA signature
operation. For this reason, SLH-DSA pre-hash mode is not specified for use operation. For this reason, SLH-DSA pre-hash mode is not specified for use
skipping to change at line 442 skipping to change at line 537
attributes. To assist recipients that might make use of stream-based APIs, attributes. To assist recipients that might make use of stream-based APIs,
implementers <bcp14>SHOULD</bcp14> include signed attributes within any SignerIn fo that uses implementers <bcp14>SHOULD</bcp14> include signed attributes within any SignerIn fo that uses
SLH-DSA as signature algorithm. Doing so allows the recipient implementation SLH-DSA as signature algorithm. Doing so allows the recipient implementation
to avoid keeping the signed content in memory. Recall that when signed to avoid keeping the signed content in memory. Recall that when signed
attributes are present, they <bcp14>MUST</bcp14> contain a content-type attribut e and a attributes are present, they <bcp14>MUST</bcp14> contain a content-type attribut e and a
message-digest attribute, and they <bcp14>SHOULD</bcp14> contain a CMSAlgorithmP rotection message-digest attribute, and they <bcp14>SHOULD</bcp14> contain a CMSAlgorithmP rotection
attribute.</t> attribute.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>For the ASN.1 Module in the Appendix of this document, IANA <t>For the ASN.1 Module in <xref target="appendix-asn1"/>, IANA
is requested to assign an object identifier (OID) for the module has assigned an Object Identifier (OID) for the module
identifier (TBD1) with a Description of "id-mod-slh-dsa-2024". identifier (81) with a Description of "id-mod-slh-dsa-2024".
The OID for the module should be allocated in the The OID for the module has been allocated in the
"SMI Security for S/MIME Module Identifier" (1.2.840.113549.1.9.16.0).</t> "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.<
/t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="FIPS180"> <reference anchor="FIPS180">
<front> <front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization>National Institute of Standards and Technology (NIST )</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="180-4"/> <seriesInfo name="NIST FIPS" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<reference anchor="FIPS202"> <reference anchor="FIPS202">
<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>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization>National Institute of Standards and Technology (NIST )</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="202"/> <seriesInfo name="NIST FIPS" value="202"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
</reference> </reference>
<reference anchor="FIPS205" target="https://doi.org/10.6028/NIST.FIPS.20
5"> <reference anchor="FIPS205">
<front> <front>
<title>Stateless Hash-Based Digital Signature Standard</title> <title>Stateless Hash-Based Digital Signature Standard</title>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization>National Institute of Standards and Technology (NIST )</organization>
</author> </author>
<date year="2024" month="August" day="13"/> <date year="2024" month="August" day="13"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="205"/> <seriesInfo name="NIST FIPS" value="205"/>
</reference> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.205"/>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC5652">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS).
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
ry message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="RFC5754">
<front>
<title>Using SHA2 Algorithms with Cryptographic Message Syntax</titl
e>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="January" year="2010"/>
<abstract>
<t>This document describes the conventions for using the Secure Ha
sh Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512
) with the Cryptographic Message Syntax (CMS). It also describes the conventions
for using these algorithms with the CMS and the Digital Signature Algorithm (DS
A), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algori
thms. Further, it provides SMIMECapabilities attribute values for each algorithm
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5754"/>
<seriesInfo name="DOI" value="10.17487/RFC5754"/>
</reference>
<reference anchor="RFC5958">
<front>
<title>Asymmetric Key Packages</title>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="August" year="2010"/>
<abstract>
<t>This document defines the syntax for private-key information an
d a content type for it. Private-key information includes a private key for a sp
ecified public-key algorithm and a set of attributes. The Cryptographic Message
Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, aut
henticate, or encrypt the asymmetric key format content type. This document obso
letes RFC 5208. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5958"/>
<seriesInfo name="DOI" value="10.17487/RFC5958"/>
</reference>
<reference anchor="RFC6211">
<front>
<title>Cryptographic Message Syntax (CMS) Algorithm Identifier Prote
ction Attribute</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="April" year="2011"/>
<abstract>
<t>The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certi
ficates, is vulnerable to algorithm substitution attacks. In an algorithm substi
tution attack, the attacker changes either the algorithm being used or the param
eters of the algorithm in order to change the result of a signature verification
process. In X.509 certificates, the signature algorithm is protected because it
is duplicated in the TBSCertificate.signature field with the proviso that the v
alidator is to compare both fields as part of the signature validation process.
This document defines a new attribute that contains a copy of the relevant algor
ithm identifiers so that they are protected by the signature or authentication p
rocess. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6211"/>
<seriesInfo name="DOI" value="10.17487/RFC6211"/>
</reference>
<reference anchor="RFC8702">
<front>
<title>Use of the SHAKE One-Way Hash Functions in the Cryptographic
Message Syntax (CMS)</title>
<author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/
>
<author fullname="Q. Dang" initials="Q." surname="Dang"/>
<date month="January" year="2020"/>
<abstract>
<t>This document updates the "Cryptographic Message Syntax (CMS) A
lgorithms" (RFC 3370) and describes the conventions for using the SHAKE family o
f hash functions in the Cryptographic Message Syntax as one-way hash functions w
ith the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digit
al Signature Algorithm (ECDSA). The conventions for the associated signer public
keys in CMS are also described.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8702"/>
<seriesInfo name="DOI" value="10.17487/RFC8702"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
958.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
211.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
702.xml"/>
<reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680"> <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
<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>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
skipping to change at line 585 skipping to change at line 615
<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>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1-2021"/> <seriesInfo name="ISO/IEC" value="8825-1-2021"/>
</reference> </reference>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
le> 174.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4086"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 086.xml"/>
<title>Randomness Requirements for Security</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 911.xml"/>
rd"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="J. Schiller" initials="J." surname="Schiller"/> 554.xml"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="June" year="2005"/> 391.xml"/>
<abstract> <!-- [CMP2018] -->
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC5911">
<front>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and
S/MIME</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="June" year="2010"/>
<abstract>
<t>The Cryptographic Message Syntax (CMS) format, and many associa
ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the
1988 version of ASN.1. This document updates those ASN.1 modules to conform to
the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the f
ormats; this is simply a change to the syntax. This document is not an Internet
Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5911"/>
<seriesInfo name="DOI" value="10.17487/RFC5911"/>
</reference>
<reference anchor="RFC8554">
<front>
<title>Leighton-Micali Hash-Based Signatures</title>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<author fullname="M. Curcio" initials="M." surname="Curcio"/>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
<date month="April" year="2019"/>
<abstract>
<t>This note describes a digital-signature system based on cryptog
raphic hash functions, following the seminal work in this area of Lamport, Diffi
e, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifi
es a one-time signature scheme and a general signature scheme. These systems pro
vide asymmetric authentication without using large integer mathematics and can a
chieve a high security level. They are suitable for compact implementations, are
relatively simple to implement, and are naturally resistant to side-channel att
acks. Unlike many other signature systems, hash-based signatures would still be
secure even if it proves feasible for an attacker to build a quantum computer.</
t>
<t>This document is a product of the Crypto Forum Research Group (
CFRG) in the IRTF. This has been reviewed by many researchers, both in the resea
rch group and outside of it. The Acknowledgements section lists many of them.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="8554"/>
<seriesInfo name="DOI" value="10.17487/RFC8554"/>
</reference>
<reference anchor="RFC8391">
<front>
<title>XMSS: eXtended Merkle Signature Scheme</title>
<author fullname="A. Huelsing" initials="A." surname="Huelsing"/>
<author fullname="D. Butin" initials="D." surname="Butin"/>
<author fullname="S. Gazdag" initials="S." surname="Gazdag"/>
<author fullname="J. Rijneveld" initials="J." surname="Rijneveld"/>
<author fullname="A. Mohaisen" initials="A." surname="Mohaisen"/>
<date month="May" year="2018"/>
<abstract>
<t>This note describes the eXtended Merkle Signature Scheme (XMSS)
, a hash-based digital signature system that is based on existing descriptions i
n scientific literature. This note specifies Winternitz One-Time Signature Plus
(WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a
multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building
block. XMSS provides cryptographic digital signatures without relying on the con
jectured hardness of mathematical problems. Instead, it is proven that it only r
elies on the properties of cryptographic hash functions. XMSS provides strong se
curity guarantees and is even secure when the collision resistance of the underl
ying hash function is broken. It is suitable for compact implementations, is rel
atively simple to implement, and naturally resists side-channel attacks. Unlike
most other signature systems, hash-based signatures can so far withstand known a
ttacks using quantum computers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8391"/>
<seriesInfo name="DOI" value="10.17487/RFC8391"/>
</reference>
<reference anchor="CMP2018" target="https://link.springer.com/chapter/10 .1007/978-3-319-79063-3_8"> <reference anchor="CMP2018" target="https://link.springer.com/chapter/10 .1007/978-3-319-79063-3_8">
<front> <front>
<title>Grafting Trees: A Fault Attack Against the SPHINCS Framework< /title> <title>Grafting Trees: A Fault Attack Against the SPHINCS Framework< /title>
<author initials="L." surname="Castelnovi" fullname="Laurent Casteln ovi"> <author initials="L." surname="Castelnovi" fullname="Laurent Casteln ovi">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Martinelli" fullname="Ange Martinelli "> <author initials="A." surname="Martinelli" fullname="Ange Martinelli ">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Prest" fullname="Thomas Prest"> <author initials="T." surname="Prest" fullname="Thomas Prest">
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="Post-Quantum Cryptography" value="pp. 165-184"/> <refcontent>Post-Quantum Cryptography (PQCrypto 2018), Lecture Notes i
<seriesInfo name="PQCrypto" value="2018"/> n Computer Science, vol. 10786, pp. 165-184</refcontent>
<seriesInfo name="Lecture Notes in Computer Science" value="vol 10786" <seriesInfo name="DOI" value="10.1007/978-3-319-79063-3_8"/>
/>
</reference> </reference>
<!-- [SLoTH] -->
<reference anchor="SLotH" target="https://eprint.iacr.org/2024/367.pdf"> <reference anchor="SLotH" target="https://eprint.iacr.org/2024/367.pdf">
<front> <front>
<title>Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit</title> <title>Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit</title>
<author initials="M.-J." surname="Saarinen" fullname="M-J. Saarinen" > <author initials="M.-J." surname="Saarinen" fullname="M-J. Saarinen" >
<organization/> <organization/>
</author> </author>
<date year="2024"/> <date year="2024"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2024/367</refcontent>
</reference> </reference>
<!-- [Ge2023] -->
<reference anchor="Ge2023" target="https://tches.iacr.org/index.php/TCHE S/article/view/10278/9726"> <reference anchor="Ge2023" target="https://tches.iacr.org/index.php/TCHE S/article/view/10278/9726">
<front> <front>
<title>On Protecting SPHINCS+ Against Fault Attacks</title> <title>On Protecting SPHINCS+ Against Fault Attacks</title>
<author initials="A." surname="Genêt" fullname="Aymeric Genêt"> <author initials="A." surname="Genêt" fullname="Aymeric Genêt">
<organization/> <organization/>
</author> </author>
<date year="2023"/> <date year="2023"/>
</front> </front>
<seriesInfo name="TCHES" value="2023/02"/> <refcontent>IACR Transactions on Cryptographic Hardware and Embedded S ystems, vol. 2023, no. 2, pp. 80-114</refcontent>
<seriesInfo name="DOI" value="10.46586/tches.v2023.i2.80-114"/> <seriesInfo name="DOI" value="10.46586/tches.v2023.i2.80-114"/>
</reference> </reference>
</references> </references>
</references> </references>
<?line 564?> <?line 564?>
<section anchor="appendix-asn1"> <section anchor="appendix-asn1">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t>This ASN.1 Module builds upon the conventions established in <xref targ et="RFC5911"/>.</t> <t>This ASN.1 Module builds upon the conventions established in <xref targ et="RFC5911"/>.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[ <sourcecode type="asn.1" markers="true"><![CDATA[
SLH-DSA-Module-2024 SLH-DSA-Module-2024
{ 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-slh-dsa-2024(TBD1) } id-smime(16) id-mod(0) id-mod-slh-dsa-2024(81) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [RFC5911] FROM AlgorithmInformation-2009 -- in [RFC5911]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
skipping to change at line 976 skipping to change at line 929
sa-slh-dsa-shake-256s.&smimeCaps | sa-slh-dsa-shake-256s.&smimeCaps |
sa-slh-dsa-shake-256f.&smimeCaps, sa-slh-dsa-shake-256f.&smimeCaps,
... } ... }
END END
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to <t>Thanks to
Mike Ounsworth, <contact fullname="Mike Ounsworth"/>,
Tomas Gustavsson, <contact fullname="Tomas Gustavsson"/>,
Daniel Van Geest, <contact fullname="Daniel Van Geest"/>,
Carl Wallace, <contact fullname="Carl Wallace"/>,
Phillip Hallam-Baker, <contact fullname="Phillip Hallam-Baker"/>,
Dieter Bratko, <contact fullname="Dieter Bratko"/>,
Vijay Gurbani, <contact fullname="Vijay Gurbani"/>,
Paul Wouters, and <contact fullname="Paul Wouters"/>, and
Roman Danyliw <contact fullname="Roman Danyliw"/>
for their careful review and constructive comments.</t> for their careful review and constructive comments.</t>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAH51hWcAA909a3PjxpHf51fMyVVn6kJQIvVYSY5z5lLUirFeFrle+1K+
1BAciohAAMYA4tKb9W+5z/cz7v7YdffM4EGCFJeqXJVSldgUMI9+T3dPN+w4
DlOJCEZ/FX4YyDOexKlkXhTTL5W09vdP91tsFLqBmMLrUSzGiePJZOz4Yhop
x50qR0UTL3CVE/mpcpqnzBXJGVfJiLlhoGSgUnXGv8aFv2aRd8Y4T0IXnsyl
+hr+UGGcxHKsCk/m0+KDxEt82Prr90rycMyTieT9q0vnvN/mfe8hEEkaS972
H8LYSyZT7gU0pBPPoyR8iAUA5/JrqZR4gInzIBEfea1z3d/9monhMJZPsPQz
68Hor5lKh1NPKS8MBvMI4Ol1BxdMxFKc8b50Uxg8Z48zeB4kMg5k4pwjrdhI
JDC4td86cvabTvOAMZEmkzA+Yw7XNL1PleKXYap8OQfsw/jhjP/oPXh+tm6d
X1114JWFt/wWXsip8PwzPtGLfPeE75V0G244zbbpu2GS8As/ncQytvt0POWG
QBWVyKnKF1JjPew7F9+XlrkTQaj498B8EYhHT9mV2lPxWxjwD3IIgMVPnisL
6z1GOOs7QWNKy70VCubA9vFQiCADyw/T0dgH6uZrDIX6bpaNbOB0xrxgHMZT
kXhPEgXr/qJzuH9ybH4enTab5ufJ0dGh/XlwSk8713et/eYJ/gSJFPGDBKmd
JEmkzvb2fC94bKgo9oIHGSPAe+5ERLD3XnO/0dzff7N3+ubEOXAOmqfOm9P9
Y/j11xO9kpbWnXfIfZjOB7GUIMttfiFSP+HtJBHuI28/CC9QiZbmu8veTafP
L2LAaRbGjzu0kpUT/G3JdSVAOIOEdwQQwg/CJ49ec5BS2OOqsfjCzmsDHvxa
xACR9P3SpHZj8YWdNJiEU2DPXQxUL84YNArPrHw3NfpKxp5UyJYzM2XnLlSJ
80MqgiSdFtVyvgNkiqIGbx4fOc2Tw51swg96FL7HhbMXV9Il5bwJE6lIMcNp
lAJXQLg9GbgSZzyFPm/uvzk5xmn9qzC5rGaxRO4mDU+4cQOEbg9U9HDv4PhN
IxqNi5xsu670ZSyImdZQDOd8MAv5bTySsUKrdC0eAi9JR5LPwGpwAaYkePAl
vxRqwt/Dq5UsvXb+3OB9IQAaGRTJvPwisyWH8Oc7CT8OqnFL3IlUOWpeMJIf
G9Ek2ht0Lrv9PWS368u9J0/OQKBbb05AnFvHRaxvA+AxkNnVaGsJ/UMmtkVZ
VitRa8+nIA4ugBr8738nC0JXeJjhdbBChghskobWwd5+ywrE+W0PHoJGHh4f
nRwbrJ9wUMNrNU72nWYTpIoFRRNx0bvrN0/2z4rIkiU1vOrjaSjiEa/1L/u7
FaiRgbqB9cJA+GDtFSwCMohCYOcqDv/mA+lOgtAPH+a8dtPrD3bL+gLnwUqV
QSD53fu3KM8ArEO6gQ8BtxLkO/3LtnOQbQzmWcbTNCHoHLCtcqSxQni6HxMJ
o4a+dG7TBPSGX6SBiyNVlcH5/8azpfmqsTyqlutR6JFAA8uP91sne7hdA2c0
YEqZLkADUFs8WQF/Q4pzOBcTQCY/5i0m/0ACtA6BAHjwb0SDox1zdrW0jOLP
46OW/fkmO8aOTo9OzM/jVn7OvdEC8tNxJuILJJzNZg3AowG2by+W7t7Aue92
nJ8aMKFIwD8Z8Hr2gIWzPcnxBLdRv28PVRILN7GeFZhmPfg2kLzW7t80mrsW
1X4kXW/suXoAkBGOdLAOgZmyigW9wXtnUCZp0wGntJqeNJrfSzizpyjuuPIZ
z/GDEf3bvV63c8ZPToA3zTNcj0h2+qUkO92OZEgUDsdVOELbGqc++gdLxHlL
xOnaYfc4jNfedu9362ahDjhVAczwl0Z1YBSJ5rmn0ICnnpqA/C8OO4dh/2Cq
n1ZRHY57h6jOHMcBr1aLEGP2dPVAryCAsBo8QQ0ekgarTHMVGPupbMDZMIHh
EKCksHHClCYjYIeeFQQgT/AUTRwHpvBUIfbFCCJfUFiPn9EJvlkM0UB2czEa
ebhJHWcxkYcOI9wcoImJGVE69GGdRzmHEIfWAAeXRzE4ayM5amhqTL3RyAfP
9isMJOJwlJKFZqyEJv9SNHMSsgqM+adPxux+/szXY8+K2MM8Y59gHq4rRw7w
XiBACYKZQKTUyPkajsfoLiXgOeVQTMMRyn9kf2tSxdJBmOlJg1s8CsCHEflk
iDIEnz56Xmbfj0CeBD13LvAdHHQkJXLhLYP1YcpUfPSm4Jj6MngAxEHxWkdH
4N+BhwnT3s75SI7R2albShc38Ij+TE6jZG6eLUokDwN/vsCvVEeyOcraZww4
LcQWNkGOEj+u+19CZIjfQEtMjAjoPUlfGUJEAiONBIfh4lK4ExNZs4UJfCYB
RncSQhwPYbsVVt5snfChl5Drq7IotXnask9Z/hT52To6XhqPbJUISlIUxVxn
UPGfJBtK2FoojTnBazEVSRF0tYztl1mUDAYA7BYWjJ/RGkXqS4uOU79uxBA5
dtnv710Bt0g9MPQE9QAqsJ+u+/YhBKGfP8NGH2ClMNVxYCANgrQm2IkowUAD
XxH2cb2IzzQF1AmbcSwg3pcwUOjch4XpGTyRQF99pc8jxlC8noSfSo3XgwxQ
wWCmtib61Pr0CT2Lz5/rBRtDBxWrOqiI9Thk3THE6BiilU9hZQ3TdQj+urCW
D2UQZYGTLMARjGIvRk8CQj6KA100VQLctLnytE9WfItyPUKJCCOtkWP+qwlH
XRNAomZ0S7KULRCF+BdDfQKBAx2YgYj6aBciP5wDOiPjVa6gcG+swbOWVPgw
OQY5hPWTZUDAst7/0NklHgDMMR+mnrE+cziZfB+IwNGJR1CGANMjmLBgbjNj
+oxx8IzRuyqd2+GgGZg5gL2BImCA6iyX1/t+u87P8R/dDv2LwoUR/ASytJEC
iZMBWliV1+4QVE9pbQe4THi4jBXIZqJ5OA1jI6qCg4F78oB0QTodAqo5YxgZ
i9qvqYM/6JhNUOjB6pMdAtv3N5MMmE3gkZdwS5uxBHm09AHage6ipiyB9A2f
hDOkcB1nw9pRnI7InoZkoEtMYwWtJ1RizEoF3ODtjQEZ5Buu49FhDAd6dmxp
8wO0qjIjWuAHELd52lMkiScvYRZiiLFz/b4/2Knrf/ObW/p93/3hfe++e46/
IQa8usp+MDOif3n7/uo8/5XP7NxeX3dvzvVkeMpLj9jOdfvnHS0DO7d3g97t
TftqR+tR8VxDAUUSA/aY8YQTG42FUKBqyo29IfwBc9527v7nv5qHoN7/AmYP
ApVTsIX6j5PmGzSMyD+9G52U+k+SdhFFUsS4CugMd0WEaqbqeKwr4F3A0TAA
+f7tL0iZX874H4du1Dz8k3mACJceWpqVHhLNlp8sTdZErHhUsU1GzdLzBUqX
4W3/XPrb0r3w8I//7nsQUznNk3//E0P/0ArXZW7kq/LXt0+YjpWzhcNwvVNt
h07FI5hA468I0K0ZS7ypLEzBHH8Say+1TnkfYOJFiPlBnHMPjA2nvJ8OlUSN
vri97+8ystB8Ao4L5v5xQ3xOq5JPZjxtk0qLYjwLSCUa6L+AgwS2TEVhQNaL
pua+tT6+0Bb6EuwNnQCP4HwEIoazFJOxDVKwOAy1P6LtPb2hqUgZoAroviQv
AIQcAzoAhHbCeY2MlkAahDgMpLNAGE1LjvYeVvtwO+j/gaCnVRhuZ0AgL0J7
N3DaCz20akVDB2bpwMt00POKhCCwy5QYOb6Yg/VjmLOU8SPYSZUONfLm5iSL
GXL24GbDMEmAkzQdHTxt0e0Yw7vE4GdQIwYWUMen1tM06y0CYZgXWJLkS1hv
gn0p2uZoDNCnJs+QpxEzGzZQNBeYQddWv6b6tMw5A2t4cZnmdhVNFVAUcF19
2iwJI4sT6luMjioeCQPzTpPRjGAIsSZeTlCi1QzOngmFGXgbh/ZVu4qg0+Qj
g/VrV8SyiAG4XBnqMWmh95tOLui4op4zK5tYZ/hMUzRfDeSC/GyCuZ45dZHA
QDHUGxjG0jiLVU6NAt8LGBboUo0GDDCIEgPo99y6nQuQk2QsQK42hrXBP0zI
tYRnyNeVQNczd1yDaOBT+vACP8BLtAEBloW0DIaylnvFJSvUbOt4pW8cfrbG
qiOxf0097XxpKTKqk5tXVsvdfiC49vENIJxuEdDbA01CxzSWKe5jolO9CfND
NIhAhDzKa/sY4jyAGINAZiHaSLpAbRhc15y0ks5oUQOgsRGrKAbOCGwWAE3d
0PdFpNATI6IrOIeKiHFaNdF5B0pAANjkiY48jJfRoTGnjmK+90hCvz6MMlRt
VIZwbFUIhzDglThKN3mdCL2mZJ0vRHesGN0VgtkZOEDgZGnDZHFKI/zZ+s/j
wwwR7VQV0gGL0f1yOmAlpW2OpZQjyCZqraCEzdjcKehHNBfs5sPEJFAyT58Z
k4kJAWP79YgP5E4GXvJbvj6OImFdWCQ/SzWy+TmHivxstmMxYcAWsh0CzwsB
joxQ1tOnnBEpCZw2Qz90H7nrRRMNTbN1QkmQOoN9bMqjUfTV7vQx9T1IZC9L
dGiHP/PY8hcEr8gmF/KH5N+SWxbYogiWzKQP8ZU3cpQ/cUYKvJIhBkmllIrv
kSEaQjA8q3Mt02FQkfrJNMZahGrBMPZwih46ADsGajEwDsoksfFlZqfyo8M4
lOBpt0zusYlZBViBwbPvu1lCskVJkgtk20cxjXzYL8fPURNwTx0gtGKxBDsL
bEv0MQrPMHJcYHAR2DKQbC2Q33dhvQpp8qQ/sgusYl+RaosMpEgegQYZ+f33
3zFTHgB/2nmsefv2z93OgPfOuzeD3kWve8/Pzr7ln/jfQtASx1Oh4yWpk9Ra
u1zn2d0QTt14Xmse7wICtZPD/V3M54vAHP615i5/CJ9qzX344aowrh3s8kP+
meF0MCSw9+pdF4A7MNPKHGk5oAar17B7tPZXzx4/P7u5avZpa4O9W6tnb7D3
KrxREJ+ffbh69gZ7H1XOBi3YjOjHa6ZvsPubldM3IvvJmukb7H66avpGhD+o
Fjg9/fndD1DiUEkZeYqUC6nSeZ20yIOplGywtvtg9vFyMDMcEAfznxpH+6fc
BWuqb/+kuVRp6TQrXToUXmpfBoNjidf5ZMKu2z/TnQEmpEwysp/7xUEY3Mso
HXlCH8uwQgcWxBHa1rn3V/jHNzq2em4vk1jhdsOQYmSdOM7NWPRYYRLu3r+9
6nWc77s/a9qam8EizatMiR3mOBynBqHJRc9ioDU6qNnNKu907we4vvO+337X
tU85sPEL6WJoAizPN7+77/3YHnSdVUAY8apAfbwl6uPXjjpahW1Qh3mvH/Xt
uA7zXjnqZI23QJ38uFeP+lZcx3mvGnXrgHwx7mbiPwHyWzDeTHz1yG9l5s3E
fwLkt+T8a7f01vHeBvlXb+tt2LAl8q+N8yaD4WRxDGF72xl0B7w/uO/dvOO1
fu8/urx20OJ/54cn8I/jw91dxkuzdUJ23fTjQ5h5egz/AMsI8yniugmzEjvh
55WTC8nKQnYF0+dR5Hv6DhrjmrVxGH8uDmtsDEMh5bwMRI5/eXt9TZDRpvT8
NpBtNZ9OZRIT4AzLvQzM+QvKKN4J9xGjNQ346dEJAU7hamUS0YaqYZooLOqi
K95KQuGeDO/hA8D8yYvDgEoA6CKBbkDLNa31FXxhLiwwlHocFQvgiiUxyG4d
CisUpM7Uui3iVKB6FVKrKLU9SoUrk21xyvltkPqKru9tdV8nr+lkrK2yCsKR
aUgr1l5q4JbrkKioBUtI8VIiDqd0NWIv12E43tHbbKe+nvhaLd22l9cz5TMj
FuIVUH55YirHRjKS+lo2DLCUg5ID5qZCJED/YZqYS16d+cSUr8ncWr6uG15m
Qy2roNythpIjlCwr3AywEnTNHgaQuimPyJK0K5cr8JVunEo3IFqWPKUz6QuX
66bsAasZlmGhfReqWoPEIc3PhukyN8tOR7OTZa9Nurr8ujDb5G9UfnNDLLTp
7Jxeg8pq6UUi6zI/OO0WLaOSCdYaLCG5cmVz30C5eVvjS9tRIQWDo/SvitJV
Skrs3KH3zf1GC7QVNiqUMuvibJVOpyKen2W5qd4Fr62TMSqJH1x2b7jdq2ao
QW+6V/3uarJ+S+U42YRvsuM6WwuIVNOK3s52twcdghuCHHl41YH2SFc41zkQ
gpoKAhdYKuYolLgYHVW6qG+Kpbl0bUsCRRe3ICD5nXnlvrp6rijRQGkf+x9Q
90XCPNwcq29pPY4WKZZ6RGZJskLkMLMkVLds9UDfghRq30DSPN0jkA9CM0r1
gfBvQAZbSuBpAW9zRZ9UakxJez99smJx1DigIqSsSN1cgeuybdKw4k3VGkVL
1uhSQ5cLswI8iI3wlSmPI0UeWfumbUZWxByM1lujzHKQgcbjWNc6aCgK1zHa
bSiOHp3jSVKyJvjOW7qhYlhtNAO5KhswewVoNJ0vHx+VOGkjTeCoZegJN33J
jxeyvh/OFCjnpzP+pIDt8tud/Z3Pi9idsTMyFwuPDW4an7mpw1rCo2z02ZqD
ZXH5AqVop6lI3ElmMVmZUBUWnteyWkXzFu9f9e3r7nqwMmnOCwawyMEjeYV3
Hrbtu+b+NYNztAAYQW18AHuqaTtvD6fsjjuZea40Cvxbdg5UCMTKk6xMdXQG
xl5AE1jxkhclvnC/m52yKo2iME5MDTzevmatKE8i9kSgGwsyxbGUJWrm5p1X
X0iecbzJxdhr9aDx84NOW3alo2Zr9aDxs4MwAt5k0HMrmQTamb6nxr4Mopqp
PkA3GFR3zczxljOJEPZuXM8EEDebOd5upibZljOf29NMRTGuKJugthMtGSS/
hiOkqda+280D/hfTqvlL47kFNd2xN0RPzkAsLmyXxObOX0zHme/DEmkMB40y
hTO2u7DiTjIvVM7OgbyMoaFdjwX7mx3WSyZ4+Y3W4OxCMKtIKZmJvL2uQIa8
2CJvAFoqsFgoldBOc2WTnR1ZAEEfMHA4PWsg6tUmob7GElRNAeleNQXlt2IK
Cmf1FKPbFTUvqyEzulk1ZyVoRreqa2vGzwjIklyUQ4uS1wfnDhxdqU8fFcCI
VOdmCjEARQ6Z258dAAWhAGc0dD0qUbSvmZI+KFixPK9daOZ6Ls5gpTijFGiv
jS8y6WXLq+u6ULcijimuzwrrHyxHL/3q5YoOHXMn0n3UQagpmqxQUOMaWk1R
WT9lga4035Y/Y5VYkGgCFzJG1iE0Drxkpf10DsNWXHVwmZFt0oTYphzTZK4J
fmOimAGjGm5AHr/tARLiZV/9YcUBFAVpWbIOiRh6Pm6s6/UfCoAp66Zanutg
xnINMYuER6XNC6GXhtKWwDGqHbTDqSAW0x26UBwTTVgERykPO2axqJ7l1b7F
kmfyFbPSiqHxj8e2RpW6pai0c0lFEDWU72LUPC6REnvNdIGyKQM35ZM2Aoet
MED3AjGC4AhnRUqmo9ApjbYbhNihdnd/8w5ix0JxIAqCkjYLhNFPzhtgSuJL
jAKDsNj82Q4w4hHuI6wO3GTgLI6wKJYaG7GJS1fLYmWf9l+Rjrj1csLOZrlI
HhHpOmwkYqrl1jXfmdXR1X9KUh12FEJkS2Lj4SkKmEwowYMpvRgjHmCBKxfW
mk1CX+cayRwaMpYYwICQJItliqP6Y8rMc6mhWDvC5ptFWP1IpboMJBDcYGwO
fEhByzDkt81X+LkpZDgEUU+hNyqcmiod6u9TIACarKaetnPdzwyB/aSLHqPD
DZa76Roa/JwEQGOchmHZD1nO4xQ0G1EEnzwFW+Ma7TddExF9cib1hXbsyWsh
/JHx7iTEHkvgdaZ8IOAm007N1wYjXd0o4ylIB6o1hBXmK07UVKa/iEOW88cs
7SEKRnkox6hO2HwpbOKOLR5QVHqfzCP6sMKa3Qv9g8gbVn5rS7sl8NTFb8+U
OpdLsN7LURogn+dsiDYt8snQ27xiVWIM5N3F2vDr9s+ZtaDEMyvstxr0FbB8
wwoYPZOaQyr5II2jecZqPH7B1wKBuPIe5QwMd53/I0QjyoRYZQ2nlKICpCNA
QH9sQZqPtSmGmzku6HQgfasamCPCT0PpfmN+a80psHzp3BpnuTvq7swwIn3A
mDoezfDcHEn86hmnblOhsud5XfUUjBRYjtpl/xqLcjmpOXaqllpNAdlHbIFc
yAHSPYPWemVS7OTfptgaWU7AaUD01wvyJt+lNEPd9FwEEmUJImx/XkoTrcxx
YriyLl1G3Ql5C+jqdJxuNyJ7T2YZ7wq0Ya7OiKklJHW7vD4UgZMVCBfXqMik
YaiAlA2HFLwob+qBJDLqQRiDdecgOPhxErAnYF9d7OrJ2zSCpe9UfCCHqfiw
nqdRyllGup0BsdUeVbXCFRxHkHLQNusKEdsX8q/VDH8Gf8HAGtLHsbDXjc7G
JHSG0jGzM5v4DKi5D23q9em8wg4fvIbO780KlLEmMneITd6n8AGW634hkwkr
45ffVqwm/JkAb2eu044iv5tasvB0vue3k+YKqY7t9gG2cFHoWiRCzrGsuag6
mYsSka+XN/hoP0P3pCv6MJyD9LR2vHSlhO41nV70Ebksi2uZTf5Ooe8pMHK7
oNzolYT02QyF/UWuF3mmOQKmT7Efh3p7bZODAg9UTE2PU/uup+rMK5pu4wxY
87AsWsgyuk2dF1O92W1qKWtX1cHGz0OS2RCd6HCmjNdm4F4whiyxDtCjlFHx
pCwyKwCagfs8pyPWJclGcGab5FwntkXDEnj9LRxbZSuzEHFuSZgvWO2YFW7w
6CNA7Zv2wpHEP33liUB8ZuzC9Jfoq+prfbwYJW9HdBP7UVuMQuN+ndZknu4H
lNQOlITmCyucTOFCtorXbnvnu1k3iz7GWPH94O15c9e2a5+T8Y9sLLLjjRyY
kiUW8ItoO7oFG5ZdWNX6CJjuATlwRZJXT+z0r3t5eEkuzN5177prEc8TXju8
1oR4/eRwv9FsHhwdnjaaDfj/cWN/13xlaQhOAJK3RLlPXwlDNEeooPnZfHSp
NIa+KKF4GoXZtVn26SWgJRzn+hsn1pnGb5CSk/H7778DjYNG06qCo1d0zOcc
P4GtCLE7B4QWYgVnGI7m2NZjm3hiJUbKq2l8dnn06Cocjf8+rZ3qz3hh+mbq
TSV1/2iy1/btrxIDDMcAxfPuRe+mh18b6PPe9d1Vr9Mb8EH7XZ9KdN523/Vu
GOv+dHd7P+jz9tXVN+ARXdNfsGVe/QQ2vvfupj14f9912lfvbu97g8treIgM
cjrtuz4BeHF/e13IUOYfSnPwQ8NUkGTTp0C3X5guczKEyS85nFJH08EuyPao
hiibT+/CaJPnsr5X7QgJi06gp6YK/4oevY+1NwUy5ZkxJJaoAnK/VTs6Aarx
b1CK4H/8VutKLnoKX7AXdXFt38K1Tf/WC5q3XtC59YK2rRf0bL2gYesF3Vov
adV6SZ/WS5q0XtKh9ZL2rBf0ZhmNzHOm7bylM2+71QeyKb7CB6SvuN2SElQY
tEKN5yZNS3ft+zZ4sO37rrm80E8zo9kHHCo7pXSFZm48YVy23zl/+3N1y+Vn
sgHLqIxfhMr4JaiMt0JlvAIVlN/tUbHF5luhglt/OSo0awUqL+GKLR3fEpVt
uEKzqlAh7d4alawQfBtUaOsvRkXPWoHKC7iSlXVvicoWXNGzllGxh8yWuBSb
cr4cGbv5F2KTTVuFztasKbbZbIvOFzMnm1aNzgtMWbFxZjt0tjBm2bRV6LyI
O9vbM7v5Vuis4s5LTFqxuWUrdLYxatm0Vei8hDsvsGt2863QMdzZvJV8E5fs
uX6bymabF3babNhms3nj+CYO22tCdGX/4Cbu3OtCdAuOWuP4ihBd3Re4iSv4
uhD9co5mBvXVILq2vXsjN/KVofqlTC26mK8K1S83vUX385Whug1XX531XduW
vZHb+spQ3YKrr8ECv6Dl+gX91iaL2v0YFRtDF/97IVilQUVHwznd0ec3NphN
zciSZWD7MH5FAGLueCozsH+3tzhVOc2VL9GkrXm5eiapzZqXq2ba03Hd23Vz
VwNszdbKt2tANmJuK74bjUaeJC+w19yhuiISthDyOfZee1PZEZEqBnTrOdn4
V7qXpEnrmLrROCDXhuM2Wg9JuOG4DdYzsrDpwA1X3AhlIywbDdwMadsAkA8s
SxP9ZN2bc+oQ+HTGVZjGrsRGeGcq4kcZq2/1f/j1M122u49BOPPl6IFKORTO
0JWxcvTtThDu0I27CB7p28nX+BXe2zRQszBOJnU2oP8Y5btUJeJJYVUROxeB
J33+owj4OylVUmcdEfv8g/B94co6u5t4vu9F/BIfTJ23gE8Mszz6ouzbWCSP
YZ396P1NzGHZeAirwRyRwgoh/Rci6K6I3cO+AYe95r43Y6ZcAT8ELmL6OHAs
8ev6+kt62bfwn6hpnLBssP8D43zRfmV3AAA=
<!-- [rfced] FYI - We have added expansions for abbreviations upon
first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
review each expansion in the document carefully to ensure
correctness.
--> -->
</back>
</rfc> </rfc>
 End of changes. 63 change blocks. 
559 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.48.