[Openid-specs-ab] Issue #2100: Federation Historical Keys (openid/connect)

[Tom Jones]

This problem has existed forever.

This spec, as well as any, needs to understand when an expired key is still
valid for evaluating a signature. It seems that the federation spec is not
the best place to clarify the correct evaluation. It is likely that the
machine performing the evaluation is NOT a member of the federation.

The biggest challenge comes when a key is revoked which should not revoked
any existing signature made by that key.

It would be good for a full description to be made. What really bothers me
is the idea that different standards might come to different conclusions.

thx ..Tom (mobile)

On Sun, Dec 3, 2023, 9:50 AM David W Chadwick via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> New issue 2100: Federation Historical Keys
> https://bitbucket.org/openid/connect/issues/2100/federation-historical-keys
>
> David W Chadwick:
>
> A superior entity publishes the keys of its subordinate entity in the
> Entity Statement that it signs for its subordinate. Therefore historical
> keys should be published by superior entities and not by the entities
> themselves. Section 7.6 says “Each Federation Entity MAY publish its
> previously used Federation Entity Keys at the historical keys endpoint”.
> This is wrong and it opens up the possibility of an attack. A fake entity
> statement can be published now, and the key can be published at the
> historical keys endpoint. No-one can tell this is fake because the superior
> is publishing a different key now for this entity.
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://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/20231203/cf544d19/attachment.html>