Hi Mike, We addressed these points in the presentation in YVR, where we had a successful IRL adoption call based on the premise that these could be worked in the WG post-adoption. You were in the room for that, so I'm surprised that these concerns are being re-raised now. The chairs advised us not to revise the draft before we confirmed that adoption call on the list.
Nonetheless, here's a quick recap of what we said in YVR: 1. Application-level use of PKI -- Several developers have opined on-list that this is not a practical barrier, and that the resilience benefits of PIKA are worth the extra effort. 2. Reuse of keys -- The core idea here is to make PIKA signing certificates different from certificates you would use on a web server. For example, we can require that the PIKA signing certificate use a prefix, say containing a SAN for _pika.example.com when authenticating the issuer URL < https://example.com>. 3. Authorities with paths not secured -- Paths are not secured today, with HTTPS-based discovery. Anyone who controls the domain on which an issuer is hosted can impersonate that issuer. PIKA is not making any change in that regard. 4. Odd hybrid -- I'm not sure how to respond to "odd" as an engineering concern. JOSE and X.509 have been intermixed since the "x5c" parameter was introduced. The layering here is actually quite clean: JWK and X.509 talk about different keys, with the X.509 keys "blessing" the JWKs. 5. Upgrade path -- There is a trade-off here between concreteness and future-proofing. Our proposal is to continue to have PIKA articulate a concrete, PKI-based mechanism, but also provide some notes on how one would update it to use different authority mechanisms. As to the direction of travel: The direction this document is trying to move is orthogonal to the axis you're talking about. The OAuth ecosystem already relies on X.509 in the ways we are relying on it here. We are just expressing that reliance in JWS instead of HTTPS. If, in the future, the OAuth ecosystem relies more on JWS in the places it currently uses X.509, we can make a PIKAv2 that takes that up. But that is not the world we live in today. Best, --Richard On Mon, Sep 16, 2024 at 6:23 PM Michael Jones <michael_b_jo...@hotmail.com> wrote: > Hi Richard. Thanks for the quick response. > > > > What surprises me is that a lot of substantive feedback was communicated > during the prior call for adoption and as far as I can tell, none of the > problems identified were corrected in the draft before the second call for > adoption. Incorporating it could have both solved the real problems > identified and likely increased working group consensus. > > > > I would really appreciate it if you could send a reply to my note saying * > *how** you plan to address each of the points raised – certainly the 5 > main points but possibly also the 6th bonus point “direction of travel”. > > > > Again, none of this feedback is new. It’s a synopsis of issues that you > were already aware of from the first call for adoption. > > > > Thank you, > > -- Mike > > > > *From:* Richard Barnes <r...@ipv.sx> > *Sent:* Monday, September 16, 2024 2:10 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 > > > > Hi Mike, > > > > This is a call for *adoption*, not a WGLC. Our thinking was that these > were fine problems for the WG to work on. The adoption question is whether > we believe the WG will succeed at that, i.e., whether we pretty much know > how to solve the problems. As your email points out, there have been a > bunch of good discussions about these problems, and broad agreement on > solutions. We will get a draft out in time for Dublin with a first pass at > getting them reflected in text. > > > > But resolving these problems should not be a blocker to adoption. > > > > Thanks, > > --Richard > > > > On Mon, Sep 16, 2024 at 3:55 PM Michael Jones <michael_b_jo...@hotmail.com> > wrote: > > I regret to have to report that the issues that I believe resulted in the > first call for adoption failing, despite being discussed on-list and at > IETF 120, have not been addressed in the specification > <https://www.ietf.org/archive/id/draft-barnes-oauth-pika-01.html>. I did > have a productive conversation with Richard in Vancouver, which resulting > in him mentioning some of the problems in his presentation > <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>. > Here are the problems that have not been addressed since the first call for > adoption: > > > > 1. *Application-level use of PKI trust chains.* As I wrote in my > response to the first call for adoption > <https://mailarchive.ietf.org/arch/msg/oauth/rPPI9E8fwN1NiMM1TkaQUfFYEDI/>, > “Other than for TLS certificates, the OAuth and JOSE specs generally steer > clear of dependence upon X.509 certificates. Especially for a spec focused > on JWK Sets, it’s odd to require an X.509 certificate to secure them.” > This problem is acknowledged in Issue 1 of Slide 7 of Richard’s > presentation > > <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01>. > As I also wrote > <https://mailarchive.ietf.org/arch/msg/oauth/zvIsbxHTFC4YXozOgOfQutR6GN8/>, > “application-level X.509 … is an anachronism that OAuth and JOSE have moved > away from”. > 2. *Reuse of keys intended for one purpose for a different purpose.* > PIKA uses WebPKI keys for signing things that are not Web resources. Key > reuse is not a good security practice. This problem is acknowledged in > Issue 2 of Slide 7 of Richard’s presentation > > <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01> > . > 3. *Authorities with paths not secured.* In OAuth, authorities such > as issuers can have a path component in their URL. But the spec says “The > contents of this field *MUST* represent a certificate chain that > authenticates the domain name in the iss field” – meaning that the path > component of the issuer is not secured. > 4. *Odd hybrid of JWKs and X.509.* The spec uses both JSON Web Keys > and X.509 certificates in the trust evaluation, which is an odd intermixing > of technologies with overlapping purposes. Architecturally, it would be > cleaner to go all in on one or the other. This is evident in Slide 5 of > Richard’s > presentation > > <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01> > . > 5. *Upgrade path not defined.* As Slide 7 of Richard’s presentation > > <https://datatracker.ietf.org/meeting/120/materials/slides-120-oauth-pika-01> > says, “Need to make sure that systems using PIKA have a clear > upgrade/interop path to alternatives to application-level certificates > (e.g., OpenID Federation)”. This is a point that I know John Bradley made > to Richard in person in Vancouver. This problem is not addressed in the > specification. > > > > I’m also personally uncomfortable with the *direction of travel* embraced > by this specification. For over a decade, we’ve been consciously working > to move OAuth away from X.509 and towards JOSE and this specification goes > in the opposite direction. > > > > As documented above, these problems were discussed and acknowledged. > Therefore, it’s disappointing to me that the updated draft didn’t address > these previously identified issues. > > > > Therefore, I believe this specification should not be adopted, as the > problems that caused it to not be previously adopted have not been > addressed. > > > > Sincerely, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > *Sent:* Tuesday, September 3, 2024 3:47 AM > *To:* oauth <oauth@ietf.org> > *Subject:* [OAUTH-WG] Call for adoption - PIKA > > > > All, > > As per the discussion in Vancouver, this is a 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 *Sep 17th*. > > 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
