Return-Path: 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 7BD17120804 for ; Fri, 31 Jan 2020 06:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ve7jtb-com.20150623.gappssmtp.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 5EplQFxUhmuV for ; Fri, 31 Jan 2020 06:39:50 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 98BF81201C6 for ; Fri, 31 Jan 2020 06:39:50 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id g195so6669778qke.13 for ; Fri, 31 Jan 2020 06:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=SkygXKwWCVaFG7iEQtI04gx2ROTdb+WduEzYvuJLBNA=; b=toIiGWHL8lUjPQ1z8KWEc9+Y0DRvPcbd+4oqDT18FrIaz1c/MKdAwgKA+3wnM3Stb0 ApXDewqzO/nNdcu55oS0EE8E0l3Zq5xiQRwm6AXcqx8LZP3Tg81lMn9Q+9QQyuEEzOgb u5E8zcCxGZ3ld6t4XMWacUZJkpuVLh3boDiV3X2sjrZBzEg/maRe81t8Q6SnsUeOt7E1 ajHXcQDDyl7qbPTzP6l00OunvpKjsARMDSTMKfcpznGvQeBK37nQVINXtk0pnKgKkNqR VkMQasfsPHcUaTgtTmGthH7SSBgvPtZzB7VnXKoYUjuzyU793pVpA18zN+Lc9INHDJNR MqHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=SkygXKwWCVaFG7iEQtI04gx2ROTdb+WduEzYvuJLBNA=; b=l1QC8lRa0UdSqN3GI9gVTItXwi4ts1A9QK4KLCo6+xwZcWWeJ21NBbT06uEoS1WoXK 8vuFFhw9vTtUfTThjBweBcJCqMBP1d+x61Up7ECTzT/Ry/py67DzVPJoPBgA6p7tj589 KDrvPJQPxIu59Ohp6HO84c/ysb6uhU4ngPWuQvVtahmT9HFwMGImeK2ikEzHWtkp3M4G xfL09XTcpwAX7Y0J3z19wjYMLy9YUpS5/BjnRHtI5fSpEJC1NRjPwvnny9VNVn5GmBPF b4uh+4GHZYbKEuJhmoAD/zEUtkww4nL2WtgSk//VN0WnSukKjVlaYmAQsgwUS+QGfVg4 Jaww== X-Gm-Message-State: APjAAAUAMvKCs+yJIskQRULsvceG3wzCtrP9Lpi5Wyd6ZCHcWxS7tQYG Zs6udScCmx4NcsG00TqGHicmyZTl6ZbFvg== X-Google-Smtp-Source: APXvYqybbC8alSxVhZB0LFDWUUonTktDiVfVbVdfSfKhgjPBrnhGb/K9M9rGUM4J5yY2Q7uNmChYKA== X-Received: by 2002:a05:620a:9c7:: with SMTP id y7mr10822565qky.393.1580481588814; Fri, 31 Jan 2020 06:39:48 -0800 (PST) Received: from [192.168.8.103] ([190.107.226.39]) by smtp.gmail.com with ESMTPSA id t38sm5233378qta.78.2020.01.31.06.39.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:39:37 -0800 (PST) To: oauth@ietf.org References: <5F7A3816-AC9B-4BA2-9D91-CF89109B6788@forgerock.com> <79DF80DA-6682-4F25-A02A-B4137053FD8A@mit.edu> <6fab97c9-e9bb-58f8-ba14-22307e35bfcf@connect2id.com> <7AAAB265-6D3C-4FA6-81DD-E809AA49F8E3@mit.edu> From: John Bradley Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE= Message-ID: Date: Fri, 31 Jan 2020 11:39:36 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B0EA313B44139C1AFF46A01F" Content-Language: en-GB Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 14:39:53 -0000 This is a multi-part message in MIME format. --------------B0EA313B44139C1AFF46A01F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I remember the fight to have diffrent keys defined for signing and encryption. I am glad times have changed.=C2=A0=C2=A0 You can use difffent keys now with a JWKS URI that allows you to separate the private keys. The question is if you want the verifier to be able to differentiate the purpose. One way might be to encode some context into the keyID, but it is probably better to have separate JWKS URI. John B. On 1/30/2020 4:27 PM, Dick Hardt wrote: > Rephrasing Annabelle's description to highlight the issue: > > The AS says "here are the keys to use to verify all of the tokens that > *we* have signed" > > Separating duties in a large system is good cryptographic hygiene, IE, > one component signs ID Tokens, another signs access tokens. > > > On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle > > wrote: > > This could be nice, but it=E2=80=99s solving a different problem. T= he > issue I=E2=80=99m drawing attention to is about how an AS indicates= that a > given key is valid. That=E2=80=99s what the jwks_uri AS metadata pr= operty > 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 =E2=80=9C= here > are the keys to use to verify stuff I signed.=E2=80=9D It can=E2=80= =99t say =E2=80=9Chere > are the keys to use to verify ID Tokens, and here is a different > set of keys to use to verify access tokens.=E2=80=9D > > =E2=80=94 > Annabelle Backman > AWS Identity > > > On Jan 28, 2020, at 10:51 PM, Manger, James > > wrote: > > > > =EF=BB=BF > >> > >>> It would=E2=80=99ve been nice if JWK could=E2=80=99ve agreed on= a URL-based > >>> addressing format for individual keys within the set, but that > ship=E2=80=99s 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------B0EA313B44139C1AFF46A01F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I remember the fight to have diffrent keys defined for signing and encryption.

I am glad times have changed.  

You can use difffent keys now with a JWKS URI that allows you to separate the private keys.

The question is if you want the verifier to be able to differentiate the purpose.

One way might be to encode some context into the keyID, but it is probably better to have separate JWKS URI.

John B.



On 1/30/2020 4:27 PM, Dick Hardt wrote:
Rephrasing Annabelle's description to highlight the issue:

The AS says "here are the keys to use to verify all of the tokens that we have signed"

Separating duties in a large system is good cryptographic hygiene, IE, one component signs ID Tokens, another signs access tokens.


On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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