On 5/20/25 8:10 AM, Jay Acuna via NANOG wrote:
On Tue, May 20, 2025 at 9:14 AM Eliot Lear via NANOG <nanog@lists.nanog.org> wrote:
On 19.05.2025 03:27, Tom Beecher via NANOG wrote: In other words, EKU is a horrible mishmash of authentication and authorization because the signer is prohibiting the principal from using [clip] I believe that's because a X.500 directory also has what I would consider to be administrative controls.
One of the things the CA might want to do is differentiate certain services. For example: Your identity is proven, but the CA wishes to only authorize you to digitally sign to verify the authorship of a document or email, and not grant the ability to sign a piece of software or code without an extra $1000 fee paid to the CA for "Code signing access".
That begs the question of why a CA should have any role in such administrative work. Why should a CA be involved in authz at all when a simple authz lookup provides the same functionality without all of the issues and potentially $$$ of involving at CA? Doubly true when certificates have expirey considerations (cf: revocation) where changing authz tends to want to be *immediate* (eg, you just got fired and all work related authz must be disabled immediately). Involving revocation servers just clouds the issue even more, and begs the question of why the bearer needs to carry that part of the authz database rather than servers in the net. Why? It has been an unfortunate part of internet security that certificates have muddied the waters about identity. Nobody in their right mind would want a login user to carry around a bundle of bits on their laptop of what they are authorized to do when a simple database lookup suffices along with the myriad of other things that the backend servers need to know about individual users. It is completely sufficient to associate public keys with an identity in the backend to authenticate that identity and not need a binding to a name the user carries around (eg, a cert) which is how the rest of the world is organized. It should be noteworthy that the symmetric key equivalent -- Kerberos -- fell out a favor decades ago. I wrote an essay describing the current mess that certs and cert-think cause here: https://rip-van-webble.blogspot.com/2021/03/certificates-confuse-everything....
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. For example: You have a secret key you want to install on a web server, and a secret key your server to sign authentication tickets with.
Or you just generate different key pairs and associate the keys with different capabilities in the backend. key-gen is cheap, and there is about zero motivation for some heavy CA-like machinery with all of its ops and maintenance considerations to be involved at all. DKIM got that right. DANE seems to have gotten that right. Webauthn seems to gotten that right. Everything that I'm aware of goes off the rails when certs are introduced. Web/TLS is the real exception and mainly because the web grew up with it. Every other use is suspect until proven necessary, IMO. Mike