<div dir="ltr"><div><div>Thanks Breno,<br><br></div>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? <br>

<br></div><div>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.<br><br></div><div><br><br>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 11:57 PM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Your outline on signatures and key rotation are correct, and in fact<br>
Google's implementation rotates the signing keys daily, maintaining a<br>
list of only 2 keys (old an new). It works as long as your clocks are<br>
less than 12h off from universal time.<br>
<br>
Rotation of encryption keys is a far harder problem. I think generally<br>
the way to do this is to define a key agreement protocol, which<br>
essentially allows for dynamic negotiation of the encryption keys once<br>
you have the ability to do signing/authentication.<br>
<div><div class="h5"><br>
On Tue, Jan 22, 2013 at 12:33 PM, Brian Campbell<br>
<<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:<br>
> I've been thinking about key rollover mostly in the context of signatures<br>
> and I imagine, using jwk_url, it'd work something like the following<br>
> paragraph.<br>
><br>
> The signer publishes its keys at the jwk_url and includes a kid in every<br>
> message to indicate to the verifier which key is to be used to check the<br>
> signature.  Keys can be rolled by periodically adding new keys to the<br>
> jwk_url (and removing really old ones). The signer begins using the new key<br>
> and signals that to the verifier by the kid header. If the verifier knows to<br>
> go back to the jwk_url and re-get the keys when it sees an unfamiliar kid<br>
> (possibly with some protections against abuse).<br>
><br>
> Is this similar to what others have been thinking?<br>
> <a href="https://bitbucket.org/openid/connect/issue/703" target="_blank">https://bitbucket.org/openid/connect/issue/703</a> and<br>
> <a href="https://bitbucket.org/openid/connect/issue/704" target="_blank">https://bitbucket.org/openid/connect/issue/704</a> were largely intended to be<br>
> about codifying that approach and ensuring that a (roughly) equivalent<br>
> approach was available for X509 that also supported certificate chains.<br>
><br>
> I'm not sure that approach works as well for encryption, however.  The<br>
> decrypting party can publish new keys to its jwk_encryption_url but how does<br>
> it single to an encrypting party that new keys are there? Has anyone thought<br>
> though a reasonable approach here? It seems like indicating some kind of<br>
> expiration or lifetime on individual keys or the whole jwk_encryption_url<br>
> might be needed. But am I missing an easier/different approach?<br>
><br>
> The different flow of events in encryption also means, I think, that neither<br>
> the kid parametrization idea mentioned in<br>
> <a href="https://bitbucket.org/openid/connect/issue/704" target="_blank">https://bitbucket.org/openid/connect/issue/704</a> nor John's suggestion that I<br>
> tried to capture in a comment are are viable approaches. Both require the<br>
> encrypting party to know about key ids or key URLs that couldn't really be<br>
> known without some other exchange.<br>
><br>
> Any thoughts or guidance here would be much appreciated.<br>
><br>
> Thanks,<br>
> Brian<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
--Breno<br>
</font></span></blockquote></div><br></div>