Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9814 Vigil Security
Category: Standards Track S. Fluhrer
ISSN: 2070-1721 Cisco Systems
P. Kampanakis
Amazon Web Services
B. Westerbaan
Cloudflare
July 2025
SLH-DSA is a stateless hash-based signature algorithm. 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.
SLH-DSAは、ステートレスハッシュベースの署名アルゴリズムです。このドキュメントは、暗号化メッセージ構文（CMS）でSLH-DSA署名アルゴリズムを使用するための規則を指定します。さらに、アルゴリズム識別子と公開キーの構文が提供されます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
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/rfc9814.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9814で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. ASN.1
1.2. Motivation
1.3. Terminology
2. SLH-DSA Hash-Based Signature Algorithm Overview
3. SLH-DSA Public Key Identifier
4. Signed-Data Conventions
5. Security Considerations
6. Operational Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. ASN.1 Module
Acknowledgements
Authors' Addresses
This document specifies the conventions for using the SLH-DSA hash-based signature algorithm [FIPS205] with the Cryptographic Message Syntax (CMS) [RFC5652] signed-data content type.
このドキュメントは、暗号化メッセージの構文（CMS）[RFC5652]で署名されたDATAコンテンツタイプを使用して、SLH-DSAハッシュベースの署名アルゴリズム[FIPS205]を使用するための規則を指定します。
SLH-DSA offers two signature modes: pure mode and pre-hash mode. SLH-DSA 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 empty string. This document only specifies the use of pure mode with an empty context string for the CMS signed-data content type.
SLH-DSAは、純粋なモードとプレハッシュモードの2つの署名モードを提供します。SLH-DSA署名操作には、入力としてのコンテキスト文字列が含まれます。コンテキスト文字列の最大長は255バイトです。デフォルトでは、コンテキスト文字列は空の文字列です。このドキュメントは、CMS署名されたDATAコンテンツタイプの空のコンテキスト文字列を使用した純粋なモードの使用のみを指定します。
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. Separate algorithm identifiers have been assigned for SLH-DSA at each of these security levels.
SLH-DSAは3つのセキュリティレベルを提供します。各セキュリティレベルのパラメーターは、128ビットのセキュリティ、192ビットのセキュリティ、256ビットのセキュリティを提供するために選択されました。これらのセキュリティレベルのそれぞれで、SLH-DSAに個別のアルゴリズム識別子が割り当てられています。
SLH-DSA is a stateless hash-based signature algorithm. Other hash-based signature algorithms are stateful, including Hierarchical Signature System (HSS) / Leighton-Micali Signatures (LMS) [RFC8554] and eXtended Merkle Signature Scheme (XMSS) [RFC8391]. Without the need for state kept by the signer, SLH-DSA is much less fragile than the stateful hash-based signature algorithms.
SLH-DSAは、ステートレスハッシュベースの署名アルゴリズムです。他のハッシュベースの署名アルゴリズムは、階層的な署名システム（HSS） / Leighton-Micali Signatures（LMS）[RFC8554]および拡張Merkle Signature Scheme（XMSS）[RFC8391]を含むステートフルです。署名者が保持する状態の必要性がなければ、SLH-DSAは、ステートフルハッシュベースの署名アルゴリズムよりもはるかに脆弱ではありません。
CMS values are generated with ASN.1 [X680] using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
CMS値は、基本的なエンコードルール（BER）と著名なエンコードルール（der）[x690]を使用して、asn.1 [x680]で生成されます。
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 algorithms.
暗号化の最近の進歩と量子コンピューターの開発の進歩がありました。これらの各進歩は、広く展開されているデジタル署名アルゴリズムに対する脅威をもたらします。
If Cryptographically Relevant Quantum Computers (CRQCs) are ever built, they will be able to break many of the public key cryptosystems currently in use, including RSA, DSA, Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (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 CRQC is invented. SLH-DSA is a PQC signature algorithm.
暗号化に関連する量子コンピューター（CRQC）がこれまでに構築されている場合、RSA、DSA、楕円曲線デジタル署名アルゴリズム（ECDSA）、およびエドワーズカーブデジタル署名アルゴリズム（EDDSA）など、現在使用されている公開鍵暗号システムの多くを破壊することができます。質量式暗号システム（PQC）は、些細な数の量子ビット（qubits）を超える量子コンピューターに対して安全です。このような量子コンピューターを構築することが可能になる場合、推測することができます。ただし、CRQCが発明されている場合は安全なままである暗号化アルゴリズムを使用することは賢明です。SLH-DSAはPQC署名アルゴリズムです。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
SLH-DSA is a stateless hash-based signature algorithm. SLH-DSA makes use of a few-time signature construction (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 Winternitz One-Time Signature Plus (WOTS+). The FORS tree roots are signed by a WOTS+ 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 roots 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. Subtree roots are consequently signed by their corresponding subtree layers until the top subtree is reached. The top-layer subtree forms the hypertree root, which is trusted at the verifier.
SLH-DSAは、ステートレスハッシュベースの署名アルゴリズムです。SLH-DSAは、数回の署名構造（ランダムサブセットの森林（FORS））とハイパーツリーを利用しています。FORSは、秘密鍵でメッセージに署名します。対応するFORSパブリックキーは、Kバイナリツリーの葉です。これらの木の根は一緒にハッシュされてForsの根を形成します。SLH-DSAは、Winternitz One-Time Signature Plus（WOTS+）と呼ばれる1回限りの署名スキームを使用します。FORSツリールーツは、WOTS+秘密キーによって署名されます。対応するWOTS+パブリックキーは、SLH-DSAハイパーツリーのMerkleサブツリーのD層に葉を形成します。そのハイパーツリーの一番下の層は、FOTS+でFORSの根に署名します。次に、底部のマークルサブツリーの根はWOTS+で署名され、対応するWOTS+パブリックキーは次のレベルアップサブツリーの葉を形成します。その結果、サブツリーの根は、上部のサブツリーに到達するまで、対応するサブツリーレイヤーによって署名されます。トップレイヤーサブツリーは、検証者に信頼されているハイパートリールートを形成します。
An 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.
SLH-DSA署名は、ランダム化文字列、FORS署名、各レイヤーの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 the root of the hypertree, the signature verifies only if it hashes to the pre-trusted root of the SLH-DSA hypertree.
SLH-DSA署名は、FORS署名、WOTS+署名、および各サブツリーのルートへのパスを使用して検証されます。ハイパーツリーの根に到達すると、署名は、SLH-DSAハイパーツリーの事前にトラストされたルートにハッシュする場合にのみ検証されます。
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) never be reused or the scheme loses its security. FORS is used at the bottom of the SLH-DSA hypertree. Security decreases if the same private key is used to sign two or more different messages, but security does not collapse, as is the case in stateful hash-based signature algorithms. Without the need for state kept by the signer to ensure it is not reused, SLH-DSA is much less fragile.
SLH-DSAは、ステートレスハッシュベースの署名アルゴリズムです。ステートフルハッシュベースの署名スキームでは、WOTS+秘密キー（状態インデックスを使用して生成される）が再利用されないか、スキームがセキュリティを失うことを必要とします。FORSは、SLH-DSAハイパーツリーの下部に使用されます。同じ秘密鍵を使用して2つ以上の異なるメッセージに署名するとセキュリティが減少しますが、Stateful Hashベースの署名アルゴリズムの場合のように、セキュリティは崩壊しません。署名者が再利用しないようにするために署名者が保持する必要がなければ、SLH-DSAは脆弱ではありません。
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+, and the number 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 block cipher of 128, 192, or 256 bits.
SLH-DSAは、最大2^64のメッセージにサインアップするように設計されており、3つのセキュリティレベルを提供します。SLH-DSAハイパーツリーのパラメーターには、セキュリティパラメーター、ハッシュ関数、ツリーの高さ、サブツリーの層の数、WOTS+のWinternitzパラメーター、およびそれぞれのForsの木と葉の数が含まれます。各セキュリティレベルのパラメーターは、少なくとも128、192、または256ビットの一般的なブロック暗号と同じくらい安全であるように選択されました。
The AlgorithmIdentifier for an 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]. For example, id-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.
SLH-DSA公開キーのアルゴリズム科学者は、以下にリストされている12のID-SLH-DSAオブジェクト識別子のいずれかを使用する必要があります。たとえば、ID-SLH-DSA-SHAKE-256Sは、256ビットのセキュリティレベル、アルゴリズムの小さなバージョン、およびShake256の使用を表します。SLH-DSA公開キーのアルゴリズムIdentifierのパラメーターフィールドはない必要があります。
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-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }
id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }
id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 }
id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 }
id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 }
id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 }
id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 }
id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 }
id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 }
id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 }
id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 }
id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }
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.
このアルゴリズムのIndidentifierがX.509証明書[RFC5280]の件名PublicKeyInfoフィールドに表示されると、証明書キーの使用拡張機能には、DigitalSignature、Nonepudiation、KeyCertSign、およびCRLSignが含まれる場合があります。証明書キーの使用拡張機能には、他の値を含めてはなりません。
pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
IDENTIFIER id-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-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-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-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-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-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-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-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-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-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-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-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 (SIZE (32 | 48 | 64))
SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))
No additional encoding of the SLH-DSA public key is applied in the SubjectPublicKeyInfo field of an X.509 certificate [RFC5280].
X.509証明書[RFC5280]の件名PublicKeyInfoフィールドにSLH-DSA公開キーの追加エンコードは適用されません。
No additional encoding of the SLH-DSA private key is applied in the PrivateKeyInfo field of the privateKey field of the OneAsymmetricKey type of an Asymmetric Key Package [RFC5958].
SLH-DSA秘密キーの追加エンコードは、非対称キーパッケージ[RFC5958]のOneaSymmetrickeyタイプのプライベートキーフィールドのプライベートキーフィールドフィールドに適用されません。
When an SLH-DSA public key appears outside of a SubjectPublicKeyInfo type 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.
ASN.1エンコーディングを使用する環境でSLH-DSAの公開キーが件名の外側に表示される場合、SLH-DSA-Publickeyタイプを使用してSLH-DSAの公開キーをオクテット文字列としてエンコードできます。
When an SLH-DSA private key appears outside of an Asymmetric Key Package 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.
ASN.1エンコーディングを使用する環境でSLH-DSA秘密キーが非対称キーパッケージの外側に表示される場合、SLH-DSA-PrivateKeyタイプを使用してSLH-DSA秘密キーをオクテット文字列としてエンコードできます。
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.
CMS [RFC5652]で指定されているように、デジタル署名はメッセージダイジェストと署名者の秘密鍵から生成されます。署名は、署名された属性が存在しないか存在するかに応じて、異なる値で計算されます。
When signed attributes are absent, the SLH-DSA (pure mode) signature is computed over the content. When signed attributes are present, a hash SHOULD be computed over the DER-encoded signed attributes 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 10.2.1 of [FIPS205]. In summary:
署名された属性が存在しない場合、SLH-DSA（Pure Mode）署名はコンテンツに対して計算されます。署名された属性が存在する場合、SLH-DSAツリーで使用される同じハッシュ関数を使用して、derエンコードされた署名属性を介してハッシュを計算する必要があります。署名された属性には、コンテンツタイプの属性とメッセージダイジスト属性を含める必要があります。メッセージダイジェスト属性には、コンテンツのハッシュ値が含まれています。SLH-DSA署名は、署名された属性のセットのderエンコードで計算されます。SLH-DSAシグネチャジェネレーション操作はSLH_SIGNと呼ばれます。[FIPS205]のセクション10.2.1を参照してください。要約すれば：
IF (signed attributes are absent)
THEN slh_sign(content)
ELSE signed attributes 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.
いくつかの実装では、コンテンツが大きいときにDER（SigneDattributes）に署名および検証することにより、パフォーマンスが大幅に改善される場合があります。つまり、署名関数または署名検証関数に大きなメッセージコンテンツ全体を渡すことは、パフォーマンスに影響を与える可能性があります。署名された属性が存在する場合、[RFC5652]のセクション5.3では、コンテンツタイプの属性とメッセージダイジェスト属性を含める必要があります。他の属性も含めることができます。
When using SLH-DSA and signed attributes are present in the SignerInfo, the digestAlgorithms field in the SignedData MUST include the identifier for the one-way hash function used to compute the message digest.
SLH-DSAを使用して署名された属性をSignerInfoに存在する場合、SignedDataのDigestalgorithmsフィールドには、メッセージダイジェストを計算するために使用される一方向ハッシュ関数の識別子を含める必要があります。
When using SLH-DSA, the fields in the SignerInfo are used as follows:
SLH-DSAを使用する場合、Signerinfoのフィールドは次のように使用されます。
digestAlgorithm:
消化器gorthm：
The digestAlgorithm MUST identify a one-way hash function. When signed attributes are absent, the digestAlgorithm identifier SHOULD match the hash function used in the SLH-DSA tree (as shown in the list below). The digestAlgorithm does not have any significance when signed attributes are absent as it is not used to pre-hash the message. When there is a concern for failures with legacy implementations that do not support all hash functions, signers MAY choose to always use the SHA-256 algorithm identifier as the digestAlgorithm when signed attributes are absent. When signed attributes are present, to ensure collision resistance, the identified hash function MUST produce a hash value that is at least twice the size of the hash function used in the SLH-DSA tree. The hash functions defined in [FIPS180] and [FIPS202] MUST be supported for use with the variants of SLH-DSA as shown below:
消化器gorthは一方向ハッシュ関数を識別する必要があります。署名された属性が存在しない場合、消化器gorthmの識別子は、SLH-DSAツリーで使用されるハッシュ関数と一致する必要があります（以下のリストに示すように）。メッセージの事前ハッシュに使用されていないため、署名された属性が存在しない場合、消化器goritymは何の意味もありません。すべてのハッシュ関数をサポートしないレガシー実装での障害の懸念がある場合、署名者は、署名された属性が存在しないときに消化器gorityとしてSHA-256アルゴリズム識別子を常に使用することを選択できます。署名された属性が存在する場合、衝突抵抗を確保するために、特定されたハッシュ関数は、SLH-DSAツリーで使用されるハッシュ関数の少なくとも2倍のサイズのハッシュ値を生成する必要があります。[FIPS180]および[FIPS202]で定義されているハッシュ関数は、以下に示すようにSLH-DSAのバリアントで使用するためにサポートする必要があります。
id-slh-dsa-sha2-128s: SHA-256
id-slh-dsa-sha2-128f: SHA-256
id-slh-dsa-sha2-192s: SHA-512
id-slh-dsa-sha2-192f: SHA-512
id-slh-dsa-sha2-256s: SHA-512
id-slh-dsa-sha2-256f: SHA-512
id-slh-dsa-shake-128s: 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-192f: 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
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.
SHA-256およびSHA-512のオブジェクト識別子は[RFC5754]に含まれています。Shake128およびShake256のオブジェクト識別子は[RFC8702]に含まれています。4つのケースすべてで、アルゴリズムIdentifierにパラメーターを含めるべきではありません。
signatureAlgorithm:
SignatureAlgorithm：
The signatureAlgorithm MUST contain one of the SLH-DSA algorithm identifiers, and the algorithm parameters field MUST be absent. The algorithm identifier MUST be one of the following:
SignatureAlgorithmには、SLH-DSAアルゴリズム識別子のいずれかを含める必要があり、アルゴリズムパラメーターフィールドがない必要があります。アルゴリズム識別子は、次のいずれかでなければなりません。
id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f,
id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f,
id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f,
id-slh-dsa-shake-128s, id-slh-dsa-shake-128f,
id-slh-dsa-shake-192s, id-slh-dsa-shake-192f,
id-slh-dsa-shake-256s, id-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 signature-generation operation is specified in Section 10.2.1 of [FIPS205], and the SLH-DSA signature verification operation is specified in Section 10.3 of [FIPS205]. Signature verification MUST include checking that the signatureAlgorithm field identifies SLH-DSA parameters that are consistent with public key used to validate the signature.
署名には、選択したSignatureAlgorithmに関連付けられたパラメーターを使用したSLH-DSA署名操作に起因する署名値が含まれています。SLH-DSAの署名生成操作は[FIPS205]のセクション10.2.1で指定されており、SLH-DSA署名検証操作は[FIPS205]のセクション10.3で指定されています。署名検証には、SignatureAlgorithmフィールドが署名の検証に使用される公開キーと一致するSLH-DSAパラメーターを識別することを確認する必要があります。
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.
SLH-DSAキーペアを生成する場合、実装は、SLH-DSAハイパートリーの他のすべてのキーペアとは独立して各キーペアを生成する必要があります。
A SLH-DSA tree MUST NOT be used for more than 2^64 signing operations.
SLH-DSAツリーは、2^64を超える署名操作に使用してはなりません。
The generation of private keys relies on random numbers. The use of inadequate Pseudorandom 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.
プライベートキーの生成は、乱数に依存しています。これらの値を生成するために不十分な擬似ランダム数ジェネレーター（PRNG）を使用すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成したPRNG環境を再現する方がはるかに簡単になる場合があり、キー空間全体を検索するのではなく、結果として生じる小さな可能性のセットを検索します。品質の乱数の生成は困難であり、[RFC4086]はこの分野で重要なガイダンスを提供します。
To avoid algorithm-substitution attacks, the CMSAlgorithmProtection attribute defined in [RFC6211] SHOULD be included in signed attributes.
アルゴリズム分解攻撃を回避するには、[RFC6211]で定義されているcMSAlgorithMProtection属性を署名属性に含める必要があります。
Implementers should consider their particular use cases and may choose to implement optional fault-attack countermeasures [CMP2018] [Ge2023]. Verifying a signature before releasing the signature value is a typical fault-attack countermeasure; however, this countermeasure is not effective for SLH-DSA [Ge2023]. Redundancy by replicating the signature-generation process MAY be used as an effective fault-attack countermeasure for SLH-DSA [Ge2023]; however, the SLH-DSA signature generation is already considered slow.
実装者は特定のユースケースを検討する必要があり、オプションの障害攻撃対策[CMP2018] [GE2023]を実装することを選択できます。署名値をリリースする前に署名を検証することは、典型的な障害攻撃対策です。ただし、この対策はSLH-DSA [GE2023]には効果的ではありません。署名生成プロセスを複製することによる冗長性は、SLH-DSAの効果的な障害攻撃対策として使用できます[GE2023]。ただし、SLH-DSAの署名生成はすでに遅いと見なされます。
Likewise, implementers should consider their particular use cases and may choose to implement protections against passive power and emissions side-channel attacks [SLotH].
同様に、実装者は特定のユースケースを検討する必要があり、受動的なパワーおよび排出量サイドチャネル攻撃に対する保護を実装することを選択することができます[Sloth]。
If slh_sign is implemented in a hardware device such as Hardware Security Module (HSM) or portable cryptographic token, implementations can avoid 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.
SLH_SIGNがハードウェアセキュリティモジュール（HSM）やポータブル暗号化トークンなどのハードウェアデバイスに実装されている場合、実装は完全なコンテンツをデバイスに送信することを避けることができます。[RFC5652]のセクション5.3で説明されているように、メッセージダイジェスト属性とコンテンツタイプの属性を必然的に含める署名属性を含めることにより、署名のためにはるかに小さな署名属性のセットがデバイスに送信されます。
By including signed attributes in the SignerInfo, one can obtain similar 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 full message content. By including signed attributes in the SignerInfo, a 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 with the CMS SignedData. Note SLH-DSA pre-hash mode always yields a different signature value than SLH-DSA pure mode, even if the to-be-signed content is the same.
SignerInfoに署名属性を含めることにより、プレハッシュモードでSLH-DSAに同様のインターフェイス特性を取得できます。プレハッシュモードでは、コンテンツのハッシュが完全なメッセージコンテンツではなくSLH-DSA署名操作に渡されます。SignerInfoに署名属性を含めることにより、比較的小さな署名値がSLH-DSA署名操作に渡されます。このため、SLH-DSAプレハッシュモードは、CMS SignedDataで使用するために指定されていません。注SLH-DSAプレハッシュモードは、署名されたコンテンツが同じであっても、常にSLH-DSA Pureモードとは異なる署名値を生成します。
When using SLH-DSA in pure mode, it is not possible to single-pass process the content to verify a SignedData message that does not contain signed attributes. To assist recipients that might make use of stream-based APIs, implementers SHOULD include signed attributes within any SignerInfo that uses SLH-DSA as signature algorithm. Doing so allows the recipient implementation to avoid keeping the signed content in memory. Recall that when signed attributes are present, they MUST contain a content-type attribute and a message-digest attribute, and they SHOULD contain a CMSAlgorithmProtection attribute.
純粋なモードでSLH-DSAを使用する場合、署名された属性が含まれていないSignedDataメッセージを検証するためにコンテンツをシングルパスすることはできません。ストリームベースのAPIを使用する可能性のある受信者を支援するには、実装者はSLH-DSAを署名アルゴリズムとして使用するSignerInfo内に署名属性を含める必要があります。そうすることで、受信者の実装が署名されたコンテンツをメモリに保持しないようにすることができます。署名された属性が存在する場合、コンテンツタイプの属性とメッセージダイジェスト属性が含まれている必要があり、CMSAlgorithmProtection属性を含める必要があることを思い出してください。
For the ASN.1 Module in Appendix A, IANA has assigned an Object Identifier (OID) for the module identifier (81) with a Description of "id-mod-slh-dsa-2024". 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)" registry.
付録AのASN.1モジュールの場合、IANAは、「ID-MOD-SLH-DSA-2024」の説明を含むモジュール識別子（81）にオブジェクト識別子（OID）を割り当てました。モジュールのOIDは、「S/MIMEモジュール識別子のSMIセキュリティ（1.2.840.113549.1.9.16.0）」に割り当てられています。
[FIPS180] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", NIST FIPS 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
[FIPS202] National Institute of Standards and Technology (NIST),
"SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions", NIST FIPS 202,
DOI 10.6028/NIST.FIPS.202, August 2015,
<https://doi.org/10.6028/NIST.FIPS.202>.
[FIPS205] National Institute of Standards and Technology (NIST),
"Stateless Hash-Based Digital Signature Standard", NIST
FIPS 205, DOI 10.6028/NIST.FIPS.205, 13 August 2024,
<https://doi.org/10.6028/NIST.FIPS.205>.
[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/info/rfc2119>.
[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/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm
Identifier Protection Attribute", RFC 6211,
DOI 10.17487/RFC6211, April 2011,
<https://www.rfc-editor.org/info/rfc6211>.
[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/info/rfc8174>.
[RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash
Functions in the Cryptographic Message Syntax (CMS)",
RFC 8702, DOI 10.17487/RFC8702, January 2020,
<https://www.rfc-editor.org/info/rfc8702>.
[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>.
[CMP2018] Castelnovi, L., Martinelli, A., and T. Prest, "Grafting
Trees: A Fault Attack Against the SPHINCS Framework",
Post-Quantum Cryptography (PQCrypto 2018), Lecture Notes
in Computer Science, vol. 10786, pp. 165-184,
DOI 10.1007/978-3-319-79063-3_8, 2018,
<https://link.springer.com/
chapter/10.1007/978-3-319-79063-3_8>.
[Ge2023] Genêt, A., "On Protecting SPHINCS+ Against Fault Attacks",
IACR Transactions on Cryptographic Hardware and Embedded
Systems, vol. 2023, no. 2, pp. 80-114,
DOI 10.46586/tches.v2023.i2.80-114, 2023,
<https://tches.iacr.org/index.php/TCHES/article/
view/10278/9726>.
[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/info/rfc4086>.
[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/info/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/info/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/info/rfc8554>.
[SLotH] Saarinen, M.-J., "Accelerating SLH-DSA by Two Orders of
Magnitude with a Single Hash Unit", Cryptology ePrint
Archive, Paper 2024/367, 2024,
<https://eprint.iacr.org/2024/367.pdf>.
This ASN.1 Module builds upon the conventions established in [RFC5911].
このASN.1モジュールは、[RFC5911]で確立された規則の上に構築されます。
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(81) }
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
--
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-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }
id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }
id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 }
id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 }
id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 }
id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 }
id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 }
id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 }
id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 }
id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 }
id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 }
id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }
--
-- Signature Algorithm, Public Key, and Private Key
--
sa-slh-dsa-sha2-128s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-sha2-128s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-128s }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-128s } }
sa-slh-dsa-sha2-128f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-sha2-128f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-128f }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-128f } }
sa-slh-dsa-sha2-192s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-sha2-192s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-192s }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-192s } }
sa-slh-dsa-sha2-192f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-sha2-192f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-192f }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-192f } }
sa-slh-dsa-sha2-256s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-sha2-256s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-256s }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-256s } }
sa-slh-dsa-sha2-256f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-sha2-256f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-sha2-256f }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-256f } }
sa-slh-dsa-shake-128s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-shake-128s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-128s }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-128s } }
sa-slh-dsa-shake-128f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-shake-128f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-128f }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-128f } }
sa-slh-dsa-shake-192s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-shake-192s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-192s }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-192s } }
sa-slh-dsa-shake-192f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-shake-192f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-192f }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-192f } }
sa-slh-dsa-shake-256s SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-shake-256s
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-256s }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-256s } }
sa-slh-dsa-shake-256f SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-slh-dsa-shake-256f
PARAMS ARE absent
PUBLIC-KEYS { pk-slh-dsa-shake-256f }
SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-256f } }
pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
IDENTIFIER id-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-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-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-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-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-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-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-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-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-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-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-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 (SIZE (32 | 48 | 64))
SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))
--
-- 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
Thanks to Mike Ounsworth, Tomas Gustavsson, Daniel Van Geest, Carl Wallace, Phillip Hallam-Baker, Dieter Bratko, Vijay Gurbani, Paul Wouters, and Roman Danyliw for their careful review and constructive comments.
マイク・オンスワース、トマス・グスタフソン、ダニエル・ヴァン・ジスト、カール・ウォレス、フィリップ・ハラム・ベーカー、ディーター・ブラトコ、ヴィジェイ・グルベイニ、ポール・ウーターズ、ロマン・ダニリウの慎重なレビューと建設的なコメントに感謝します。
Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Panos Kampanakis
Amazon Web Services
Email: kpanos@amazon.com
Bas Westerbaan
Cloudflare
Email: bas@westerbaan.name