[Openid-specs-ab] jku and x5u

Breno de Medeiros breno at google.com
Wed Apr 3 20:01:36 UTC 2013


On Wed, Apr 3, 2013 at 12:30 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  The “issuer” language is overly specific for the JOSE specs because
> “issuer” is a JWT concept – not a JOSE one.  Do you want to suggest a
> generalization of the language for the JOSE specs that doesn’t assume that
> the signed/encrypted content is a JWT?
>

We will need to introduce the concept of signer/holder of keys there then.
I don't think JOSE should talk about keys w/o talking about how to
establish beliefs about who owns those keys.


> ****
>
> ** **
>
> Suggesting language for the JWT spec and/or Connect specs is also OK.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Breno de Medeiros [mailto:breno at google.com]
> *Sent:* Wednesday, April 03, 2013 10:48 AM
>
> *To:* Mike Jones
> *Cc:* John Bradley; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] jku and x5u****
>
> ** **
>
> 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****
>



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


More information about the Openid-specs-ab mailing list