[Openid-specs-ab] Proposal(s) on key publication and rotation

Brian Campbell bcampbell at pingidentity.com
Wed Feb 20 14:44:00 UTC 2013


Yeah, that's certainly an option for the caching side of it (as was pointed
out http://www.ietf.org/mail-archive/web/jose/current/msg01597.html in
response to my proposal of a JWK TTL/EXP). I was trying to avoid that but
my resolve on the issue is weakening. I'm starting to think using what HTTP
already gives us is better/easier anyway.

The questions I asked yesterday about managing the dependencies between
draft standards still stands though. I'd like to pursue and use the PKIX
kty in Connect but am uncertain about how to proceed with that.


On Tue, Feb 19, 2013 at 8:24 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Caching for the jku can be done by http headers but that is not ideal in
> some ways.
>
> John B.
> On 2013-02-19, at 9:30 PM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
> And I just floated the idea of a TTL parameter on JWK to the JOSE WG:
> http://www.ietf.org/mail-archive/web/jose/current/msg01588.html  (and as
> I write this Mike has already asked about the name
> http://www.ietf.org/mail-archive/web/jose/current/msg01589.html)
>
> A JWK TTL parameter and the PKIX key type [1] would provide the pieces
> needed to get to a single JWK endpoint in Connect that can support
> certificates and certificate chains as well as bare keys and can handle
> singing and encryption cases complete with a codified key roll over
> technique for both.
>
> But neither of those ideas are 'real' in JOSE and even if they become
> standardized, it's likely to take some time. So I'm looking for some
> thoughts/guidance from the OIDF folks and/or the Connect editors about how
> to proceed on this.  I still maintain that this functionality is extremely
> important to have in connect. I'm just not sure how best to proceed with
> all the dependencies between the various standards bodies.
>
>
> [1] http://tools.ietf.org/html/draft-miller-jose-pkix-key-00
>
>
>
>
> On Tue, Feb 12, 2013 at 12:34 PM, Brian Campbell <
> bcampbell at pingidentity.com> wrote:
>
>> With a (very) little help from me, Matt Miller has just submitted "JSON
>> Web Key (JWK) for PKIX Certificates" as an I-D at
>> http://tools.ietf.org/html/draft-miller-jose-pkix-key-00 to
>> explore/discuss/push the idea of an X509/PKIX key type for JWK.
>>
>> The approach is inline with, and starts to build the foundation for, the
>> consolidated x509/jwk and encryption/signature endpoints I discussed in the
>> original message in this thread. It is effectively option #1 from that
>> message.
>>
>> At this point I'm proposing that Connect go with that approach.
>>
>> I'd kindly ask that folks in this group take a moment to review the short
>> draft (references and examples are longer than the actual text) and provide
>> feedback or lend support to the idea, as appropriate.
>>
>> Assuming we can move forward with this approach, the question of key
>> cache indicators is the only remaining item needed in order to address the
>> various issues I had with key publication and rotation.  JWK level vs. HTTP
>> level?
>>
>>
>>
>>
>>
>> On Mon, Feb 11, 2013 at 12:22 PM, Brian Campbell <
>> bcampbell at pingidentity.com> wrote:
>>
>>> Just a quick FYI about this.
>>>
>>> Matt and I (well, mostly Matt so far) have started working on a I-D to
>>> define PKIX key type for JWK and no one has raised any real objections so
>>> far. http://www.ietf.org/mail-archive/web/jose/current/msg01502.htmland follow ups
>>>
>>>
>>> On Mon, Feb 11, 2013 at 7:18 AM, Brian Campbell <
>>> bcampbell at pingidentity.com> wrote:
>>>
>>>> Thanks Vladimir. I had similar thoughts about using HTTP header hints
>>>> to cache keys - it would work but seems really likely that at least some
>>>> wouldn't bother with it or do it properly. So yes, we'd want to be very
>>>> explicit about it, if we went that direction. Or, because of that concern,
>>>> I've been thinking that a exp type parameter in JWK might be a more
>>>> practical approach.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Feb 8, 2013 at 2:17 AM, Vladimir Dzhuvinov / NimbusDS <
>>>> vladimir at nimbusds.com> wrote:
>>>>
>>>>> The idea to have all sig+enc keys into a single JWK set is a good one.
>>>>> Not only we'll reduce the number of reg parameters in case encryption
>>>>> is
>>>>> used, but this will also reduce the number of HTTP requests between OP
>>>>> and clients to get JWKs. I began to realise that we're already having a
>>>>> significant amount of HTTP back and forth in a full OIDC suite
>>>>> implementation and identifying ways to minimise the message exchange
>>>>> and
>>>>> make it more efficient will make overall operation snappier.
>>>>>
>>>>> When I worked on the Java JOSE+JWT library I realised there's potential
>>>>> to use HTTP header hints to cache keys. If we choose to go this way
>>>>> we'll have to be explicit on that of course. However, I don't assume
>>>>> everyone would actually implement that properly. Some people may for
>>>>> instance publish the JWK set as a static file and simply forget or omit
>>>>> to specify the cache headers, which means the HTTP server will apply
>>>>> its
>>>>> default policy.
>>>>>
>>>>>
>>>>> Vladimir
>>>>>
>>>>>
>>>>> --
>>>>> Vladimir Dzhuvinov : www.NimbusDS.com <http://www.nimbusds.com/> :
>>>>> vladimir at nimbusds.com
>>>>>
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [Openid-specs-ab] Proposal(s) on key publication and rotation
>>>>> From: Brian Campbell <bcampbell at pingidentity.com>
>>>>> Date: Tue, February 05, 2013 9:01 pm
>>>>> To: "<openid-specs-ab at lists.openid.net>"
>>>>> <openid-specs-ab at lists.openid.net>
>>>>> Cc: Matthew Miller <mamille2 at cisco.com>
>>>>>
>>>>> What follows are a few different proposed approaches for addressing the
>>>>> open key publication and rotation issues [0]. There are a variety of
>>>>> different ideas here but they are all really just variation on a theme.
>>>>> Clearly I think that some change has to be made and I hope this can
>>>>> begin the process of driving to some consensus about what that
>>>>> something
>>>>> is.
>>>>>
>>>>>
>>>>> Initially something needs to be done to address the asymmetry of
>>>>> features between the jwk and x509 urls (basically allowing for multiple
>>>>> keys in an x509_url) while also supporting certificate chains.
>>>>>
>>>>>  One approach is to have the x509_url return JSON that is a collection
>>>>> of x5c [1] type objects. That would allow the same keys and same number
>>>>> of keys to be represented via the x509_urls as with jwk_urls. It also
>>>>> allows for certificate chains to be used by entities that so desire.
>>>>> That might look something like this:
>>>>>
>>>>> {
>>>>>   "certificates":
>>>>>  [
>>>>>   ["MIIE3j...+4=","MIIE+z...09VZw==", "MIIC5zC...9ViH0Pd"],
>>>>>   ["MIIGzDC...TGwxcw==","MIIC5zCCA...ViH0Pd"]
>>>>>  ]
>>>>> }
>>>>>
>>>>>  A key rotation recommendation for signatures is then fairly
>>>>> straightforward and goes something like the following. The signer
>>>>> publishes its keys at the jwk_url or x509_url or both and includes a
>>>>> kid
>>>>> or x5t or both in every message to indicate to the verifier which key
>>>>> is
>>>>> to be used to check the signature. Keys can be rolled by periodically
>>>>> adding new keys to the jwk_url/x509_url (and purging really old ones).
>>>>> The signer begins using a new key and signals that to the verifier by
>>>>> the kid and/or x5t header. If the verifier knows to go back to the
>>>>> jwk_url or x509_url and re-get the keys when it sees an unfamiliar kid
>>>>> or x5t (possibly with some protections against abuse).
>>>>>
>>>>> A variation on the above would be to augment each x5c type object with
>>>>> a
>>>>> "kid" parameter, which would allow a key to be identified the same way
>>>>> across jwk_url and x509_urls. It could also make individual JWS/E
>>>>> headers smaller by only needing to include one header to identify the
>>>>> key, regardless of the format keys are in. Which is nice. That might
>>>>> look something like this:
>>>>>
>>>>> {
>>>>>   "certificates":
>>>>>  [
>>>>>   {"kid":"abc",
>>>>>    "x5c":["MIIE3j...+4=","MIIE+z...09VZw==", "MIIC5zC...9ViH0Pd"]},
>>>>>   {"kid":"xyz",
>>>>>     "x5c":["MIIGzDC...TGwxcw==","MIIC5zCCA...ViH0Pd"]}
>>>>>  ]
>>>>> }
>>>>>
>>>>> Taking it a bit further, the "use" [3] parameter could be added and,
>>>>> with proper spec treatment across jwk and x509 urls, we could eliminate
>>>>> jwk_encryption_url and x509_encryption_url and consolidate to just
>>>>> having jwk_url and x509_url.
>>>>>
>>>>> And with everything being in JSON, it's a small step to just having a
>>>>> single URL with all the keys. That might look something like this:
>>>>>
>>>>> {
>>>>>  "certificates":
>>>>>  [
>>>>>   {"kid":"abc",
>>>>>     "use":"enc",
>>>>>    "x5c":["MIIE3j...+4=","MIIE+z...09VZw==", "MIIC5zC...9ViH0Pd"]},
>>>>>   {"kid":"xyz",
>>>>>    "use":"sign",
>>>>>     "x5c":["MIIGzDC...TGwxcw==","MIIC5zCCA...ViH0Pd"]}
>>>>>  ],
>>>>>  "keys":
>>>>>  [
>>>>>   {"kty":"RSA",
>>>>>     "n": "0xxcagodb….4Kpw",
>>>>>     "e":"AQAB",
>>>>>     "use":"enc",
>>>>>    "kid":"abc"},
>>>>>   {"kty":"RSA",
>>>>>     "n": "0vx7agoeb....DKgw",
>>>>>     "e":"AQAB",
>>>>>     "use":"sign",
>>>>>      "kid":"xyz"}
>>>>>   ]
>>>>> }
>>>>>
>>>>> That really seems to beg the question of some kind of X.509 support in
>>>>> JWK itself.  Which is admittedly a bit odd at first but has come up on
>>>>> the JOSE list [4] and might help address a number of issues. I spoke
>>>>> with Matt Miller (cc'd and was part of the aforementioned JOSE thread)
>>>>> yesterday about it and we are both generally in favor of exploring the
>>>>> possibility. It seems there are two general approaches that could take:
>>>>>
>>>>> 1) Define an X509 "kty" (Key Type) that would define x5c (and/or maybe
>>>>> x5u) as a JWK parameter. That might look something like:
>>>>>
>>>>> {
>>>>>  "kty":"X509",
>>>>>   "x5c": ["...","..."]
>>>>>
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> 2) Define x5c as parameter in JWK that could be an alternative
>>>>> representation of the key. Something like:
>>>>>
>>>>>
>>>>> {
>>>>>   "kty":"RSA",
>>>>>    "n":".....",
>>>>>    "e":"AQAB",
>>>>>    "x5c": ["...","..."]
>>>>> }
>>>>>
>>>>>
>>>>> There are tradeoffs either way but the first approach might make for a
>>>>> cleaner extension to JWK as it is now (even that may or may not be good
>>>>> but could allow work to proceed here with less direct dependency on
>>>>> JOSE).
>>>>>
>>>>> One last issue is key rotation for encryption, which unfortunately is a
>>>>> bit more tricky that signing. The encrypting party starts the process
>>>>> and thus cannot rely on a change in kid to signal to it that keys need
>>>>> to change. The encrypting party still uses kid to tell the decrypting
>>>>> party which private key to use to decrypt. But the encrypting party
>>>>> needs a different way of knowing that a new key is available and is to
>>>>> be used.  One way to do this is to get the jkw/x509/combined url fresh
>>>>> on every transaction. But that's needlessly inefficient and could be
>>>>> improved by the use of some kind of cache lifetime indicator on the url
>>>>> or individual keys, which allow the encrypting party to cache
>>>>> encryption
>>>>> keys while still checking for new ones on a schedule determined by the
>>>>> decrypting party. It seems like it might be wise to use existing cache
>>>>> control constructs provided by HTTP? But I'm honestly not familiar
>>>>> enough with the various possible headers to know which one(s) is(are)
>>>>> most appropriate. It might also be a tad awkward to write up given the
>>>>> Messages/Standard split and goal of decoupling Messages from HTTP.
>>>>> Alternatively key life or cache duration could be indicated on the
>>>>> individual keys themselves. The concept of a exp parameter that defines
>>>>> an expiration parameter for keys has been mentioned before [5] - maybe
>>>>> this could/should be formalized?
>>>>>
>>>>>
>>>>>
>>>>> If you made this far, I appropriate it. I think this is important.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [0] Open Issues (at the time of writing) in Connect:
>>>>>
>>>>>
>>>>> https://bitbucket.org/openid/connect/issue/703/key-publication-needs-to-be-reworked
>>>>>
>>>>> https://bitbucket.org/openid/connect/issue/704/provide-key-rollover-guidance
>>>>>
>>>>> https://bitbucket.org/openid/connect/issue/740/use-of-same-key-for-different-operations
>>>>>
>>>>>
>>>>> [1] It would be the general concept x5c though not necessarily the same
>>>>> processing rules
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.6
>>>>> (JWS definition of x5c)
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#appendix-B
>>>>> (example)
>>>>>
>>>>> [2] One definition of kid from JWK
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08#section-4.4
>>>>>
>>>>> [3] use from JWK
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08#section-4.2
>>>>>
>>>>> [4] JOSE mail archives on a thread that turned into x509 and jwk
>>>>>  http://www.ietf.org/mail-archive/web/jose/current/msg01445.html
>>>>>
>>>>>
>>>>> [5] Doc history on JWK -06 that talks about exp
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06#appendix-C
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130220/e89008e3/attachment-0001.html>


More information about the Openid-specs-ab mailing list