I am working on a MAJOR, and I really mean MAJOR use of instream
recoding of X.509 certificates as c509.
The application is to authenticate the TESLA keys that will be used for
authenticating GPS messages.
EU is very close to rolling this out for their constellation. US is
more complex as there are ~30 private companies around the world that
have a hand in augmenting GPS.
We are arguing over bits here. "Look at the message, we ONLY have 7
bits where do you thing there is another bit; how will we do it?"...
I missed the call today, too tired. But this is pretty much a done thing.
I AM working on changes to the actual certs. I believe we can squeeze
out some more bytes here that will even help out the CBOR encoded format.
Oh, the TESLA part is pretty much done with code ready. It is not pure
RFC TESLA, but apparently something a "bit better". I don't have the
time/experience to evaluate their work. I did argue to use KMAC over
HMAC when they were crying about the compute cost of HMAC in those
birds. But so far, they are staying with HMAC.
Oh, and there is talk about sticking all this on top of ADS-B, but that
is a MUCH bigger lift with a lot more players.
On 3/18/25 1:51 PM, Göran Selander wrote:
Hi Michael,
Happy to hear that people are showing interest in the work. It would
be great to learn what applications they have in mind for the
compressed X.509, please share! We also have noted an interest, for
example from the aviation side, but more examples are welcome.
However, the overwhelming interest has been for native C509 and for
this setting there are already products deployed. So I believe the
genie is out of the bottle and it would IMHO be better to set the
standard rather than let this be developed in different proprietary ways.
I don’t think this work pre-empts other work onnew standardized
COSE/CWTbased identity systems. Native C509 are semantically identical
to the compressed X.509 which is intended to support whever is
relevant from PKIX in this context. I take it from your comment this
is not at all what you have in mind, and therefore I don’t see any
significant overlap. The fact that both are signed CBOR does not make
much of any difference.
Indeed, there has already been different proposal on “COSE/CWT
basedidentity” but it has not reached IETF consensus yet. I would be
happy to see a development in that area, but I don’t think it is fair
to say that the lack of success so far should be blamed on native C509.
Göran
*From: *Michael Richardson <[email protected]>
*Date: *Tuesday, 18 March 2025 at 07:17
*To: *[email protected] <[email protected]>
*Subject: *[COSE] Re: [EXT] I-D Action:
draft-ietf-cose-cbor-encoded-cert-13.txt
I was talking about cbor-encoded-cert with a few people over the hackathon
and over some dinners.
A few people asked that we remove the native signature content.
I concur. I don't think it's useful to create a new, isolated C509
ecosystem
which retains all of the semantic bugs of PKIX, while being
incompatible with
PKIX.
Many many many people would like to work on a new standardized
COSE/CWT based
identity system which does not share the PKIX history, and they feel
that the
world does not have space for PKIX, native-C509, *and* such a new system.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
_______________________________________________
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]
