Feel free to float any deprecation proposals you want in LAMPS; I suspect you might find a reasonable amount of support for simplifying some of the unnecessarily complex corners of PKIX.
Getting rid of things that are not needed any more is a very important and useful standards maintenance activity. -Tim From: Phillip Hallam-Baker <[email protected]> Sent: Friday, October 10, 2025 3:14 PM To: Robert Moskowitz <[email protected]> Cc: Tim Hollebeek <[email protected]>; Göran Selander <[email protected]>; Tschofenig, Hannes <[email protected]>; Sipos, Brian J. <[email protected]>; [email protected] Subject: Re: [COSE] Re: The term "PKIX" and C509 Naming might seem like a trivial matter but it can be the most important decision a group makes. It is how the group promotes its work product. The part of PKIX that has the weakest rationale at this point as far as I am concerned is the X part. If we are looking to save bytes, lets knife distinguished names. They are a relic from the X.500 world that died long ago. We could also kill the support for character sets other than UTF-8. Using key identifiers to specify cert chains is a lot more robust and they are in the spec already. We already have LAMPS describing 'limited additions'. There are some deletions I would like to see. Or at least deprecating. We would still have to specify how a PKIC deserializer fills the subject and issuer fields in the validated tbsCert structure it returns after checking the cert but that is easy to do. On Fri, Oct 10, 2025 at 2:09 PM Robert Moskowitz <[email protected] <mailto:[email protected]> > wrote: Fun stuff. Hannes is right that the 'X" is from X.509. Also right that PKIX refers to the whole infrastructure. So the former implies these are NOT PKIX. But the later, in the natural evolution of language (I have been having a lot of these discussions with my wife, she really deplores the dilution of "awesome"), is that PKIX includes all standardized reencodings of X.509 data envelopes. I mean we COULD use PKIXC: Public Key Infrastructure using X.509 reencoded in CBOR. But that borders on ridiculous. Plus it is a marketing thing. Make it complex enough and watch people leave the room. More fun is the draft defines a field NOT in X.509. That is the signature over the CBOR object in place of the CBOR encoding of the signature over the ASN.1 object! Let's just confuse the bejeepers out of people here. (and those poor AI systems) Languages evolve. Lots and lots of years ago I got REALLY upset over the verb "ecologize". Note I have a degree in Botany, in Secessional Ecology, along with my degree in Computer Science. And back then in the early '70s, ecology was NOT a commonly known area of science. One of the profs in linguistics told me to get a life; language does! So C509 is within the scope of PKIX. No need to add to the alphabet soup over this. My 2c worth on this. Bob On 10/10/25 12:28 PM, Tim Hollebeek wrote: I mean, this is a definitional thing, so there is no right answer, but C509 is so close that I think trying to be a purist and claiming they are not X.509 just because they are not ASN.1 encoded will cause more problems than it solves. Seeing C509 just as an alternative encoding for traditional ASN.1 certs, and that both of them basically encode the same X.509 profile(s) and follow similar rules makes more sense to me. So I would put them under the general PKIX umbrella. It will also be easier to convince people to adopt them if people realize it’s just a different (and better!) encoding for the thing they already know and pretend to love. -Tim From: Göran Selander <mailto:[email protected]> <[email protected]> Sent: Wednesday, October 8, 2025 9:56 AM To: Tschofenig, Hannes <mailto:[email protected]> <[email protected]>; Sipos, Brian J. <mailto:[email protected]> <[email protected]>; [email protected] <mailto:[email protected]> Subject: [COSE] Re: The term "PKIX" and C509 Hi, C509 defines an invertible CBOR re-encoding of DER encoded X.509 certificates, which supports large commonly used parts of RFC 5280 including RFC 7925, IEEE 802.1AR, CAB Baseline, RPKI, and eUICC profiled X.509 certificates. This doesn’t make C509 into X.509. But since the mapping can be reversed to obtain the original DER encoded X.509 certificate it can be used as a compact representation of X.509 certificates within the PKIX infrastructure. Hope that helps! Göran From: Tschofenig, Hannes <[email protected] <mailto:[email protected]> > Date: Wednesday, 8 October 2025 at 15:22 To: Sipos, Brian J. <[email protected] <mailto:[email protected]> >, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Subject: [COSE] Re: The term "PKIX" and C509 Hi Brian! The term PKIX stands for Public-Key Infrastructure using X.509. Using it to refer to other technologies that do not use the same encoding as X.509 certificates is likely to cause confusion. Note that PKIX also refers to the entire infrastructure – not just the format of the cert. Just my two cents. Ciao Hannes Von: Sipos, Brian J. <[email protected] <mailto:[email protected]> > Gesendet: Mittwoch, 8. Oktober 2025 15:00 An: [email protected] <mailto:[email protected]> Betreff: [COSE] The term "PKIX" and C509 WG, >From the perspective of a user or a profile specification allowing the use of >X509 and C509 in, for example, COSE messages has there been any discussion >about terminology in the sense of the following: Is it expected that the term “PKIX” will exclusively refer to X.509 as defined in RFC 5280? Or will PKIX be an umbrella term to include C509 as an equivalent encoding of the same information model? Possibly “public key certificate” is a better general purpose term, though a little more narrow in scope (a single credential) than what PKIX would imply (the whole PKI). Any thoughts about this? Brian S. _______________________________________________ COSE mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ COSE mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
