Hi Mike, "There is no code that understands X.509 certificates in most applications that use TLS". As Waston said, many platforms and libraries provide a way to verify a certificate outside of TLS. However, the whole point of PIKA is that it is an additional *choice* for people who *cannot* use TLS because the issuer may be offline at verification time.
Let's look at your statement under two cases: those applications that need offline verification, and those that don't. 1) If your application doesn't need offline verification, it doesn't need to implement PIKA and therefore doesn't need an X.509 verification library. *Conclusion*: No change, no negative implications. Continue doing issuer verification using TLS as today. 2) If your application requires offline verification, it isn't going to be able to open up a TLS connection to an offline issuer .well-known URL as you proposed. The options are to use an existing X.509 verification API built into a number of platforms and crypto libraries, or to include one in your application. At a previous employer we had to do X.509 validation in a web client and were able to find a small, suitable library for this purpose (the certval Rust crate) and could have optionally included the Mozilla root certs (webpki-roots crate). *Conclusion*: If you need it, you can find off-the-shelf (or may already have) the libraries you need to implement this in your application. The change in the JWT validation code looks trivial. Thanks, -rohan On Mon, Jun 10, 2024 at 11:32 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. > > > > -- Mike > > > > *From:* Richard Barnes <r...@ipv.sx> > *Sent:* Monday, June 10, 2024 8:18 PM > *To:* Michael Jones <michael_b_jo...@hotmail.com> > *Cc:* Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com>; oauth <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] Re: Call for adoption - PIKA > > > > The applications we're talking about are **already** doing X.509 when they > make HTTPS connections. It's not a new requirement. The only thing we're > doing is using the certificate for JWT instead of HTTPS. > > > > --RLB > > > > On Mon, Jun 10, 2024 at 11:15 PM Michael Jones < > michael_b_jo...@hotmail.com> wrote: > > As both I and Giuseppe pointed out, the requirement for applications to > use and understand X.509 certificates means that the draft is way beyond > the minimum complexity needed. > > > > Eliminate application-level X.509 (which is an anachronism that OAuth and > JOSE have moved away from), and I’ll support adoption of the next draft. > > > > -- Mike > > > > *From:* Richard Barnes <r...@ipv.sx> > *Sent:* Monday, June 10, 2024 8:11 PM > *To:* Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > *Cc:* oauth <oauth@ietf.org> > *Subject:* [OAUTH-WG] Re: Call for adoption - PIKA > > > > In case it's not clear from other messages in this thread: I think this > draft should be adopted. It solves several pressing use cases, with the > minimal amount of complexity needed. > > > > --Richard > > > > On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > > All, > > This is an official call for adoption for the *Proof of Issuer Key > Authority (PIKA)* draft: > > https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ > > > Please, reply *on the mailing list* and let us know if you are in favor > or against adopting this draft as WG document, by *June 24th*. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
