Thanks for your reply. I try not to worry about too many identity frameworks... :)
We've talking about 1&2, so we might as well talk about 3. Recently COSE has been extended to support kccs and cwt claims in headers. One interesting claim that can go in a header is the cnf claim. Its easy to imagine a "pure COSE" cert-like structure that might be built on these. Similar to how c509 doesn't specify a complete bi-directional lossless mapping for all things an x509 cert can include, there will be differences in what "Native COSE" and "Pure COSE" can do and how they do it... Btw, I don't love either of these terms "Native or Pure"... Sorry I don't have anything better to offer... On Fri, Mar 21, 2025, 10:54 PM Göran Selander <[email protected]> wrote: > 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]> > 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]> > *Date: *Friday, 21 March 2025 at 11:59 > *To: *Michael Richardson <[email protected]>, cose <[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:[email protected] <[email protected]>> wrote: > > > > Carsten Bormann [email protected] <mailto:[email protected] <[email protected]>> > wrote: > > > On 19. Mar 2025, at 08:23, Michael Richardson [email protected] < > mailto:[email protected] <[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]
