[Openid-specs-ab] jku and x5u

Mike Jones Michael.Jones at microsoft.com
Wed Apr 3 17:32:42 UTC 2013


Is there specific language that you'd like to suggest be added to the JOSE specs in that regard?

				-- Mike

-----Original Message-----
From: Breno de Medeiros [mailto:breno at google.com] 
Sent: Wednesday, April 03, 2013 10:29 AM
To: Mike Jones
Cc: John Bradley; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] jku and x5u

On Wed, Apr 3, 2013 at 10:26 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> I think people have already agreed that, for Connect, we can say that 
> key locators aren't to be used in the tokens.  Is there an additional 
> change beyond that that you were advocating, Breno?

No. I am worried, however, that the JOSE specs introduce the field w/o clear prescriptions about when safe to process it. If someone layers an OpenIDConnect library on top of a JWT/JWS/... whatever substrate, will the caller have a simple way to _deterministically_ infer how the keys were bound to the issuer?

>
> -- Mike
>
> From: Breno de Medeiros
> Sent: Wednesday, April 3, 2013 10:23 AM
> To: John Bradley
> Cc: openid-specs-ab at lists.openid.net
>
> On Wed, Apr 3, 2013 at 10:17 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> I wasn't recommending changing the discovery mechanism.   We support out
>> of band configuration.   There are a number of ways to do that, including
>> typing it in.
>>
>> One possible way is to use some sort of meta data from a federation.  
>> That would require an extension document ad is out of scope.
>>
>> We decided not to support discovery for domains without web servers on the
>> top level.   I think Tim was the main proponent of dropping discovery
>> support for other issuers.
>>
>> For self issued there is no discovery the assertion is self contained.
>
> Right. The problem here is not OOB. This is always possible in a 
> federation. The problem is the prescription to parse jku in the 
> absence of PKI trust. That's a recipe for generalized insecurity.
>
>>
>> John B.
>> On 2013-04-03, at 2:06 PM, Breno de Medeiros <breno at google.com> wrote:
>>
>>> On Wed, Apr 3, 2013 at 10:03 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>> self issued is a special case where the public key is provided in 
>>>> the envelope directly and validated against the sig the sub is 
>>>> derived from the public key.
>>>>
>>>> I don't think that is a problem.
>>>>
>>>> For IdP that publish a discovery document that is authoritative 
>>>> that specifies the jku url not the JWT.
>>>>
>>>> For idp who can't publish a discovery document RP will need to 
>>>> manually configure out of band as they do now for facebook and 
>>>> others, or there needs to be a trusted source of meta-data for those small IdP.
>>>
>>> I disagree that the benefit of creating a complex and likely 
>>> security-challenged discovery mechanism is worth the cost.
>>>
>>>>
>>>> John
>>>>
>>>> On 2013-04-03, at 1:58 PM, Breno de Medeiros <breno at google.com> wrote:
>>>>
>>>>> On Wed, Apr 3, 2013 at 9:56 AM, Breno de Medeiros 
>>>>> <breno at google.com>
>>>>> wrote:
>>>>>> On Wed, Apr 3, 2013 at 1:54 AM,  <Axel.Nennker at telekom.de> wrote:
>>>>>>> Here are two use cases that would not work under the 
>>>>>>> "${issuer}/.well-known/openid-configuration" assumption.
>>>>>>>
>>>>>>> 1)      The issuer has no control over the top level domain's files
>>>>>>> e.g. you rented some hosting space at 
>>>>>>> https://geocities.yahoo.co.jp/KafkaTamura and this is the iss. 
>>>>>>> Kafka can not change the top level openid-configuration only
>>>>>>>
>>>>>>> https://geocities.yahoo.co.jp/KafkaTamura/.well-known/openid-con
>>>>>>> figuration
>>>>>>>
>>>>>>> 2)      A self-issued OP on a phone
>>>>>>> The issuer could dynamically register its keys or provide the 
>>>>>>> public key with the first token. The consumer would then ensure 
>>>>>>> that the key is the same in subsequent tokens.
>>>>>>
>>>>>> I am not interested in supporting either of these cases if it 
>>>>>> comes at the expense of generalized insecurity on the common 
>>>>>> case. If the spec wants to support these cases, it needs to be 
>>>>>> very careful on how to coach the language.
>>>>>
>>>>> And why can't _both_ of these cases be achieved though PKI-based means?
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of 
>>>>>>> Tim Bray
>>>>>>> Sent: Tuesday, April 02, 2013 11:55 PM
>>>>>>> To: Hannes Tschofenig
>>>>>>> Cc: <openid-specs-ab at lists.openid.net>
>>>>>>>
>>>>>>>
>>>>>>> Subject: Re: [Openid-specs-ab] jku and x5u
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From where I sit, the most obvious thing to do is look at the 
>>>>>>> issuer claim, resolve 
>>>>>>> ${issuer}/.well-known/openid-configuration, extract the jwk-url 
>>>>>>> claim, fetch the jwk, and validate using that.  For the kind of 
>>>>>>> consumer/internet stuff we do, wouldn't that nearly always be 
>>>>>>> the right choice?
>>>>>>>
>>>>>>> -T
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 2, 2013 at 11:48 AM, Hannes Tschofenig
>>>>>>> <hannes.tschofenig at gmx.net> wrote:
>>>>>>>
>>>>>>> Hi Tim,
>>>>>>>
>>>>>>> There are three ways to shuffle keys around:
>>>>>>>
>>>>>>> * per value: you include the key in the message
>>>>>>> * per reference: you include a pointer to the key (e.g., a URL)
>>>>>>> * out-of-band: here you just give the key a name without telling
>>>>>>> where to
>>>>>>> find it.
>>>>>>>
>>>>>>> Needless to say that you have to be careful with all three mechanisms
>>>>>>> when
>>>>>>> it comes to security.
>>>>>>>
>>>>>>> You are already thinking about a complete use case that goes beyond
>>>>>>> what
>>>>>>> these header parameters by itself are able to answer.
>>>>>>>
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 04/02/2013 09:35 PM, Tim Bray wrote:
>>>>>>>
>>>>>>> Sorry, I'm probably failing to understand because I'm a crypto moron,
>>>>>>> but if I want to use keys to validate a JWT allegedly from
>>>>>>> example.com
>>>>>>>
>>>>>>> <http://example.com>, I'm not going to believe anything in the JWT
>>>>>>> until
>>>>>>> I've checked using example.com <http://example.com>'s keys, so why
>>>>>>>
>>>>>>>
>>>>>>> should I believe the JWT's assertion about where to get the keys to
>>>>>>> validate it?  -T
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 2, 2013 at 11:27 AM, Mike Jones
>>>>>>> <Michael.Jones at microsoft.com
>>>>>>>
>>>>>>> <mailto:Michael.Jones at microsoft.com>> wrote:
>>>>>>>
>>>>>>>   Yes, that's exactly it.  If you already know where the keys are or
>>>>>>>   what they are (for instance, if you've established that information
>>>>>>>   at registration time), there's no need to use these parameters.
>>>>>>> But
>>>>>>>   for some use cases, this is valuable information that can be
>>>>>>>   dynamically provided.  (The Key ID ("kid") can also be dynamically
>>>>>>>
>>>>>>>   provided, if appropriate to the use case.)____
>>>>>>>
>>>>>>>   __ __
>>>>>>>
>>>>>>>                                                                    --
>>>>>>>   Mike____
>>>>>>>
>>>>>>>   __ __
>>>>>>>
>>>>>>>   *From:*openid-specs-ab-bounces at lists.openid.net
>>>>>>>   <mailto:openid-specs-ab-bounces at lists.openid.net>
>>>>>>>   [mailto:openid-specs-ab-bounces at lists.openid.net
>>>>>>>   <mailto:openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of
>>>>>>>   *Tim Bray
>>>>>>>   *Sent:* Tuesday, April 02, 2013 11:19 AM
>>>>>>>   *To:* <openid-specs-ab at lists.openid.net
>>>>>>>   <mailto:openid-specs-ab at lists.openid.net>>
>>>>>>>   *Subject:* [Openid-specs-ab] jku and x5u____
>>>>>>>
>>>>>>>   __ __
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   Almost certainly I'm just missing something obvious, but I'm having
>>>>>>>   trouble understanding why the jku and x5u header claims exist.  The
>>>>>>>   idea is I get a message and believe the message's assertion about
>>>>>>>
>>>>>>>   where I should go to get the cert to validate the message?  -T____
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --Breno
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --Breno
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>
>>>
>>>
>>> --
>>> --Breno
>>
>
>
>
> --
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



--
--Breno


More information about the Openid-specs-ab mailing list