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

[John Bradley]

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
>  > 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
>  > 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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’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.man...@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

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

[Richard Backman, Annabelle]

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  
> 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

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

[Manger, James]

>> 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

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

[Justin Richer]

Well that’s what I’m saying — we could have had restrictions within JWK (and 
maybe even a different syntax) that would guarantee a unique key ID, as well as 
ways to talk about it from the outside. 

 — Justin

> On Jan 15, 2020, at 3:53 PM, Vladimir Dzhuvinov  
> wrote:
> 
> On 14/01/2020 04:25, Justin Richer 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.
> 
> For querying / selecting JWKs from a set this would have been a useful
> addition to the spec.
> 
> But I don't see how such an URL can help us to identify a single JWK in
> a set, given the possibility to have multiple JWKs with the same "kid".
> 
> I.e. if we do "https://example.com/jwks.json?kid=xyz;, there is no
> guarantee for a single key. Even if we add additional query params, like
> use, alg, etc, none of them guarantees a unique JWK identification.
> 
> I like the utility of that though.
> 
> Vladimir
> 
> 
> ___
> 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

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

[Aaron Parecki]

Right now, Okta publishes two keys at the jwks_uri in order to be able to
rotate keys periodically. During the token lifetime window during key
rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be
fine to include additional keys that are used for something other than
access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a
decent extension mechanism.



On Mon, Jan 13, 2020 at 6:26 PM Justin Richer  wrote:

> I would rather see extensions define a key ID than a new key set URI.
> Otherwise what’s the point of having more than one key in the set, with
> unique identifiers?
>
> 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..
>
>
>  — Justin
>
> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
>
> I was not saying that there was anything special about keys, nor that we
> needed to change OAuth.
>
> While using one key and controlling where it us used via access control
> works, it is not ideal.
>
> OAuth could have had just one endpoint, and done access control for
> different roles -- but it did not. We enabled flexibility by separating the
> authorization endpoint and the token endpoint. The dynamic client
> registration extension defined a new endpoint, the registration endpoint.
>
> I don't think we can change what has been deployed today -- but NEW
> extensions that use keys for new purposes SHOULD define their own URI.
> ᐧ
>
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden 
> wrote:
>
>> Sure, but we know how to run resilient services. My point is that there’s
>> nothing particularly special about cryptographic keys: if you want to
>> control how they are used there is a whole range of normal access control
>> methods you can apply to them without needing to change anything in OAuth.
>>
>> Neil
>>
>> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
>>
>> 
>> There are many other factors to resiliency than multiple instances.
>>
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
>> wrote:
>>
>>>
>>>
>>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>>> [...]
>>> >
>>> > As to the suggestion of using a JWT-decryption-microservice, another
>>> goal would be increased resiliency of the components. If the
>>> JWT-decryption-microservice is unavailable, the whole system is
>>> unavailable. If there are separate keys, then a failure in one component
>>> does not fail the entire system.
>>>
>>> Well you can run more than one instance - it’s a completely stateless
>>> service. You can also run a separate instance (or set of instances) per key
>>> if you like.
>>>
>>> Neil
>>
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

I would rather see extensions define a key ID than a new key set URI. Otherwise 
what’s the point of having more than one key in the set, with unique 
identifiers?

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.

 — Justin

> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
> 
> I was not saying that there was anything special about keys, nor that we 
> needed to change OAuth.
> 
> While using one key and controlling where it us used via access control 
> works, it is not ideal.
> 
> OAuth could have had just one endpoint, and done access control for different 
> roles -- but it did not. We enabled flexibility by separating the 
> authorization endpoint and the token endpoint. The dynamic client 
> registration extension defined a new endpoint, the registration endpoint.
> 
> I don't think we can change what has been deployed today -- but NEW 
> extensions that use keys for new purposes SHOULD define their own URI.
> ᐧ
> 
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden  > wrote:
> Sure, but we know how to run resilient services. My point is that there’s 
> nothing particularly special about cryptographic keys: if you want to control 
> how they are used there is a whole range of normal access control methods you 
> can apply to them without needing to change anything in OAuth. 
> 
> Neil
> 
>> On 10 Jan 2020, at 18:50, Dick Hardt > > wrote:
>> 
>> 
>> There are many other factors to resiliency than multiple instances. 
>> 
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden > > wrote:
>> 
>> 
>> > On 10 Jan 2020, at 17:22, Dick Hardt > > > wrote:
>> [...]
>> > 
>> > As to the suggestion of using a JWT-decryption-microservice, another goal 
>> > would be increased resiliency of the components. If the 
>> > JWT-decryption-microservice is unavailable, the whole system is 
>> > unavailable. If there are separate keys, then a failure in one component 
>> > does not fail the entire system. 
>> 
>> Well you can run more than one instance - it’s a completely stateless 
>> service. You can also run a separate instance (or set of instances) per key 
>> if you like. 
>> 
>> Neil

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

I was not saying that there was anything special about keys, nor that we
needed to change OAuth.

While using one key and controlling where it us used via access control
works, it is not ideal.

OAuth could have had just one endpoint, and done access control for
different roles -- but it did not. We enabled flexibility by separating the
authorization endpoint and the token endpoint. The dynamic client
registration extension defined a new endpoint, the registration endpoint.

I don't think we can change what has been deployed today -- but NEW
extensions that use keys for new purposes SHOULD define their own URI.
ᐧ

On Fri, Jan 10, 2020 at 11:31 AM Neil Madden 
wrote:

> Sure, but we know how to run resilient services. My point is that there’s
> nothing particularly special about cryptographic keys: if you want to
> control how they are used there is a whole range of normal access control
> methods you can apply to them without needing to change anything in OAuth..
>
> Neil
>
> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
>
> 
> There are many other factors to resiliency than multiple instances.
>
> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
> wrote:
>
>>
>>
>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>> [...]
>> >
>> > As to the suggestion of using a JWT-decryption-microservice, another
>> goal would be increased resiliency of the components. If the
>> JWT-decryption-microservice is unavailable, the whole system is
>> unavailable. If there are separate keys, then a failure in one component
>> does not fail the entire system.
>>
>> Well you can run more than one instance - it’s a completely stateless
>> service. You can also run a separate instance (or set of instances) per key
>> if you like.
>>
>> Neil
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

Sure, but we know how to run resilient services. My point is that there’s 
nothing particularly special about cryptographic keys: if you want to control 
how they are used there is a whole range of normal access control methods you 
can apply to them without needing to change anything in OAuth. 

Neil

> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
> 
> 
> There are many other factors to resiliency than multiple instances. 
> 
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden  
>> wrote:
>> 
>> 
>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>> [...]
>> > 
>> > As to the suggestion of using a JWT-decryption-microservice, another goal 
>> > would be increased resiliency of the components. If the 
>> > JWT-decryption-microservice is unavailable, the whole system is 
>> > unavailable. If there are separate keys, then a failure in one component 
>> > does not fail the entire system. 
>> 
>> Well you can run more than one instance - it’s a completely stateless 
>> service. You can also run a separate instance (or set of instances) per key 
>> if you like. 
>> 
>> Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

To restate my previous point, we may not be able to change what is
currently specified and deployed, but we can for future extensions such as
RAR and PAR.

To paraphrase Annabelle, this ship may have already sailed.

On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt  wrote:

> The metadata document is declarative, and can easily be yet another
> separate role in the AS.
>
> In large organizations, different people are empowered different roles, so
> the team owning the metadata document could be different from the team
> generating ID tokens, and different from the team generating JWTs.
>
>
> On Fri, Jan 10, 2020 at 10:27 AM Neil Madden 
> wrote:
>
>> The problem with specifying a property on the key itself is that a
>> microservice might lie about what it’s keys are for. I think you either
>> need separate documents or some separate metadata mapping uses to key ids.
>>
>> — Neil
>>
>> On 10 Jan 2020, at 18:19, Aaron Parecki  wrote:
>>
>> !
>> Can the keys in the document at the jwks_uri indicate what they are for?
>> Either by adding other top-level properties next to "keys" or by specifying
>> a property on a key itself? At least that way implementations that expect
>> just one value of jwks_uri wouldn't have to change.
>>
>> Aaron
>>
>>
>>
>> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:
>>
>>> Yes. Thanks for clarifying.
>>> ᐧ
>>>
>>> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
>>> tors...@lodderstedt.net> wrote:
>>>
 You mean additional JWKS URIs, for example?

 Am 10.01.2020 um 19:09 schrieb Dick Hardt >>> >:

 
 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 <
 tors...@lodderstedt.net> wrote:

