]> NIO Inc.

lijun.liao@nio.io

This document registers post-quantum algorithms in the IANA registries defined by . It extends the C509 certificate specification with post-quantum cryptography (PQC) signature and key encapsulation algorithms: ML-DSA, FN-DSA, ML-KEM, and the stateful hash-based signature algorithms HSS/LMS, XMSS, and XMSS^MT, as well as with composite ML-DSA and ML-KEM algorithms, which combine a PQC algorithm with a traditional algorithm. About This Document Status information for this document may be found at . Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines C509, a compact CBOR encoding of X.509 certificates and certification requests, and establishes a set of IANA registries, including the "C509 Signature Algorithms" and "C509 Public Key Algorithms" registries. That specification populates these registries with commonly used values and anticipates that new algorithms, including post-quantum algorithms, are registered as they are specified. This document adds entries to the C509 Signature Algorithms and C509 Public Key Algorithms registries for PQC signature and key encapsulation algorithms: ML-DSA, FN-DSA, ML-KEM, and the stateful hash-based signature algorithms HSS/LMS, XMSS, and XMSS^MT. It also adds entries for the composite ML-DSA and ML-KEM algorithms, which combine a PQC algorithm with a traditional algorithm into a single post-quantum/traditional (PQ/T) hybrid algorithm. All new values are registered in the "CBOR Encoded X.509 (C509)" registry group, following the registration procedures defined in .

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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology and registry structure defined in . The CBOR terminology of applies.

Additional Signature Algorithms This section defines additional entries for the C509 Signature Algorithms registry established in .

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) ML-DSA is a lattice-based digital signature algorithm standardized by NIST as and specified for use in X.509 PKI by . In C509, the signature value (issuerSignatureValue in a C509 certificate, subjectSignatureValue in a C509 certification request) is a byte string containing the raw ML-DSA signature. For natively signed C509 certificates and certification requests, the ML-DSA signature is computed over the CBOR-encoded TBSCertificate or TBSCertificationRequest, respectively, with the context string (ctx) set to the empty string, as specified in for the DER-encoded structures.

FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm) FN-DSA is a lattice-based digital signature algorithm based on Falcon, standardized by NIST as and specified for use in X.509 PKI by . In C509, the signature value (issuerSignatureValue in a C509 certificate, subjectSignatureValue in a C509 certification request) is a byte string containing the raw FN-DSA signature. For natively signed C509 certificates and certification requests, the FN-DSA signature is computed over the CBOR-encoded TBSCertificate or TBSCertificationRequest, respectively, with the context string (ctx) set to the empty string, as specified in for the DER-encoded structures. The OIDs id-fn-dsa-512 and id-fn-dsa-1024 have not yet been assigned by NIST. The final arc of each OID and the last byte of each DER encoding below are therefore given as TBD. Likewise, the signature sizes are given as TBD until is finalized.

Stateful Hash-Based Signature Algorithms (HSS/LMS, XMSS, XMSS^MT) The Hierarchical Signature System (HSS) built on the Leighton-Micali Signature (LMS) scheme is defined in ; its use in X.509 PKI is specified in and . The eXtended Merkle Signature Scheme (XMSS) and its multi-tree variant (XMSS^MT) are defined in ; their use in X.509 PKI is specified in . For all three schemes, the C509 signature value is a byte string containing the raw signature. All three are stateful signature schemes. Their signature sizes depend on the chosen parameter set, while their public key sizes depend only on the hash output length; see .

