IDP certificate metadata

[Cantor, Scott]

On 10/17/14, 2:13 PM, "Edwards, Wendy A" <wedwards at illinois.edu> wrote:

>The IDP v3 creds file contain two .crt files, one for encryption and one
>for signing.  The IDP v2 credentials file contained a single idp.crt file.

Yes, V2 does not support decryption, and due to the recent spate of
serious vulnerabilities in everything short of the toaster, we felt it
best to start encouraging proper key hygiene using defaults to limit the
impact of any particular compromise.

The only common use case for decryption in the IdP is in logout requests,
and that's not even on by default in Shibboleth SPs, so it's very rare
that it's going to affect anybody. Omitting that key from metadata is well
within the scope of reasonableness probably.

>The IDP v2 metadata contains two <ds:X509Certificate> elements, which
>have identical values for Idp v2, since there¹s one x509 cert.

The metadata includes two roles. Keys are bound to roles. We also assumed
a common key for TLS and for signing, and we're also not encouraging that
any longer.

If the V2 metadata didn't include a use attribute on what it generated,
that's something we screwed up and need to fix. In the meantime, any IdP
metadata that's claiming to support encryption using that key is wrong
anyway. And if separate keys are used, then it's also wrong to not
delineate which is which.

If you don't deploy attribute queries, then you don't need that role at
all.

>   For IDP v3 metadata, do we use both idp-encryption.crt and
>idp-signing.crt?  If so, in any particular order?

For any given role, you have to include the keys you intend to use. If a
key is used for signing or for TLS on a SOAP port, you mark it
use="signing". If it's used for decryption at the IdP, i.e., encrypting
data to it, you mark it use="encryption". In the case that the same key is
used for both, you either list it twice, or once with no use attribute.

Order matters only because you can't (for any useful result) list multiple
encryption keys that support the same algorithms, or at least if you do,
only the first matters.

Key rollover of different kinds of keys has very different properties.
Using separate keys for different functions makes rollover of a given key
much simpler, but not if they all have to be rolled.

There is also a different kind of key generated by the installer, a
symmetric key used for encrypting data stored in cookies and a few other
cases. It's called a DataSealer key and is like a Kerberos keytab with
multiple versions of the key in a keystore and a version file. It is
secret and never shared except by cluster nodes.

-- Scott