[OAUTH-WG] Re: Call for adoption - PIKA
Richard Barnes <rlb@ipv.sx> Mon, 16 September 2024 21:09 UTC
Return-Path: <rlb@ipv.sx>
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 52D6EC15155B for <oauth@ietfa.amsl.com>; Mon, 16 Sep 2024 14:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=ipv-sx.20230601.gappssmtp.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 Kq7FTXRjnOUp for <oauth@ietfa.amsl.com>; Mon, 16 Sep 2024 14:09:52 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 72A41C151552 for <oauth@ietf.org>; Mon, 16 Sep 2024 14:09:52 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-82cdadeeb2eso153994239f.2 for <oauth@ietf.org>; Mon, 16 Sep 2024 14:09:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1726520991; x=1727125791; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IGe7p4sXFhAMcOrVKR8c7ZgD1F0Sb+lwOjBBKY8FbaE=; b=fL2qdQllKEQvu3Q5YKqxR7gQ4Q5MLusT3R3CMP7zBM45e+MMNedxegiKRRx/UGI9QH s1TU8gSWMM+VIImoPrKEE0ZW+SBWg+aqHhkqbLyjlem+yVEsCINT2ar6viFeoetKy80T 2er39SXrwd3FLDgLNAZU70JrjaGveGks8FlLNY0oHYBSuZxVLCuZxqa4c5oS+ZFTodui p/8NDSnh+muHk8HwICKpbu7AXOijbeTByyLkc70eXPkScehoOkRyrbbr//Ob9/JbgtDm O+I4pVGdOXg3hIofdKQMtqamX0UIQVBCkYwoKJqnxYBPqPZfbxQbtFJHQEveh1pUiuOw YoGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726520991; x=1727125791; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IGe7p4sXFhAMcOrVKR8c7ZgD1F0Sb+lwOjBBKY8FbaE=; b=ds5aVxQfhTMfWgU0qDCyY11DNyAqdsqHtc3vFyv8owbK5FCPd14E2NY4r8tMGVdOfm EOY2t2A5u9rKDMEl9mVuyVgT8LISlApTZn84dRC0hk03ryjtLbCCZbQnxcrHgjui+vDa D579Yx0M783GC2EXOQgzpISzl5PgQQgDNvaRBaGBcCXSaVm6xwRBSkVK1h9jslQOWk2D 2xupTgz/Hd3sDNMoMMIZSuyPB5y6NLQDfSFb1m1Tp6CzWrdKGVkL+916WYeqDFSVRU75 YoZEeWVguwW7ENr2rK/fU2BVrjVZt+7dB+wXKQCYdVyNdBYikhI5teVm3IEjSjPCsNgz yb/A==
X-Forwarded-Encrypted: i=1; AJvYcCWYvJn9fgbNmMuntazDynz7z1yyiROCZPVActM5/NaeDUnyWCVEBALAe+PTTnAHN9ex97KRiQ==@ietf.org
X-Gm-Message-State: AOJu0Yw8KgLsBFOQ94V4jeVMvimdV3PtkDGorVhNdMaLv53zPTzJA7Jc SEtjSMj5maiCcjQgKyADb75rKLpEhnhcsgcpumZbmqH0dt6iJSKqoPWKrl0GqAUcQ+ik/09DZ8d g0GuXCPKp4+3n1wz+co2jFtlf9irVBmYApWKPkg==
X-Google-Smtp-Source: AGHT+IE8R3L0FGY1Vy3IScV6je/wkqAxclAwB83lcQrRFXskorQ8J0+tgMrphrvFWBUQEAImAZkVrPwsc+6YQDxuj9M=
X-Received: by 2002:a05:6e02:1a68:b0:39f:5557:857f with SMTP id e9e14a558f8ab-3a084900bc8mr146998335ab.6.1726520991187; Mon, 16 Sep 2024 14:09:51 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP80YnzxOc_NDbFqK0bv=i0Ys1s8hYHwo-PqhUPbAWs4sg@mail.gmail.com> <SJ0PR02MB7439153AD9ACAC9C1C5563A4B7602@SJ0PR02MB7439.namprd02.prod.outlook.com>
In-Reply-To: <SJ0PR02MB7439153AD9ACAC9C1C5563A4B7602@SJ0PR02MB7439.namprd02.prod.outlook.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 16 Sep 2024 17:09:39 -0400
Message-ID: <CAL02cgR0LDDq_ZD1MXy3T-qapKrx0DywvXiKi6m+0T4PPH4RNg@mail.gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Content-Type: multipart/alternative; boundary="00000000000060ad50062242fe49"
Message-ID-Hash: HIVTLY2OEB3WBDWD4YAGROIEBV4MXSR4
X-Message-ID-Hash: HIVTLY2OEB3WBDWD4YAGROIEBV4MXSR4
X-MailFrom: rlb@ipv.sx
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
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mQ7dOj6luHxBSiACvUez_9GuwhA>
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>
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-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