[Openid-specs-ab] On Key Rolling

[Brian Campbell]

I've been thinking about key rollover mostly in the context of signatures
and I imagine, using jwk_url, it'd work something like the following
paragraph.

The signer publishes its keys at the jwk_url and includes a kid 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 (and removing really old ones). The signer begins using the new key and
signals that to the verifier by the kid header. If the verifier knows to go
back to the jwk_url and re-get the keys when it sees an unfamiliar kid
(possibly with some protections against abuse).

Is this similar to what others have been thinking? https://bitbucket.org/
openid/connect/issue/703 and https://bitbucket.org/openid/connect/issue/704
were largely intended to be about codifying that approach and ensuring that
a (roughly) equivalent approach was available for X509 that also supported
certificate chains.

I'm not sure that approach works as well for encryption, however.  The
decrypting party can publish new keys to its jwk_encryption_url but how
does it single to an encrypting party that new keys are there? Has anyone
thought though a reasonable approach here? It seems like indicating some
kind of expiration or lifetime on individual keys or the whole jwk
_encryption_url might be needed. But am I missing an easier/different
approach?

The different flow of events in encryption also means, I think, that
neither the kid parametrization idea mentioned in https://bitbucket.org/
openid/connect/issue/704 nor John's suggestion that I tried to capture in a
comment are are viable approaches. Both require the encrypting party to
know about key ids or key URLs that couldn't really be known without some
other exchange.

Any thoughts or guidance here would be much appreciated.

Thanks,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130122/534b6db8/attachment.html>