Hi Orie, I see where you are coming from. There exists already a number of identity frameworks, incompatible frameworks creates admin overhead, etc. On the constrained IoT side, however, the challenge could be to have *a* identity framework, credential format, protocol, etc. that is performant.
X.509, Compressed X.509 and Native C509 at least share common semantics, you can set policies which express equally in all, etc. In the draft we mention a migration path starting with legacy X.509, introducing compression as a bump-in-the-wire to maintain legacy backend CA. This enables CBOR parsing of certificate content on the device while using existing code to verify the signatures. Once the CA supports native C509, the device implementation can be simplified. An interesting data point is that a CA software vendor we have contact with is actually more interested in native than compressed C509 (presumably based on customer input but just speculating there). In cases where the communication link is not constrained (unlike aviation etc.), a device handling compressed X.509 may often just as well handle ordinary X.509. But a device for which CBOR is selected for optimized processing, X.509 is not the optimal choice and native C509 can make a difference. Thus implementing native C509 extends the reach of their identity products and services to other device categories. While it would be great if one size could fit all, if there is one setting for which a new security wrapping is warranted, then IMHO it is constrained IoT. I don't know if this answered the question, happy to continue the discussion. Göran From: Orie Steele <[email protected]> Date: Friday, 21 March 2025 at 13:25 To: Göran Selander <[email protected]> Cc: Göran Selander <[email protected]>, Michael Richardson <[email protected]>, cose <[email protected]> Subject: Re: [COSE] Re: [EXT] I-D Action: draft-ietf-cose-cbor-encoded-cert-13.txt Hi Göran, Native C509 seems to target scenarios where there is not yet an established CA ecosystem that needs to be compressed. I guess ecosystems will pick either Compressed or Native... Are there deployment scenarios where both would be used together? Thanks for this draft, it's an impressive amount of work. Regards, OS On Fri, Mar 21, 2025, 6:37 PM Göran Selander <[email protected]<mailto:[email protected]>> wrote: Oh, and it’s in the charter: https://datatracker.ietf.org/wg/cose/about/ ”Accordingly, a secondary objective is to reuse these data structures to produce a natively signed CBOR certificate encoding; such a structure is relevant in situations where DER parsing and the machinery to convert between CBOR and DER encodings are unnecessary overhead, such as embedded implementations.” Göran From: Göran Selander <[email protected]<mailto:[email protected]>> Date: Friday, 21 March 2025 at 11:59 To: Michael Richardson <[email protected]<mailto:mcr%[email protected]>>, cose <[email protected]<mailto:[email protected]>>, Orie Steele <[email protected]> Subject: [COSE] Re: [EXT] I-D Action: draft-ietf-cose-cbor-encoded-cert-13.txt Hi Michael, and all, > On 2025-03-19, 11:46, "Michael Richardson" > [email protected]<mailto:mcr%[email protected]> > <mailto:[email protected]> wrote: > > Carsten Bormann [email protected]<mailto:[email protected]> <mailto:[email protected]> wrote: > > On 19. Mar 2025, at 08:23, Michael Richardson > > [email protected]<mailto:mcr%[email protected]> > > <mailto:[email protected]> wrote: > >> > >> I'm complaining that #2 will get in the way of making #3 real. > > > Ah, the transition dilemma. > > Offer a transition aid and users will become addicted to it. > > Yes, this is the concern. > > > I think the upside of #2 way, way, outweighs this. > > Is the upside that a device can avoid doing any ASN.1/DER parsing, since it > never has to turn the CBOR back into DER to check the signature. > But is that even true? If a certificate has something we do not compress, or > deep in the structure, then the ASN.1 will still be there, right? I guess we > can avoid ever creating such things for #2 (native signed). Correct. It seems to me that a recap is in place, please bear with me. There are two variants of C509 certficates: Compressed X.509 (here called #1) is specifying a CBOR re-encoding of the fields of a X.509 certificate with the signature copied from the X.509. This means that you need to convert back to ASN.1/DER to verify the signature, but it is more compact during transport. Native C509 (here called #2) is identical to Compressed X.509 except for one byte (actually one bit) in the CBOR field used for versioning, indicating what is being signed. With Native C509 a device can avoid doing, or even implementing, ASN.1/DER parsing by using existing CBOR encodings, and it is further extensible. Examples of the different encodings using an RFC 7925 profiled X.509 Certificate are given in appendices A.1.1 (#1) and A.1.2 (#2) [1]. Native C509 has been around since the first individual -00 submission April 25, 2019 [2]. The original intent is identical [3] and preserved through the IETF consensus adoption in COSE all the way until the current version. The detailed CBOR encoding of the C509 certificate fields is not identical to that of 2019 (although you easily recognize yourself) but there has not been any change in how native C509 is related to compressed X.509 and how it is intended to be deployed. Admittedly, C509 has taken time to complete due to other priorites of the authors. The last years’ updates has been driven by the input from non-authors, in particular Lijun Liao, Brian Sipos, Bob Moscowitz and others who helped improve the document significantly. Bob provided feedback from the aviation industry that lead to an optimisation of device identifier representation, which was further optimized in -13. Brian has made careful reviews and discovered several disconnects between specification of C509 and how it is being applied which has lead to improvements of the specification (and one more to fix, see issue #222 [4]). But most of our gratitude (and delay 😊) during the last years has been due the very detailed insights and combined competence in X.509 and CBOR from Lijun. Neither of these individuals are authors of the draft, but Lijun has been listed as Contributor for his large volume of important inputs. Most of the work has taken place on the COSE WG github, but with continuous reporting on COSE WG meetings and contentious issues brought to the mailing list for discussion. Native C509 certificates are being deployed, for example by a car manufacturer. Derek Atkins has reported on deployment exclusively using native C509 [4]. Native C509 is on the roadmap of a CA software vendor. (Note also that IoT device deployment is an example where private CAs makes a lot of sense.) These are deployments I'm aware of, which may not be all, and there are also research implementations. Since the difference between compressed X.509 and native C509 is miniscule, any implementation of Compressed X.509 essentially also supports Native C509, so there are good chances for high quality implementations becoming available further facilitating deployments of either variant. To summarize: Native C509 has been an integral part of the specification, its intent and use is unchanged since 2019, and it has been deployed for years. It has advantages for certain IoT settings compared to Compressed X.509. The specification of Compressed X.509 and Native C509 differ by one bit. Göran [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-cbor-encoded-cert-13%23name-example-rfc-7925-profiled-x&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643739265%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=49XXAr8FbBBIQg6AfT7q4DO90kdVLInw0YVXLXbCXT4%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-13#name-example-rfc-7925-profiled-x> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-cbor-encoded-cert-13%23name-example-rfc-7925-profiled-x&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643764221%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gkSB%2FKHeVWHwUnJQQNHcKDjLKCTIWzzFu9gIKhtvtBA%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-13#name-example-rfc-7925-profiled-x>> [2] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raza-ace-cbor-certificates-00&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643777291%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eI2Qj6ylSQuQoLyzHTuFIEMWuanN9lHDkaXPxj7YsXg%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-raza-ace-cbor-certificates-00> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raza-ace-cbor-certificates-00&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643789775%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j%2FxGAWvFxsQhddNjBknG1QGBi2XnGg0fJSFe8cCE39M%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-raza-ace-cbor-certificates-00>> [3] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raza-ace-cbor-certificates-00%23section-6&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643802278%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vvl%2BRKx5lm7rl4fIDbYT%2FowjvOoWEEthGgwhJ5J5Pr0%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-raza-ace-cbor-certificates-00#section-6> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-raza-ace-cbor-certificates-00%23section-6&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643814361%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=50q5MPdwVOPnmBgZ7YCxVQ%2F2rUtCxi8ZXIllP23sLjM%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-raza-ace-cbor-certificates-00#section-6>> [4] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcose-wg%2FCBOR-certificates%2Fissues%2F222&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643830202%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hpPeVKLEr2NGNCX080pKS0IK6TB11JkKoMO4%2Fd3bz%2Bk%3D&reserved=0<https://github.com/cose-wg/CBOR-certificates/issues/222> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcose-wg%2FCBOR-certificates%2Fissues%2F222&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643842890%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=45eyChM7IRvNYddz3V2Qr2%2FvRvwYzDL61C0pDbz90Rs%3D&reserved=0<https://github.com/cose-wg/CBOR-certificates/issues/222>> [5] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fcose%40ietf.org%2Fmsg03576.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643855072%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=u5lN1lDkj7Q3FSSvixe2WIfz2CH1na%2BRgd9hB3X8KTU%3D&reserved=0<https://www.mail-archive.com/[email protected]/msg03576.html> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fcose%40ietf.org%2Fmsg03576.html&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cec44a259bd7c469ddec708dd68676e0d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638781515643866897%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NzheaJW43ilXf7qnpYdO8usNfAAvBIbt4OcbvIXwYWM%3D&reserved=0<https://www.mail-archive.com/[email protected]/msg03576.html>>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
