[Openid-specs-ab] JWK clarification

Mike Jones Michael.Jones at microsoft.com
Sat Aug 25 00:08:32 UTC 2012


To your second point, they can be intermixed.  The keys can specify "use" attributes if desired to distinguish between them.  Use "use":"sig" for signing keys and "use":"enc" for encryption keys.

To your first point, the Key ID parameter can be used for selecting specific keys, if desired.  You're right though, that defining specific Key ID usage guidelines is beyond the scope of the present JOSE and OpenID Connect specifications.

                                                                -- Mike

P.S.  Sorry for the very delayed reply.  I just noticed that I hadn't gotten back to you on this.

From: Dingwell, Robert A. [mailto:bobd at mitre.org]
Sent: Wednesday, June 27, 2012 1:33 PM
To: Mike Jones; John Bradley
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] JWK clarification

Mike, I think we are talking about 2 different things.  I am referring to the the OpenID Connect Messages specification where in section 4.2 it outlines parameters for signing and encrypting key urls.

 John, I think it would be good to have a way to specify which key in a key set is the one that is the same as the X509 if that is also given. That can be even as simple as specifying a kid of 1 like you say. It may even be good to state that the headers for either singed  or encrypted content contain the key id that was used.   I think without further specifying the behavior that is expected out of the key url's and the JWS and JWE headers it makes implementation more difficult than it needs to be.

 Say I get a signed JWT and there isn't something in the header that lets me know what key was used to sign it, and the signer has multiple keys available via their signing key urls.  If I don't have a way to identify the key that was used I have to try them all to see if one of them works.  Now I know that the header is perfectly capable of containing that information but that doesn't mean that it will, it's optional in the JWS and JWE specs.

On another note if the jwk urls point to key sets are all of the keys in the key set pointed to by the jwk_url signing keys and all of the keys in the key set pointed to by the jwk_encryption_url encryption keys? Or are they intermixed?


Rob

From: Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
Date: Wednesday, June 27, 2012 3:50 PM
To: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>, Rob Dingwell <bobd at mitre.org<mailto:bobd at mitre.org>>
Cc: "openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: RE: [Openid-specs-ab] JWK clarification

Maybe you're looking at an old version of the spec, Robert?  I'm pretty sure that http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02#section-4.1.2 makes it clear that what's pointed to by the URL is a key set.  If you believe additional language is needed, please let me know what you think we should say.

                                                                Best wishes,
                                                                -- Mike

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Wednesday, June 27, 2012 12:38 PM
To: Dingwell, Robert A.
Cc: Mike Jones; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] JWK clarification

If you use a key with keyid of 1 you should make that key available in both formats.  Given that x.509 certificates don't have keyID you probably need to include both a thumbprint and  and a keyID if you are making keys available in both formats.

I could add the public key for a given ID/thumbprint combination should be identical in both formats.

I am also open to the argument that they don't need to be identical, as long as the receiver can process it.
The bottom line is that the receiver and sender need to publish keys that they can identify when they receive things signed or encrypted.

For JWK the kid is the obvious way to identify keys,  with x.509 that is less obvious.  Should we be more prescriptive and specify thumbprint or something else?

John B.

On 2012-06-27, at 2:42 PM, Dingwell, Robert A. wrote:



I get that from a JWK point of view, but what is suppose to live at the end of the jwk_url  and jwk_encryption_url parameters of an idP or a client as far as section 4.2 in the Messages spec goes?  It doesn't make a distinction as to if it expects those urls to point to keys or key sets.  At the end of section 4.2 is states that if keys are supplied in both X509 and JWK format then the keys must be identical.  They can't be identical if one is a set and the other is an X509 cert with just one key in it so it seems to implicitly state that the jwk_url and jwk_encruyption_url params point to single JWK's and not a Ket Set.


Rob


From: Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>
Date: Wednesday, June 27, 2012 1:56 PM
To: Rob Dingwell <bobd at mitre.org<mailto:bobd at mitre.org>>, "openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: RE: JWK clarification

The top-level format continues to be an array of keys.  Individual keys can also be used where appropriate.  In the following example, an array of keys is specified:

{"keys":
  [
    {"alg":"EC",
     "crv":"P-256",
     "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
     "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
     "use":"enc",
     "kid":"1"},

    {"alg":"RSA",
     "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "exp":"AQAB",
     "kid":"2011-04-29"}
  ]
}

In this example, a single key is specified:

    {"alg":"EC",
     "crv":"P-256",
     "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
     "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
     "use":"enc",
     "kid":"1"}

The array format is used in contexts such as the key values retrieved for the JWS and JWE "jku" parameter where multiple keys may be specified.  The single key format is used in contexts such as the JWE "epk" parameter, where only a single key value is called for.

If this isn't clear, feel free to ask a follow-up question.

                                                            Best wishes,
                                                            -- 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] On Behalf Of Dingwell, Robert A.
Sent: Wednesday, June 27, 2012 9:04 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] JWK clarification

If I remember correctly the initial version of the JWK format specified the format as being an array of keys but the latest version of the JWK spec appears to have broken that idea out to where there is the key format and set format.

As both the client and the server have the option of providing signing and encrypting keys in JWK format are the urls for those keys intended to be a single JWK or a JWK set? Seeing how the specifications states that if both X509 and JWK urls are provided they must be the same key makes me believe that the url would point to a single key.  If it is a set how would one determine which key to use in the set considering that the set could contain a number of keys that are marked as signing or encrypting keys?

Rob

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

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


More information about the Openid-specs-ab mailing list