>
>
> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
> >
> > 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.

 ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> 
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk 
>>
>> ___
>> 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

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

[Dick Hardt]

The metadata document is declarative, and can easily be yet another
separate role in the AS.

In large organizations, different people are empowered different roles, so
the team owning the metadata document could be different from the team
generating ID tokens, and different from the team generating JWTs.


On Fri, Jan 10, 2020 at 10:27 AM Neil Madden 
wrote:

> The problem with specifying a property on the key itself is that a
> microservice might lie about what it’s keys are for. I think you either
> need separate documents or some separate metadata mapping uses to key ids..
>
> — Neil
>
> On 10 Jan 2020, at 18:19, Aaron Parecki  wrote:
>
> !
> Can the keys in the document at the jwks_uri indicate what they are for?
> Either by adding other top-level properties next to "keys" or by specifying
> a property on a key itself? At least that way implementations that expect
> just one value of jwks_uri wouldn't have to change.
>
> Aaron
>
>
>
> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:
>
>> Yes. Thanks for clarifying.
>> ᐧ
>>
>> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>>> You mean additional JWKS URIs, for example?
>>>
>>> Am 10.01.2020 um 19:09 schrieb Dick Hardt >> >:
>>>
>>> 
>>> 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 <
>>> tors...@lodderstedt.net> wrote:
>>>


 > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
 >
 > 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.
>>>
>>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
> ___
> 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

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

[Dick Hardt]

There are many other factors to resiliency than multiple instances.

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
wrote:

>
>
> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
> [...]
> >
> > As to the suggestion of using a JWT-decryption-microservice, another
> goal would be increased resiliency of the components. If the
> JWT-decryption-microservice is unavailable, the whole system is
> unavailable. If there are separate keys, then a failure in one component
> does not fail the entire system.
>
> Well you can run more than one instance - it’s a completely stateless
> service. You can also run a separate instance (or set of instances) per key
> if you like.
>
> Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

> On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
[...]
> 
> As to the suggestion of using a JWT-decryption-microservice, another goal 
> would be increased resiliency of the components. If the 
> JWT-decryption-microservice is unavailable, the whole system is unavailable. 
> If there are separate keys, then a failure in one component does not fail the 
> entire system. 

Well you can run more than one instance - it’s a completely stateless service. 
You can also run a separate instance (or set of instances) per key if you like. 

Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

Can the keys in the document at the jwks_uri indicate what they are for?
Either by adding other top-level properties next to "keys" or by specifying
a property on a key itself? At least that way implementations that expect
just one value of jwks_uri wouldn't have to change.

Aaron



On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt  wrote:

> Yes. Thanks for clarifying.
> ᐧ
>
> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> You mean additional JWKS URIs, for example?
>>
>> Am 10.01.2020 um 19:09 schrieb Dick Hardt > >:
>>
>> 
>> 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 <
>> tors...@lodderstedt.net> wrote:
>>
>>>
>>>
>>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>>> >
>>> > 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.
>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

Yes. Thanks for clarifying.
ᐧ

On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> You mean additional JWKS URIs, for example?
>
> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
>
> 
> 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 <
> tors...@lodderstedt.net> wrote:
>
>>
>>
>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>> >
>> > 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.
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

You mean additional JWKS URIs, for example?

> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
> 
> 
> 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 
>>  wrote:
>> 
>> 
>> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>> > 
>> > 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.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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 
wrote:

