On Tue, May 20, 2025 at 4:45 PM Michael Thomas via NANOG < [email protected]> 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. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/HTTGPN222BFMIZSDWQ7TWBFLU2EGE2WK/
