On 10/10/25 3:13 PM, Phillip Hallam-Baker wrote:
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.
Which is what I have done in DRIP and what ICAO is doing in GNSS SBAS.
Though in SBAS, IMHO, they are not going far enough.
We could also kill the support for character sets other than UTF-8.
Let them die on the vine.
Using key identifiers to specify cert chains is a lot more robust and
they are in the spec already.
But use shorter KI than SHA1. I am doing that, but lost that arguement
in SBAS as "the software only supports SHA1".
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]> 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
<[email protected]>
<mailto:[email protected]>
*Sent:* Wednesday, October 8, 2025 9:56 AM
*To:* Tschofenig, Hannes <[email protected]>
<mailto:[email protected]>; Sipos, Brian J.
<[email protected]> <mailto:[email protected]>;
[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]>
*Date: *Wednesday, 8 October 2025 at 15:22
*To: *Sipos, Brian J. <[email protected]>, [email protected]
<[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]>
*Gesendet:* Mittwoch, 8. Oktober 2025 15:00
*An:* [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]
To unsubscribe send an email [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
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]
