Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 10 January 2020 18:14 UTC

Return-Path: <torsten@lodderstedt.net>
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 9DFA8120B3E for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 10:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKhOZCBjWAZL for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 10:14:43 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14226120B01 for <oauth@ietf.org>; Fri, 10 Jan 2020 10:14:43 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id z7so2668981wrl.13 for <oauth@ietf.org>; Fri, 10 Jan 2020 10:14:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=gnWxfchKmqfwcp0HhtX7N9oK7w6fRoWoKdvGsrj1DBQ=; b=morHIYDoEvkqmFOLmJDFnavmo9L2olSGIOUk9ZcBbYvLI6bzDih3vwHJDy9xvoxWn1 94jD6GutGh4s9VL333YwEtSzI2eCddm29525i9+MM1TAtGQ6KRUrLhqjdy7qyKBniqmu JvlL4l5xVfRKehQRjTSAPMCoHW7RT/oRVxfjj865/m0RX6iKZ8FCJShc8l5erKTTRbAL oKesku9UZ2SwKIN0gWJpLUXf0m5YVceBR3bPZgqF1hZoFq2XFEpXQPuZ8nhQef2jkTZn zz1bhXRcmgCGrC2JpXJ8eynKZqC+hbSBUuSPlgeTf48gIuqlUoxkKMEM9Jd4NMXF6YDL GZ6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=gnWxfchKmqfwcp0HhtX7N9oK7w6fRoWoKdvGsrj1DBQ=; b=BZ9cHBfTqUabxFT8olDvWo49Pr3kXCd+a4w8jgFN4txaCqGzSBqRn736TbmCxMBWym beQndKTxYs/UOEOaSk3XFM4RSOd8bcUITOEoQA7JX7Vgxet9TOnfHSq27cw4fJqDdxFv CX+bciH6iv8bRK6bEKX94SlaqNPpLtL0uDnnonO333rEC6C9GMsuzOG2vR6MEXjJxypT kH3raODoHrO3ROFPakzHPleeCZC4skFUpKA9FgwIcwLFCgboCcz/Wb4Hib0yJsRvvtZ/ sr2R59pOI2sIiTIDLgsbIcfFGVoT3mhAyAGl0fbVCsuUrthvbkTZ3N9er8Mt7kBBeg4s 8Z7A==
X-Gm-Message-State: APjAAAUYr3XkXc6IYioRkxxQsbS9ZJ+YqZQnmw04Q6K76buu7uQEo41U IOGQb+1+d0cWitTBDDQFd+aCufbEBVJRHMIf
X-Google-Smtp-Source: APXvYqxqsAtDv0/8CA+bthPQ+lUdmtw6Fy4ik4Uv56APZ4Di2PHWx8qLCO7BO0EqVV0isQ6yVhpc0A==
X-Received: by 2002:a5d:49cc:: with SMTP id t12mr4591741wrs.363.1578680081512; Fri, 10 Jan 2020 10:14:41 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id s8sm2955861wrt.57.2020.01.10.10.14.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:14:40 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 19:14:39 +0100
Message-Id: <9D366169-C548-4D5C-8F4B-E546829DC9B0@lodderstedt.net>
References: <CAD9ie-sHSNn34S-hyQHa-uxMKNhH22i-9ajdyTEyPh8w61yHsA@mail.gmail.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
In-Reply-To: <CAD9ie-sHSNn34S-hyQHa-uxMKNhH22i-9ajdyTEyPh8w61yHsA@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: iPad Mail (17C54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/s7afvdhI-r8F4dHI4LDVkO8G7hA>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Jan 2020 18:14:46 -0000

You mean additional JWKS URIs, for example?

> Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail.com>:
> 
> 
> Perhaps I am misunderstanding what Annabelle was getting at, but having more than one key in the metadata document would solve the the issue. IE, extensions would define their own key instead of using the same one.
> 
> The metadata document itself was an extension. 
> 
> 
>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> 
>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:
>> > 
>> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Provider, and the access token is being defined. These extensions have assumed all of this functionality is a monolith. 
>> > 
>> > I'm not suggesting that we MUST make changes to existing extensions, but design future extensions so that an implementation can separate duties if desired.
>> 
>> How do you envision this to work? As you said, OAuth 2.0 is built on the assumption the AS is (at least logically) a monolith. All extension were built on that underlying assumption. I don’t see how an arbitrary extension can relax that assumption and still be compatible with the rest (just revisit the discussion re PAR and keys).
>> 
>> I think we should accept this design assumption, in the same way we should accept form encoding as request format instead of JSON, for OAuth 2.0 extensions. 
>> 
>> OAuth 3.0 could explicitely be developed with different architectures in mind.