* Aaron Howell <[hidden email]> [2018-06-14 07:16]:
> We are looking to upgrade our keys after many years - we have
> started to get “don’t support SHA1” conversations. So if we are gong
> to have to put in new keys, would prefer to make them the default
> moving forward.
You're referring to the "Signature Algorithm: sha1WithRSAEncryption"
of the self-signed signing cert of your IDP?
If there's no issue with the size of the key and you're still
confident about the confidentiality of the secret key you can simply
re-wrap the same key in a new self-signed cert and should be able to
just replace the existing keys in metadata. No roll-over, no nothing.
> There does not appear to be any clear instruction documented - and
> most I have found only appear to deal with the Signing key.
That may be because the IDP traditionally didn't have support for
inbound encryption, so signing was its main concern.
Also your IDP does not currently publish an encryption key (which is
to be expected for existing deployments), so again there's nothing
about encryption keys to roll-over here.
[For some reason, the original message has not appeared in my inbox. I
see the original message in the archives, however. Weird.]
> * Aaron Howell <[hidden email]> [2018-06-14 07:16]:
>> We are looking to upgrade our keys after many years - we have
>> started to get “don’t support SHA1” conversations. So if we are gong
>> to have to put in new keys, would prefer to make them the default
>> moving forward.
This excerpt from the article may be relevant to your discussions:
There are absolutely no security considerations concerning the
signature on certificates in metadata. Refer to the article for