From adafc557bbcc8a77a5816ea8041a33d4ce3518a1 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 29 Oct 2024 13:52:22 +0000 Subject: [PATCH] Script updating gh-pages from a4d5d77. [ci skip] --- draft-ietf-lamps-cms-ml-dsa.html | 1802 ++++++++++++++++++++++++++++++ draft-ietf-lamps-cms-ml-dsa.txt | 618 ++++++++++ index.html | 11 +- 3 files changed, 2430 insertions(+), 1 deletion(-) create mode 100644 draft-ietf-lamps-cms-ml-dsa.html create mode 100644 draft-ietf-lamps-cms-ml-dsa.txt diff --git a/draft-ietf-lamps-cms-ml-dsa.html b/draft-ietf-lamps-cms-ml-dsa.html new file mode 100644 index 0000000..123c80c --- /dev/null +++ b/draft-ietf-lamps-cms-ml-dsa.html @@ -0,0 +1,1802 @@ + + + + + + +Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftML-DSA in CMSOctober 2024
Salter, et al.Expires 2 May 2025[Page]
+
+
+
+
Workgroup:
+
Limited Additional Mechanisms for PKIX and SMIME
+
Internet-Draft:
+
draft-ietf-lamps-cms-ml-dsa-latest
+
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 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.

+

+ 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 2 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 [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.

+
+
+
+
+
+
+

+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 }
+
+
+
+
+
+
+
+

+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.

+
+
+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.

+
+
+
+
+

+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.

+

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.

+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+Table 1: +Recommended message digest algorithms for ML-DSA signature algorithms +
Signature algorithmMessage digest algorithm
ML-DSA-44SHAKE128
ML-DSA-65SHAKE256
ML-DSA-87SHAKE256
+
+
+
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 2: +Signature algorithm identifier OIDs for ML-DSA +
Signature algorithmAlgorithm Identifier OID
ML-DSA-44id-ml-dsa-44
ML-DSA-65id-ml-dsa-65
ML-DSA-87id-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 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.

+
+
+
+
+

+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", , <https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration>.
+
+
[FIPS204]
+
+NIST, "Module-Lattice-Based Digital Signature Standard", , <https://csrc.nist.gov/pubs/fips/204/final>.
+
+
[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-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-04>.
+
+
[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>.
+
+
[RFC5652]
+
+Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/rfc/rfc5652>.
+
+
[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>.
+
+
+
+
+
+
+

+8.2. Informative References +

+
+
[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, , <https://doi.org/10.6028/nist.fips.202>.
+
+
[FIPS203]
+
+"Module-Lattice-Based Key-Encapsulation Mechanism Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.203, , <https://doi.org/10.6028/nist.fips.203>.
+
+
[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-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-sphincs-plus-09>.
+
+
[RFC5272]
+
+Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, , <https://www.rfc-editor.org/rfc/rfc5272>.
+
+
[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>.
+
+
[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>.
+
+
[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, , <https://www.rfc-editor.org/rfc/rfc8702>.
+
+
[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
+
+ML-DSA-PrivateKey ::= OCTET STRING
+
+
+--
+-- 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
+ +
+
+
+ + + diff --git a/draft-ietf-lamps-cms-ml-dsa.txt b/draft-ietf-lamps-cms-ml-dsa.txt new file mode 100644 index 0000000..b37aa74 --- /dev/null +++ b/draft-ietf-lamps-cms-ml-dsa.txt @@ -0,0 +1,618 @@ + + + + +Limited Additional Mechanisms for PKIX and SMIME B. Salter +Internet-Draft A. Raine +Intended status: Standards Track UK National Cyber Security Centre +Expires: 2 May 2025 D. Van Geest + CryptoNext Security + 29 October 2024 + + + Use of the ML-DSA Signature Algorithm in the Cryptographic Message + Syntax (CMS) + draft-ietf-lamps-cms-ml-dsa-latest + +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. + + 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 2 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 + 1.1. Conventions and Definitions + 2. ML-DSA Algorithm Identifiers + 3. ML-DSA Key Encoding + 4. Signed-data Conventions + 4.1. Pure mode vs pre-hash mode + 4.2. Signature generation and verification + 4.3. SignerInfo content + 5. Security Considerations + 6. IANA Considerations + 7. Acknowledgments + 8. References + 8.1. Normative References + 8.2. Informative References + Appendix A. ASN.1 Module + Authors' Addresses + +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. + +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 } + +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. + + 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. + +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. + + 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: + + +=====================+==========================+ + | 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. + +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- + 04, 22 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, + . + + [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 + + [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-09, 21 + August 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, . + + [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 } } + + 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 | + 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 diff --git a/index.html b/index.html index 0979022..0468660 100644 --- a/index.html +++ b/index.html @@ -15,13 +15,22 @@

Editor's drafts for main branch of lamps-wg/cms-ml-dsa

View saved issues, or the latest GitHub issues and pull requests in the repo.

+ + + + + + + + +
ML-DSA in CMSplain textdatatrackerdiff with last submission

Preview for branch dvg

Preview for branch dvg/my_original_review

- +
ML-DSA in CMS plain textdiff with mainsame as main