Internet-Draft ML-DSA in CMS November 2024
Salter, et al. Expires 26 May 2025 [Page]
Workgroup:
Limited Additional Mechanisms for PKIX and SMIME
Internet-Draft:
draft-ietf-lamps-cms-ml-dsa-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Salter
UK National Cyber Security Centre
A. Raine
UK National Cyber Security Centre
D. Van Geest
CryptoNext Security

Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)

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 possession 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:[email protected]), 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.

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 26 May 2025.

▲

Table of Contents

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 [FIPS205], an alternative post-quantum signature algorithm also standardised by NIST. This document specifies the use of the ML-DSA in CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See Appendix B of [I-D.ietf-lamps-dilithium-certificates] for more information on the security levels and key sizes of ML-DSA.

Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Dilithium are not compatible.

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.

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. The same AlgorithmIdentifiers are used to identify ML-DSA public keys and signature algorithms. [I-D.ietf-lamps-dilithium-certificates] describes the use of ML-DSA in X.509 certificates. The AlgorithmIdentifier type is defined as follows:

AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
        SEQUENCE {
            algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
            parameters  ALGORITHM-TYPE.
                   &Params({AlgorithmSet}{@algorithm}) OPTIONAL
        }

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 }

3. ML-DSA Key Encoding

[RFC5280] defines the SubjectPublicKeyInfo ASN.1 type. In X.509 certificates [RFC5280] and Certificate Management over CMS [RFC5272], the SubjectPublicKeyInfo type is used to encode public keys. It has the following syntax:

  SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE {
      algorithm        AlgorithmIdentifier {PUBLIC-KEY, {IOSet}},
      subjectPublicKey BIT STRING
  }

The PUBLIC-KEY ASN.1 types for ML-DSA are defined here:

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 (SIZE (1312 | 1952 | 2592))

ML-DSA-PrivateKey ::= OCTET STRING (SIZE (32))

Algorithm 22 in Section 7.2 of [FIPS204] defines the raw byte string encoding of an ML-DSA public key. When used in a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains the raw byte string encoding of the public key.

When an ML-DSA public key appears outside of a SubjectPublicKeyInfo type in an environment that uses ASN.1 encoding, it can be encoded as an OCTET STRING by using the ML-DSA-PublicKey type.

[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].

When the ML-DSA private key appears outside of an Asymmetric Key Package in an environment that uses ASN.1 encoding, it can be encoded as an OCTET STRING by using the ML-DSA-PrivateKey type.

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] and SLH-DSA [FIPS205] 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 this document follows the convention set by EdDSA in CMS [RFC8419] and SLH-DSA in CMS [I-D.ietf-lamps-cms-sphincs-plus] and only specifies use of the pure mode of ML-DSA in CMS.

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.

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 the complete DER encoding of the SignedAttrs value contained in the SignerInfo's signedAttrs field. As described in Section 5.4 of [RFC5652], this encoding includes 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.

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.

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.

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. SHA-512 [FIPS180] MUST be supported for use with the variants of SLH-DSA in this document; however, other hash functions MAY also be supported. When SHA-512 is used, the id-sha512 [RFC5754] digest algorithm identifier is used and the parameters field MUST be omitted. When signing using ML-DSA without including signed attributes, the algorithm specified in the digestAlgorithm field has no meaning, as ML-DSA computes signatures over entire messages rather than externally computed digests. Nonetheless, it SHOULD specify a digest algorithm that otherwise would have been used if signed attributes were present, such as SHA-512. When processing a SignerInfo signed using ML-DSA, if no signed attributes are present, implementations MUST ignore the content of the digestAlgorithm field.

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:

Table 1: Signature algorithm identifier OIDs for ML-DSA
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
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 security considerations [RFC5652] and [I-D.ietf-lamps-dilithium-certificates] apply to this specification as well.

Security of the ML-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures.

ML-DSA depends on high quality random numbers that are suitable for use in cryptography. The use of inadequate pseudo-random number generators (PRNGs) to generate such values can significantly undermine the security properties offered by a cryptographic algorithm. For instance, an attacker may find it much easier to reproduce the PRNG environment that produced any private keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of random numbers of a sufficient level of quality for use in cryptography is difficult, and [RFC4086] offers important guidance in this area.

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, side-channel attacks and fault attacks. [FIPS204] also permits creating deterministic signatures using just the precomputed random data in the signer's private key. The same verification algorithm is used to verify both hedged and deterministic signatures, so this choice does not affect interoperability. The signer SHOULD NOT use the deterministic variant of ML-DSA on platforms where side-channel attacks or fault attacks are a concern. Side channel attacks and fault attacks against ML-DSA are an active area of research [WNGD2023] [KPLG2024]. Future protection against these styles of attack may involve interoperable changes to the implementation of ML-DSA's internal functions. Implementers SHOULD consider implementing such protection measures if it would be beneficial for their particular use cases.

To avoid algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in [RFC6211] SHOULD be included in signed attributes.

6. Operational Considerations

If ML-DSA signing is implemented in a hardware device such as hardware security module (HSM) or portable cryptographic token, implementers might want to avoid sending the full content to the device for performance reasons. 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.

This approach addresses the use case for HashML-DSA, and is one reason why HashML-DSA is not specified for use with CMS in this document. Additionally, the pure variant of ML-DSA does support a form of pre-hash via the mu "message representative" value described in Section 6.2 of [FIPS204]. This value may "optionally be computed in a different cryptographic module" and supplied to the hardware device, rather than requiring the entire message to be transmitted.

7. IANA Considerations

For the ASN.1 module found in Appendix A, IANA is requested to assign an object identifier for the module identifier (TBD) with a description of "id-mod-ml-dsa-2024". This should be allocated in the "SMI Security for S/MIME Module Identifier" registry (1.2.840.113549.1.9.16.0).

8. Acknowledgments

This document was heavily influenced by [RFC8419], [I-D.ietf-lamps-cms-sphincs-plus], and [I-D.ietf-lamps-dilithium-certificates]. Thanks go to the authors of those documents.

9. References

9.1. Normative References

[CSOR]
NIST, "Computer Security Objects Register", , <https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration>.
[FIPS204]
"Module-Lattice-Based Digital Signature Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.204, , <https://doi.org/10.6028/nist.fips.204>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-05>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/rfc/rfc5652>.
[RFC5754]
Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, , <https://www.rfc-editor.org/rfc/rfc5754>.
[RFC6211]
Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute", RFC 6211, DOI 10.17487/RFC6211, , <https://www.rfc-editor.org/rfc/rfc6211>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

9.2. Informative References

[FIPS180]
"Secure hash standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.180, , <https://doi.org/10.6028/nist.fips.180>.
[FIPS205]
"Stateless Hash-Based Digital Signature Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.205, , <https://doi.org/10.6028/nist.fips.205>.
[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-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-sphincs-plus-16>.
[KPLG2024]
Krahmer, E., Pessl, P., Land, G., and T. Güneysu, "Correction Fault Attacks on Randomized CRYSTALS-Dilithium", , <https://ia.cr/2024/138>.
[RFC4086]
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfc-editor.org/rfc/rfc4086>.
[RFC5272]
Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, , <https://www.rfc-editor.org/rfc/rfc5272>.
[RFC5911]
Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, , <https://www.rfc-editor.org/rfc/rfc5911>.
[RFC5958]
Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, , <https://www.rfc-editor.org/rfc/rfc5958>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8419]
Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, , <https://www.rfc-editor.org/rfc/rfc8419>.
[WNGD2023]
Wang, R., Ngo, K., Gärtner, J., and E. Dubrova, "Single-Trace Side-Channel Attacks on CRYSTALS-Dilithium: Myth or Reality?", , <https://ia.cr/2023/1931>.
[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.", , <https://www.itu.int/rec/T-REC-X.680>.

Appendix A. ASN.1 Module 

<CODE BEGINS>
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 } }

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 (SIZE (1312 | 1952 | 2592))

ML-DSA-PrivateKey ::= OCTET STRING (SIZE (32))

--
-- Expand the signature algorithm set used by CMS [RFC5911]
--

SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= {
  sa-ml-dsa-44 |
  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
<CODE ENDS>

Authors' Addresses

Ben Salter
UK National Cyber Security Centre
Adam Raine
UK National Cyber Security Centre
Daniel Van Geest
CryptoNext Security