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

[John Bradley <[e-mail]>]

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=[e-mail]
> <mailto:[e-mail]>> 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
>     <[e-mail]
>     <mailto:[e-mail]>> 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
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/oauth
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth