Summary

  • The COSE working group submitted revision 21 of its C509 certificate draft on 24 September 2026. The IESG had approved revision 20 in July, but the document remains in the RFC Editor queue; it is not a published RFC.
  • The revision clarifies the CBOR sequence to be signed, fixes byte-string encoding for serial numbers, and confines a shortened issuer field to an octet-identical issuer and subject.
  • Its two certificate types cross different signature boundaries: type 3 preserves and reconstructs a DER-signed X.509 certificate; type 2 signs the CBOR form itself. Neither route dispenses with certificate-path validation.

Imagine a certificate converted into a smaller package for a device that has little bandwidth. The public key and subject may look familiar after conversion, but a verifier does not sign off on resemblance. It checks a defined signature against a defined sequence of bytes. If the conversion path changes that sequence, “same certificate” becomes an assertion requiring proof rather than a property of the label C509.

That is the practical importance of the COSE working group's 24 September revision. The draft calls the whole C509 certificate a CBOR array and makes clear that its elements form a sequence. For a natively signed certificate, the to-be-signed material is the specified TBSCertificate group without the final signature value. This is an editorially important clarification of a signing boundary, not an announcement that an implementation has failed or been attacked.

The revision is unusually concrete about two small fields. A serial number must remain a CBOR byte string even when its value would fit into a normal CBOR unsigned integer. When a type 3 certificate is converted back to X.509, a leading zero is restored if the first remaining byte would otherwise carry a high bit. The issuer can be represented by CBOR null only if issuer and subject are identical octet for octet. A name that merely displays the same way is not enough under that rule. These details constrain reconstruction and interpretation; they do not select a trusted issuer.

C509 offers two routes that should not be collapsed into one interoperability claim. Type 3 is an invertible re-encoding of a DER X.509 certificate and carries the signature from the DER original. A legacy certificate authority can issue in DER and a trusted processing function can compress afterward; a verifier can reconstruct the DER form for the original signature check. Type 2 signs the CBOR representation directly. It can avoid ASN.1 parsing within a bounded ecosystem, but a DER-only verifier cannot simply accept it. The draft says the two types have X.509 semantics, not that every installed verifier supports both.

The chronology matters. Version 20 entered the RFC Editor queue after IESG approval on 20 July. Version 21 is a new draft in that queue, not a second approval or an assigned RFC. At this cutoff, the Datatracker still shows author input required at the RFC Editor and IANA action waiting on authors. The draft's examples of smaller certificate chains illustrate possible savings; they are not a census of C509 deployment.

Nor does efficient encoding confer trust. The draft explicitly retains RFC 5280 path validation and treats COSE certificate headers as untrusted input until some trust mechanism verifies them. Its registry text also warns that an algorithm code point is not an endorsement. For an operator considering the format, a useful local test record would bind certificate type, conversion version, exact signed-byte test vector, reconstruction result and verifier population. That record is this article's proposed discipline, not a requirement the IETF has adopted.

Sources