Composite ML-DSA Signature Algorithms Composite ML-DSA combines an ML-DSA component with a traditional signature algorithm (RSA, ECDSA, Ed25519, or Ed448) into a single signature algorithm for use in X.509 PKI. These algorithms are defined in , which assigns their OIDs under the PKIX algorithms arc (1.3.6.1.5.5.7.6). In C509, the signature value is a byte string containing the composite signature value as serialized by SerializeSignatureValue in , i.e., the ML-DSA signature followed by the traditional signature, exactly as in X.509. The traditional component is not re-encoded. In particular, ECDSA signatures remain DER-encoded Ecdsa-Sig-Value structures, so the size of composite signatures with an ECDSA component varies slightly. This is the same encoding as used for composite ML-DSA signatures in JOSE and COSE , so composite signature values need no conversion between X.509, C509, and COSE. For natively signed C509 certificates and certification requests, the composite signature is computed with the Composite-ML-DSA.Sign function of , with the message M set to the CBOR-encoded TBSCertificate or TBSCertificationRequest, respectively, and the application context string (ctx) set to the empty string.

Additional Public Key Algorithms This section defines additional entries for the C509 Public Key Algorithms registry established in . As required by , a public key algorithm that can only be used with one signature algorithm and that has the same OID as that signature algorithm is assigned the same integer value in both registries. This applies to the ML-DSA, FN-DSA, HSS/LMS, XMSS, XMSS^MT, and composite ML-DSA entries below. The ML-KEM and composite ML-KEM entries have no counterpart in the C509 Signature Algorithms registry.

ML-DSA Public Keys ML-DSA public keys in X.509 certificates are encoded as specified in . In C509, the subjectPublicKey field is a byte string containing the raw ML-DSA public key. The values TBD1, TBD2, and TBD3 are the same as in the C509 Signature Algorithms registry.

FN-DSA Public Keys FN-DSA public keys in X.509 certificates are encoded as specified in . In C509, the subjectPublicKey field is a byte string containing the raw FN-DSA public key. The public key sizes are given as TBD until is finalized. The values TBD4 and TBD5 are the same as in the C509 Signature Algorithms registry.

ML-KEM Public Keys (Key Encapsulation Mechanism) ML-KEM is a lattice-based key encapsulation mechanism standardized by NIST as and specified for use in X.509 PKI by . In C509, the subjectPublicKey field is a byte string containing the raw ML-KEM public key. ML-KEM is not a signature algorithm, so these entries have no counterpart in the C509 Signature Algorithms registry.

Stateful Hash-Based Public Keys HSS/LMS, XMSS, and XMSS^MT public keys in X.509 certificates are encoded as specified in . In C509, the subjectPublicKey field is a byte string containing the raw public key, i.e., the hss_public_key structure of or the xmss_public_key or xmssmt_public_key structure of . Its size depends only on the hash output length n of the parameter set:

• HSS/LMS: 4 + 24 + n bytes, i.e., 52 bytes for n = 24 and 60 bytes for n = 32. The parameter sets with n = 32 are defined in and , and those with n = 24 in .
• XMSS and XMSS^MT: 4 + 2n bytes, i.e., 52 bytes for n = 24, 68 bytes for n = 32, and 132 bytes for n = 64.

The values TBD6, TBD7, and TBD8 are the same as in the C509 Signature Algorithms registry.

Composite ML-DSA Public Keys In C509, the subjectPublicKey field is a byte string containing the composite public key as serialized by SerializePublicKey in , i.e., the ML-DSA public key followed by the traditional public key, exactly as in X.509. The traditional component is not re-encoded: RSA public keys remain DER-encoded RSAPublicKey structures, and ECDSA public keys remain uncompressed points. This is the same encoding as used for the pub parameter of composite ML-DSA keys in JOSE and COSE . The sizes given below for RSA-based composites assume the public exponent 65537. The OIDs are those of the corresponding composite signature algorithms in , and the values TBD9 through TBD26 are the same as in the C509 Signature Algorithms registry.

Composite ML-KEM Public Keys Composite ML-KEM combines an ML-KEM component with a traditional key establishment algorithm (RSA-OAEP, ECDH, X25519, or X448) into a single KEM for use in X.509 PKI. These algorithms are defined in , which assigns their OIDs under the PKIX algorithms arc (1.3.6.1.5.5.7.6). These entries have no counterpart in the C509 Signature Algorithms registry. In C509, the subjectPublicKey field is a byte string containing the composite public key as serialized by SerializePublicKey in , i.e., the ML-KEM public key followed by the traditional public key, exactly as in X.509. As for composite ML-DSA (), the traditional component is not re-encoded, and the sizes given below for RSA-based composites assume the public exponent 65537.

