On 5/20/25 12:56 PM, brent saner via NANOG wrote:
On Tue, May 20, 2025 at 2:32 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:
(SNIP) Suffice it to say, I pretty much agree with Eliot's assessment of "mismash" re: authn/authz.
This is likely due to X.509 (and various other parts of X.500 - which surprisingly I think I've only seen one other person mention in this thread so far) were historically designed to *be* AA, providing identities tied to actual structured, registered entities/objects - not simply a verification method for public keys.
Let's start with the obvious: X.509 is *old*. The assumptions it made are either not true anymore or just not applicable to the modern world for the most part.
X.500 was also designed with the expectation of federation -- or at the least org-specific -- rather than centralization. Which is why a lot of this stuff makes more sense if you approach X.509 as an org-managed thing first and foremost, and wide-trust CAs being bolted on as kind of a kludgy ad-hoc post-facto sort of thing rather than the other way around (if private authorities are considered at all in your mental model).
At this point in time, what X.509 was or wasn't designed to do is sort of irrelevant. It's main use -- by far -- is providing an identity to key binding which browsers with embedded CA roots can verify against. That's about it. All of the rest is pretty irrelevant in this day and age and everybody should be extremely suspicious use of certs for anything beyond that without going back to first principles of what is trying to be achieved, rather than starting from the premise of "certs are necessary, so how do we achieve XYZ with them?" Unfortunately that's the way too many of us with too much gray in our beards were encultured back in the day.
(That reminds me - Michael, Kerberos is still heavily used! Active Directory - and I guess whatever "cloud"-y thing Microsoft has now.. "Entra"? -is basically just DNS, Kerberos, and LDAP wrapped up in a clicky-clicky. FreeIPA and other F/OSS IdP/IdMs still *heavily* use Kerberos as well. It hasn't gone anywhere, it's just usually abstracted away and buried underneath a more C-level-friendly interface.)
Yes, I'm aware of that. It sort of proves my point though: Kerberos has been sort of been relegated to a fairly "niche" slice of the identity world where in the 80's it had a lot more traction especially in the .edu world back then. These days it's almost all username/password over TLS due to the web-like world we live in (and everything needs to support). Maybe webauthn will make some of the problems better, but it should be noted that even webauthn doesn't use certs for clients -- enrolling naked public to a given identity sitting in an online database is completely adequate. (I say this as somebody who likes Kerberos, but reality is still reality).
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. Mike