On Tue, May 20, 2025 at 2:32 PM Michael Thomas via NANOG < [email protected]> 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. 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). DAP et. al. instead gave way to LDAP and X.509 kind of got co-opted into encryption purposes instead (because static *identities*, even if they have no associated *entity* can still be useful in certain contexts when it comes to cryptographic exchange, which is why as hard as some people might try, PGP/GnuPG still isn't going anywhere -- it serves some purposes that non-attributed asym crypto can't. But I digress.) (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.) 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.) Generally speaking if you're using EKU client/server restrictions (and technically per RFC 5280, again, it should only be used for Web mTLS auth), more power to you - but to reiterate something I've said multiple times, it only makes sense *if you're running your own org-private CA*. I suspect that's why Google is requiring absence of id-kp-clientAuth for anchor inclusion - horrible abuses and misunderstanding of that particular bit seem rampant (and Let's Encrypt, nor to my knowledge any other wide-trust CA, even issues user-entity leaf certificates) because it's an RFC violation - per 4.2.1.12 of 5280: "If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present." I suspect Google recognized that wide-trust CAs should not be issuing certs for usage that will be acting as a web client to *org-foreign* wide-trust-signed web servers requiring mTLS auth. Because it doesn't make sense to do so. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/T5W56UPF3FRFU4UKKNUERGKFTYPH4G4L/
