[Openid-specs-ab] jku and x5u

[Breno de Medeiros]

On Tue, Apr 2, 2013 at 2:54 PM, Tim Bray <tbray at textuality.com> wrote:
> 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?

As long as the spec _very_ clearly explains that one should _not_
parse/retrieve the jku or x5u unless one knows how to configure
PKI-based trust. The current write-up of the spec doesn't call this
out.

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