>
>
> > Am 10.01.2020 um 18:23 schrieb Dick Hardt :
> >
> > 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.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

> Am 10.01.2020 um 18:23 schrieb Dick Hardt :
> 
> 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.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

OAuth 1.0 assumed the RS and AS were a monolith.

OAuth 2.0 separated the RS and the AS. It put them in separate boxes. It
also did not define the access token, allowing an implementation to keep
them as a monolith, or allow separation of duties. There was no impact on
the client, but it was a more agile specification for implementation.

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.

As to the suggestion of using a JWT-decryption-microservice, another goal
would be increased resiliency of the components. If the
JWT-decryption-microservice is unavailable, the whole system is
unavailable. If there are separate keys, then a failure in one component
does not fail the entire system.

/Dick




ᐧ

On Fri, Jan 10, 2020 at 9:01 AM Justin Richer  wrote:

> I would argue that the AS being monolithic, as seen by outside parties, is
> a core assumption in OAuth 2. While there are deployments that, for
> example, split the authorization and token endpoints into different domains
> and servers, the client still sees them as a single entity.
>
> I think it’s fair for any extension to OAuth 2 to rest on that assumption.
> Any effort to split the endpoints into parts should be seen as a deployment
> detail requiring some extra work on the deployer’s side. For example, take
> PKCE: you need to communicate the client’s challenge at the authorization
> endpoint back to the token endpoint in order to verify the verifier. Or
> even just the authorization code itself. OAuth doesn’t tell you how to do
> that at all because it assumes that’s your problem to solve and it’s
> internal to the box drawn by the protocol.
>
> We do have a chance with the next generation work that we’re trying to
> start over in TxAuth to change these assumptions, but I think it’s too late
> to impose that requirement on OAuth 2.
>
>  — Justin
>
> On Jan 10, 2020, at 10:50 AM, Neil Madden 
> wrote:
>
> This is an interesting point.
>
> I think OAuth has historically assumed that the AS is a monolithic system,
> or at least can be treated like one by clients. I think we might have to
> revisit quite a lot if we drop this assumption and adopt a threat model in
> which the AS is itself composed of a collection of mutually distrusting
> entities. Especially as different ASes might decide to divide up the trust
> boundaries in different ways.
>
> At least partially this feels like an internal implementation detail of
> the AS that can also be solved internally to that AS. For example, rather
> than providing microservices direct access to private keys you could
> implement a JWT-decryption-microservice that other microservices call. It
> can then check if the calling microservice is allowed to decrypt that type
> of JWT before returning the response (e.g., by checking the "typ" header)..
> The same can be done for signing JWTs. Of course, that's not a perfect
> solution, but it illustrates that we don't necessarily need to solve these
> problems in the WG.
>
> If we go down the path of separate keys, then it might be simpler to
> introduce new metadata elements to list the kids of valid key ids for a
> given purpose rather than having multiple JWK Set endpoints. e.g.
> "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids the
> client having to fetch multiple sets of keys.
>
> -- Neil
>
> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle <
> richanna=40amazon@dmarc.ietf.org> wrote:
>
> The “typ” field helps prevent misrepresentation of a legitimately issued
> JWT, but it doesn’t address the issue I am trying to draw attention to,
> which is that the current model forces broader distribution and reuse of
> keys than is necessary, resulting in a greater blast radius for compromised
> keys or systems.
>
> For many cases, this is not a significant concern, as the AS is a
> monolithic system with no internal trust boundaries. However, in cases
> where the AS is composed of multiple microservices performing different
> tasks, the need to share keys between different microservices undermines
> efforts to create trust boundaries between them. I gave one example of this
> in my original email, where ID Token generation and access token generation
> are relegated to independent systems, each with separate private keys for
> signing tokens. Suppose a malicious party compromised the ID Token
> generator, or gained access to its private key, and issued fraudulent
> access tokens signed using that key. Since verifiers of both token types
> will look to the same metadata file and thus the same JWK set, they have no
> way to recognize that these access tokens are fraudulent.
>
> Note that while “typ” would help a verifier distinguish between an ID
> 

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

