Limited Additional Mechanisms for PKIX and SMIME B. Salter Internet-Draft A. Raine Intended status: Standards Track UK National Cyber Security Centre Expires: 8 May 2025 D. Van Geest CryptoNext Security 4 November 2024 Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) draft-ietf-lamps-cms-ml-dsa-00 Abstract The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in posession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://lamps- wg.github.io/cms-ml-dsa/draft-ietf-lamps-cms-ml-dsa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/. Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME 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/lamps-wg/cms-ml-dsa. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Salter, et al. Expires 8 May 2025 [Page 1] Internet-Draft ML-DSA in CMS November 2024 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 8 May 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 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 2. ML-DSA Algorithm Identifiers . . . . . . . . . . . . . . . . 4 3. ML-DSA Key Encoding . . . . . . . . . . . . . . . . . . . . . 5 4. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 6 4.1. Pure mode vs pre-hash mode . . . . . . . . . . . . . . . 6 4.2. Signature generation and verification . . . . . . . . . . 7 4.3. SignerInfo content . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Salter, et al. Expires 8 May 2025 [Page 2] Internet-Draft ML-DSA in CMS November 2024 1. Introduction The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a digital signature algorithm standardised by NIST as part of their post-quantum cryptography standardization process. It is intended to be secure against both "traditional" cryptographic attacks, as well as attacks utilising a quantum computer. It offers smaller signatures and significantly faster runtimes than SLH-DSA [FIPS203], an alternative post-quantum signature algorithm also standardised by NIST. Prior to standardisation, the algorithm was known as Dilithium. ML- DSA and Dilithium are not compatible. ML-DSA offers parameter sets that meet three security levels: ML-DSA- 44, ML-DSA-65, and ML-DSA-87. ML-DSA-44 is intended to meet NIST's level 2 security category, ML-DSA-65 is intended to meet level 3, and ML-DSA-87 is intended to meet level 5. Each category requires that algorithms be as resistant to attack as a particular cryptographic algorithm. Attacks on algorithms in the level 2 category are intended to be at least as hard as performing a collision search on SHA256. Attacks on algorithms in the level 3 category are intended to be at least as hard as performing an exhaustive key search on AES192. Attacks on algorithms in the level 5 category are intended to be at least as hard as performing an exhaustive key search on AES256. EDNOTE: Appendix B of draft-ietf-lamps-dilithium-certificates describes this well, if it's easier just to refer to that. For each of the ML-DSA parameter sets, an algorithm identifier OID has been specified. [FIPS204] also specifies a pre-hashed variant of ML-DSA, called HashML-DSA. HashML-DSA is not used in CMS. 1.1. 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. Salter, et al. Expires 8 May 2025 [Page 3] Internet-Draft ML-DSA in CMS November 2024 2. ML-DSA Algorithm Identifiers Many ASN.1 data structure types use the AlgorithmIdentifier type to identify cryptographic algorithms. In CMS, AlgorithmIdentifiers are used to identify ML-DSA signatures in the signed-data content type. They may also appear in X.509 certificates used to verify those signatures. [I-D.ietf-lamps-dilithium-certificates] describes the use of ML-DSA in X.509 certificates. The AlgorithmIdentifier type, which is included herein for convenience, is defined as follows: AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= SEQUENCE { algorithm ALGORITHM-TYPE.&id({AlgorithmSet}), parameters ALGORITHM-TYPE. &Params({AlgorithmSet}{@algorithm}) OPTIONAL } The above syntax is from [RFC5911] and is compatible with the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 syntax. The fields in the AlgorithmIdentifier type have the following meanings: algorithm: The algorithm field contains an OID that identifies the cryptographic algorithm in use. The OIDs for ML-DSA are described below. parameters: The parameters field contains parameter information for the algorithm identified by the OID in the algorithm field. Each ML-DSA parameter set is identified by its own algorithm OID, so there is no relevant information to include in this field. As such, parameters MUST be omitted when encoding an ML-DSA AlgorithmIdentifier. The object identifiers for ML-DSA are defined in the NIST Computer Security Objects Register [CSOR], and are reproduced here for convenience. sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 3 } id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 } id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 } id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 } Salter, et al. Expires 8 May 2025 [Page 4] Internet-Draft ML-DSA in CMS November 2024 3. ML-DSA Key Encoding Section 4 of [I-D.ietf-lamps-dilithium-certificates] describes the format of ML-DSA public keys when encoded as a part of the SubjectPublicKeyInfo type. The signed-data content type as described in [RFC5652] does not encode public keys directly, but CMS content types defined by other documents do. For example, [RFC5272] describes Certificate Management over CMS, and its PKIData content utilises the SubjectPublicKeyInfo type to encode public keys for certificate requests. When the SubjectPublicKeyInfo type is used in CMS, ML-DSA public keys MUST be encoded as described in [I-D.ietf-lamps-dilithium-certificates] [RFC5958] describes the Asymmetric Key Package CMS content type, and the OneAsymmetricKey type for encoding asymmetric keypairs. When an ML-DSA private key or keypair is encoded as a OneAsymmetricKey, it follows the description in Section 6 of [I-D.ietf-lamps-dilithium-certificates]. The ASN.1 descriptions of ML-DSA keys are repeated below for convenience. EDNOTE: This section should reflect the content of draft-ietf-lamps- dilithium-certificates. The ASN.1 public key definitions in that document are not yet fully expanded, so the below is a best guess based on the equivalent SLH-DSA keys. Alternatively, draft-ietf- lamps-dilithium-certificates could reflect this document, as is the case for the SLH-DSA X.509/CMS drafts. Salter, et al. Expires 8 May 2025 [Page 5] Internet-Draft ML-DSA in CMS November 2024 pk-ml-dsa-44 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-44 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-ml-dsa-65 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-65 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-ml-dsa-87 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-87 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } ML-DSA-PublicKey ::= OCTET STRING ML-DSA-PrivateKey ::= OCTET STRING 4. Signed-data Conventions 4.1. Pure mode vs pre-hash mode [RFC5652] specifies that digital signatures for CMS are produced using a digest of the message to be signed, and the signer's private key. At the time of publication of that RFC, all signature algorithms supported in CMS required a message digest to be calculated externally to that algorithm, which would then be supplied to the algorithm implementation when calculating and verifying signatures. Since then, EdDSA [RFC8032], SLH-DSA [FIPS203] have also been standardised, and these algorithms support both a "pure" and "pre-hash" mode. In the pre-hash mode, a message digest (the "pre- hash") is calculated separately and supplied to the signature algorithm as described above. In the pure mode, the message to be signed or verified is instead supplied directly to the signature algorithm. ML-DSA also supports a pre-hash and pure mode, though we follow the convention set by EdDSA in CMS [RFC8419] and SLH-DSA in CMS [I-D.ietf-lamps-cms-sphincs-plus] in that only the pure mode of ML-DSA is used in CMS. That is, the pre-hash mode of ML-DSA MUST NOT be used in CMS. Salter, et al. Expires 8 May 2025 [Page 6] Internet-Draft ML-DSA in CMS November 2024 4.2. Signature generation and verification [RFC5652] describes the two methods that are used to calculate and verify signatures in CMS. One method is used when signed attributes are present in the signedAttrs field of the relevant SignerInfo, and another is used when signed attributes are absent. Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of ML-DSA is used, the "message digest" is in fact the entire message. Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness. EDNOTE: Would it make sense to make a stronger statement here? For instance, that CMS implements MAY reject signatures if they don't contain signed attributes, or that generation/verification of signed- data without signed attributes SHOULD NOT be supported? Some of the discussion around the use of context strings for new signature algorithms has highlighted the dangers here, as has Falko's paper here: https://eprint.iacr.org/2023/1801 When signed attributes are absent, ML-DSA (pure mode) signatures are computed over the content of the signed-data. As described in Section 5.4 of [RFC5652], the "content" of a signed-data is the value of the encapContentInfo eContent OCTET STRING. The tag and length octets are not included. When signed attributes are included, ML-DSA (pure mode) signatures are computed over a DER encoding of the SignerInfo's signedAttrs field. As described in Section 5.4 of [RFC5652], this encoding does include the tag and length octets, but an EXPLICIT SET OF tag is used rather than the IMPLICIT [0] tag that appears in the final message. The signedAttrs field MUST at minimum include a content-type attribute and a message-digest attribute. The message-digest attribute contains a hash of the content of the signed-data, where the content is as described for the absent signed attributes case above. Recalculation of the hash value by the recipient is an important step in signature verification. Choice of digest algorithm is up to the signer; algorithms for each parameter set are recommended below. Section 4 of [I-D.ietf-lamps-cms-sphincs-plus] describes how, when the content of a signed-data is large, performance may be improved by including signed attributes. This is as true for ML-DSA as it is for SLH-DSA, although ML-DSA signature generation and verification is significantly faster than SLH-DSA. Salter, et al. Expires 8 May 2025 [Page 7] Internet-Draft ML-DSA in CMS November 2024 ML-DSA has a context string input that can be used to ensure that different signatures are generated for different application contexts. When using ML-DSA as described in this document, the context string is not used. EDNOTE: It's been suggested that the context string could be used to separate content-only/signed attributes signatures. SLH-DSA and ML- DSA should stay in alignment here. If not specified here, are there other ways the context string could be used, e.g. with a different algorithm identifier or a signed attribute? If so, we could add a note to signpost that this is could appear in a future standard. 4.3. SignerInfo content When using ML-DSA, the fields of a SignerInfo are used as follows: digestAlgorithm: Per Section 5.3 of [RFC5652], the digestAlgorithm field identifies the message digest algorithm used by the signer, and any associated parameters. To ensure collision resistance, the identified message digest algorithm SHOULD produce a hash value of a size that is at least twice the collision strength of the internal commitment hash used by ML-DSA. The SHAKE hash functions defined in [FIPS202] are used internally by ML-DSA, and hence the combinations in Table 1 are RECOMMENDED for use with ML-DSA. [RFC8702] describes how SHAKE128 and SHAKE256 are used in CMS. The id-shake128 and id-shake256 digest algorithm identifiers are used and the parameters field MUST be omitted. +=====================+==========================+ | Signature algorithm | Message digest algorithm | +=====================+==========================+ | ML-DSA-44 | SHAKE128 | +---------------------+--------------------------+ | ML-DSA-65 | SHAKE256 | +---------------------+--------------------------+ | ML-DSA-87 | SHAKE256 | +---------------------+--------------------------+ Table 1: Recommended message digest algorithms for ML-DSA signature algorithms signatureAlgorithm: When signing a signed-data using ML-DSA, the signatureAlgorithm field MUST contain one of the ML-DSA signature algorithm OIDs, and the parameters field MUST be absent. The algorithm OID MUST be one of the following OIDs described in Section 2: Salter, et al. Expires 8 May 2025 [Page 8] Internet-Draft ML-DSA in CMS November 2024 +=====================+==========================+ | Signature algorithm | Algorithm Identifier OID | +=====================+==========================+ | ML-DSA-44 | id-ml-dsa-44 | +---------------------+--------------------------+ | ML-DSA-65 | id-ml-dsa-65 | +---------------------+--------------------------+ | ML-DSA-87 | id-ml-dsa-87 | +---------------------+--------------------------+ Table 2: Signature algorithm identifier OIDs for ML-DSA signature: The signature field contains the signature value resulting from the use of the ML-DSA signature algorithm identified by the signatureAlgorithm field. The ML-DSA (pure mode) signature generation operation is specified in Section 5.2 of [FIPS204], and the signature verification operation is specified in Section 5.3 of [FIPS204]. Note that Section 5.6 of [RFC5652] places further requirements on the successful verification of a signature. 5. Security Considerations The relevant security considerations from [RFC5652] apply to this document as well. The security considerations for [I-D.ietf-lamps-dilithium-certificates] are equally applicable to this document. Security of the ML-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures. By default ML-DSA signature generation uses randomness from two sources: fresh random data generated during signature generation, and precomputed random data included in the signer's private key. This is referred to as the "hedged" variant of ML-DSA. Inclusion of both sources of random can help mitigate against faulty random number generators and side-channel attacks. [FIPS204] also permits creating deterministic signatures using just the precomputed random data in the signer's private key. The signer SHOULD NOT use the deterministic variant of ML-DSA on platforms where side-channel attacks are a concern. Salter, et al. Expires 8 May 2025 [Page 9] Internet-Draft ML-DSA in CMS November 2024 6. IANA Considerations IANA is requested to assign an object identifier for id-mod-ml-dsa- 2024, for the ASN.1 module identifier found in Appendix A. This should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 7. Acknowledgments TODO acknowledgements. 8. References 8.1. Normative References [CSOR] NIST, "Computer Security Objects Register", 20 August 2024, . [FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard", 13 August 2024, . [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- 05, 4 November 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References Salter, et al. Expires 8 May 2025 [Page 10] Internet-Draft ML-DSA in CMS November 2024 [FIPS202] "SHA-3 standard :: permutation-based hash and extendable- output functions", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.202, 2015, . [FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.203, August 2024, . [I-D.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-12, 4 November 2024, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . [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, . [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, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, . Salter, et al. Expires 8 May 2025 [Page 11] Internet-Draft ML-DSA in CMS November 2024 [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, . [X680] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.680 (2021) | ISO/IEC 8824-1:2021.", February 2021, . Appendix A. ASN.1 Module ML-DSA-Module-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-ml-dsa-2024(TBD) } 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 -- sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 3 } id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 } id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 } id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 } -- -- Signature Algorithm Identifiers -- sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ml-dsa-44 PARAMS ARE absent PUBLIC-KEYS { pk-ml-dsa-44 } SMIME-CAPS { IDENTIFIED BY id-ml-dsa-44 } } Salter, et al. Expires 8 May 2025 [Page 12] Internet-Draft ML-DSA in CMS November 2024 sa-ml-dsa-65 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ml-dsa-65 PARAMS ARE absent PUBLIC-KEYS { pk-ml-dsa-65 } SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 } } sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ml-dsa-87 PARAMS ARE absent PUBLIC-KEYS { pk-ml-dsa-87 } SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 } } -- -- Public Keys -- pk-ml-dsa-44 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-44 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-ml-dsa-65 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-65 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-ml-dsa-87 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-87 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } ML-DSA-PublicKey ::= OCTET STRING ML-DSA-PrivateKey ::= OCTET STRING -- -- Expand the signature algorithm set used by CMS [RFC5911] -- SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { sa-ml-dsa-44 | Salter, et al. Expires 8 May 2025 [Page 13] Internet-Draft ML-DSA in CMS November 2024 sa-ml-dsa-65 | sa-ml-dsa-87, ... } SMimeCaps SMIME-CAPS ::= { sa-ml-dsa-44.&smimeCaps | sa-ml-dsa-65.&smimeCaps | sa-ml-dsa-87.&smimeCaps, ... } END Authors' Addresses Ben Salter UK National Cyber Security Centre Email: ben.s3@ncsc.gov.uk Adam Raine UK National Cyber Security Centre Email: adam.r@ncsc.gov.uk Daniel Van Geest CryptoNext Security Email: daniel.vangeest@cryptonext-security.com Salter, et al. Expires 8 May 2025 [Page 14]