On Tue, May 20, 2025 at 4:45 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:
(SNIP)
So a significant amount of KU/EKU is still kind of mired in the historical roots of X.509 and has been shoehorned into other uses. (Though if I recall correctly, id-kp-(client|server)Auth wasn't introduced until AFTER X.509 sort of branched into its own away from strict X.500 usage, but it's still within the timeframe of "yes, these certificates are idents for actual entities in an org-centric system". There's some overlap in the timeframes.)
Yeah, so let's not do that. There is an awful lot of X.509 hammers (and their vendors, especially) laying around looking for anything resembling an identity nail regardless of whether it makes any sense wrt authn/authz/policy. I've seen plenty of times where people start with the premise of "first we have an X.509 binding, and then what happens?" which instantly falls into a very deep rathole that's hard to claw back out of. The mistake is first positing the existence of an X.509 style key/name binding first -- it should be the last choice, and only if there is absolutely no other way to achieve the requirements, imo.
Yeah, this is fair. Probably the only real relevance X.509 (or... *TLS certificates* I guess we should say, since it's not really X.509 anymore) that I can think of is for LDAP entities tied to the subject (and principals, KRB tickets, etc. thereof), and those are fairly rare. Certs for HTTPS, SMTPS/SMTP+STARTTLS etc. feels more like a time-trodden "solution looking for a problem" in its implementation than vice versa.