Re: Massive change in Public Cert behaviour coming soon

[Tom Beecher via NANOG <nanog () lists nanog org>]

Yes, absolutely correct.

I was just generalizing the example, perhaps unclearly.

On Sun, May 18, 2025 at 10:04 PM brent saner via NANOG <
nanog () lists nanog org> wrote:

> On Sun, May 18, 2025, 20:28 Tom Beecher via NANOG <nanog () lists nanog org>
> wrote:
>
> > > "This identity may only be used for clients verifying servers," smells
> > > like authorization to me.
> >
> >
> > It's not. It's "This certificate can only be used to authenticate me if
> it
> > is being used in the manner with which I specify."
> >
> > Ex 1 :
> >
> > 1. Alice creates certificate A, with the EKU set to Server Auth Only.
> > 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified*
> > herself.
> > 3. Bob says "Hello, prove you are Alice."
> > 4. Alice sends certificate A.
> > 5. Bob verifies certificate A cryptographically, but since it is only
> > allowed to be used as Server Auth, not Client Auth, then *authentication*
> > fails.
> >
> > No authorization of anything ever occurs here, because authentication has
> > failed.
> >
> > Ex 2 :
> > 1. Alice creates certificate A, with the EKU set to Client Auth Only.
> > 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified*
> > herself.
> > 3. Bob says "Hello, prove you are Alice."
> > 4. Alice sends certificate A.
> > 5. Bob verifies certificate A cryptographically, and it is allowed to be
> > used for Client Auth. *Authentication* succeeds.
> >
> > Now that Alice has been authenticated, Bob can determine if she is
> > *authorized* to do the thing she is trying to do.
>
>
> Generally yes, precisely this, but what I think many are missing is TLS
> verification itself is still not even authentication unless actual
> identification context is associated (e.g. a certificate attribute is given
> meaning). See RFC 4949, "authenticate" definition, second and third
> deprecations.
>
> #5 in both the above examples is *service*-specific, and should probably be
> split into:
>
> ==
>
> 5.a.) Bob verifies certificate A cryptographically; it's verification (may)
> determine validity/continuance of TLS communication
> 5.b.) (Only in certain services) The usage of the certificate is verified
> in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth),
> which (may) determine continuance of TLS communication.
>
> ==
>
> Internet-facing MTAs do not do 5.b. when communicating with other MTAs (and
> typically don't even do it for clients, opting instead for doing encryption
> via TLS and authentication via SASL).
>
> Most wide-trust CAs don't even issue certs with id-kp-clientAuth set, I
> wasn't aware LE was even doing so until I found out about them removing it-
> because it's generally not useful for internet-facing resources unless you
> control the authority.
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/TFGSQP42CU3FWGDZX75B3EC3O3WTPYH3/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FRVKSQPKTMFFZMAIWCNK2I72ALBITOSN/