On Wed, Oct 8, 2025 at 11:58 AM Carsten Bormann <[email protected]> wrote:
> On 2025-10-08, at 17:37, Phillip Hallam-Baker <[email protected]> > wrote: > > > > When CBOR was originally proposed, we were told it would do everything > JSON does. > > And you got that. > > > What we got was something subtly different so COSE wasn't just JOSE in a > different serialization. > > COSE wasn’t JOSE because there was an opportunity to fix some JOSE > idiosyncrasies. > We could have decided against that and try to be bug-for-bug compatible, > but there really was no point. > > > I can't see how PKIX in CBOR is going to turn out any different. > > Well, for one thing, C509 is usually way more compact than DER-encoded > X.509. > That may matter to you or it may not. > OK, so you have a more efficient encoding for ASN.1, that isn't too much of a departure, ASN.1 is designed to allow different encoding rules. What I was objecting to was the assertion that you can convert a C509 certificate into an X509. That is only going to work if the tbsCertificate blob is encoded in DER for purposes of calculating the signature. So any client software consuming such certs is going to have to implement the most knarly part of PKIX. A COSE certificate format that makes no effort to be backwards compatible with PKIX except for expressing X509v3 extensions would be a heck of a lot simpler to implement and the result more useful. There are a lot of parts of PKIX that seemed like a good idea at the time. Which is exactly what I would expect in a 30 year old spec.
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
