LAMPS - Limited Additional Mechanisms for PKIX and SMIME K. Bashiri Internet-Draft BSI Intended status: Standards Track S. Fluhrer Expires: 6 January 2025 Cisco Systems S. Gazdag genua GmbH D. Van Geest CryptoNext Security S. Kousidis BSI 5 July 2024 Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH- DSA draft-ietf-lamps-x509-slhdsa-01 Abstract Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Standard (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private key are also described. [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized FIPS 205 Stateless Hash-Based Digital Signature Standard. The current FIPS draft was published August 24, 2023 for public review. Final versions are expected by April 2024. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-slhdsa/. Discussion of this document takes place on the LAMPS Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/. Source for this draft and an issue tracker can be found at https://github.com/x509-hbs/draft-x509-slhdsa. Bashiri, et al. Expires 6 January 2025 [Page 1] Internet-Draft SLH-DSA for X.509 July 2024 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 3 4. SLH-DSA Signatures in PKIX . . . . . . . . . . . . . . . . . 5 5. SLH-DSA Public Keys in PKIX . . . . . . . . . . . . . . . . . 6 6. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Security Strengths . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Bashiri, et al. Expires 6 January 2025 [Page 2] Internet-Draft SLH-DSA for X.509 July 2024 1. Introduction Stateless Hash-Based Digital Signatures (SLH-DSA) is a quantum- resistant digital signature scheme standardized in [FIPS205] [EDNOTE: [FIPS205-ipd] until officially published] by the US National Institute of Standards and Technology (NIST) PQC project [NIST-PQC]. This document specifies the use of the SLH-DSA algorithm in Public Key Infrastructure X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs). 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. There are small (s) or fast (f) version of the algorithm, and the option to use SHA-256 [FIPS180] or SHAKE256 [FIPS202]. The fast versions are optimized for key generation and signing speed, they are actually slower at verification than the small parameter sets. 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. Separate algorithm identifiers have been assigned for SLH-DSA at each of these security levels, fast vs small, and SHA-256 vs SHAKE256. This specification includes conventions for the encoding of SLH-DSA digital signatures and public keys in the X.509 Public Key Infrastructure. 2. Conventions and Definitions 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. 3. Algorithm Identifiers This specification uses placeholders for object identifiers until the identifiers for the new algorithms are assigned by NIST. The AlgorithmIdentifier type, which is included herein for convenience, is defined as follows: Bashiri, et al. Expires 6 January 2025 [Page 3] Internet-Draft SLH-DSA for X.509 July 2024 AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } | NOTE: The above syntax is from [RFC5280] and matches the | version used therein, i.e., the 1988 ASN.1 syntax. See | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. The fields in AlgorithmIdentifier have the following meanings: * algorithm identifies the cryptographic algorithm with an object identifier. * parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. The OIDs are: 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 } Bashiri, et al. Expires 6 January 2025 [Page 4] Internet-Draft SLH-DSA for X.509 July 2024 The contents of the parameters component for each algorithm are absent. 4. SLH-DSA Signatures in PKIX SLH-DSA is a digital signature scheme built upon hash functions. The security of SLH-DSA relies on the presumed difficulty of finding preimages for hash functions as well as several related properties of the same hash functions. Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from [RFC5280] below, in an X.509 certificate, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } Signatures are also used in the CRL list ASN.1 representation from [RFC5280] below. In a X.509 CRL, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. CertificateList ::= SEQUENCE { tbsCertificate TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } The identifiers defined in Section 3 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field in the sequence TBSCertificate/TBSCertList in certificates CRLs, respectively, [RFC5280]. The parameters of these signature algorithms are absent, as explained in Section 3. The signatureValue field contains the corresponding SLH-DSA signature computed upon the ASN.1 DER encoded tbsCertificate [RFC5280]. Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly by using the OIDs specified in Section 3 when encoding SLH-DSA signatures in certificates and CRLs. Conforming client implementations that process certificates and CRLs using SLH-DSA MUST recognize the corresponding OIDs. Encoding rules for SLH-DSA signature values are specified Section 3. Bashiri, et al. Expires 6 January 2025 [Page 5] Internet-Draft SLH-DSA for X.509 July 2024 When any of the id-alg-slh-dsa-* identifiers appear in the algorithm field as an AlgorithmIdentifier, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the id-alg-slh-dsa-* OID. 5. SLH-DSA Public Keys in PKIX In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } The fields in SubjectPublicKeyInfo have the following meanings: * algorithm is the algorithm identifier and parameters for the public key (see above). * subjectPublicKey contains the byte stream of the public key. [I-D.draft-ietf-lamps-cms-sphincs-plus] defines the following public key identifiers for SLH-DSA: 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 Bashiri, et al. Expires 6 January 2025 [Page 6] Internet-Draft SLH-DSA for X.509 July 2024 -- 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 -- } 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 ::= { Bashiri, et al. Expires 6 January 2025 [Page 7] Internet-Draft SLH-DSA for X.509 July 2024 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 Section 9.1 of [FIPS205] defines the raw octet string encoding of an SLH-DSA public key as the concatenation of the PK.seed and PK.root values. The octet string length is 2*n bytes, where n is 16, 24, or 32, depending on the parameter set. When used in a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains the raw octet string encodings of the public keys. [I-D.draft-ietf-lamps-cms-sphincs-plus] defines the SLH-DSA-PublicKey ASN.1 OCTET STRING type for encoding a public key when not used in a SubjectPublicKeyInfo. The OCTET STRING is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The id-alg-slh-dsa-* identifiers defined in Section 3 MUST be used as the algorithm field in the SubjectPublicKeyInfo sequence [RFC5280] to identify a SLH-DSA public key. The following is an example of a [TODO: pick an OID] public key encoded using the textual encoding defined in [RFC7468]. -----BEGIN PUBLIC KEY----- TODO -----END PUBLIC KEY----- Conforming CA implementations MUST specify the X.509 public key algorithm explicitly by using the OIDs specified in Section 3 when using SLH-DSA public keys in certificates and CRLs. Conforming client implementations that process SLH-DSA public keys when processing certificates and CRLs MUST recognize the corresponding OIDs. Bashiri, et al. Expires 6 January 2025 [Page 8] Internet-Draft SLH-DSA for X.509 July 2024 6. Key Usage Bits The intended application for the key is indicated in the keyUsage certificate extension; see Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that indicates an id- alg-slh-dsa-* identifier in the SubjectPublicKeyInfo, then the at least one of following MUST be present: digitalSignature; or nonRepudiation; or keyCertSign; or cRLSign. Requirements about the keyUsage extension bits defined in [RFC5280] still apply. 7. Security Considerations The security considerations of [RFC5280] applies accordingly. 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. Bashiri, et al. Expires 6 January 2025 [Page 9] Internet-Draft SLH-DSA for X.509 July 2024 When computing signatures, implementations SHOULD include protections against fault injection attacks [CMP2018],[SLotH]. 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. 8. 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-x509-slh-dsa-2024". 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). 9. References 9.1. Normative References [FIPS205] "TBD", n.d.. [FIPS205-ipd] National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", 24 August 2023, . [I-D.draft-ietf-lamps-cms-sphincs-plus] Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-cms-sphincs-plus-06, 3 July 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . Bashiri, et al. Expires 6 January 2025 [Page 10] Internet-Draft SLH-DSA for X.509 July 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [CMP2018] Castelnovi, L., A, Martinelli, and T. Prest, "Grafting Trees: A Fault Attack Against the SPHINCS Framework", Lecture Notes in Computer Science vol 10786, PQCrypto 2018, Post-Quantum Cryptography pp. 165-184, 2018, . [FIPS180] Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal Information Processing Standards Publications 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, . [FIPS202] Dworkin, M., Dworkin, M. J., and NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, NIST Federal Information Processing Standards Publications 202, DOI 10.6028/nist.fips.202, DOI 10.6028/NIST.FIPS.202, August 2015, . [I-D.ietf-lamps-dilithium-certificates] Massimo, J., Kampanakis, P., Turner, S., and B. Westerbaan, "Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA", Work in Progress, Internet-Draft, draft-ietf-lamps-dilithium-certificates- 03, 5 February 2024, . [NIST-PQC] National Institute of Standards and Technology, "Post- Quantum Cryptography Project", 20 December 2016, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . Bashiri, et al. Expires 6 January 2025 [Page 11] Internet-Draft SLH-DSA for X.509 July 2024 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10.17487/RFC8411, August 2018, . [SLotH] Saarinen, M-J., "Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit", 2024, . Appendix A. ASN.1 Module RFC EDITOR: Please replace TBD2 with the value assigned by IANA during the publication of [I-D.draft-ietf-lamps-cms-sphincs-plus]. X509-SLH-DSA-Module-2024 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-x509-slh-dsa-2024(TBD1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS PUBLIC-KEY, SIGNATURE-ALGORITHM 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) } pk-slh-dsa-sha2-128s, pk-slh-dsa-sha2-128f, pk-slh-dsa-sha2-192s, pk-slh-dsa-sha2-192f, pk-slh-dsa-sha2-256s, pk-slh-dsa-sha2-256f, pk-slh-dsa-shake-128s, pk-slh-dsa-shake-128f, pk-slh-dsa-shake-192s, pk-slh-dsa-shake-192f, pk-slh-dsa-shake-256s, pk-slh-dsa-shake-256f, 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 FROM SLH-DSA-Module-2024 -- in [I-D.draft-ietf-lamps-cms-sphincs-plus] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-slh-dsa-2024(TBD2) } ; -- -- Expand SignatureAlgorithms from RFC 5912 -- SignatureAlgorithms SIGNATURE-ALGORITHM ::= { sa-slh-dsa-sha2-128s | sa-slh-dsa-sha2-128f | Bashiri, et al. Expires 6 January 2025 [Page 12] Internet-Draft SLH-DSA for X.509 July 2024 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 PublicKeyAlgorithms from RFC 5912 -- PublicKeyAlgorithms PUBLIC-KEY ::= { pk-slh-dsa-sha2-128s | pk-slh-dsa-sha2-128f | pk-slh-dsa-sha2-192s | pk-slh-dsa-sha2-192f | pk-slh-dsa-sha2-256s | pk-slh-dsa-sha2-256f | pk-slh-dsa-shake-128s | pk-slh-dsa-shake-128f | pk-slh-dsa-shake-192s | pk-slh-dsa-shake-192f | pk-slh-dsa-shake-256s | pk-slh-dsa-shake-256f, ... } END Appendix B. Security Strengths Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates of the number of bits of security, NIST has instead elected to define a collection of broad security strength categories. Each category is defined by a comparatively easy-to-analyze reference primitive that cover a range of security strengths offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for: Level 1 - key search on a block cipher with a 128-bit key (e.g., AES128), Level 2 - collision search on a 256-bit hash function (e.g., SHA256/ SHA3-256), Level 3 - key search on a block cipher with a Bashiri, et al. Expires 6 January 2025 [Page 13] Internet-Draft SLH-DSA for X.509 July 2024 192-bit key (e.g., AES192), Level 4 - collision search on a 384-bit hash function (e.g. SHA384/SHA3-384), Level 5 - key search on a block cipher with a 256-bit key (e.g., AES 256). The parameter sets defined for NIST security levels 1, 3 and 5 are listed in Table 1, along with the resulting signature size, public key, and private key sizes in bytes. +===========================+============+=======+==========+=======+ | OID | NIST Level | Sig. | Pub. | Priv. | | | | | Key | Key | +===========================+============+=======+==========+=======+ | id-alg-slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-sha2-128f | 1 | 17088 | 32 | 64 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-sha2-192s | 3 | 16224 | 48 | 96 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-sha2-192f | 3 | 35664 | 48 | 96 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-sha2-256s | 5 | 29792 | 64 | 128 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-sha2-256f | 5 | 49856 | 64 | 128 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-shake-128s | 1 | 7856 | 32 | 64 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-shake-128f | 1 | 17088 | 32 | 64 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-shake-192s | 3 | 16224 | 48 | 96 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-shake-192f | 3 | 35664 | 48 | 96 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-shake-256s | 5 | 29792 | 64 | 128 | +---------------------------+------------+-------+----------+-------+ | id-alg-slh-dsa-shake-256f | 5 | 49856 | 64 | 128 | +---------------------------+------------+-------+----------+-------+ Table 1: SLH-DSA security strengths Acknowledgments Much of the structure and text of this document is based on [I-D.ietf-lamps-dilithium-certificates]. The remainder comes from [I-D.draft-ietf-lamps-cms-sphincs-plus]. Thanks to those authors, and the ones they based their work on, for making our work earier. "Copying always makes things easier and less error prone" - [RFC8411]. Bashiri, et al. Expires 6 January 2025 [Page 14] Internet-Draft SLH-DSA for X.509 July 2024 Authors' Addresses Kaveh Bashiri BSI Email: kaveh.bashiri.ietf@gmail.com Scott Fluhrer Cisco Systems Email: sfluhrer@cisco.com Stefan Gazdag genua GmbH Email: ietf@gazdag.de Daniel Van Geest CryptoNext Security Email: daniel.vangeest@cryptonext-security.com Stavros Kousidis BSI Email: kousidis.ietf@gmail.com Bashiri, et al. Expires 6 January 2025 [Page 15]