Shibboleth SPv3: checking how to rollover the signing key

[Gernot Hassenpflug]

Hello,

This is the first time for us to try and rollover a signing key, as
opposed to an encryption key.

I would like to confirm whether the order of operations is the same as
that for rollover of an encryption key.

On the following page,
https://wiki.shibboleth.net/confluence/display/SP3/Multiple+Credentials
there is stated under 'Key Rollover' that

"On the authentication side, the solution is to publish the new
key/certificate in your metadata and wait for that to propagate before
switching your SP from the old credential to the new one. In that
scenario, you need not ever configure both within the SP itself (i.e.,
it's different from this topic's goal)."

On the following page,
https://wiki.shibboleth.net/confluence/display/IDP30/SecurityAndNetworking#SecurityAndNetworking-SigningKeyandCertificate
there is stated under 'SP Signing and Back-Channel TLS Keys and
Certificates' that

"An SP may advertise any number of such keys in its metadata and the IdP
will accept any of them. This allows a new key to be added alongside an
older key before adding it to the SP configuration, as part of replacing
the old key with the new one."

I want to confirm that I understand that above correctly:

It appears to mean that one must not add the new signing key to the SP's
chained CredentialResolver block first before publishing in the
metadata. Instead, since the first user of the key will be the SP, one
must publish in (add to) the published SP metadata first, so that the
IdP knows that a message signed with this key by the SP is legitimate
when one then uses the new key. Presumably, if the IdP does not have
knowledge the new SP key yet, the IdP will display some kind of error
that the SP message does not meet security standards. If my
understanding is correct, I presume the rolloever order will be:

1. Publish the new signing key in metadata (adding to existing keys
   listed in the SP metadata), with use="signing".

2. Confirm that the IdP has read the new SP metadata.

3. Add the new signing key to the chained SP CredentialResolver block. I
   assume that the SP can use any of the use="signed" keys, and that one
   should list the new one ahead of the old one in the list (or maybe
   there is some other way to ensure the new one is used in
   preference?).

4. Check that the SP and IdP can communicate (and used debug logs
   perhaps if possible to see that the new signing key is in use).

5. Remove the old signing key from chained SP CredentialResolver block,
   thus leaving only the new signing key.

6. Check again that the SP and IdP can communicate (and verify in debug
   logs if possible).

7. Remove the old signing key from the SP metadata, publish it, and ask
   the IdP to read it (if they do not update in a timely manner it is
   not critical since the SP will never use the key).

If the above is correct, maybe it would be useful to have in the Wiki
along with the encryption key rollover procedure?

Best regards,
Gernot Hassenpflug
-- 
Asahi Net, Inc.
Tokyo, Japan