Re: [OAUTH-WG] Signed JWK Sets

Watson Ladd <watsonbladd@gmail.com> Tue, 19 March 2024 01:36 UTC

Return-Path: <watsonbladd@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 3B1FAC14F68B for <oauth@ietfa.amsl.com>; Mon, 18 Mar 2024 18:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, 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 zKnAGurcllSC for <oauth@ietfa.amsl.com>; Mon, 18 Mar 2024 18:36:52 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 690F4C14F600 for <oauth@ietf.org>; Mon, 18 Mar 2024 18:36:52 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-41412411672so10597385e9.3 for <oauth@ietf.org>; Mon, 18 Mar 2024 18:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710812211; x=1711417011; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rY66ud2FUGvWpwxvwU7ydF2ARptCZ8oJKiM9w8/q/0k=; b=kmcUupnAmTVhKjq4jheQe0V/higtpwT3a8zsH0aQ7wmUpitqcdYpw359R3cCpqp5Yl R8SVUyZg8sEqGt8YqzDrPcwbX4PCdD9Zq46BQWVMU+Ze4MgSbcXN0aQEDnGE39kcNdgx 3sDwrLlvVw60FdGrBLXFXZ/Py6g5HJWX8TFyUQqZaWXI4MQsvh4+iVu3/LCFUe/eZKkS QGXItsk4DGjHvMZQpNTG5dahp/7/z6ouoFRW7eB+C8ra1FNMQEXEfSIPz2PzT1GE41o3 9PDY8quoTtCj6AxbeOhZI00iJfrnZMoKHYHOQNbEiQNsg+k14tIcNxUju5qoheg+cFoE H/Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710812211; x=1711417011; h=content-transfer-encoding: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=rY66ud2FUGvWpwxvwU7ydF2ARptCZ8oJKiM9w8/q/0k=; b=QL3ItLD9X0XtACooNasKfPEYjefOriTY3VHX5czd4vL/BZXE1CLZQtZtLx1fc4Ejv6 l4XewfnFr4ACfgKDqstqKo/dtHZsNptmT8eomEZX4fN3YUCfwOZn1mfrDgy1lMIXpo6V HJHeadg9/CQog1wtWOGRu6rTvx9wStIM9gPV/7TNZ5zTPej4n9VXMJq4AqxA561WnHpX NL2/rFzl9f1BgvgjGclCX6+9XudZg+yQbY+LvpVIWk9luZmsuddbG7Z15IO0l/tnCO/o AjY5nRKRIdmj9db4aGiIgwNIWw4Cxb8UD6PuuL4B+SH/FKVFnpPSch2qKTiWXFz5a9xp 654g==
X-Gm-Message-State: AOJu0Yxj1aKWzobg+hXf9G4JUal5IIE5+PWOS4isF/c/cCq5NQXJKwRQ hUi3g8HtXgPKh5yr4oxmSK2TqknOnPhx3AethOEw9sI6LlqF/mMQWNzoHNxh1KPk+xQ3p9cj118 iZ1PNZOTpcDEK4T8wVwjWZBvmYg7SUW9S
X-Google-Smtp-Source: AGHT+IGIMk+ue8eyYpuyrJUFrZFjx50kZWEpFuIw/cvS8XaT3KJKhyQdJQgaJDCTX7QSnobLDtJtiyy3zLJED2fCDqI=
X-Received: by 2002:a05:600c:138b:b0:413:ee37:20e0 with SMTP id u11-20020a05600c138b00b00413ee3720e0mr8820517wmf.9.1710812210637; Mon, 18 Mar 2024 18:36:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgSANrR=nys3RXDOYJPibLkv25X8Okq4dhL0Dpfi_ZSS_A@mail.gmail.com> <CACsn0cm0XdfFEjspPuBaHiv5AD0PNpCCRifo4OOC+F+XC3rAmg@mail.gmail.com> <CAL02cgQVWQfQ2wnpHZ2=OL5NMJTMf_Bxv+jifBFzu0WK+wYqrg@mail.gmail.com>
In-Reply-To: <CAL02cgQVWQfQ2wnpHZ2=OL5NMJTMf_Bxv+jifBFzu0WK+wYqrg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 18 Mar 2024 18:36:39 -0700
Message-ID: <CACsn0cmM3otJ-P0O7dVNtNzc8sjJUxzOfzz+nAgmzqXtzdXb-A@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>, Sharon Goldberg <goldbe@bastionzero.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HiX_WSvBNO7Kgf0mo8CAaEuMhYw>
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: Tue, 19 Mar 2024 01:36:56 -0000

On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes <rlb@ipv.sx> wrote:
>
> Hi Watson,
>
> I appreciate the concerns with regard to re-using Web PKI certs for cases such as these.  Care is required, but I think there is a path here.
>
> 1. Clearly there are cross-protocol concerns.  I expect that most usage here in reality would be based on ECDSA / EdDSA, not RSA, which helps.  I would be comfortable with security considerations recommending that a key pair / certificate used for signing these things be used for no other purpose.
>
> 2. Validity times are definitely a challenge for the container signing use case, but from the conversations I've had with that community, they are taking an orthogonal approach.  As I tried to sketch in the document, they are establishing authorities that will vouch that a signed thing existed at a given time, so that a relying party can safely rewind their clock and validate as if it were that time.  See, e.g., SigStore <https://www.sigstore.dev/>, which has roughly this shape if you squint right.

That should work out: might want a security considerations saying this.

>
> 3. I don't think there's actually any disconnect between HTTPS authentication and proof of authority.  The Web PKI is about authenticating domain names, which is what both use cases require.

Only with certain validation methods. Others like agreed upon change
to site content have a narrower scope and the BRs reflect this
subtlety. To be honest you're probably safe and I am not the expert
here.

Sincerely,
Watson

--
Astra mortemque praestare gradatim