Getting a grasp on Heartbleed and IDPs

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Thursday, April 10, 2014 1:24 PM
>
> No, it has to be in the metadata regardless. The key hygeine issue is
> reusing the XML signing key for TLS instead of using separate keys.
[...] 
> You need a key that's in the metadata

I'm still a bit confused, sorry; in a different thread somebody posted:

	https://spaces.internet2.edu/display/InCFederation/Key+Usage

So, to identify the certificates/keypairs involved, if I understand correctly there are:

A) the certificate/keypair used on port 443 of the idp for interaction with end-user browsers
B) the certificate/keypair use on port 4443 of the idp for back channel interaction
C) the certificate/keypair configured in relying-party.xml as the security:Credential
D) the public key listed in the IDPSSODescriptor section of the metadata
E) the public key listed in the AttributeAuthorityDescriptor section of the metadata

We can disregard A, as that is just a normal commercial certificate solely used for interaction with end-users.

Currently, in my configuration, B, C, D, and E all refer to the same certificate/keypair.

If I'm understanding correctly, C is the XML signing key, and B is the TLS key. So the recommendation is to make B and C different, but both B and C need to be in the metadata. What is the correlation between B/D and D/E? Does the XML signing key correspond with the IDPSSODescriptor metadata or the AttributeAuthorityDescriptor metadata? And then the TLS key corresponds with whatever one the XML signing key does not?

> It's not in memory when the vulnerability is in Apache and the key is in a
> Java application.

Well, the vulnerability is in openssl, not specifically Apache, so if you're running tomcat with the tomcat-native apr ssl option, the vulnerability is in the java application, right next to the key. At least for us.

Thanks much...