[Openid-specs-ab] Issue #1161: Key rotation should require a delay between publishing a key and starting to use it? (openid/connect)

Vladimir Dzhuvinov vladimir at connect2id.com
Sun Mar 22 20:38:23 UTC 2020


If we only had 'nbf' and 'exp' defined in the original JWK spec.

On 22/03/2020 19:49, Torsten Lodderstedt via Openid-specs-ab wrote:
> You are right. The problem with JWKS_URI as far as I understand is, there is no lifecycle status indication in the sense the OP could leave the key in the list but deactivate it or valid from/to time fields. This kind of information  could be added by using X.509 certs, which is rather untypical in the OIDC space.
>
>> On 22. Mar 2020, at 18:35, Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>
>> this is not good advice. A signing key may need to be used for validation for may years after the signing occurs. The signing key MUST be retained for a period of time that corresponds to the effective life of the document signed.  Encryption keys are different in that the lifetime of the decryption of the object may be different than the time frame when a document needs to be validated and is entirely an internal function. The public key used for encryption can be changed at any time and the only one retired IN THE PUBLIC KEY CERTIFICATE.
>> Peace ..tom
>>
>>
>> On Sun, Mar 22, 2020 at 9:28 AM josephheenan via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>> New issue 1161: Key rotation should require a delay between publishing a key and starting to use it?
>> https://bitbucket.org/openid/connect/issues/1161/key-rotation-should-require-a-delay
>>
>> Joseph Heenan:
>>
>> [https://openid.net/specs/openid-connect-core-1\_0.html#RotateSigKeys](https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys) says:
>>
>>> Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at its `jwks_uri` location and includes the `kid` of the signing key in the JOSE Header of each message to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over by periodically adding new keys to the JWK Set at the `jwks_uri`location. The signer can begin using a new key at its discretion and signals the change to the verifier using the `kid` value. The verifier knows to go back to the `jwks_uri` location to re-retrieve the keys when it sees an unfamiliar `kid` value. The JWK Set document at the `jwks_uri` SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.
>>>>
>> The “signer can begin using a new key at its discretion” seems potentially problematic - discussion within the certification \(around a test intended to test RPs rotating keys, see [https://www.heenan.me.uk/~joseph/oidcc\_test\_desc-phase1.html#OP\_Rotation\_RP\_Sig](https://www.heenan.me.uk/~joseph/oidcc_test_desc-phase1.html#OP_Rotation_RP_Sig) \) revealed that OPs in larger distributed deployments will in some cases not react immediately to keys being added and a new kid being found. For example to prevent a DoS attack an OP may well decide not to refetch a JWKS it has fetched in the last 60 seconds.
>>
>> I would suggest tweaking the text so that “The signer can begin using a new key at its discretion” becomes something like “The signer should wait at least a few minutes after it publishes the new key and then can begin using a new key at its discretion”
>>
>>>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200322/88175c47/attachment.p7s>


More information about the Openid-specs-ab mailing list