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 1st
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 <[email protected]>
Sent: Wednesday, September 18, 2024 7:28 AM
To: Michael Jones <[email protected]>
Cc: Rifaat Shekh-Yusef <[email protected]>; oauth <[email protected]>
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<http://pika.example.com/> when authenticating the issuer
URL <https://example.com<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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Sent: Monday, September 16, 2024 2:10 PM
To: Michael Jones
<[email protected]<mailto:[email protected]>>
Cc: Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>>; oauth
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, September 3, 2024 3:47 AM
To: oauth <[email protected]<mailto:[email protected]>>
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 -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