Use in Other C509 Structures

Private Keys defines the C509PrivateKey structure, whose subjectPrivateKeyAlgorithm field takes values from the C509 Public Key Algorithms registry. The entries registered in can therefore be used in C509PrivateKey with any C509 private key type, without further definitions in this document. For example, with C509PrivateKeyType 0, subjectPrivateKey is the PrivateKey OCTET STRING value field of the OneAsymmetricKey structure , encoded as a CBOR byte string. For the algorithms in this document, the PrivateKey content is defined in the following specifications:

• ML-DSA: the ML-DSA-44-PrivateKey, ML-DSA-65-PrivateKey, or ML-DSA-87-PrivateKey defined in , i.e., the 32-byte seed, the expanded private key, or both.
• FN-DSA: the FN-DSA-PrivateKey defined in , i.e., the seed, whose size is TBD until is finalized.
• ML-KEM: the ML-KEM-512-PrivateKey, ML-KEM-768-PrivateKey, or ML-KEM-1024-PrivateKey defined in , i.e., the 64-byte seed, the expanded private key, or both.
• Composite ML-DSA and composite ML-KEM: the composite private key defined in and , respectively.

With C509PrivateKeyType 1, subjectPrivateKey is a COSE_Key. For example, ML-DSA private keys can be represented as COSE_Key using the Algorithm Key Pair (AKP) key type defined in , and composite ML-DSA private keys using the AKP key type as specified in .

Certification Requests A C509 certification request is signed by the subject using the algorithm in subjectSignatureAlgorithm (). ML-KEM and composite ML-KEM keys cannot produce signatures, so a C509 certification request for such a key cannot prove possession of the private key with its own signature. Another proof-of-possession mechanism is required, which this document does not define.

Security Considerations The security considerations of apply to all entries registered in this document. For post-quantum algorithms, implementers should consult the respective NIST standards (, , ) for guidance on security levels and parameter sets. HSS/LMS, XMSS, and XMSS^MT are stateful signature schemes: each one-time key MUST be used to sign at most one message, and the signer has to update its private key state reliably after each signature. Reusing a one-time key undermines the security of the scheme; see the security considerations of , , and . Copying or restoring the private key state, for example by exporting it in a private key structure, can lead to such reuse.

IANA Considerations

C509 Signature Algorithms Registry IANA is requested to register the entries defined in in the "C509 Signature Algorithms" registry within the "CBOR Encoded X.509 (C509)" registry group, following the registration policy defined in .

C509 Public Key Algorithms Registry IANA is requested to register the entries defined in in the "C509 Public Key Algorithms" registry within the "CBOR Encoded X.509 (C509)" registry group, following the registration policy defined in . Per , the public key algorithm entries TBD1 through TBD26 MUST be assigned the same values as the corresponding entries in the "C509 Signature Algorithms" registry.

Suggested Values RFC Editor's Note: Please remove this section before publication. Values in the interval [0, 23] are encoded in one byte, values in the interval [24, 255] in two bytes, and values in the interval [256, 65535] in three bytes (). Negative values are used in mainly for deprecated algorithms, such as those based on SHA-1, and are not suggested for the algorithms in this document. The public keys and signatures of these algorithms are hundreds to thousands of bytes long, so saving one byte per algorithm identifier has little effect on certificate size, whereas the one-byte interval is small. The following assignments are therefore suggested. The suggested value of each entry is also given in parentheses below its TBD value in the tables of and .

