[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
>