I really do not understand most of Mike's objections. If key reuse were such a problem then TLS keys should be used for nothing but TLS. He didn't complain about that. The original use of PKI was application level protection. TLS came later. I am no fan of X.509. It is ubiquitous right now. Peace ..tom jones
On Mon, Sep 16, 2024 at 12:56 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