[Justin Richer]

I would argue that the AS being monolithic, as seen by outside parties, is a 
core assumption in OAuth 2. While there are deployments that, for example, 
split the authorization and token endpoints into different domains and servers, 
the client still sees them as a single entity. 

I think it’s fair for any extension to OAuth 2 to rest on that assumption. Any 
effort to split the endpoints into parts should be seen as a deployment detail 
requiring some extra work on the deployer’s side. For example, take PKCE: you 
need to communicate the client’s challenge at the authorization endpoint back 
to the token endpoint in order to verify the verifier. Or even just the 
authorization code itself. OAuth doesn’t tell you how to do that at all because 
it assumes that’s your problem to solve and it’s internal to the box drawn by 
the protocol.

We do have a chance with the next generation work that we’re trying to start 
over in TxAuth to change these assumptions, but I think it’s too late to impose 
that requirement on OAuth 2.

 — Justin

> On Jan 10, 2020, at 10:50 AM, Neil Madden  wrote:
> 
> This is an interesting point.
> 
> I think OAuth has historically assumed that the AS is a monolithic system, or 
> at least can be treated like one by clients. I think we might have to revisit 
> quite a lot if we drop this assumption and adopt a threat model in which the 
> AS is itself composed of a collection of mutually distrusting entities. 
> Especially as different ASes might decide to divide up the trust boundaries 
> in different ways.
> 
> At least partially this feels like an internal implementation detail of the 
> AS that can also be solved internally to that AS. For example, rather than 
> providing microservices direct access to private keys you could implement a 
> JWT-decryption-microservice that other microservices call. It can then check 
> if the calling microservice is allowed to decrypt that type of JWT before 
> returning the response (e.g., by checking the "typ" header). The same can be 
> done for signing JWTs. Of course, that's not a perfect solution, but it 
> illustrates that we don't necessarily need to solve these problems in the WG.
> 
> If we go down the path of separate keys, then it might be simpler to 
> introduce new metadata elements to list the kids of valid key ids for a given 
> purpose rather than having multiple JWK Set endpoints. e.g. 
> "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids the 
> client having to fetch multiple sets of keys.
> 
> -- Neil
> 
>> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle 
>> > > wrote:
>> 
>> The “typ” field helps prevent misrepresentation of a legitimately issued 
>> JWT, but it doesn’t address the issue I am trying to draw attention to, 
>> which is that the current model forces broader distribution and reuse of 
>> keys than is necessary, resulting in a greater blast radius for compromised 
>> keys or systems.
>>  
>> For many cases, this is not a significant concern, as the AS is a monolithic 
>> system with no internal trust boundaries. However, in cases where the AS is 
>> composed of multiple microservices performing different tasks, the need to 
>> share keys between different microservices undermines efforts to create 
>> trust boundaries between them. I gave one example of this in my original 
>> email, where ID Token generation and access token generation are relegated 
>> to independent systems, each with separate private keys for signing tokens. 
>> Suppose a malicious party compromised the ID Token generator, or gained 
>> access to its private key, and issued fraudulent access tokens signed using 
>> that key. Since verifiers of both token types will look to the same metadata 
>> file and thus the same JWK set, they have no way to recognize that these 
>> access tokens are fraudulent.
>>  
>> Note that while “typ” would help a verifier distinguish between an ID Token 
>> and an access token, it does not help in this case because the malicious 
>> party is generating well-formed access token JWTs, signed with a key that is 
>> legitimate for the AS but not for this purpose.
>>  
>> The case for this being a concern on the encryption side is fuzzier, 
>> primarily because we simply don’t have many use cases where different kinds 
>> of content gets encrypted and sent to the AS in different contexts. However, 
>> I gave one example on the PAR thread 
>> , 
>> where a PAR endpoint that decrypts request object JWTs will also be able to 
>> decrypt id_token_hint JWTs.
>>  
>> – 
>> Annabelle Richard Backman
>> AWS Identity
>>  
>>  
>> From: Mike Jones > >
>> Date: Thursday, January 9, 2020 at 11:34 AM
>> To: "Richard Backman, Annabelle" > >, oauth mailto:oauth@ietf.org>>
>> Subject: [UNVERIFIED SENDER] RE: 

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

