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<mailto: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<mailto:rifaat.s.i...@gmail.com>>
Sent: Tuesday, September 3, 2024 3:47 AM
To: oauth <oauth@ietf.org<mailto: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<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
