This document is almost ready, but there are some details that need to be extended and corrected. (A long list, most of them are easy to be corrected, but quite difficult to be fixed once the draft becomes RFC).
Best Lijun Below the complete list: 1. TLS support The draft needs to be extended to define the encoding of C509 name in the TLS context. The raw CBOR encoded name does not apply in the TLS 1.2 and 1.3 spec. (Details in https://github.com/cose-wg/CBOR-certificates/issues/287) 2. Assignment of key algorithms and signature algorithms Use the same number (id) for the signature algorithm and the key algorithm if the key can only be used for one signature algorithm. In the X.509 world, many key types have the same algorithm identifier to identify the key and the corresponding signature algorithm, e.g. Ed25519, Ed448, ML-DSA-{44|65|87}, and the composite keys (see https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/). In draft-16, Ed25519 has different numbers (10 in key, 12 in signature), and also Ed448(11 in key, and 13 in signature). If still possible, please change them to use the same value. (Details in https://github.com/cose-wg/CBOR-certificates/issues/291) 3. C509CertificateRequestTemplate The C509CertificateRequestTemplate shall be extended to support flexible Subject and Extensions in the request. In draft-16, the list of Subject RDNs and extension IDs are fixed. Such limitations are in the praxis difficult to satisfy. (Details in https://github.com/cose-wg/CBOR-certificates/issues/293) 4. Reduce the number of Certificate Request Types In the draft-16, there are 4 types for the certificate request, and the following two seem to be redundant. Type 1: CBOR re-encoded request to apply for C509 type 2 certificate. Type 2: CBOR-encoded request to apply for X.509 certificate These two types are not necessary and make it difficult to understand and implement. They can be implemented in other way, e.g. via different interface, here some examples: https://example.org/enroll-c509-cert/via-c509type3req to replace type 1. https://example.org/enroll-x509-cert/via-c509type0req to replace type 2. (Details in https://github.com/cose-wg/CBOR-certificates/issues/298) 5. Add signature algorithm id-alg-unsigned A certificate with alg-unsigned contains zero-length signature value, and reduces the certificate size dramatically. Such certificates are useful for trust-anchor certificates where signature value will not be validated. Especially in the IoT world, the size reduction (64 bytes for P256 signature, and 256 bytes for RSA 2048 signatures) is not ignorable. In the C509-context, the signature can be either empty bstr or null, both with 1 wired byte. (Details in https://github.com/cose-wg/CBOR-certificates/issues/303) 6. Missing C509 type for public key In draft -16, there is no syntax to save / transport the public key. And we also need a media type for this. (Details in https://github.com/cose-wg/CBOR-certificates/issues/297) 7. Extension CRLDistributionPoints: extend the definition to support cRLIssuer and reasons (high priority) In draft -16, the cRLIssuer and reasons are not permitted. However, cRLIssuer is widely used in many PKIs e.g gemany ehealth gematik, if the CA itself does not issuing the CRL. (Details in https://github.com/cose-wg/CBOR-certificates/issues/292) 8. Extensions AuthorityKeyIdentifier and SubjectKeyIdentifier (nice-to-have change) In self-signed certificates, both extensions have the same identifier. Optimization is still possible here by changing the AuthorityKeyIdentifier to null, which in general saves 20 bytes. (Details in https://github.com/cose-wg/CBOR-certificates/issues/286). 9. Extension PolicyMappings: extend the syntax to support policy with number id In draft-16, extension Policy Mappings allows only policy identified by oid, it shall be extended to support the certificate policies defined in "Figure 13: C509 Certificate Policies". (Details: https://github.com/cose-wg/CBOR-certificates/issues/294) 10. Extensions Extension IP Resource and IP Resources v2 In draft-16, SAFI is not supported, please add support of SAFI. SAFI represents the sub AFI, e.g. multi-case, uni-cast, and will be used in some cases. And in draft-16, delta of addresses is used, this is quite complex to implement and also difficult to understand. Please encode the absolute value instead delta of the address value. (Details: https://github.com/cose-wg/CBOR-certificates/issues/295) 11. Extension AS Resources and AS Resources v2 In draft-16, the delta values are used. This is quite complex to implement and also difficult to understand. Please encode the absolute value instead delta of the address value. (Details: https://github.com/cose-wg/CBOR-certificates/issues/296) 12. SCT extension In draft-16, SCT extensions are not allowed. Please re-review it to add the support of extensions. (Details: https://github.com/cose-wg/CBOR-certificates/issues/272) > On 27. Jan 2026, at 17:52, The IESG <[email protected]> wrote: > > > The IESG has received a request from the CBOR Object Signing and Encryption > WG (cose) to consider the following document: - 'CBOR Encoded X.509 > Certificates (C509 Certificates)' > <draft-ietf-cose-cbor-encoded-cert-16.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > [email protected] mailing lists by 2026-02-10. Exceptionally, comments may > be sent to [email protected] instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > 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, common certificate > profiles and 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 over the CBOR encoding instead > of the DER encoding, avoiding the use of ASN.1. Both types of > certificates have the same semantics as X.509 and the same reduced > size compared to X.509. > > The document also specifies CBOR encoded data structures for > certificate (signing) requests and certificate request templates, new > COSE headers, as well as a TLS certificate type and a file format for > C509. This document updates RFC 6698; the TLSA selectors registry is > extended to include C509 certificates. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
