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

Mike Jones Michael.Jones at microsoft.com
Wed Feb 20 15:37:51 UTC 2013


Let's make Key Rotation a subject of tomorrow morning's call.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Wednesday, February 20, 2013 7:35 AM
To: John Bradley
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Proposal(s) on key publication and rotation

BTW, I'm willing (and I think able) to do the editing on this but don't want to inadvertently step on any toes or do the wrong thing.

On Wed, Feb 20, 2013 at 7:44 AM, Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>> wrote:
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<mailto: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<mailto: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<mailto: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<mailto: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.html and follow ups

On Mon, Feb 11, 2013 at 7:18 AM, Brian Campbell <bcampbell at pingidentity.com<mailto: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<mailto: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<mailto:vladimir at nimbusds.com>



-------- Original Message --------
Subject: [Openid-specs-ab] Proposal(s) on key publication and rotation
From: Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>>
Date: Tue, February 05, 2013 9:01 pm
To: "<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>>
Cc: Matthew Miller <mamille2 at cisco.com<mailto: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<mailto: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<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/20130220/fcee207e/attachment-0001.html>


More information about the Openid-specs-ab mailing list