[Openid-specs-ab] jku and x5u

Breno de Medeiros breno at google.com
Wed Apr 3 17:47:59 UTC 2013


Sorry, pressed 'send' too soon. Ignore the recommendation part for 'remove
the 'The protocol used to acquire ...' -- I realize now that it address
non-HTTP response mechanisms. The recommended text changes (in bold)
already reflect that understanding.


On Wed, Apr 3, 2013 at 10:47 AM, Breno de Medeiros <breno at google.com> wrote:

> Today the language is:
>
> "The jku (JWK Set URL) header parameter is a URI [RFC3986] that refers to
> a resource for a set of JSON-encoded public keys, one of which corresponds
> to the key used to digitally sign the JWS. The keys MUST be encoded as a
> JSON Web Key Set (JWK Set) [JWK]. The protocol used to acquire the resource
> MUST provide integrity protection; an HTTP GET request to retrieve the
> certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server
> MUST be validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of
> this header parameter is OPTIONAL."
>
> I recommend removing the "The protocol used to acquire the resource MUST
> provide integrity protection;" since it's redundant w/ " an HTTP GET
> request to retrieve the certificate MUST use TLS" and doesn't address the
> threat of binding it.
>
> "The jku (JWK Set URL) header parameter is a URI [RFC3986] that refers to
> a resource for a set of JSON-encoded public keys, one of which corresponds
> to the key used to digitally sign the JWS. The keys MUST be encoded as a
> JSON Web Key Set (JWK Set) [JWK]. The protocol used to acquire the resource
> MUST provide integrity protection* and source authenticity*; an HTTP GET
> request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the
> identity of the server MUST be validated, as per Section 3.1 of HTTP Over
> TLS [RFC2818].* In addition, the client MUST validate that the Issuer of
> the JWT (indicated by the 'iss' in the JWS envelope) is also the Issuer of
> the retrieved JWK Set. The mechanism for performing this validation is
> specified by application, but a compliant library MUST support at least the
> following: [Well-Known Location Method, PKI method], described below. *Use
> of this header parameter is OPTIONAL."
>
>
> On Wed, Apr 3, 2013 at 10:32 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:
>
>> 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
>>
>
>
>
> --
> --Breno
>



-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130403/8b80ec71/attachment-0001.html>


More information about the Openid-specs-ab mailing list