This whole problem did not need to happen. When the federation spec was being created I asked them not to deviate unnecessarily from pki. But the very guys that are on this thread told me that they were not a pki and so there was no reason for them to follow existing rules. This is entirely a problem of there own making. So let them fix their own mistakes.
thx ..Tom (mobile) On Mon, Jun 10, 2024, 8:37 PM Watson Ladd <watsonbl...@gmail.com> wrote: > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
