SP certificate rollover

[Peter Schober]

* Ondřej Košarko <kosarko at ufal.mff.cuni.cz> [2017-03-03 13:44]:
> I've added the new certificate to the sp config Started distributing
> metadata with the new cert to federations (the sp is member of
> multiple); the communication with some was faster than with others;
> so there were federations with just the old cert, with both, and
> with just the new one (because the ui didn't let you to have more
> than one).

Not having more than one certificate in metadata means not performing
a key rollover. As simple as that.

As an SP operator you can still *replace* (in-place) the old key with
the new key, provided that:
1. your software has the old and the new key available for decryption
2. you're not signing any requests. Authentication requests are not
   signed by default, but SLO requests are, IIRC.

The IDPs having cached/old metadata will encrypt with the old key, the
IDPs with new/current metadata will encrypt with the new key.
Eventually the former IDPs will all become the latter and only the new
key will be used, at which point you can remove the old from your
local config.

> Now the impression was that the sp will still work with any idp from
> any of those federations.

Tell me, if you could just skip proper key rollover procedures without
loss of fidelity why would those procedures exist?

> Finally, you cannot prevent a "downtime" when you are allowed to
> have only one cert in the metadata, or can you?

Only if you're not signing anything and have all keys available
locally, I think, as per above.

Btw, feel free to identify those federations that don't allow for
proper key rollover, either to me (off-list) or CESNET/eduID.cz folks
or contact the REFEDS secretariat (contact on their website).
Someone will have to take this up with them.
-peter