IdP request signing certificate will change

[Cantor, Scott]

> Their current certificate is defined in a filesystemmetadataprovider xml file.

If you're maintaining their metadata for them (or to put it another way, if you're not using metadata as intended because they don't support it), then key management is a manual process. The local metadata gives you some flexibility to handle that in accordance with the specifications we follow, but without a tight connection back to what the SP is doing, there's little chance of it not breaking unless encryption is not part of the picture. Signing is simple (in fact most SPs don't even do any). Without encryption the SP may not even be doing anything with a key.

> I've been searching google but can't seem to find a clear unambiguous an
> answer to the following question:

The unambiguous explanation is in the SAML Metadata Interoperability profile if that's the form of the metadata you're using. It won't help because the problem isn't the metadata; rather it's what the keys are actually doing, what SAML features are used, and what the SP is, what it supports, and when it's going to make various changes.

> Now my question is: Can I just add another block like
> <md:KeyDescriptor use="signing">
> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> ...
> </ds:KeyInfo>
> </md:KeyDescriptor>
> with the new certificate today?

Yes. But encryption rollover at the same time is much more complex and so the answer is that it depends on what the SP is and what it supports and what they plan to do. There is essentially no hope of a clean process when you maintain the metadata separately from the configuration of the peer. Something is pretty much guaranteed to break. The only real substitute is a flag day, a scheduled cutover.

> From what I've read in the wiki and on the switch site it appears there's some
> method in SAML2 to allow 2 certificates to exist at the same time during
> rollover but I'm not certain these should/can exist in both the SP and the IdP
> or not.

Shibboleth fully supports multiple credentials and follows all the rules. Other software does not and even if the software does, people don't do things properly. So the answer remains that it depends.

-- Scott