You can invert a certificate if it is in fact DER encoded. But generating genuinely DER certs is very hard and rather fewer application libraries do it correctly than you might imagine. And your signature verification is going to have to make the same transformation.
What you are proposing here is to venture off onto a completely untested code path. If you convert a cert I generate into some other format and it doesn't work when reconverted, I am not going to fix my code, I am going to send you sarcastic memes and ask why the heck you ever expected that to work. No, seriously, the whole notion of DER was insane start to finish. But actually relying on it in code? What advantage does being able to parse the cert using a COSE deserializer provide if you have to serialize it as ASN.1 DER to verify the signature? Deserializing ASN.1 is the easy part, it is the insane DER construction that is a pain in the patootie. I have implemented that many times in many different languages. If you are constructing C509 certs with the signature over the CBOR serialization, that is not going to interoperate with any legacy PKIX infrastructure. I cannot see any point in PKIX in any syntax other than ASN.1. The only reason to change the serialization format is if you are going to redo the entire design differently. Which is what I did with TAXI which originally did all of PKIX in 20 pages, that work then turned into XKMS and the assertion structure of SAML. From time to time, I consider proposing SAML in JSON because JOSE is a much cleaner approach than XML Signature and the world has chosen JSON over XML. But OAUTH2 is already doing much the same things. When CBOR was originally proposed, we were told it would do everything JSON does. What we got was something subtly different so COSE wasn't just JOSE in a different serialization. I can't see how PKIX in CBOR is going to turn out any different. Yes, design reuse is good but the PKIX design is over 30 years old and is based on even older work and it all happened when PKI was new and none of us knew what we were doing. On Wed, Oct 8, 2025 at 9:56 AM Göran Selander <goran.selander= [email protected]> wrote: > > Hi, > > C509 defines an invertible CBOR re-encoding of DER encoded X.509 > certificates, which supports large commonly used parts of RFC 5280 > including RFC 7925, IEEE 802.1AR, CAB Baseline, RPKI, and eUICC profiled > X.509 certificates. > > This doesn’t make C509 into X.509. But since the mapping can be reversed > to obtain the original DER encoded X.509 certificate it can be used as a > compact representation of X.509 certificates within the PKIX infrastructure. > > Hope that helps! > > Göran > > > *From: *Tschofenig, Hannes <[email protected]> > *Date: *Wednesday, 8 October 2025 at 15:22 > *To: *Sipos, Brian J. <[email protected]>, [email protected] < > [email protected]> > *Subject: *[COSE] Re: The term "PKIX" and C509 > > Hi Brian! > > > > The term PKIX stands for Public-Key Infrastructure using X.509. Using it > to refer to other technologies that do not use the same encoding as X.509 > certificates is likely to cause confusion. Note that PKIX also refers to > the entire infrastructure – not just the format of the cert. > > > > Just my two cents. > > > > Ciao > > Hannes > > > > *Von:* Sipos, Brian J. <[email protected]> > *Gesendet:* Mittwoch, 8. Oktober 2025 15:00 > *An:* [email protected] > *Betreff:* [COSE] The term "PKIX" and C509 > > > > WG, > > >From the perspective of a user or a profile specification allowing the > use of X509 and C509 in, for example, COSE messages has there been any > discussion about terminology in the sense of the following: > > Is it expected that the term “PKIX” will exclusively refer to X.509 as > defined in RFC 5280? Or will PKIX be an umbrella term to include C509 as an > equivalent encoding of the same information model? Possibly “public key > certificate” is a better general purpose term, though a little more narrow > in scope (a single credential) than what PKIX would imply (the whole PKI). > > > > Any thoughts about this? > > Brian S. > _______________________________________________ > 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]
