[OAUTH-WG] Re: Secdir last call review of draft-ietf-oauth-resource-metadata-08

David Mandelberg <david@mandelberg.org> Thu, 12 September 2024 23:42 UTC

Return-Path: <david@mandelberg.org>
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 D765BC16943B for <oauth@ietfa.amsl.com>; Thu, 12 Sep 2024 16:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b="8YGoK73i"; dkim=pass (2048-bit key) header.d=mandelberg.org header.b="F3mDGDLT"
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 Mv8Y6v16_G8N for <oauth@ietfa.amsl.com>; Thu, 12 Sep 2024 16:42:07 -0700 (PDT)
Received: from mail-il1-x162.google.com (mail-il1-x162.google.com [IPv6:2607:f8b0:4864:20::162]) (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 21BE6C169437 for <oauth@ietf.org>; Thu, 12 Sep 2024 16:42:07 -0700 (PDT)
Received: by mail-il1-x162.google.com with SMTP id e9e14a558f8ab-39f51371baeso7538945ab.3 for <oauth@ietf.org>; Thu, 12 Sep 2024 16:42:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726184526; x=1726789326; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature:dkim-signature:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=r2Zq7iyXJ8wud9+o8+fFE4wklCxGGjaZtYI2abLHge0=; b=AHw0rfkRNlSJTqlTfc1spS4uKi2f23wx6uaXS923a5NtYFH9L3gLYmCC53tHE+8CdQ 7RsuT2vOnipx0RxLrzBcnLeBCL3kh4tMUtpCMOif3QYcXcpzP4bG5GmqxfHDJTefyC7L b09CDS59X/M1zVmm+N38F87NHmgSAS5tAQJw1HPp4CiGd53n90mP9EEDvKzhrwW9b/50 io+yNp0jcSQQO5pwqzCWE4qCFCXni3BL5ip9yesIQDH70wYlMtl1HqyoYtjiAiudwHAl 0ON5JO/lp5chYHWJC4LKADK0DEy/uVCdWM0foytCMdrNrVQPjsdrIcyitCo6qu0He30K srqg==
X-Forwarded-Encrypted: i=1; AJvYcCVbE8F8lGG9pr/oewvnyoJtvE5lHb3aKggYmtC4MP1QGIlajL8ZrH4uRWtm7UWPT1AcLuGD4Q==@ietf.org
X-Gm-Message-State: AOJu0YwuSAMlLtx8F9gDAMaNcEgZjUsvmGLCKNy/UCJgQwWSKtK7DgCe I61TyJZSAf3xQlx91i8eMstf5kdgsw4FfLdpcH5PKPu5q+jpjpvvamcSK5qe/uIHT89ZKm4heGj 0NBPxGlGM7Gxyhp9PTw7eamHvgwePO5xFKrdZhQUU+eW+JLQD
X-Google-Smtp-Source: AGHT+IFam7rK+PCO3n+aqFWgox89t9JNxT7cVkaxIFgXpCZysfDSTFOb+WRypryewotL4fsL1PAB9Ks4mZa3
X-Received: by 2002:a05:6e02:1d05:b0:39d:2a84:86a3 with SMTP id e9e14a558f8ab-3a0848aff21mr52721815ab.4.1726184525835; Thu, 12 Sep 2024 16:42:05 -0700 (PDT)
Received: from mail-outbound-e14cf917.virgo.mandelberg.org ([2600:4040:52fd:b906::8]) by smtp-relay.gmail.com with ESMTPS id 8926c6da1cb9f-4d35f77e66dsm136947173.43.2024.09.12.16.42.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2024 16:42:05 -0700 (PDT)
X-Relaying-Domain: mandelberg.org
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-597d7abb; t=1726184525; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : from; bh=E8tri1Mb9wxXM6nUSP9OBOYDKWtjdlWtM4x2rh+v/Aw=; b=8YGoK73i3hevtLtLRiAtP00uo4o5KsxoX9+SOm3G+CR0vTNh9Y/AcKqct1rkoT6J+728L tu/kg6GBCebtxXBDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-e56dad1c; t=1726184525; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : from; bh=E8tri1Mb9wxXM6nUSP9OBOYDKWtjdlWtM4x2rh+v/Aw=; b=F3mDGDLTWO96DXDsR1JMzftRgewpTAWNRirtLoeGH0LX5z6vUt24n0+PwW44xpJecN32d P+uHk7rVVb3tHMEqoXMbr/x9GUY5jtPNriJAH46rElITRD/VdPlwWh6ZmlFQho/M2tM+lJh UgJMvvNIue3CeRLuW1A0YNEAvVr6ecZLFE7gMth5IXaz8KHHnFhx5uAzaWJbo0/ZRXpHwl8 r0hBnoP50Y95T0OPx/nUTyx5PAvdpMKBMmSOdBP8ZnTXQtIgg34rn/sZN6OP31MWRbd6QzO GcFQ0bu7RvoLWfcoXev3jn+CvtaWPOEFwJkgcfx1jScFR54fveyMzxdgp5Yg==
Received: from [IPV6:fde5:2b79:35f0:2::166] (unknown [IPv6:fde5:2b79:35f0:2::166]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4X4YrF0F0xzySJ; Thu, 12 Sep 2024 23:42:05 +0000 (UTC)
Message-ID: <7d51f45f-4417-4143-a9c6-4ebffd375491@mandelberg.org>
Date: Thu, 12 Sep 2024 19:42:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Michael Jones <michael_b_jones@hotmail.com>, "secdir@ietf.org" <secdir@ietf.org>
References: <172384809277.1449681.408544072139184106@dt-datatracker-6df4c9dcf5-t2x2k> <SJ0PR02MB743925A6D204478BE2A21C6CB79B2@SJ0PR02MB7439.namprd02.prod.outlook.com>
Content-Language: en-US
From: David Mandelberg <david@mandelberg.org>
In-Reply-To: <SJ0PR02MB743925A6D204478BE2A21C6CB79B2@SJ0PR02MB7439.namprd02.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: VTEBVWQ4N3UTKLRGCFOR5PINWHEJ46QI
X-Message-ID-Hash: VTEBVWQ4N3UTKLRGCFOR5PINWHEJ46QI
X-MailFrom: david@mandelberg.org
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: "draft-ietf-oauth-resource-metadata.all@ietf.org" <draft-ietf-oauth-resource-metadata.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Secdir last call review of draft-ietf-oauth-resource-metadata-08
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zA69agEOXRAh3JH1jclTAF2YQr4>
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>

Those changes sound good, thanks!

Op 2024-09-10 om 22:22 schreef Michael Jones:
> Thanks David.  My replies are inline below, prefixed by "Mike>".
> 
> -----Original Message-----
> From: David Mandelberg via Datatracker <noreply@ietf.org>
> Sent: Friday, August 16, 2024 3:42 PM
> To: secdir@ietf.org
> Cc: draft-ietf-oauth-resource-metadata.all@ietf.org; last-call@ietf.org; oauth@ietf.org
> Subject: Secdir last call review of draft-ietf-oauth-resource-metadata-08
> 
> Reviewer: David Mandelberg
> Review result: Has Nits
> 
> Overall, looks good. I just have a couple of questions that might not need any changes to the doc.
> 
> Section 5.2 says "SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained" which makes sense for the values included directly in the metadata.
> 
> Mike> How about if we make this change to 5.2?  Change "and use the new metadata values obtained" to "and use the new metadata values obtained after validating them as described in Section 3.3"
> 
> For the URLs like jwks_uri though, is the client expected to retrieve those again even if the URL itself didn't change? Or does that not need to be specified?
> 
> Mike> URLs such as jwks_uri are governed by HTTP caching rules, as is the primary metadata itself.  I'd already told Arnt Gulbrandsen in my reply to his ART review that I'd add something about caching lifetimes in the Security Considerations.
> 
> What do you think about adding something to section 5.2 about redoing all validation (like checking the resource field and validating the signature in
> signed_metadata) before using new values? I'd hope that any implementations would do that without it being specified, but I could see some bugs if the code path for fetching initial values is different than the code path for updating values.
> 
> Mike> Your comment about signature validation made me realize that we don't say anything about validating the signature of signed metadata!  I propose to add something like this:  "The recipient MUST validate the signature of the signed metadata using a key belonging to the issuer.  If the signature does not validate or the issuer is not trusted, the recipient SHOULD consider this an error condition."
> 
> Thanks for your useful review!
> 
> 				-- Mike
>