Changing IDP Metadata Cert

[Cantor, Scott]

None of this has any sort of simple answer. I've covered the challenges and processes involved in key changes on the list pretty often.

But this situation can also be addressed through the thing Shibboleth does not have ideal or simple support for, dedicated signing keys for specific SPs, because you can't just go changing the cert and count on most non-compliant software from breaking. That can effectively be a key change for all intents and purposes when it's done globally.

> Instead it has:

Absence of use="signing" or use="encryption" implies both signing and encryption, which should not be done with an IdP because of the huge challenges and differences in rotating them. Only very old versions defaulted to that approach because back then we didn't even support IdP decryption so the absence of the attribute was somewhat accidental, and it shouldn't be done that way in any "real" metadata as published by federations.

>    Apart from that, though, this sounds like what needs to be changed, given
 > the fact that it's in the metadata.

Metadata reflects deployment state, but key changes involve critical and ordered steps that separate the content of the metadata from the configuration to ensure graceful outcomes. But that applies to full rotation, not one-off situations where metadata might not even be involved. Only SPs using a tiny handful of implementations support metadata to begin with.

> I do see, however, that the end of that page has a 'Metadata Signing Keys
> and Certificates' section. And while the section title sounds relevant, the
> contents do not. 

Metadata signing is about metadata signing, not runtime assertion or message signing. Entirely different.

>So my first question is which key/cert needs to be updated, the signing
> key/cert or the metadata signing/key cert?

The former, except that you don't want to do that unless you're prepared to enter a multi-month process or break a lot of systems, or do some work up front to determine what the risk really is.

> I'm assuming that when SHA-1 went EOL, everyone had to deal with this.

Many people got ahead of it long before they had sufficient non-Shibboleth (i.e. broken) SAML SPs at scale to deal with. So not everyone had to deal with the full scope of the problem. Maybe you don't either, it depends on the scale of your deployment.

I definitely rolled mine off SHA-1 before the cloud got huge, just a matter of luck, but I also subsequently did a full rotation of the key, which took, yes, 9 months of calendar time and easily 120 or more hours of meticulous work.

As for generating something outside of using OpenSSL, there's
$ idp/bin/keygen.sh --help

And if you go down the "override key for an SP" route, it's covered in https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631697/SecurityConfiguration

Configuration -> Per-Profile Credential

It's ugly, it's not something we really target as a use case and have never made it that clean to pull off. But avoiding it by rolling the cert outright is a difficult undertaking that just depends on too many local factors to map out a plan for.

Among the emails in the archive on this:

https://marc.info/?l=shibboleth-users&m=158086168427222&w=2
https://marc.info/?l=shibboleth-users&m=161125296125093&w=2

Directly on point:
https://marc.info/?l=shibboleth-users&m=162507942204859&w=2

Essentially, as I say there, if you do a key rotation by issuing a new cert with the same key, you can expect Shibboleth SPs to work (even if they never get updated metadata), and you can expect an unknown number of SPs to work or not work if they don't get updated metadata or get manually updated. It's hard or impossible to predict.

I'm sure you hate this response, but that's all I can do on list. This is a deep, deep member support sort of topic that would require much more time to do proper justice to.

We need a ton of docs on this topic, most of which have little to do with Shibboleth at all, just no time to do it.

-- Scott