1. For closed environments, the native version (no ASN.1 encoding is needed) can be used. E.g. the code signing system in IoT devices. Implementing C.509 is much simpler than X.509, so it is specially useful for the industrial use (which offen is „closed system“).
2. The CBOR-compressed version of X509 certificate, is useful to reduce the storage and transport size. The application usually needs to convert it back the the X.509 one. Such compression will usually only be used in constrained devices which usually have only a small subset of the extensions in the certificates. The developers do not need to implement the whole X.509 semantics. Lijun > On 9. Oct 2025, at 01:51, Göran Selander > <[email protected]> wrote: > > > > From: Phillip Hallam-Baker <[email protected]> > Date: Wednesday, 8 October 2025 at 23:19 > To: Göran Selander <[email protected]> > Cc: Carsten Bormann <[email protected]>, Göran Selander > <[email protected]>, Tschofenig, Hannes > <[email protected]>, Sipos, Brian J. <[email protected]>, > [email protected] <[email protected]> > Subject: Re: [COSE] Re: The term "PKIX" and C509 > > > > On Wed, Oct 8, 2025 at 4:54 PM Göran Selander <[email protected] > <mailto:[email protected]>> wrote: > > > From: Phillip Hallam-Baker <[email protected] > <mailto:[email protected]>> > Date: Wednesday, 8 October 2025 at 22:16 > > On Wed, Oct 8, 2025 at 11:58 AM Carsten Bormann <[email protected] > <mailto:[email protected]>> wrote: > On 2025-10-08, at 17:37, Phillip Hallam-Baker <[email protected] > <mailto:[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. > > GS: This is essentially C509 "type 1" > > So any client software consuming such certs is going to have to implement the > most knarly part of PKIX. > > GS: Some people consider it a feature to align with PKIX. > > It is a feature that is going to impose a very high burden on developers, is > unlikely to work because of issues that are outside their control (i.e. > X.509v3 certs not necessarily using correct DER) and is going to prevent the > wider effort taking advantage of the opportunity to break backwards > compatibility and jettison some of the X.500 legacy. > > GS: Well, if it doesn’t work then it is hardly going to effectively prevent > other efforts, nor impose any significant burden on developers. > > Göran > _______________________________________________ > 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]
