On 3/22/25 5:57 AM, Göran Selander wrote:
Hi Orie,
*From: *Orie Steele <[email protected]>
*Date: *Saturday, 22 March 2025 at 04:18
*To: *Göran Selander <[email protected]>
*Cc: *cose <[email protected]>
*Subject: *Re: [COSE] Re: [EXT] I-D Action:
draft-ietf-cose-cbor-encoded-cert-13.txt
> Thanks for your reply.
>
> I try not to worry about too many identity frameworks... :)
OK.
And more to come...
> 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,
Right, C509 it is not covering everything that can be expressed with
X.509, there are a lot of things never used in the real world.
Or not any more. Lots of stuff that are legacy from OSI and REAL
X.500! Some of that I actually had to deal with.
But that is the way it goes; pruning standards just is not allowed.
But identifying what are the relevant parts of RFC 5280 and creating a
bi-directional lossless map has been one of the main objectives with
the work.
> there will be differences in what "Native COSE" and "Pure COSE" can
do and how they do it...
C509 is NOT COSE. If it were, we would have called it C053 ;-)
Jokes aside, C509 is really about CBOR encoding of X.509 (the title of
the draft). Compactly. And therefore COSE is out, at least as
transport format.
(Someone may ask what this is doing in the COSE WG. The answer is
that, in 2019 the bright star shining on CBOR & security (and many
other things) was Jim Schaad, so that's who you wanted to work with.)
And I still remember the hackathon where Jim, Max, Henk, I, and I think
Michael were working on a draft for this (I think I got all the bodies
then mentioned). But I can't find a copy of our work back then. It is
good that the current team picked up from Jim and have run with it.
If people want to work on a new standardized COSE/CWT based identity
system, then that is something completely different in content,
semantics and format, different design goals, etc.Sure, both are
encoded in CBOR, but CBOR can be used for many things. I’m sorry, but
I fail to see how a bit in a C509 IANA registry can be a significant
show-stopper for this project.
> Btw, I don't love either of these terms "Native or Pure"... Sorry I
don't have anything better to offer...
Yeah, we already had that discussion. The good thing with a term like
"Native C509" is that, since we define C509 in the draft we have the
authority to define what it means to be native and what isn't. A
problem with calling a new COSE based identity system "Pure COSE"
might be that someone may have a different opinion what pure COSE
really is. (Or "Universal CBOR" for that matter.) But let's try to get
out of the bike shed :-)
Göran
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] <mailto:mcr%[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]
<mailto:mcr%[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:mcr%[email protected]><mailto:[email protected]
<mailto:[email protected]>> wrote:
>
> Carsten Bormann [email protected]
<mailto:[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]
<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 [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
