[Openid-specs-ab] On Key Rolling

[Brian Campbell]

Thanks Breno,

Glad to hear some confirmation on the signature side. Not sure where to go
on the encryption side. Can you elaborate on your idea? Is it something
that could or should be codified in the standard?

IMHO, it's extremely important for Connect to provide sufficient facilities
and guidance to enable key rotation that can scale. And it doesn't seem
like it's there yet.





On Tue, Jan 22, 2013 at 11:57 PM, Breno de Medeiros <breno at google.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130123/43e083f4/attachment.html>