IETF Logo Mail Archive

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

"Richard Backman, Annabelle" <richanna@amazon.com> Wed, 29 January 2020 21:36 UTC

Return-Path: <prvs=29003f41f=richanna@amazon.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 614A012004E for <oauth@ietfa.amsl.com>; Wed, 29 Jan 2020 13:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
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 xXAhG_Zle8co for <oauth@ietfa.amsl.com>; Wed, 29 Jan 2020 13:36:03 -0800 (PST)
Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33B3120047 for <oauth@ietf.org>; Wed, 29 Jan 2020 13:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1580333763; x=1611869763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yKcCa7m1NWozs7DJRnZKdxw5tLQTEcobY19nqTESfO4=; b=gNZ/+KvEPJs3+k8hBUFOnIwvS1u2GvCNntCrJUhgsU6dOCqjZ3ohb+W2 irtestUMWrRmI/v7EeZXp0BG9ozmGMnvfCUT9Fb64WHlRgOHWvIOf+gSy BfcOhl8uM0AgtsqnUV+mWM7oUs8my7qy2UlabORAiYEoi7HmwXGYz67iQ U=;
IronPort-SDR: V5brS7/Q3VTs9oaBev4TjDpo5k7W4vSfI124zwUdR7flSJL4eUlpV5XyOu6AHBrrdTa4isAa/b ijLXmP6MVFSA==
X-IronPort-AV: E=Sophos;i="5.70,379,1574121600"; d="scan'208";a="13499776"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 29 Jan 2020 21:35:52 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 805DFA1F4F; Wed, 29 Jan 2020 21:35:50 +0000 (UTC)
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Jan 2020 21:35:49 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 29 Jan 2020 21:35:49 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 29 Jan 2020 21:35:49 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
CC: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri
Thread-Index: AQHVy+YWu2zA9W8kAkangjebWqbyl6ftg5qAgBPFRwCAAPd4rA==
Date: Wed, 29 Jan 2020 21:35:49 +0000
Message-ID: <C42BEE5B-C73C-4211-9ED7-656513A83C3D@amazon.com>
References: <CAD9ie-vRsL9ey2LDNoaWkapRUewS_c1S0r3QCcqJLmJ5KqKsGw@mail.gmail.com> <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com> <CAD9ie-uebUCw5vxELPXQvQSY3Z3T2dNJGOpzEQ8cMgZcCOu+tg@mail.gmail.com> <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com> <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu>, <ME2PR01MB3524A19AEE8C383C1F8FEF6BE5050@ME2PR01MB3524.ausprd01.prod.outlook.com>
In-Reply-To: <ME2PR01MB3524A19AEE8C383C1F8FEF6BE5050@ME2PR01MB3524.ausprd01.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nim-IUK6N4aJd0_p5n4YmcfC59Q>
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: Wed, 29 Jan 2020 21:36:06 -0000

This could be nice, but it’s solving a different problem. The issue I’m drawing attention to is about how an AS indicates that a given key is valid. That’s what the jwks_uri AS metadata property is for, and it does a great job. The problem is that it does not allow enough granularity. Currently all an AS can do is say “here are the keys to use to verify stuff I signed.” It can’t say “here are the keys to use to verify ID Tokens, and here is a different set of keys to use to verify access tokens.”

—
Annabelle Backman
AWS Identity

> On Jan 28, 2020, at 10:51 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
> 
> 
>> 
>>> It would’ve been nice if JWK could’ve agreed on a URL-based 
>>> addressing format for individual keys within the set, but that ship’s sailed.
> 
> Using the fragment on a JWKS URL to indicate the key id would be good.
> Then a single URL by itself can identify a specific key.
> 
> https://example.com/keys.jwks#2011-04-29
> 
> This would have worked particularly well if a JWKS was a JSON object with key-ids as the member names, instead of an array. That is presumably too late to fix. But defining the fragment format for application/jwk-set+json to be a kid value should be possible.
> 
> If you put multiple keys with the same key-id in a JWKS you are asking for trouble -- just call that a non-interoperable corner for people to avoid.
> 
> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email