Watson, you wrote "An X509 certificate is the only way to link a DNS name to a
key at a given point in time". However, that's not true. For over a dozen
years, OpenID Connect has used a .well-known endpoint rooted at the issuer URL
from which keys are retrieved (using the jwks_uri parameter) that are used to
validate the signature by the issuer. No application-level X.509 required.
The OAuth Authorization Server Metadata spec uses the same mechanism.
And Watson, you wrote "I don't understand your proposal." I would propose to
likewise define a .well-known endpoint for this specification used to retrieve
keys used to validate the issuer signature. It's a well-established pattern
that should be used here too.
-- Mike
-----Original Message-----
From: Watson Ladd <watsonbl...@gmail.com>
Sent: Monday, June 10, 2024 8:36 PM
To: Michael Jones <michael_b_jo...@hotmail.com>
Cc: Richard Barnes <r...@ipv.sx>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Re: Call for adoption - PIKA
On Mon, Jun 10, 2024 at 8:33 PM Michael Jones <michael_b_jo...@hotmail.com>
wrote:
>
> We all know that TLS certificates are handled by platform layers used by
> applications and not the applications themselves. There is no code that
> understands X.509 certificates in most applications that use TLS. They are
> not equivalent in complexity.
>
>
>
> The draft would require adding code directly understanding the structure and
> fields of X.509 to applications using it. Eliminate that, and I’ll support
> adoption.
I don't understand your proposal. An X509 certificate is the only way to link a
DNS name to a key at a given point in time as we can leverage the Web PKI.
Absent that, what do you do?
Also, I'm not sure what you mean by platform layers. Many of them expose a
function to verify a signature with a key in an X509 cert or verify a cert
chain, even outside the context of TLS. Are there particular ones that would
have a problem you are concerned about?
Sincerely,
Watson Ladd
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
