As I tried to make clear in an earlier post - there is no such thing as a TLS cert. Various attributes MUST be included in TLS certs and that combination is well known and easy to request.
thx ..Tom (mobile) On Wed, Sep 18, 2024, 12:44 PM Michael Jones <michael_b_jo...@hotmail.com> wrote: > Hi Richard, > > > > We clearly had different expectations for the 2nd call for adoption. > Yes, I was in the room in Vancouver but nowhere in the minutes > <https://datatracker.ietf.org/meeting/120/materials/minutes-120-oauth-202407262000-00> > does it say that the authors were not to incorporate the feedback from the 1 > st call for adoption to improve the specification before the 2nd call, > nor do I remember that being said. Given that useful feedback was known to > the authors as a result of the 1st call, I was quite surprised not to see > the draft improved before the 2nd call by incorporating it, as were > others. Yes, the problems were **acknowledged** in the presentation, but > they could have been **corrected**. Not correcting them was a missed > opportunity. > > > > As it is, once I reviewed the draft for the 2nd call and realized the > feedback wasn’t incorporated, it felt to me like an attempt at a do-over – > running the 2nd call on essentially the same content as the 1st, but > hoping for a different outcome. Anyway, that’s my perception of the > situation. > > > > Thank you for responding to my 6 points. I’m not going to go > back-and-forth on them individually at the moment, as I think the chairs > should first figure out what to do about the new call for adoption, the > feedback received during it, and next steps. > > > > I will say that, given the legal and compliance issues raised by Vladimir > and DW, I personally don’t feel like we’d be on solid ground to adopt the > spec until at least the spec clearly says that the certificates used MUST > NOT be TLS certificates. > > > > Sincerely, > > -- Mike > > > > *From:* Richard Barnes <r...@ipv.sx> > *Sent:* Wednesday, September 18, 2024 7:28 AM > *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, > > > > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
