Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-sphincs-plus-07
| Document | Type | Active Internet-Draft (lamps WG) | |
|---|---|---|---|
| Authors | Russ Housley , Scott Fluhrer , Panos Kampanakis , Bas Westerbaan | ||
| Last updated | 2024-07-05 | ||
| Replaces | draft-housley-lamps-cms-sphincs-plus | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lamps-cms-sphincs-plus-07
Network Working Group R. Housley
Internet-Draft Vigil Security
Intended status: Standards Track S. Fluhrer
Expires: 6 January 2025 Cisco Systems
P. Kampanakis
Amazon Web Services
B. Westerbaan
Cloudflare
5 July 2024
Use of the SLH-DSA Signature Algorithm in the Cryptographic Message
Syntax (CMS)
draft-ietf-lamps-cms-sphincs-plus-07
Abstract
SLH-DSA is a stateless hash-based signature scheme. This document
specifies the conventions for using the SLH-DSA signature algorithm
with the Cryptographic Message Syntax (CMS). In addition, the
algorithm identifier and public key syntax are provided.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Housley, et al. Expires 6 January 2025 [Page 1]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. SLH-DSA Hash-based Signature Algorithm Overview . . . . . . . 3
3. SLH-DSA Public Key Identifier . . . . . . . . . . . . . . . . 4
4. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Operational Considerations . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Appendix: ASN.1 Module . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
NOTICE: This document will be adjusted to match the final FIPS 205
specification that is published by NIST. Until that happens, just
about everything in this document is likely to change.
This document specifies the conventions for using the SLH-DSA hash-
based signature algorithm [FIPS205-IPD] with the Cryptographic
Message Syntax (CMS) [RFC5652] signed-data content type.
The final version of [FIPS205-IPD] is expected to define two
signature modes: pure mode and predigest mode. This document only
specifies the use of pure mode with the CMS signed-data content type.
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, and 256 bits of security. A separate algorithm
identifier has been assigned for SLH-DSA at each of these security
levels.
SLH-DSA is a stateless hash-based signature algorithm. Other hash-
based signature algorithms are stateful, including HSS/LMS [RFC8554]
and XMSS [RFC8391]. Without the need for state kept by the signer,
SLH-DSA is much less fragile.
Housley, et al. Expires 6 January 2025 [Page 2]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
1.1. ASN.1
CMS values are generated using ASN.1 [X680], using the Basic Encoding
Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
1.2. Motivation
There have been recent advances in cryptanalysis and advances in the
development of quantum computers. Each of these advances pose a
threat to widely deployed digital signature.
If large-scale quantum computers are ever built, they 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 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 such quantum computers; however, it
is prudent to use cryptographic algorithms that remain secure if a
large-scale quantum computer is invented. SLH-DSA is a PQC signature
algorithm.
One use of a PQC signature algoritm is the protection of software
updates, perhaps using the format described in [RFC4108], to enable
deployment of software that implements other new PQC algorithms for
key management and confidentiality.
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SLH-DSA Hash-based Signature Algorithm Overview
SLH-DSA is a hash-based signature scheme which consists of a few time
signature construction, namely Forest of Random Subsets (FORS) and a
hypertree. FORS signs a message with a private key. The
corresponding FORS public keys are the leaves in k binary trees. 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 tree
roots are signed by a WOTS+ one-time signature private key. The
corresponding WOTS+ public keys form the leaves in d-layers of Merkle
subtrees in the SLH-DSA hypertree. The bottom layer of that
hypertree signs the FORS roots with WOTS+. The root of the bottom
Merkle subtrees are then signed with WOTS+ and the corresponding
WOTS+ public keys form the leaves of the next level up subtree.
Housley, et al. Expires 6 January 2025 [Page 3]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
Subtree roots are consequently signed by their corresponding subtree
layers until we reach the top subtree. The top layer subtree forms
the hypertree root which is trusted at the verifier.
A SLH-DSA signature consists of the randomization string, the FORS
signature, the WOTS+ signature in each layer, and the path to the
root of each subtree until the root of the hypertree is reached.
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 the root of the hypertree, the signature verifies only if it
hashes to the pre-trusted root of the SLH-DSA hypertree.
SLH-DSA is a stateless hash-based signature algorithm. Stateful
hash-based signature schemes require that the WOTS+ private key
(generated by using a state index) is never reused or the scheme
loses it security. 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. Without the need for state
kept by the signer to ensure it is not reused, SLH-DSA is much less
fragile.
SLH-DSA was designed to sign up to 2^64 messages and offers three
security levels. The parameters of the SLH-DSA hypertree include the
security parameter, the hash function, the tree height, the number of
layers of subtrees, the Winternitz parameter of WOTS+, the number of
FORS trees and leaves in each. The parameters for each of the
security levels were chosen to provide 128 bits of security, 192 bits
of security, and 256 bits of security.
3. SLH-DSA Public Key Identifier
The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the
twelve id-alg-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 SHA-256 [FIPS180] or
SHAKE256 [FIPS202]. For example, id-alg-slh-dsa-shake-256s
represents the 256-bit security level, the small version of the
algorithm, and the use of SHAKE256. The parameters field of the
AlgorithmIdentifier for the SLH-DSA public key MUST be absent.
Housley, et al. Expires 6 January 2025 [Page 4]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) 4 }
sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }
id-alg-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs TBD }
When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
field of an X.509 certificate [RFC5280], the certificate key usage
extension MAY contain digitalSignature, nonRepudiation, keyCertSign,
and cRLSign; the certificate key usage extension MUST NOT contain
other values.
pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-128s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-128f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-128f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
Housley, et al. Expires 6 January 2025 [Page 5]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
pk-slh-dsa-sha2-192s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-192s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-192f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-192f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-256s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-256s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-256f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-256f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-128s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-128s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-128f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-128f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-192s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-192s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
Housley, et al. Expires 6 January 2025 [Page 6]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
pk-slh-dsa-shake-192f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-192f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-256s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-256s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-256f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-256f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
SLH-DSA-PublicKey ::= OCTET STRING
SLH-DSA-PrivateKey ::= OCTET STRING
NOTE: The values for these object identifiers will be assigned by
NIST. Once assigned, they will be added to a future revision of this
document.
No additional encoding of the SLH-DSA public key value is applied in
the SubjectPublicKeyInfo field of an X.509 certificate [RFC5280].
However, whenever the SLH-DSA public key value appears outside of a
certificate, it MAY be encoded as an OCTET STRING.
No additional encoding of the SLH-DSA private key value is applied in
the PrivateKeyInfo field of an Asymmetric Key Package [RFC5958].
However, whenever the SLH-DSA private key value appears outside of a
Asymmetric Key Package, it MAY be encoded as an OCTET STRING.
4. Signed-data Conventions
As specified in CMS [RFC5652], the digital signature is produced from
the message digest and the signer's private key. The signature is
computed over different values depending on whether signed attributes
are absent or present.
Housley, et al. Expires 6 January 2025 [Page 7]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
When signed attributes are absent, the SLH-DSA (pure mode) signature
is computed over the content. When signed attributes are present, a
hash is computed over the content using the same hash function that
is used in the SLH-DSA tree. The signed attributes MUST include a
content-type attribute and a message-digest 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 of signed
attributes. The SLH-DSA signature generation operation is called
slh_sign; see Section 9.2 of [FIPS205-IPD]. In summary:
IF (signed attributes are absent)
THEN slh_sign(content)
ELSE message-digest attribute = Hash(content);
slh_sign(DER(SignedAttributes))
In some implementations, performance may be significantly improved by
signing and verifying DER(SignedAttributes) when the content is
large. That is, passing an entire large message content to the
signing function or the signature validation function can have an
impact on performance. When the signed attributes are present,
Section 5.3 of [RFC5652] requires the inclusion of the content-type
attribute and the message-digest attribute. Other attributes can
also be included.
When using SLH-DSA, the fields in the SignerInfo are used as follows:
digestAlgorithm:
The digestAlgorithm MUST identify a one-way hash function. To
ensure collision resistance, the identified hash function SHOULD
produce a hash value that is at least twice the size of the hash
function used in the SLH-DSA tree. The following hash functions
defined in [FIPS180] and [FIPS202] are RECOMMENDED for use with
the variants of SLH-DSA:
id-alg-slh-dsa-sha2-128s: SHA-256
id-alg-slh-dsa-sha2-128f: SHA-256
id-alg-slh-dsa-sha2-192s: SHA-512
id-alg-slh-dsa-sha2-192f: SHA-512
id-alg-slh-dsa-sha2-256s: SHA-512
id-alg-slh-dsa-sha2-256f: SHA-512
id-alg-slh-dsa-shake-128s: SHAKE128
id-alg-slh-dsa-shake-128f: SHAKE128
id-alg-slh-dsa-shake-192s: SHAKE256
id-alg-slh-dsa-shake-192f: SHAKE256
id-alg-slh-dsa-shake-256s: SHAKE256
id-alg-slh-dsa-shake-256f: SHAKE256
signatureAlgorithm:
Housley, et al. Expires 6 January 2025 [Page 8]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
The signatureAlgorithm MUST contain one of the the SLH-DSA
algorithm identifiers, and the algorithm parameters field MUST be
absent. The algorithm identifier MUST be one of the following:
id-alg-slh-dsa-sha2-128s, id-alg-slh-dsa-sha2-128f,
id-alg-slh-dsa-sha2-192s, id-alg-slh-dsa-sha2-192f,
id-alg-slh-dsa-sha2-256s, id-alg-slh-dsa-sha2-256f,
id-alg-slh-dsa-shake-128s, id-alg-slh-dsa-shake-128f,
id-alg-slh-dsa-shake-192s, id-alg-slh-dsa-shake-192f,
id-alg-slh-dsa-shake-256s, id-alg-slh-dsa-shake-256f.
signature:
The signature contains the signature value resulting from the SLH-
DSA signing operation with the parameters associated with the
selected signatureAlgorithm. The SLH-DSA signing operation and
the signature verification operation are specified in
[FIPS205-IPD].
5. Security Considerations
Implementations MUST protect the private keys. Compromise of the
private keys may result in the ability to forge signatures.
When generating an SLH-DSA key pair, an implementation MUST generate
each key pair independently of all other key pairs in the SLH-DSA
hypertree.
A SLH-DSA tree MUST NOT be used for more than 2^64 signing
operations.
The generation of private keys relies on random numbers. The use of
inadequate pseudo-random number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute
force searching the whole key space. The generation of quality
random numbers is difficult, and [RFC4086] offers important guidance
in this area.
When computing signatures, the same hash function SHOULD be used to
compute the message digest of the content and the signed attributes,
if they are present.
Housley, et al. Expires 6 January 2025 [Page 9]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
When computing signatures, implementations SHOULD include protections
against fault injection attacks [CMP2018]. Protections against these
attacks include signature verification prior to releasing the
signature value to confirm that no error injected and generating the
signature a few times to confirm that the same signature value is
produced each time.
6. Operational Considerations
If slh_sign is implemented in a hardware device such as hardware
security module (HSM) or portable cryptographic token,
implementations might want to avoid is sending the full content to
the device. By including signed attributes, which necessarily
include the message-digest attribute and the content-type attribute
as described in Section 5.3 of [RFC5652], the much smaller set of
signed attributes are sent to the device for signing.
7. IANA Considerations
For the ASN.1 Module in the Appendix of this document, IANA is
requested to assign an object identifier (OID) for the module
identifier (TBD1) with a Description of "id-mod-slh-dsa-2023". The
OID for the module should be allocated in the "SMI Security for PKIX
Module Identifier" registry (1.3.6.1.5.5.7.0).
8. Acknowledgements
Thanks to Mike Ounsworth and Tomas Gustavsson for their careful
review and constructive comments.
9. References
9.1. Normative References
[FIPS205-IPD]
National Institute of Standards and Technology (NIST),
"Stateless Hash-Based Digital Signature Standard", FIPS
PUB 205 (Initial Public Draft), 24 August 2023,
<https://doi.org/10.6028/NIST.FIPS.205.ipd>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Housley, et al. Expires 6 January 2025 [Page 10]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/rfc/rfc5958>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
9.2. Informative References
[CMP2018] Castelnovi, L., A, Martinelli, and T. Prest, "Grafting
Trees: A Fault Attack Against the SPHINCS Framework",
Post-Quantum Cryptography pp. 165-184, PQCrypto 2018,
Lecture Notes in Computer Science vol 10786, 2018,
<https://link.springer.com/
chapter/10.1007/978-3-319-79063-3_8>.
[FIPS180] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015.
[FIPS202] National Institute of Standards and Technology (NIST),
"SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions", FIPS PUB 202, August 2015.
Housley, et al. Expires 6 January 2025 [Page 11]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005,
<https://www.rfc-editor.org/rfc/rfc4108>.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/rfc/rfc5911>.
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/rfc/rfc8391>.
[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
April 2019, <https://www.rfc-editor.org/rfc/rfc8554>.
Appendix A. Appendix: ASN.1 Module
This ASN.1 Module builds upon the conventions established in
[RFC5911].
<CODE BEGINS>
SLH-DSA-Module-2024
{ 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) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [RFC5911]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ;
--
-- Object Identifiers
--
Housley, et al. Expires 6 January 2025 [Page 12]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) 4 }
sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }
id-alg-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs TBD }
id-alg-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs TBD }
--
-- Signature Algorithm, Public Key, and Private Key
--
sa-slh-dsa-sha2-128s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-sha2-128s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-128s }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-sha2-128s } }
sa-slh-dsa-sha2-128f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-sha2-128f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-128f }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-sha2-128f } }
sa-slh-dsa-sha2-192s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-sha2-192s
Housley, et al. Expires 6 January 2025 [Page 13]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-192s }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-sha2-192s } }
sa-slh-dsa-sha2-192f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-sha2-192f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-192f }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-sha2-192f } }
sa-slh-dsa-sha2-256s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-sha2-256s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-256s }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-sha2-256s } }
sa-slh-dsa-sha2-256f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-sha2-256f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-256f }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-sha2-256f } }
sa-slh-dsa-shake-128s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-shake-128s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-128s }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-shake-128s } }
sa-slh-dsa-shake-128f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-shake-128f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-128f }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-shake-128f } }
sa-slh-dsa-shake-192s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-shake-192s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-192s }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-shake-192s } }
sa-slh-dsa-shake-192f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-shake-192f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-192f }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-shake-192f } }
sa-slh-dsa-shake-256s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-shake-256s
Housley, et al. Expires 6 January 2025 [Page 14]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-256s }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-shake-256s } }
sa-slh-dsa-shake-256f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-slh-dsa-shake-256f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-256f }
SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-shake-256f } }
pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-128s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-128f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-128f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-192s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-192s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-192f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-192f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-256s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-256s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-256f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-sha2-256f
-- KEY no ASN.1 wrapping --
Housley, et al. Expires 6 January 2025 [Page 15]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-128s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-128s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-128f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-128f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-192s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-192s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-192f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-192f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-256s PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-256s
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-shake-256f PUBLIC-KEY ::= {
IDENTIFIER id-alg-slh-dsa-shake-256f
-- KEY no ASN.1 wrapping --
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- }
SLH-DSA-PublicKey ::= OCTET STRING
Housley, et al. Expires 6 January 2025 [Page 16]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
SLH-DSA-PrivateKey ::= OCTET STRING
--
-- Expand the signature algorithm set used by CMS [RFC5911]
--
SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
{ sa-slh-dsa-sha2-128s |
sa-slh-dsa-sha2-128f |
sa-slh-dsa-sha2-192s |
sa-slh-dsa-sha2-192f |
sa-slh-dsa-sha2-256s |
sa-slh-dsa-sha2-256f |
sa-slh-dsa-shake-128s |
sa-slh-dsa-shake-128f |
sa-slh-dsa-shake-192s |
sa-slh-dsa-shake-192f |
sa-slh-dsa-shake-256s |
sa-slh-dsa-shake-256f,
... }
--
-- Expand the S/MIME capabilities set used by CMS [RFC5911]
--
SMimeCaps SMIME-CAPS ::=
{ sa-slh-dsa-sha2-128s.&smimeCaps |
sa-slh-dsa-sha2-128f.&smimeCaps |
sa-slh-dsa-sha2-192s.&smimeCaps |
sa-slh-dsa-sha2-192f.&smimeCaps |
sa-slh-dsa-sha2-256s.&smimeCaps |
sa-slh-dsa-sha2-256f.&smimeCaps |
sa-slh-dsa-shake-128s.&smimeCaps |
sa-slh-dsa-shake-128f.&smimeCaps |
sa-slh-dsa-shake-192s.&smimeCaps |
sa-slh-dsa-shake-192f.&smimeCaps |
sa-slh-dsa-shake-256s.&smimeCaps |
sa-slh-dsa-shake-256f.&smimeCaps,
... }
END
<CODE ENDS>
Authors' Addresses
Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Housley, et al. Expires 6 January 2025 [Page 17]
Internet-Draft SLH-DSA Signature Algorithm in CMS July 2024
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Panos Kampanakis
Amazon Web Services
Email: kpanos@amazon.com
Bas Westerbaan
Cloudflare
Email: bas@westerbaan.name
Housley, et al. Expires 6 January 2025 [Page 18]