rfc9708.original   rfc9708.txt 
LAMPS Working Group R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9708 Vigil Security
Obsoletes: 8708 (if approved) 19 September 2024 Obsoletes: 8708 January 2025
Intended status: Standards Track Category: Standards Track
Expires: 23 March 2025 ISSN: 2070-1721
Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic
Message Syntax (CMS) Message Syntax (CMS)
draft-ietf-lamps-rfc8708bis-03
Abstract Abstract
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 signature; it is described in RFC 8554. This document obsoletes RFC
8708. 8708.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 March 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9708.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. ASN.1
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Motivation
1.4. Changes Since RFC 8708 . . . . . . . . . . . . . . . . . 3 1.4. Changes Since RFC 8708
2. HSS/LMS Hash-Based Signature Algorithm Overview . . . . . . . 4 2. HSS/LMS Hash-Based Signature Algorithm Overview
2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 2.1. Hierarchical Signature System (HSS)
2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 2.2. Leighton-Micali Signature (LMS)
2.3. Leighton-Micali One-Time Signature (LM-OTS) Algorithm . . 6 2.3. Leighton-Micali One-Time Signature (LM-OTS) Algorithm
3. Algorithm Identifiers and Parameters . . . . . . . . . . . . 7 3. Algorithm Identifiers and Parameters
4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 7 4. HSS/LMS Public Key Identifier
5. Signed-Data Conventions . . . . . . . . . . . . . . . . . . . 8 5. Signed-Data Conventions
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 Appendix A. ASN.1 Module
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address
1. Introduction 1. Introduction
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) [CMS] signature algorithm with the Cryptographic Message Syntax (CMS) [CMS]
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 the Merkle Tree Signature (MTS)
is built on top of the LMS system to efficiently scale for a larger scheme. The HSS is built on top of the LMS system to efficiently
number of signatures. The HSS/LMS algorithm is one form of hash- scale for a larger number of signatures. The HSS/LMS algorithm is
based digital signature, and it is described in [HASHSIG]. The HSS/ one form of hash-based digital signature, and it is described in
LMS signature algorithm can only be used for a fixed number of [HASHSIG]. The HSS/LMS signature algorithm can only be used for a
signing operations with a given private key, and the number of fixed number of signing operations with a given private key, and the
signing operations depends upon the size of the tree. The HSS/LMS number of signing operations depends upon the size of the tree. The
signature algorithm uses small public keys, and it has low HSS/LMS 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 [HASHSIG]. signing time. The HSS/LMS signatures are defined in [HASHSIG].
Currently, parameter sets are defined that use SHA-256 [SHS] and Currently, parameter sets are defined that use SHA-256 [SHS] and
SHAKE256 [SHA3]. SHAKE256 [SHA3].
1.1. ASN.1 1.1. ASN.1
skipping to change at page 3, line 24 skipping to change at line 114
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Motivation 1.3. Motivation
Advances in cryptanalysis [BH2013] and progress in the development of Advances in cryptanalysis [BH2013] and progress in the development of
quantum computers [NAS2019] pose a future threat to widely deployed quantum computers [NAS2019] pose a future threat to widely deployed
digital signature algorithms. As a result, there is a need to digital signature algorithms. As a result, there is a need to
prepare for a day when cryptosystems such as RSA and DSA that depend prepare for a day when cryptosystems such as RSA and DSA that use
on discrete logarithms and factoring cannot be depended upon. discrete logarithms and factoring cannot be depended upon.
If cryptographically relevant quantum computers (CRQCs) are ever If cryptographically relevant quantum computers (CRQCs) are ever
built, these computers will be able to break many of the public key built, they will be able to break many of the public key
cryptosystems currently in use. A post-quantum cryptosystem [PQC] is cryptosystems currently in use. A post-quantum cryptosystem [PQC] is
a system that is secure against quantum computers that have more than a system that is secure against quantum computers that have more than
a trivial number of quantum bits (qubits). It is open to conjecture a trivial number of quantum bits (qubits). It is open to conjecture
when it will be feasible to build such computers; however, RSA, DSA, when it will be feasible to build such computers; however, RSA, DSA,
Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve
Digital Signature Algorithm (EdDSA) are all vulnerable if CRQCs are Digital Signature Algorithm (EdDSA) are all vulnerable if CRQCs are
ever developed. ever developed.
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 second- difficulty of discrete logarithms or factoring, but on a second-
skipping to change at page 3, line 51 skipping to change at line 141
quantum-secure signatures is the protection of software updates, quantum-secure signatures is the protection of software updates,
perhaps using the format described in [FWPROT], to enable deployment perhaps using the format described in [FWPROT], to enable deployment
of software that implements new cryptosystems. of software that implements new cryptosystems.
1.4. Changes Since RFC 8708 1.4. Changes Since RFC 8708
At the time RFC 8708 was published, there were no plans to put an At the time RFC 8708 was published, there were no plans to put an
HSS/LMS public key in a certificate. The expectation was that the HSS/LMS public key in a certificate. The expectation was that the
HSS/LMS public key would be distributed by some other means. Today, HSS/LMS public key would be distributed by some other means. Today,
there are plans to put an HSS/LMS public key in a certificate there are plans to put an HSS/LMS public key in a certificate
[I-D.ietf-lamps-x509-shbs]. The KEY field of the pk-HSS-LMS-HashSig [X.509-S-HBS]. The KEY field of the pk-HSS-LMS-HashSig definition in
definition in the ASN.1 module does not come into play when using the ASN.1 module does not come into play when using HSS/LMS
HSS/LMS signatures in the CMS; however, it needs to be consistent signatures in the CMS; however, it needs to be consistent with the
with the conventions for carrying an HSS/LMS public key in a conventions for carrying an HSS/LMS public key in a certificate. The
certificate. The pk-HSS-LMS-HashSig definition is updated to reflect pk-HSS-LMS-HashSig definition is updated to reflect no ASN.1 wrapping
no ASN.1 wrapping for the public key. These changes resolve for the public key. These changes resolve [Err7960] and [Err7963].
[Err7960] and [Err7963].
Additional HSS/LMS tree sizes have been defined. The list in Additional HSS/LMS tree sizes have been defined. The list in
Section 2.2 was expanded to include the recently defined ones. Section 2.2 was expanded to include the recently defined ones.
Additional LM-OTS Signatures have been defined. The list in Additional LM-OTS Signatures have been defined. The list in
Section 2.3 was expanded to include the recently defined ones. Section 2.3 was expanded to include the recently defined ones.
Provide more detail in Section 4 regarding allowed values in the More detail has been provided in Section 4 regarding allowed values
X.509 certificate key usage extension for an HSS/LMS public key. in the X.509 certificate key usage extension for an HSS/LMS public
key.
2. HSS/LMS Hash-Based Signature Algorithm Overview 2. HSS/LMS Hash-Based Signature Algorithm Overview
Merkle Tree Signatures (MTS) are a method for signing a large but The Merkle Tree Signature (MTS) scheme is a method for signing a
fixed number of messages. An MTS system depends on a one-time large but fixed number of messages. An MTS system depends on a one-
signature method and a collision-resistant hash function. time signature method and a collision-resistant hash function.
This specification makes use of the hash-based algorithm specified in This specification makes use of the hash-based algorithm specified in
[HASHSIG], which is the Leighton and Micali adaptation [LM] of the [HASHSIG], which is the Leighton and Micali adaptation [LM] of the
original Lamport-Diffie-Winternitz-Merkle one-time signature system original Lamport-Diffie-Winternitz-Merkle one-time signature system
[M1979] [M1987] [M1989a] [M1989b]. [M1979] [M1987] [M1989a] [M1989b].
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 [HASHSIG] uses only the SHA-256 one-way hash algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash
function [SHS], but it establishes an IANA registry [IANA-LMS] to function [SHS], but it establishes an IANA registry [IANA-LMS] to
skipping to change at page 5, line 50 skipping to change at line 228
Each tree in the system specified in [HASHSIG] uses the Leighton- Each tree in the system specified in [HASHSIG] uses the Leighton-
Micali Signature (LMS) system. LMS systems have two parameters. The 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 [HASHSIG] specification supports levels in the tree minus one. The [HASHSIG] specification supports
five values for this parameter: h=5, h=10, h=15, h=20, and h=25. 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, is the There are 2^h leaves in the tree. The second parameter, m, is the
number of bytes output by the hash function, and it is the amount of number of bytes output by the hash function, and it is the amount of
data associated with each node in the tree. The [HASHSIG] data associated with each node in the tree. The [HASHSIG]
specification supports the SHA-256 hash function [SHS], with m=32. specification supports the SHA-256 hash function [SHS], with m=32.
Additional, LMS Signature parameter sets have been registered at Additional LMS Signature parameter sets have been registered at
[IANA-LMS]. [IANA-LMS].
As specified in [HASHSIG], the LMS public key consists of four As specified in [HASHSIG], the LMS public key consists of four
elements: the lms_algorithm_type from the list above, the otstype to elements: the lms_algorithm_type from the list above, the otstype to
identify the Leighton-Micali One-Time Signature (LM-OTS) type as identify the Leighton-Micali One-Time Signature (LM-OTS) type as
discussed in Section 2.3, the private key identifier (I) as described discussed in Section 2.3, the private key identifier (I) as described
in Section 5.3 of [HASHSIG], and the m-byte string associated with in Section 5.3 of [HASHSIG], and the m-byte string associated with
the root node of the tree (T[1]). the root node of the tree (T[1]).
The LMS public key can be summarized as: The LMS public key can be summarized as:
skipping to change at page 7, line 10 skipping to change at line 285
p: The number of n-byte string elements that make up the LM-OTS p: The number of n-byte string elements that make up the LM-OTS
signature value. signature value.
ls: The number of bits that are left-shifted in the final step of ls: The number of bits that are left-shifted in the final step of
the checksum function, which is defined in Section 4.4 of the checksum function, which is defined in Section 4.4 of
[HASHSIG]. [HASHSIG].
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 Appendix B of [HASHSIG]. n and w, as described in Appendix B of [HASHSIG].
The [HASHSIG] specifies four LM-OTS variants. Additional, LM-OTS [HASHSIG] specifies four LM-OTS variants (as listed in Table 1 of
Signature parameter sets have been registered at [IANA-LMS]. [HASHSIG]). Additional LM-OTS Signature parameter sets have been
registered at [IANA-LMS].
Signing involves the generation of C, an n-byte random value. Signing involves the generation of C, an n-byte random value.
The LM-OTS signature value can be summarized as the identifier of the The LM-OTS signature value can be summarized as the identifier of the
LM-OTS variant, the random value, and a sequence of hash values (y[0] LM-OTS variant, the random value, and a sequence of hash values (y[0]
through y[p-1]) that correspond to the elements of the public key, as through y[p-1]) that correspond to the elements of the public key, as
described in Section 4.5 of [HASHSIG]: described in Section 4.5 of [HASHSIG]:
u32str(otstype) || C || y[0] || ... || y[p-1] u32str(otstype) || C || y[0] || ... || y[p-1]
skipping to change at page 8, line 12 skipping to change at line 333
hss-lms-hashsig object identifier, and the parameters field MUST be hss-lms-hashsig object identifier, and the parameters field MUST be
absent. absent.
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of a certification authority (CA) X.509 certificate [RFC5280], field of a certification authority (CA) X.509 certificate [RFC5280],
the certificate key usage extension MUST contain at least one of the the certificate key usage extension MUST contain at least one of the
following values: digitalSignature, nonRepudiation, keyCertSign, and following values: digitalSignature, nonRepudiation, keyCertSign, and
cRLSign. However, it MUST NOT contain other values. cRLSign. However, it MUST NOT contain other values.
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of an end entity X.509 certificate [RFC5280], the certificate field of an end-entity X.509 certificate [RFC5280], the certificate
key usage extension MUST contain at least one of the following: key usage extension MUST contain at least one of the following:
digitalSignature or nonRepudiation. However, it MUST NOT contain digitalSignature, nonRepudiation, or cRLSign. However, it MUST NOT
other values. contain other values.
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
skipping to change at page 9, line 22 skipping to change at line 392
HSS_LMS_Sign(DER(SignedAttributes)) HSS_LMS_Sign(DER(SignedAttributes))
When using [HASHSIG], the fields in the SignerInfo are used as When using [HASHSIG], the fields in the SignerInfo are used as
follows: follows:
* digestAlgorithm MUST contain the one-way hash function used in the * digestAlgorithm MUST contain the one-way hash function used in the
HSS/LMS tree. For convenience, the AlgorithmIdentifier for HSS/LMS tree. For convenience, the AlgorithmIdentifier for
SHA-256 from [PKIXASN1] and the AlgorithmIdentifier for SHAKE256 SHA-256 from [PKIXASN1] and the AlgorithmIdentifier for SHAKE256
from [RFC8692] are repeated here: from [RFC8692] are repeated here:
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 }
* signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the * signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the
algorithm parameters field MUST be absent. algorithm parameters field MUST be absent.
* signature contains the single HSS/LMS signature value resulting * signature contains the single HSS/LMS signature value resulting
from the signing operation as specified in [HASHSIG]. from the signing operation as specified in [HASHSIG].
6. Security Considerations 6. Security Considerations
Implementations MUST protect the private keys. Compromise of the Implementations MUST protect the private keys. Compromise of the
skipping to change at page 10, line 24 skipping to change at line 442
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 searching the resulting small set of possibilities, rather than
brute-force searching the whole key space. The generation of quality brute-force searching the whole key space. The generation of quality
random numbers is difficult, and [RFC4086] offers important guidance random numbers is difficult, and [RFC4086] offers important guidance
in this area. in this area.
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 number numbers. While the consequences of an inadequate PRNG to generate
generator (PRNG) to generate these values is much less severe than in these values is much less severe than in the generation of private
the generation of private keys, the guidance in [RFC4086] remains keys, the guidance in [RFC4086] remains important.
important.
When computing signatures, the same hash function SHOULD be used to When computing signatures, the same hash function SHOULD be used to
compute the message digest of the content and the signed attributes, compute the message digest of the content and the signed attributes,
if they are present. if they are present.
7. IANA Considerations 7. IANA Considerations
In the "SMI Security for S/MIME Module Identifier In the "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)" registry, IANA is requested to change the (1.2.840.113549.1.9.16.0)" registry, IANA has changed the reference
reference for value 64 to point to this document. for value 64 to this document.
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 this
point to this document. document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation [ASN1-B] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", One (ASN.1): Specification of basic notation", ITU-T
ITU-T Recommendation X.680, August 2015. Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680-202102-I>.
[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules: [ASN1-E] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, August 2015. (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I>.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
April 2019, <https://www.rfc-editor.org/info/rfc8554>. April 2019, <https://www.rfc-editor.org/info/rfc8554>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 11, line 44 skipping to change at line 510
Infrastructure: Additional Algorithm Identifiers for Infrastructure: Additional Algorithm Identifiers for
RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
DOI 10.17487/RFC8692, December 2019, DOI 10.17487/RFC8692, December 2019,
<https://www.rfc-editor.org/info/rfc8692>. <https://www.rfc-editor.org/info/rfc8692>.
[SHA3] National Institute of Standards and Technology, "SHA-3 [SHA3] National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output Standard: Permutation-Based Hash and Extendable-Output
Functions", DOI 10.6028/NIST.FIPS.202, FIPS PUB 202, Functions", DOI 10.6028/NIST.FIPS.202, FIPS PUB 202,
August 2015, <https://doi.org/10.6028/NIST.FIPS.202>. August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
[SHS] National Institute of Standards and Technology (NIST), [SHS] National Institute of Standards and Technology, "Secure
"Secure Hash Standard (SHS)", FIPS PUB 180-4, Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015, DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>. <https://doi.org/10.6028/NIST.FIPS.180-4>.
8.2. Informative References 8.2. Informative References
[BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The [BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The
Factoring Dead: Preparing for the Cryptopocalypse", August Factoring Dead: Preparing for the Cryptopocalypse", August
2013, <https://media.blackhat.com/us-13/us-13-Stamos-The- 2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-
Factoring-Dead.pdf>. Factoring-Dead.pdf>.
skipping to change at page 12, line 21 skipping to change at line 533
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010, DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/info/rfc5911>. <https://www.rfc-editor.org/info/rfc5911>.
[CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules [CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268, Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011, DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>. <https://www.rfc-editor.org/info/rfc6268>.
[Err7960] RFC Errata Report 7960, RFC 8708, 28 May 2024, [Err7960] RFC Errata, Erratum ID 7960, RFC 8708,
<https://www.rfc-editor.org/errata/eid7960>. <https://www.rfc-editor.org/errata/eid7960>.
[Err7963] RFC Errata Report 7963, RFC 8708, 29 May 2024, [Err7963] RFC Errata, Erratum ID 7963, RFC 8708,
<https://www.rfc-editor.org/errata/eid7963>. <https://www.rfc-editor.org/errata/eid7963>.
[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to [FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005, DOI 10.17487/RFC4108, August 2005,
<https://www.rfc-editor.org/info/rfc4108>. <https://www.rfc-editor.org/info/rfc4108>.
[I-D.ietf-lamps-x509-shbs]
Van Geest, D., Bashiri, K., Fluhrer, S., Gazdag, S., and
S. Kousidis, "Internet X.509 Public Key Infrastructure:
Algorithm Identifiers for HSS and XMSS", Work in Progress,
Internet-Draft, draft-ietf-lamps-x509-shbs-04, 25 July
2024, <https://datatracker.ietf.org/doc/draft-ietf-lamps-
x509-shbs-04>.
[IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)", [IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
<https://www.iana.org/assignments/leighton-micali- <https://www.iana.org/assignments/leighton-micali-
signatures/>. signatures/>.
[LM] Leighton, T. and S. Micali, "Large provably fast and [LM] Leighton, T. and S. Micali, "Large provably fast and
secure digital signature schemes based on secure hash secure digital signature schemes based on secure hash
functions", U.S. Patent 5,432,852, July 1995. functions", U.S. Patent 5,432,852, July 1995.
[M1979] Merkle, R., "Secrecy, Authentication, and Public Key [M1979] Merkle, R., "Secrecy, Authentication, and Public Key
Systems", Technical Report No. 1979-1, Information Systems Systems", Information Systems Laboratory, Stanford
Laboratory, Stanford University, 1979. University, Technical Report No. 1979-1, 1979.
[M1987] Merkle, R., "A Digital Signature Based on a Conventional [M1987] Merkle, R., "A Digital Signature Based on a Conventional
Encryption Function", Advances in Cryptology -- CRYPTO '87 Encryption Function", Advances in Cryptology -- CRYPTO '87
Proceedings, Lecture Notes in Computer Science Vol. 293, Proceedings, Lecture Notes in Computer Science, Vol. 293,
DOI 10.1007/3-540-48184-2_32, 1988, DOI 10.1007/3-540-48184-2_32, 1988,
<https://doi.org/10.1007/3-540-48184-2_32>. <https://doi.org/10.1007/3-540-48184-2_32>.
[M1989a] Merkle, R., "A Certified Digital Signature", Advances in [M1989a] Merkle, R., "A Certified Digital Signature", Advances in
Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in
Computer Science Vol. 435, DOI 10.1007/0-387-34805-0_21, Computer Science, Vol. 435, DOI 10.1007/0-387-34805-0_21,
1990, <https://doi.org/10.1007/0-387-34805-0_21>. 1990, <https://doi.org/10.1007/0-387-34805-0_21>.
[M1989b] Merkle, R., "One Way Hash Functions and DES", Advances in [M1989b] Merkle, R., "One Way Hash Functions and DES", Advances in
Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in
Computer Science Vol. 435, DOI 10.1007/0-387-34805-0_40, Computer Science, Vol. 435, DOI 10.1007/0-387-34805-0_40,
1990, <https://doi.org/10.1007/0-387-34805-0_40>. 1990, <https://doi.org/10.1007/0-387-34805-0_40>.
[NAS2019] National Academies of Sciences, Engineering, and Medicine, [NAS2019] National Academies of Sciences, Engineering, and Medicine,
"Quantum Computing: Progress and Prospects", The National "Quantum Computing: Progress and Prospects", The National
Academies Press, DOI 10.17226/25196, 2019, Academies Press, DOI 10.17226/25196, 2019,
<https://doi.org/10.17226/25196>. <https://doi.org/10.17226/25196>.
[PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[PQC] Bernstein, D., "Introduction to post-quantum [PQC] Bernstein, D., "Introduction to post-quantum
cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009, cryptography", Post-Quantum Cryptography, Springer, pp.
1-14, DOI 10.1007/978-3-540-88702-7_1, 2009,
<https://doi.org/10.1007/978-3-540-88702-7_1>. <https://doi.org/10.1007/978-3-540-88702-7_1>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[X.509-S-HBS]
Van Geest, D., Bashiri, K., Fluhrer, S., Gazdag, S., and
S. Kousidis, "Use of the HSS and XMSS Hash-Based Signature
Algorithms in Internet X.509 Public Key Infrastructure",
Work in Progress, Internet-Draft, draft-ietf-lamps-x509-
shbs-13, 12 December 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
x509-shbs-13>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
The ASN.1 module in this appendix builds upon the modules in The ASN.1 module in this appendix builds upon the modules in
[CMSASN1] and [CMSASN1U]. [CMSASN1] and [CMSASN1U].
<CODE BEGINS> <CODE BEGINS>
MTS-HashSig-2013 MTS-HashSig-2013
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
 End of changes. 38 change blocks. 
117 lines changed or deleted 119 lines changed or added

This html diff was produced by rfcdiff 1.48.