<div dir="ltr"><div><div>I've been thinking about key rollover mostly in the context of signatures and I imagine, using <span style="background:none repeat scroll 0% 0% yellow">jwk</span>_<span style="background:none repeat scroll 0% 0% yellow">url</span>, it'd work something like the following paragraph.  <br>



<br>The signer publishes its keys at the <span style="background:none repeat scroll 0% 0% yellow">jwk</span>_<span style="background:none repeat scroll 0% 0% yellow">url</span> 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 <span style="background:none repeat scroll 0% 0% yellow">jwk</span>_<span style="background:none repeat scroll 0% 0% yellow">url</span> (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  <span style="background:none repeat scroll 0% 0% yellow">jwk</span>_<span style="background:none repeat scroll 0% 0% yellow">url</span> and re-get the keys when it sees an unfamiliar kid (possibly with some protections against abuse). <br>



<br></div>Is this similar to what others have been thinking? https://<span style="background:none repeat scroll 0% 0% yellow">bitbucket</span>.org/<span style="background:none repeat scroll 0% 0% yellow">openid</span>/connect/issue/703 and https://<span style="background:none repeat scroll 0% 0% yellow">bitbucket</span>.org/<span style="background:none repeat scroll 0% 0% yellow">openid</span>/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.<br>



<br></div><div>I'm not sure that approach works as well for encryption, however.  The decrypting party can publish new keys to its <span style="background:none repeat scroll 0% 0% yellow">jwk</span>_encryption_<span style="background:none repeat scroll 0% 0% yellow">url</span> 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  <span style="background:none repeat scroll 0% 0% yellow">jwk</span>_encryption_<span style="background:none repeat scroll 0% 0% yellow">url</span> might be needed. But am I missing an easier/different approach?<br>



<br></div><div>The different flow of events in encryption also means, I think, that neither the kid parametrization idea mentioned in https://<span style="background:none repeat scroll 0% 0% yellow">bitbucket</span>.org/<span style="background:none repeat scroll 0% 0% yellow">openid</span>/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.<br>



<br></div><div>Any thoughts or guidance here would be much appreciated. <br><br></div><div>Thanks,<br></div><div>Brian<br></div><div><br><br></div><div><br><br><br><br><br><br></div></div>