Using a second signing certificate

[Cantor, Scott]

On 7/15/13 1:16 PM, "Jason Gauthier" <jgauthier at lastar.com> wrote:

>>You can't do key rollover unless the metadata is decoupled from the
>>configuration so that it can be altered ahead of the change. InCommon
>>has a >number of wiki pages that describe how this works in some detail
>>(there are some in the Shibboleth wiki as well, but more specifically
>>geared to >the software).
>
>Okay. This makes sense, but is still a confusing concept for me.

You can't start signing with a key that you haven't told every system
about or one or more of them will break.

In turn, you don't want partners directly consuming a metadata file
generated from a system that has to be configured with all of the signing
keys it might use in order to generate that metadata, because you're
risking violating the first rule (unless you can configure the key but
guarantee it won't be used until later of course).

The upshot is that metadata, used correctly, is largely a separate
process, and that's why federations like InCommon exist and provide value.

The metadata changes in conjunction with configuration changes, but not in
lockstep with them. The specifics depend on the change.

I think you'll understand this better looking at InCommon's documentation.

>Yes, more or less.  I actually had 2 Shib systems break, and two vendor
>systems.  Those vendors had me supply a certificate for signing.
>On 07/09, my ADFS server "switched" keys, and all the vendors I supplied
>the signing key to previously just broke.

That is essentially always going to happen with some systems because most
systems other than Shibboleth don't understand metadata and won't use it
anyway. The specific case of the Shibboleth SPs was self-inflicted
failure, perhaps, but probably not the other two.

The double whammy is an SP that can't handle multiple valid keys, in which
case you're screwed and have to schedule the change no matter what.

And the sum of all of this is that you should never rely on certificates
with periods measured in small numbers of years, avoid software that cares
about certificates where possible (ADFS does unfortunately), and above
all, never change a key you don't have to.

>Since I don't have control over their systems, I am trying to understand
>this from the perspective of what I do have control over. Which is my
>ADFS and a couple Shib instances.

In those cases, you need separately maintained metadata you can manipulate
to adjust keys supplied to those systems. Then it just works.

>That makes sense.  I don't really have expectations, but more looking
>into what process I can use so that next year this doesn't break out
>without anyone understanding why, or preferably what I can do to put all
>the pieces in place now for longevity.
>
>I'm still not certain what those pieces are.

The TrustManagement topic in the wiki is about all I can point you to.
There is, again, a reason federations exist, to help with this problem.
Unfortunately, the number of people using this stuff who are diligent
enough to ask these questions is fairly small, so most of the time people
just don't get why this is useful.

And the fact that nothing but Shibboleth, and to some degree
simpleSAML.php, can do any of this at all means that the value proposition
behind it is constrained by that. You always have partners running broken
software that simply dodges all this and makes it a manual process.

>Okay.  It's comforting to know that editing the metadata is common.  I
>guess I need to figure out how to handle key roll over with Shib, in my
>environment... and maybe discuss this with my vendors as well.

I don't think you'll like the answers unfortunately, but we're all
struggling with this.

-- Scott