[Openid-specs-ab] Proposal(s) on key publication and rotation
Brian Campbell
bcampbell at pingidentity.com
Mon Feb 11 19:22:04 UTC 2013
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.html and
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 : 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130211/35f76448/attachment.html>
More information about the Openid-specs-ab
mailing list