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
<[email protected]> 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.html
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
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/MWYKT67GK3XAOMCKLQYBQWM4RHAOEARD/
