Re: [OAUTH-WG] Signed JWK Sets

Neil Madden <neil.e.madden@gmail.com> Fri, 12 April 2024 07:00 UTC

Return-Path: <neil.e.madden@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 46036C14F686 for <oauth@ietfa.amsl.com>; Fri, 12 Apr 2024 00:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.203
X-Spam-Level:
X-Spam-Status: No, score=-6.203 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, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 AG2BWGGdVKg4 for <oauth@ietfa.amsl.com>; Fri, 12 Apr 2024 00:00:43 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD419C14F61C for <oauth@ietf.org>; Fri, 12 Apr 2024 00:00:43 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-516d585c60bso214667e87.1 for <oauth@ietf.org>; Fri, 12 Apr 2024 00:00:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712905241; x=1713510041; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=kEiZjlIeWJoJYLbglAMyAtzYkrg6h2U/btF/wp0DdNw=; b=khvv3yBfof2efWK2M7a7uLKDBnfgAxBg+lEfNNeSvXLkaJ9zHguGaaLOaWW1vPSx4v papATkJfuivvt5dtdVflfSLbWSpgm5Alr837yevXyCnjrcIkLjCj3wB92NPEUhQr+Z8/ 0t5xAJDbHowq4gUdK3H29lmoHrHiC8m2ZH6XyANXVEHFZLf/VnaHNrS+KAEJ4SJLQ4vO Hv2hPQkY7DoNRTo2tM6dyB5wDtTgNnaSaSA423Y29vN7a52KkLPLMZGAQNSkxv5OxqaB K7RO6JZKBObdz6TdUiJ6mofjmhKyOJrvblM/6cKhlBJPoQKGQ7ID/FOcVdE5IaP1oq5g 9o7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712905241; x=1713510041; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kEiZjlIeWJoJYLbglAMyAtzYkrg6h2U/btF/wp0DdNw=; b=WP0NHj6eMw9fUUm/oEfTL1DArpKloaqIrLhcqw2Cezg2JjsTVqNg8t59+GbCvNxjEV wdYYNz6smyglRqljv11ljRDHDtRFrRUunMxmRNVdV3lkqV1dCCndHgmw21USTkJ+pKO1 fjj+LSgB/BXWeZW2eXqNrUn62RuBOXU4kCPFy8V8MUCXkkts33WzudarT5up/qR876Rt ZRxwVjX9uxzQAa+Rb7Fzsvrnwc9Dn7SGsJPhWCz1tqbBTb74486fqwT/hbXQJE/YJc11 zevuwdxTbCpVdT+kv8/WY+6DzFzLVr3HjdKMVnkFcdX8gRPfqIRa/X2YobMSoyijB/Fw ZR/w==
X-Gm-Message-State: AOJu0YweD1w+5uuZRZTCLkbOu1POlGZ0rLZ9gDH1feMbtfD8oJvAARYw KA4gA53bnFWdfuSu/ol5Bn13/fmakMVdJkQdbK1PIrefptMzrHLXF8jOtTzj
X-Google-Smtp-Source: AGHT+IEGiu7eQBx7Oo9RbIRvPUb6mUb2dtpNUVnzEzCqyPUeCfmUozI65914SVxvI+IEGkRYfKsj2w==
X-Received: by 2002:a19:8c4d:0:b0:516:b004:590 with SMTP id i13-20020a198c4d000000b00516b0040590mr831460lfj.4.1712905240988; Fri, 12 Apr 2024 00:00:40 -0700 (PDT)
Received: from smtpclient.apple (234.243.159.143.dyn.plus.net. [143.159.243.234]) by smtp.gmail.com with ESMTPSA id r7-20020a05600c458700b00417e5b71188sm3193447wmo.34.2024.04.12.00.00.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Apr 2024 00:00:40 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
X-Google-Original-From: Neil Madden <Neil.E.Madden@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-6E84EB71-36D9-4DDC-A725-6E4F52FD04B1"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Apr 2024 08:00:29 +0100
Message-Id: <40D027C8-F12E-460D-8B60-4ABA80581C98@gmail.com>
References: <CAL02cgQG4Fhn2zCmq0EFLJReB_jf257msdM9OEgYr03n6D1qRg@mail.gmail.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>, Sharon Goldberg <goldbe@bastionzero.com>
In-Reply-To: <CAL02cgQG4Fhn2zCmq0EFLJReB_jf257msdM9OEgYr03n6D1qRg@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: iPhone Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zp1HE_H0PD2KAk5RsNlNmH1gA54>
Subject: Re: [OAUTH-WG] Signed JWK Sets
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2024 07:00:48 -0000

I’m not sure this is an official call for adoption, but I support this draft. Regardless of the discussion in the other thread, I think this draft has clear value and is well designed. A couple of thoughts:

Presumably it is infeasible for a client to construct a TLS transcript that looks like a valid JWK Set? Ie because we are reusing the TLS cert signing key, I want to check that this doesn’t open up an issue where an attacker interacting with TLS can trick the server into signing a PIKA of their choosing. I’d like to see a security analysis of that. 

Are there privacy advantages to using PIKA? It seems like clients not all calling back to the OP to retrieve verification keys would also prevent some tracking? If so, that seems like a good positive to add to the draft. 

Best wishes,

Neil

On 9 Apr 2024, at 20:33, Richard Barnes <rlb@ipv.sx> wrote:


Hi all,

Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a second pass at this idea and actually made an Internet-Draft this time:


The new draft is focused on "Proofs of Issuer Key Authority".  This new framing is based on a couple of important bits of feedback from Mike Jones, (1) that OpenID Federation had already defined most of what we need, and (2) that it would help to be clear that the real focus here was on replacing HTTPS with JWT as the proof that a key is authoritative for a given issuer.  Given that, we reuse the "historical JWK set" format from OpenID Federation, and of course, focus on the "key authority" issue.

Obviously, more feedback is welcome, but especially on whether this would be a good thing for the OAuth WG to work on.

Thanks,
--Richard


On Sun, Mar 17, 2024 at 1:55 AM Richard Barnes <rlb@ipv.sx> wrote:
Hi all,

A few of us have been considering use cases for JWTs related to Verifiable Credentials and container signing, which require better "proof of authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick specification for how to sign a JWK set, and how you might extend discovery mechanisms to present such a signed JWK set:


(Just in GitHub for now; will publish as an I-D when the window reopens tomorrow.)

If we could get this functionality added to OAuth / OIDC, it would make these use cases work a lot better.  As a prelude toward proposing working group adoption, it would be great to know if this design seems helpful to other folks as well.  Obviously, happy to answer any questions / comments.

Thanks,
--Richard
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth