[Openid-specs-ab] Issue #1174: Federation: 9.2.2.2.1. The OP Constructing the Response - Clarify which keys need to be preserved to facilitate roll-over (openid/connect)

Tom Jones thomasclinganjones at gmail.com
Mon Jun 8 14:29:45 UTC 2020


It seems like I need to repeat this same warning at least once per year.

The issue with key retention is NOT when the issuer will need to use the
keys, but how long any relying party (in the broadest possible sense) might
need to use the keys. For signing keys this means when will someone need to
verify a signature, for encryption keys it means when will someone need to
decrypt an archived version of the data. For example, the master CA keys
need to be available for 25 years after they were last used to sign a
certificate.
Peace ..tom


On Sun, Jun 7, 2020 at 11:48 PM Vladimir Dzhuvinov via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> New issue 1174: Federation: 9.2.2.2.1. The OP Constructing the Response -
> Clarify which keys need to be preserved to facilitate roll-over
>
> https://bitbucket.org/openid/connect/issues/1174/federation-92221-the-op-constructing-the
>
> Vladimir Dzhuvinov:
>
> In [
> https://openid.net/specs/openid-connect-federation-1\_0.html#rfc.section.9.2.2.2.1](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.9.2.2.2.1)
>
> > At this point, if there already exists a client registration under the
> same entity identifier then that registration MUST be regarded as invalid.
> **Note that key material from the previous registration MUST be kept to
> make key rollover possible.**
>
> Is this the entity JWK set or the JWK set referenced by the client
> metadata \( `jwks_uri` or `jwks`\)?
>
> 1. If it’s the entity statement JWK set we don’t quite understand why
> these will need to be kept after an update.
> 2. As for the jwks\_uri / jwks, the roll-over is managed by the RP /
> client, by simply keeping the old keys in the set, until no longer used.
>
> If some roll-over needs to happen re 1 \(entity statement JWK set\) then
> this could also be managed by the client, thus making the requirement for
> the OP redundant.
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200608/cc4a6d44/attachment.html>


More information about the Openid-specs-ab mailing list