Phase 1 Report of the MD-Distro Subcommittee

INTRODUCTION

The InCommon MD signing key is rooted in a self-signed CA whose root certificate expires in March 2014. The phase 1 goal of this subcommittee is to determine if continuing with a PKIX CA may be required in the foreseeable future in which to root the MD signing key. This subcommittee offers the following observations, recommendations and guidance to InCommon's Technical Advisory Committee and InCommon Operations.

The discussions occurred over a series of weekly phone calls with email discussion on the md-distro@incommon.org email list. Members of the InCommon participant community were invited and joined the open discussions. Notes and archives are available on the subcommittee's wiki:https://spaces.at.internet2.edu/x/zRBOAg

OBSERVATIONS

In general, having a PKI gives one the ability to not take much of reconfiguration hit when the signing certificate is re-keyed. InCommon can also revoke the metadata signing key without much reconfiguration. However, reconfiguration headaches need to occur when the PKI's root cert needs to be re-keyed, so if the expiry of the CA's root is equivalent to a self-signed signing cert's expiry, the same conditions prevail and there is no benefit to a CA.

In the self-signed cert model things /could/ break, but there are not many possible cases where that would matter due to the fact that support for multilateral metadata aggregates is slim.

Furthermore, even in a full-blown PKIX model, the root of a trust path does not have to be a CA. Path validation and trust in the path is what is important. The goal is that the cert being evaluated is trusted and currently valid. In practice, the only case for real-time cert verification is software intentionally pulling MD live, and today Shib is the only candidate that offers the option.

The discussion continued, dividing the analysis into two use cases: is there any value in rooting a metadata (MD) signing key in (1) an online or (2) an offline CA?

It was also noted that relying on Certificate Revocation Lists (CRLs) extends the vulnerability window in relation to a given signed MD aggregate's expiry date. OCSP is also redundant, relying on a third party lookup, which is equivalent to re

CONCLUSION

Although there may be reason to further explore online signing and therefore related security measures of online signing keys (e.g., hardware security modules), the group found no compelling reason for a PKI CA, so long as adequate practice for and documentation of the protection of the signing key is accomplished.

IMPACT

We can't be 100% certain that no one is relying on the CA. However, there is no practical reason or known deployment to make us think this true. What might break?

1. SimpleSAML deployments rely on the fingerprint of the signing cert (rather than the key). So, if we decide to keep the same signing key but wrap it in a self-signed cert, migration and reconfiguration issues will exist for all SimpleSAML users. This has been the case every time we renew the signing cert, every two years, so this represents no significant increase in the rate of reconfiguration (current signing cert expires 2 May 2014).

2. Non-standard deployments. There are few non-standard deployments that we know of. This may be low risk with exception of, for instance, government agencies relying on CA site minder. We also need to explore the limitations of ADFS.

This raises an opportunity to be more explicit in our documentation on ways we expect participants to do MD validation. We can remind participants if they are relying on the PKI that is there, they're relying on security patterns that are no longer relevant.

If, in the future, a CA is needed, we can have the singing key signed by the CA's root at that time, or simply have the signing key sign itself. There are known examples of this. Edugain uses a self-signed cert for MDA signing.

LIFETIME OF THE CURRENT SIGNING KEY

We also discussed the determination of whether the current 2048-bit metadata signing key needs to be replaced. The question is, What would restricting the lifetime of the key prevent? Two vectors of attack were postulated. First, there might be an attack which relies on having large amounts of cypher text available. The more you generate, the more vulnerable you are. However, there are no known attacks of this nature for RSA 2048-bit keys, and the amount of known cypher text is minuscule (at most 5 signings per week for XX years for the current key). Where XX InCommon operations will provide. Second, an attack might exist that relies on sheer computational power. Someone may have theoretically been applying resources over the XX year period to the public key to compute the value of the private key?? We have found no evidence to suggest that this is practical even with today's technology. We conclude that there is currently no reasoned terminus for a 2048-bit key's lifetime. There are practical reasons to limit its life to the year 2038 for other known reasons <http://en.wikipedia.org/wiki/Year_2038_problem>.

RECOMMENDATIONS

1. Create a new policy document to replace the CP/CPS that describes security practices for the protection of the signing key
2. Re-sign the same signing key with a self-signed certificate and do away with the remnants of the old InCommon self-rooted CA. This will reduce confusion. No recommendation for cert lifetime is offered, other than to suggest no longer than 2038.
3. SimpleSAML.php will have a problem due to a change in the fingerprint as output of entire cert. We will contact the SS developers as well as communicate the migration plan clearly with participants.
4. Communicate with any known users of non-standard implementations. Of note: particularly NSF, NIH, and a call to any using ADFS for known configuration dependencies.
5. Expired Certificates issued by the old InCommon CA still exist in participant MD. We recommend communicating about these old certificates but separately, after the communication about the transition with the signing key's root cert and CA.