Summary

  • draft-ietf-cose-cbor-encoded-cert-21 defines compact CBOR certificates as either reversible X.509 re-encodings or objects signed natively over CBOR.
  • Successful decoding and signature verification do not establish trust: the draft still requires RFC 5280 path validation and treats COSE-carried certificate material as untrusted input.
  • IANA code points make formats and algorithms nameable; they do not recommend those algorithms or authorize their use.

Two compact objects, two signature receipts

C509 is often described through its byte count, but its first operational distinction is what the issuer actually signed. Type 3 re-encodes a DER X.509 certificate in CBOR. The transformation is invertible, so a recipient can reconstruct the original DER object and verify the existing signature with legacy certificate software. Type 2 is native C509: its signature covers the CBOR TBSCertificate directly and therefore avoids ASN.1 and DER in the signed path.

Those two objects may express the same certificate semantics, yet their verification receipts are not interchangeable. A type 3 record needs the reconstructed DER bytes that were presented to signature verification. A type 2 record needs the canonical CBOR bytes. A dashboard that reports only “C509 parsed” has omitted the identity of the signed object.

The compactness comes from domain knowledge. Static and redundant fields disappear, many OIDs become short integers, time values and some elliptic-curve points become smaller, and certificate fields are represented directly in CBOR. That can matter on low-power or low-bandwidth links. It is still a representation result. It does not establish who controls the private key today, whether the issuer is trusted for this purpose, whether the chain is timely, or whether the application should act.

The path did not get shorter

The draft states the boundary plainly: C509 does not change the security assumptions of X.509, and the same RFC 5280 path validation must run before the certificate can be considered trusted. Signature verification establishes integrity under a public key. Path validation asks a larger question about trust anchors, issuer constraints, time, policies, names, critical extensions and purpose.

COSE transport does not erase that distinction. The c5b, c5c, c5t and c5u fields carry certificate material or references, but their contents are untrusted input. A self-signed certificate delivered there must not update the local trust-anchor set without separate authorization. Placing a field in a protected COSE header can authenticate the enclosing message; it does not appoint the enclosed certificate as a new root of trust.

C509 also adds a TLS certificate type, media types, CoAP content formats and a TLSA selector. Each makes the new representation interoperably identifiable. None supplies the missing policy. A TLSA record still has its own DNSSEC, usage, selector and matching evidence. A TLS negotiation still needs service identity and application checks. A successful parser still needs a trust decision.

A registry is a dictionary, not an allow-list

The new C509 registries contain compact identifiers for certificate fields, algorithms, extensions and names. The draft warns that registration is not a recommendation. Deprecated algorithms may receive code points so existing certificates can be represented without loss.

That is why the current TLS Certificate Types registry can list C509 as value 4 with Recommended = N while the draft is already IESG-approved. The registry entry answers “what does this number mean?” The recommendation column expresses a different governance signal, and local algorithm policy answers a third question. Treating any one of them as a universal allow-list would collapse naming, consensus and deployment authority.

The size tables need the same discipline. C509 produces strong reductions for some profiled IoT certificates. Brotli can separately compress repetition across an entire chain. With FN-DSA and ML-DSA chains, large public keys and signatures dominate, so both techniques save much less. These are controlled examples, not evidence that a named network saved energy, shortened a handshake or improved reliability.

Conversion creates its own boundary

Legacy deployments may put C509-to-X.509 conversion in a border gateway so constrained links carry the smaller object while an unchanged endpoint receives DER. The draft notes the cost: this arrangement requires certificates to be unencrypted and may violate identity protection. Protocols that encrypt certificates end to end require endpoint support instead.

Conversion fidelity, parser safety and trust remain separate. Native C509 can remove an ASN.1 attack surface, and conversion can be implemented in constant time. Neither statement proves that a particular implementation is constant-time, complete across extensions, resistant to malformed input, or configured with the right anchors.

Revision 21 was posted on 24 September 2026. It is in the RFC Editor queue and currently blocked for author input. That is a publication workflow state, not a technical rejection. It is also not an RFC number, deployment report or interoperability result.

Sources