rfc9814v1.txt | rfc9814.txt | |||
---|---|---|---|---|
skipping to change at line 17 ¶ | skipping to change at line 17 ¶ | |||
Amazon Web Services | Amazon Web Services | |||
B. Westerbaan | B. Westerbaan | |||
Cloudflare | Cloudflare | |||
July 2025 | July 2025 | |||
Use of the SLH-DSA Signature Algorithm in the Cryptographic Message | Use of the SLH-DSA Signature Algorithm in the Cryptographic Message | |||
Syntax (CMS) | Syntax (CMS) | |||
Abstract | Abstract | |||
SLH-DSA is a stateless hash-based signature scheme. This document | SLH-DSA is a stateless hash-based signature algorithm. 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. | algorithm identifier and public key syntax are provided. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
skipping to change at line 98 ¶ | skipping to change at line 98 ¶ | |||
SLH-DSA is a stateless hash-based signature algorithm. Other hash- | SLH-DSA is a stateless hash-based signature algorithm. Other hash- | |||
based signature algorithms are stateful, including Hierarchical | based signature algorithms are stateful, including Hierarchical | |||
Signature System (HSS) / Leighton-Micali Signatures (LMS) [RFC8554] | Signature System (HSS) / Leighton-Micali Signatures (LMS) [RFC8554] | |||
and eXtended Merkle Signature Scheme (XMSS) [RFC8391]. Without the | and eXtended Merkle Signature Scheme (XMSS) [RFC8391]. Without the | |||
need for state kept by the signer, SLH-DSA is much less fragile than | need for state kept by the signer, SLH-DSA is much less fragile than | |||
the stateful hash-based signature algorithms. | the stateful hash-based signature algorithms. | |||
1.1. ASN.1 | 1.1. ASN.1 | |||
CMS values are generated using ASN.1 [X680], using the Basic Encoding | CMS values are generated with ASN.1 [X680] using the Basic Encoding | |||
Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. | Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. | |||
1.2. Motivation | 1.2. Motivation | |||
There have been recent advances in cryptanalysis and advances in the | 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. | threat to widely deployed digital signature algorithms. | |||
If Cryptographically Relevant Quantum Computers (CRQCs) are ever | If Cryptographically Relevant Quantum Computers (CRQCs) are ever | |||
built, they will be able to break many of the public key | built, they will be able to break many of the public key | |||
skipping to change at line 128 ¶ | skipping to change at line 128 ¶ | |||
1.3. Terminology | 1.3. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"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. | |||
2. SLH-DSA Hash-Based Signature Algorithm Overview | 2. SLH-DSA Hash-Based Signature Algorithm Overview | |||
SLH-DSA is a hash-based signature scheme. SLH-DSA makes use of a few | SLH-DSA is a stateless hash-based signature algorithm. SLH-DSA makes | |||
time signature constructions, namely Forest of Random Subsets (FORS) | use of a few time signature constructions, namely Forest of Random | |||
and a hypertree. FORS signs a message with a private key. The | Subsets (FORS) and a hypertree. FORS signs a message with a private | |||
corresponding FORS public keys are the leaves in k binary trees. The | key. The corresponding FORS public keys are the leaves in k binary | |||
roots of these trees are hashed together to form a FORS root. SLH- | trees. The roots of these trees are hashed together to form a FORS | |||
DSA uses a one-time signature scheme called Winternitz One-Time | root. SLH-DSA uses a one-time signature scheme called Winternitz | |||
Signature Plus (WOTS+). The FORS tree roots are signed by a WOTS+ | One-Time Signature Plus (WOTS+). The FORS tree roots are signed by a | |||
one-time signature private key. The corresponding WOTS+ public keys | WOTS+ private key. The corresponding WOTS+ public keys form the | |||
form the leaves in d-layers of Merkle subtrees in the SLH-DSA | leaves in d-layers of Merkle subtrees in the SLH-DSA hypertree. The | |||
hypertree. The bottom layer of that hypertree signs the FORS roots | bottom layer of that hypertree signs the FORS roots with WOTS+. The | |||
with WOTS+. The roots of the bottom Merkle subtrees are then signed | roots of the bottom Merkle subtrees are then signed with WOTS+ and | |||
with WOTS+ and the corresponding WOTS+ public keys form the leaves of | the corresponding WOTS+ public keys form the leaves of the next- | |||
the next-level-up subtree. Subtree roots are consequently signed by | level-up subtree. Subtree roots are consequently signed by their | |||
their corresponding subtree layers until the top subtree is reached. | corresponding subtree layers until the top subtree is reached. The | |||
The top-layer subtree forms the hypertree root, which is trusted at | top-layer subtree forms the hypertree root, which is trusted at the | |||
the verifier. | verifier. | |||
An SLH-DSA signature consists of the randomization string, the FORS | An SLH-DSA signature consists of the randomization string, the FORS | |||
signature, the WOTS+ signature in each layer, and the path to the | signature, the WOTS+ signature in each layer, and the path to the | |||
root of each subtree until the root of the hypertree is reached. | root of each subtree until the root of the hypertree is reached. | |||
An SLH-DSA signature is verified using the FORS signature, the WOTS+ | An SLH-DSA signature is verified using the FORS signature, the WOTS+ | |||
signatures, and the path to the root of each subtree. When reaching | signatures, and the path to the root of each subtree. When reaching | |||
the root of the hypertree, the signature verifies only if it hashes | the root of the hypertree, the signature verifies only if it hashes | |||
to the pre-trusted root of the SLH-DSA hypertree. | to the pre-trusted root of the SLH-DSA hypertree. | |||
SLH-DSA is a stateless hash-based signature algorithm. Stateful | 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) never be reused or the scheme | (generated by using a state index) never be reused or the scheme | |||
loses its security. Although its security decreases, FORS, which is | loses its security. FORS is used at the bottom of the SLH-DSA | |||
used at the bottom of the SLH-DSA hypertree, does not collapse if the | hypertree. Security decreases if the same private key is used to | |||
same private key used to sign two or more different messages like in | sign two or more different messages, but security does not collapse, | |||
stateful hash-based signature schemes. Without the need for state | as is the case in stateful hash-based signature algorithms. Without | |||
kept by the signer to ensure it is not reused, SLH-DSA is much less | the need for state kept by the signer to ensure it is not reused, | |||
fragile. | SLH-DSA is much less fragile. | |||
SLH-DSA was designed to sign up to 2^64 messages and offers three | 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 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+, and the number | layers of subtrees, the Winternitz parameter of WOTS+, and the number | |||
of FORS trees and leaves in each. The parameters for each of the | of FORS trees and leaves in each. The parameters for each of the | |||
security levels were chosen to be at least as secure as a generic | security levels were chosen to be at least as secure as a generic | |||
block cipher of 128, 192, or 256 bits. | block cipher of 128, 192, or 256 bits. | |||
3. SLH-DSA Public Key Identifier | 3. SLH-DSA Public Key Identifier | |||
End of changes. 4 change blocks. | ||||
24 lines changed or deleted | 24 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |