[OAUTH-WG] Re: Call for adoption - PIKA
Tom Jones <thomasclinganjones@gmail.com> Wed, 18 September 2024 20:45 UTC
Return-Path: <thomasclinganjones@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB738C151088 for <oauth@ietfa.amsl.com>; Wed, 18 Sep 2024 13:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMXTzB4wFCKN for <oauth@ietfa.amsl.com>; Wed, 18 Sep 2024 13:45:48 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ABAC151522 for <oauth@ietf.org>; Wed, 18 Sep 2024 13:45:48 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-535dc4ec181so114314e87.3 for <oauth@ietf.org>; Wed, 18 Sep 2024 13:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726692347; x=1727297147; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+Hm9TicTGGfnx9glyEBRa/yqSoFmwUvdBkjnX/oBCT0=; b=VT4PsfXdvsYGHb/ANrYD21mhJ8s/VSi5nzBf7Epv4T++KZYjoXfMBPOJ6C9OP1XYUi kYtnYDbXO1bv6lhMgddrdTU46xFp9lUx5Yu2jL1UCz9853PP/b55yOr61Qv1Mm7wbU4+ Tn/eo1+FRLL3O4kIS5g6cH5DWk1hYGAW9FtgF0JkskLfgP2vx/zO4nxLwZeMmCuf9pFz 3slmCjrq1GtVQOccyxwH4EhVn7lFLpr4VHW/LAU4iD9l26n9zOWiB+1ze24wNug6jSPy S9MhrF0MmswE94IjAq+Fzxc7kBQ8aahFq0AwocQoqhy03lGqqb3J0fG+2yjlRb/7Fmuw 9zOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726692347; x=1727297147; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+Hm9TicTGGfnx9glyEBRa/yqSoFmwUvdBkjnX/oBCT0=; b=U/Vzyjk/HUNfycJqAnP0hfVsvZJvbuz4bIcRC3aCOSjePjqgYZRVjb+Uywcd3ZIRm3 EaHCfH3E6ceKFKgVROmnbGUOQb4QdmzRZMyf05ESUFqM0K32o1DZkigcTAZsccUCqAUV F+JBV3N1nL9KLLnhpxggOjGt6Y2vXnqm78bvkhQ/4tik9nK0O2lk8SLzS22xDDDvA2mJ oEBocHMrEPeg02GRLStt8Qcvaa2H5MxfrGS5PhmJiBDozTVHzU3oR8lJWKTSm6XbDSD2 z5H+VOyQxbWTsQOBU+5wr5is+jDHk3HVhhf4e9QDRZFLtaqx154NcncqkZrfVXqk6O7o XwFg==
X-Forwarded-Encrypted: i=1; AJvYcCVyGJtsWvfvUFtnutFQpmdlIkgKmmSuBxemvMesSuL8mOcmfhkN8h2UQE1tntZhIcZFZYFuGw==@ietf.org
X-Gm-Message-State: AOJu0YwemblUts9JBTgSM6+8orgNloFUcDgtu6uDhi6CrTEaXT0Gpm7k tokDG8a574xUGa4yBYT4lNQbivGN6bCjIIb/AJWTFhj4F0TbJnp4Jw/3IF0OADgrmF/VLFc2hVE G3xWyBpW7UL3Uj7rn824E5TWNO4sSSA==
X-Google-Smtp-Source: AGHT+IHiO5MQRpJdBUDJOFQZaXDTqI3HF8cbI0hg516dNq/Zh0eZhLrdFQFj9D5jMDGPzz3mdtLFH+azkvgibKZ1g4o=
X-Received: by 2002:a05:6512:68c:b0:533:4817:7280 with SMTP id 2adb3069b0e04-53678fc24dbmr13973730e87.35.1726692346372; Wed, 18 Sep 2024 13:45:46 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP80YnzxOc_NDbFqK0bv=i0Ys1s8hYHwo-PqhUPbAWs4sg@mail.gmail.com> <SJ0PR02MB7439153AD9ACAC9C1C5563A4B7602@SJ0PR02MB7439.namprd02.prod.outlook.com> <CAL02cgR0LDDq_ZD1MXy3T-qapKrx0DywvXiKi6m+0T4PPH4RNg@mail.gmail.com> <SJ0PR02MB743983DC316ADED427CBB3F4B7602@SJ0PR02MB7439.namprd02.prod.outlook.com> <CAL02cgSA5LzHuj92Ar3QPFYStPYGTpR2YA75RQichOcwQbMdNQ@mail.gmail.com> <MW4SPR01MB0004D7F8EB9345C7C2B5853BB7622@MW4SPR01MB0004.namprd02.prod.outlook.com>
In-Reply-To: <MW4SPR01MB0004D7F8EB9345C7C2B5853BB7622@MW4SPR01MB0004.namprd02.prod.outlook.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Wed, 18 Sep 2024 13:45:34 -0700
Message-ID: <CAK2Cwb6BW04OCoDuPf8WxBo+p_d6J5k6BkD+ys+chVksrLt34A@mail.gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Content-Type: multipart/alternative; boundary="000000000000f132e106226ae382"
Message-ID-Hash: 3QIJMC5N46NK5VLVPBKS24KBQNB67GH4
X-Message-ID-Hash: 3QIJMC5N46NK5VLVPBKS24KBQNB67GH4
X-MailFrom: thomasclinganjones@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: peace@acm.org
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9mYE03Cd2JqCNHSJ8dZl3MSmdJc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>
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_jones@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 <rlb@ipv.sx> > *Sent:* Wednesday, September 18, 2024 7:28 AM > *To:* Michael Jones <michael_b_jones@hotmail.com> > *Cc:* Rifaat Shekh-Yusef <rifaat.s.ietf@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_jones@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 <rlb@ipv.sx> > *Sent:* Monday, September 16, 2024 2:10 PM > *To:* Michael Jones <michael_b_jones@hotmail.com> > *Cc:* Rifaat Shekh-Yusef <rifaat.s.ietf@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_jones@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.ietf@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-leave@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org >
- [OAUTH-WG] Call for adoption - PIKA Rifaat Shekh-Yusef
- [OAUTH-WG] Re: Call for adoption - PIKA Neil Madden
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Falk Andreas
- [OAUTH-WG] Re: Call for adoption - PIKA Joel Kamp
- [OAUTH-WG] Re: Call for adoption - PIKA Ethan Heilman
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Joseph Salowey
- [OAUTH-WG] Re: Call for adoption - PIKA Pieter Kasselman
- [OAUTH-WG] Re: Call for adoption - PIKA Kristina Yasuda
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Vladimir Dzhuvinov
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA David Waite
- [OAUTH-WG] Re: Call for adoption - PIKA Watson Ladd
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes