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