• ML-DSA (TBD1 through TBD3): 17, 18, and 19, i.e., values from the interval [0, 23] that are unassigned in both registries, as ML-DSA is expected to be widely used.
• FN-DSA (TBD4 and TBD5): 20 and 21, i.e., values from the interval [0, 23] that are unassigned in both registries, as its compact public keys and signatures make FN-DSA well suited to constrained environments.
• ML-KEM (TBD27 through TBD29): 14, 15, and 16, i.e., values from the interval [0, 23] that are unassigned in the "C509 Public Key Algorithms" registry. In the "C509 Signature Algorithms" registry, these values are assigned to non-signature proof-of-possession algorithms; this is no conflict, as ML-KEM has no entry in that registry.
• HSS/LMS (TBD6): 32, a value from the interval [24, 255] that is unassigned in both registries.
• XMSS and XMSS^MT (TBD7 and TBD8): the last arc of the OID under the PKIX algorithms arc (1.3.6.1.5.5.7.6), i.e., 34 and 35. These values are from the interval [24, 255] and are unassigned in both registries.
• Composite ML-DSA and composite ML-KEM (TBD9 through TBD26 and TBD30 through TBD41): 256 plus the last arc of the OID under the PKIX algorithms arc (1.3.6.1.5.5.7.6), i.e., 293 through 310 for composite ML-DSA, and 311 through 322 for composite ML-KEM. These values are from the interval [256, 65535] and are unassigned in both registries. Composite algorithms are numerous and intended for the transition to post-quantum cryptography, and their public keys and signatures are among the largest in this document, so the additional byte is negligible, and the interval [24, 255] is left for other algorithms.

References Normative References This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document obsoletes RFC 8708. This document specifies algorithm identifiers and ASN.1 encoding formats for the following stateful Hash-Based Signature (HBS) schemes: Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS). This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism. This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO Inc. This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST ML-KEM in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using, the forthcoming, FIPS 206, the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] This document extends HSS/LMS (RFC 8554) by defining parameter sets that use alternative hash functions. These include hash functions that result in signatures with significantly smaller sizes than the signatures that use the RFC 8554 parameter sets and should have sufficient security. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Huawei Huawei Entrust Limited Nokia This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Post- Quantum Traditional (PQ/T) hybrid composite signatures. The composite algorithms described combine the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) as the post-quantum component and either the Elliptic Curve Digital Signature Algorithm (ECDSA) or the Edwards-Curve Digital Signature Algorithm (EdDSA) as the traditional component.

Examples TBD: add examples

Change Log RFC Editor's Note: Please remove this section before publication.

Changes from draft-liao-cose-c509-algorithms-00

• Renamed the document from draft-liao-cose-c509-algorithms to draft-liao-cose-c509-pq-algorithms to reflect its scope.
• Aligned with draft-ietf-cose-cbor-encoded-cert-21:
  • Used the registry group name "CBOR Encoded X.509 (C509)".
  • Gave the DER column as the DER encoding of the complete AlgorithmIdentifier and wrote "Absent" for absent parameters.
  • Referred to the signature value as issuerSignatureValue or subjectSignatureValue.
  • Referenced Section 8.15 of that document for assigning the same value in the signature and public key algorithm registries, and moved this requirement from Security Considerations to IANA Considerations.
• Changed the encoding of composite public keys and signatures from a two-element CBOR array to the serialization defined in and , i.e., the same byte string as in X.509.
• Added FN-DSA signature and public key algorithms.
• Renumbered the TBD values to follow the order of the document.
• Specified the context string for natively signed ML-DSA, FN-DSA, and composite ML-DSA signatures.
• Specified the public key sizes of HSS/LMS, XMSS, and XMSS^MT.
• Added suggested values to the IANA considerations and to the registry tables.
• Added a section on the use of the registered algorithms in C509 private keys and certification requests.
• Added security considerations for stateful hash-based signature algorithms.
• Removed unused references.
• Editorial improvements.

Acknowledgements The authors would like to thank xxx for reviewing and commenting on earlier versions of this document.