[Neil Madden]

This is an interesting point.

I think OAuth has historically assumed that the AS is a monolithic system, or 
at least can be treated like one by clients. I think we might have to revisit 
quite a lot if we drop this assumption and adopt a threat model in which the AS 
is itself composed of a collection of mutually distrusting entities. Especially 
as different ASes might decide to divide up the trust boundaries in different 
ways.

At least partially this feels like an internal implementation detail of the AS 
that can also be solved internally to that AS. For example, rather than 
providing microservices direct access to private keys you could implement a 
JWT-decryption-microservice that other microservices call. It can then check if 
the calling microservice is allowed to decrypt that type of JWT before 
returning the response (e.g., by checking the "typ" header). The same can be 
done for signing JWTs. Of course, that's not a perfect solution, but it 
illustrates that we don't necessarily need to solve these problems in the WG.

If we go down the path of separate keys, then it might be simpler to introduce 
new metadata elements to list the kids of valid key ids for a given purpose 
rather than having multiple JWK Set endpoints. e.g. 
"id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids the 
client having to fetch multiple sets of keys.

-- Neil

> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle 
>  wrote:
> 
> The “typ” field helps prevent misrepresentation of a legitimately issued JWT, 
> but it doesn’t address the issue I am trying to draw attention to, which is 
> that the current model forces broader distribution and reuse of keys than is 
> necessary, resulting in a greater blast radius for compromised keys or 
> systems.
>  
> For many cases, this is not a significant concern, as the AS is a monolithic 
> system with no internal trust boundaries. However, in cases where the AS is 
> composed of multiple microservices performing different tasks, the need to 
> share keys between different microservices undermines efforts to create trust 
> boundaries between them. I gave one example of this in my original email, 
> where ID Token generation and access token generation are relegated to 
> independent systems, each with separate private keys for signing tokens. 
> Suppose a malicious party compromised the ID Token generator, or gained 
> access to its private key, and issued fraudulent access tokens signed using 
> that key. Since verifiers of both token types will look to the same metadata 
> file and thus the same JWK set, they have no way to recognize that these 
> access tokens are fraudulent.
>  
> Note that while “typ” would help a verifier distinguish between an ID Token 
> and an access token, it does not help in this case because the malicious 
> party is generating well-formed access token JWTs, signed with a key that is 
> legitimate for the AS but not for this purpose.
>  
> The case for this being a concern on the encryption side is fuzzier, 
> primarily because we simply don’t have many use cases where different kinds 
> of content gets encrypted and sent to the AS in different contexts. However, 
> I gave one example on the PAR thread 
> , 
> where a PAR endpoint that decrypts request object JWTs will also be able to 
> decrypt id_token_hint JWTs.
>  
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: Mike Jones  >
> Date: Thursday, January 9, 2020 at 11:34 AM
> To: "Richard Backman, Annabelle"  >, oauth mailto:oauth@ietf.org>>
> Subject: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of 
> jwks_uri
>  
> This a good thing to think about.  Thanks for bringing this up, Annabelle.
>  
> One thing that partially mitigates this is that the “use” and/or “key_ops” 
> attributes can be provided.  This can allow signing keys to be differentiated 
> from encryption keys, for instance.
>  
> I’m not as worried about encryption keys as signing keys.  If multiple kinds 
> of applications encrypt content to a party using the same public per-party 
> key, and the encryption is being used only to ensure confidentiality of the 
> messages, the confidentiality is still achieved.
>  
> One mitigation for signing keys is use of the “typ” field, as described in 
> the JWT BCP.  Even if the same key was used and you receive an unexpected JWT 
> type, you will still reject it.
>  
> I believe there’s also cases where it’s fine to use the same signing key for 
> related operations.  For instance, signing a Pushed Authorization Request and 
> a Request Object with the same key seems both logical and safe to me.  (If 
> others can think of an attack that this enables, however, please do point it 
> out.)
>  
> Which I believe leaves us with this case to worry about – shared signing keys 
> by unrelated 

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

