]> NIO Inc.

China lijun.liao@nio.io

This document registers additional algorithms in the IANA registries defined by . It extends the base C509 certificate specification with post-quantum cryptography (PQC) signature and key-encapsulation algorithms including ML-DSA, ML-KEM, stateful hash-based algorithms (HSS/LMS, XMSS, XMSS^MT), and composite algorithms. 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 IANA registries for algorithms, extensions, RDN attribute types, and CR attribute types. The base specification populates these registries with a set of commonly used values. This document adds additional entries to the algorithm registries, focusing on post-quantum cryptography (PQC) algorithms for signatures and key encapsulation, including ML-DSA, ML-KEM, stateful hash-based algorithms (HSS/LMS, XMSS, XMSS^MT), and composite algorithms. All new values are registered under the "CBOR Encoded X.509 (C509)" registry group. This document follows 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 .

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 field is a bytes value containing the raw ML-DSA signature bytes.

Stateful Hash-Based Signature Algorithms (HSS/LMS, XMSS, XMSS^MT) HSS and XMSS are stateful hash-based signature algorithms. The Hierarchical Signature System (HSS) over the Leighton-Micali Signature (LMS) scheme is defined in and its use in X.509 PKI is specified by and . The eXtended Merkle Signature Scheme (XMSS) and its multi-tree variant (XMSS^MT) are defined in and their use in X.509 PKI is specified by . In C509, the signature field is a bytes value containing the raw signature bytes for all three schemes. Note: These are stateful signature schemes. Signature and public key sizes depend on the chosen parameter set.

Composite ML-DSA Signature Algorithms Composite ML-DSA combines a Module-Lattice-Based Digital Signature Algorithm (ML-DSA) component with a traditional signature algorithm (RSA, ECDSA, Ed25519, or Ed448) to form a single composite signature algorithm suitable for use in X.509 PKI structures. These algorithms are defined in and assigned OIDs under the PKIX algorithms arc (1.3.6.1.5.5.7.6). In C509, composite signature values are encoded as a two-element CBOR array CompositeSignatureValue rather than as raw concatenated bytes. The first element holds the raw ML-DSA signature bytes; the second element holds the traditional signature encoded as specified in . Parameters are absent.

Additional Public Key Algorithms This section defines additional entries for the C509 Public Key Algorithms Registry established in . When an algorithm OID appears in both the C509 Signature Algorithms Registry and the C509 Public Key Algorithms Registry, the same integer value is assigned in both registries. This shared numbering allows decoders to use a single OID lookup table. Algorithm OIDs that exist only as public key algorithms (e.g., key encapsulation mechanisms such as ML-KEM) receive unique integer values not used in the signature registry.

ML-DSA Public Keys ML-DSA public keys in X.509 certificates are encoded as per . In C509, the subjectPublicKey field is a bytes value containing the raw ML-DSA public key bytes. The integer values TBD1, TBD2, and TBD3 are shared with 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 . ML-KEM OIDs do not appear in the signature registry, so TBD25, TBD26, and TBD27 are assigned exclusively to this registry.

Stateful Hash-Based Public Keys HSS/LMS, XMSS, and XMSS^MT public keys in X.509 certificates are encoded as per . In C509, the subjectPublicKey field is a bytes value containing the raw public key bytes. Public key size depends on the chosen parameter set.

Composite ML-DSA Public Keys In C509, composite public keys are encoded as a two-element CBOR array CompositePublicKey rather than as raw concatenated bytes. Each element uses the C509 encoding of the corresponding standalone algorithm per : ML-DSA public keys as raw bytes per ; ECDSA public keys as the compressed or uncompressed EC point; EdDSA public keys as raw bytes per ; and RSA public keys as specified in , i.e., the modulus encoded as an unwrapped CBOR unsigned bignum (~biguint) with the exponent omitted when 65537. The OIDs are the same as for the corresponding composite signature algorithms in .

Composite ML-KEM Public Keys Composite ML-KEM combines an ML-KEM component with a traditional key encapsulation mechanism (RSA-OAEP, ECDH, or X25519/X448) to form a composite KEM for use in X.509 PKI structures. These algorithms are defined in and assigned OIDs under the PKIX algorithms arc (1.3.6.1.5.5.7.6). Composite ML-KEM OIDs do not appear in the signature registry, so TBD28 through TBD39 are assigned exclusively to this registry. In C509, composite KEM public keys are encoded using the same CompositePublicKey CDDL structure defined in , where pqc holds the raw ML-KEM public key bytes and trad holds the C509 encoding of the traditional public key per . ECDH public keys use the compressed or uncompressed ECDH point; X25519 and X448 keys use the raw 32- or 56-byte key per ; RSA public keys are encoded as specified in .

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 security level and parameter guidance. When selecting algorithm value assignments, values for public key algorithms whose OID is the same as the corresponding signature algorithm MUST be assigned the same integer value. This shared-integer policy is defined in this document to reduce decoder complexity.

IANA Considerations

C509 Signature Algorithms Registry IANA is requested to assign values in the "C509 Signature Algorithms" registry under the registry group "CBOR Encoded X.509 (C509) Parameters" for the entries defined in . The registration policy follows the policy defined in .

C509 Public Key Algorithms Registry IANA is requested to assign values in the "C509 Public Key Algorithms" registry under the registry group "CBOR Encoded X.509 (C509) Parameters" for the entries defined in . The registration policy follows the policy defined in .

Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. 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. 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. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. 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. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO 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. 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.

Examples TBD: add examples

Acknowledgements The authors want to thank xxx for reviewing and commenting on intermediate versions of the draft.