[Openid-specs-ab] On Key Rolling

[Breno de Medeiros]

Your outline on signatures and key rotation are correct, and in fact
Google's implementation rotates the signing keys daily, maintaining a
list of only 2 keys (old an new). It works as long as your clocks are
less than 12h off from universal time.

Rotation of encryption keys is a far harder problem. I think generally
the way to do this is to define a key agreement protocol, which
essentially allows for dynamic negotiation of the encryption keys once
you have the ability to do signing/authentication.

On Tue, Jan 22, 2013 at 12:33 PM, Brian Campbell
<bcampbell at pingidentity.com> wrote:
> 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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
--Breno