[Dick Hardt]

+1 to Annabelle's point

Different crypto operations should be able to use separate key pairs to
allow a separation of duties.
ᐧ

On Thu, Jan 9, 2020 at 4:25 PM Richard Backman, Annabelle  wrote:

> The “typ” field helps prevent misrepresentation of a legitimately issued
> JWT, but it doesn’t address the issue I am trying to draw attention to,
> which is that the current model forces broader distribution and reuse of
> keys than is necessary, resulting in a greater blast radius for compromised
> keys or systems.
>
>
>
> For many cases, this is not a significant concern, as the AS is a
> monolithic system with no internal trust boundaries. However, in cases
> where the AS is composed of multiple microservices performing different
> tasks, the need to share keys between different microservices undermines
> efforts to create trust boundaries between them. I gave one example of this
> in my original email, where ID Token generation and access token generation
> are relegated to independent systems, each with separate private keys for
> signing tokens. Suppose a malicious party compromised the ID Token
> generator, or gained access to its private key, and issued fraudulent
> access tokens signed using that key. Since verifiers of both token types
> will look to the same metadata file and thus the same JWK set, they have no
> way to recognize that these access tokens are fraudulent.
>
>
>
> Note that while “typ” would help a verifier distinguish between an ID
> Token and an access token, it does not help in this case because the
> malicious party is generating well-formed access token JWTs, signed with a
> key that is legitimate for the AS but not for this purpose.
>
>
>
> The case for this being a concern on the encryption side is fuzzier,
> primarily because we simply don’t have many use cases where different kinds
> of content gets encrypted and sent to the AS in different contexts.
> However, I gave one example on the PAR thread
> ,
> where a PAR endpoint that decrypts request object JWTs will also be able to
> decrypt id_token_hint JWTs.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Mike Jones 
> *Date: *Thursday, January 9, 2020 at 11:34 AM
> *To: *"Richard Backman, Annabelle" , oauth <
> oauth@ietf.org>
> *Subject: *[UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits
> of jwks_uri
>
>
>
> This a good thing to think about.  Thanks for bringing this up, Annabelle..
>
>
>
> One thing that partially mitigates this is that the “use” and/or “key_ops”
> attributes can be provided.  This can allow signing keys to be
> differentiated from encryption keys, for instance.
>
>
>
> I’m not as worried about encryption keys as signing keys.  If multiple
> kinds of applications encrypt content to a party using the same public
> per-party key, and the encryption is being used only to ensure
> confidentiality of the messages, the confidentiality is still achieved.
>
>
>
> One mitigation for signing keys is use of the “typ” field, as described in
> the JWT BCP.  Even if the same key was used and you receive an unexpected
> JWT type, you will still reject it.
>
>
>
> I believe there’s also cases where it’s fine to use the same signing key
> for related operations.  For instance, signing a Pushed Authorization
> Request and a Request Object with the same key seems both logical and safe
> to me.  (If others can think of an attack that this enables, however,
> please do point it out.)
>
>
>
> Which I believe leaves us with this case to worry about – shared signing
> keys by unrelated applications when “typ” is not used.  One way to mitigate
> this would be to use per-application key sets.  For instance, using values
> other than “jwks_uri” to reference key sets for particular applications.
>
>
>
> Anyway, for PAR, I believe that it’s fine to use the same keys as used for
> Request Objects, so no new fields are needed for it.
>
>
>
> I look forward to further discussion on the topic.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Richard Backman,
> Annabelle
> *Sent:* Wednesday, January 8, 2020 3:47 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
>
>
>
> I originally brought up this issue in the context of the PAR draft, but
> since it broadly applies to the OAuth space I’m starting a new thread…
>
>
>
> Section 3.12 of the JWT BCP
> 
> says: “Use different keys for different kinds of JWTs.” Section 4 of the
> JWT Profile for OAuth 2.0 Access Tokens
>