Phase 1 Report of the MD-Distro Subcommittee

• signing key: a private key used for signing metadata; an RSA 2048-bit private key
• signing certificate: an X.509v3 certificate containing a public key used to verify the signature on a metadata file; a container for an RSA 2048-bit public key

Introduction

The InCommon metadata signing certificate is signed by a CA whose certificate expires in March 2014. The phase 1 goal of this subcommittee is to determine if a traditional X.509 PKI is required for the foreseeable future. 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 to join the open discussions. Notes and archives are available on the subcommittee's home page.

Observations

In general, a PKI provides flexibility when an end-entity certificate (which in our case is the metadata signing certificate) is re-keyed. Another advantage is that an end-entity certificate can be revoked without much reconfiguration (provided end users are doing revocation correctly). However, reconfiguration headaches will occur when the PKI's root certificate expires or otherwise needs to be replaced.

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 certificate being evaluated is trusted and currently valid. In practice, the only case for real-time certificate validation is software intentionally pulling MD live.

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.  Online Certificate Status Protocol (OCSP) is also redundant, relying on a third party lookup, which is equivalent to real-time validation of entity lookups with minimal time caching. The OCSP response is very brittle due to expiration date, which is not the case with cache duration in SAML.

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 certificate, migration and reconfiguration issues will exist for all SimpleSAML users. This has been the case every time we renewed the signing certificate (every two years), so this represents no significant increase in the rate of reconfiguration (current signing certificate 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 metadata validation. We can remind participants if they are relying on the CA today, they're relying on security patterns that are no longer relevant.

If, in the future, a CA is needed, we can resign the signing certificate at that time, or wrap a PKI around a self-signed certificate. There are known examples of this. For example, eduGAIN uses a self-signed certificate for online metadata signing.

Lifetime of the Current Signing Key & Its Certificate

We 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. For our signing key, the amount adds up to at most 5 signings per week for XX years for the current key. Second, an attack might exist that relies on sheer computational power. Someone may have theoretically been applying resources over the key's lifetime 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.

If we no longer need the CA, we should wrap the signing key in a self-signed certificate to avoid confusion.  This begs the question of choosing an expiry date for the signing /certificate/. Discussions achieved consensus that the evaluation of a key's security is always an ongoing issue. If a vulnerability is discovered we will take immediate action. A signing certificate's lifetime does not mean we won't have to take action sooner if key strength becomes an issue under then-current technology developments. Revocation strategy is critical, and InCommon will need to detail metadata signing key practices in a new document. Given this, we do not expect to make a determination that affects the lifetime of the key anytime soon. Technology developments will affect the strength in the future, so the recommendation is that our signing certificate expire prior to January 2038 (approximately 8900 days, or 24 years). At some point, we may wish to generate an additional signing certificate with an expiration beyond this date for anyone who wants to test the Year 2038 problem.

Recommendations

1. Retire the old self-signed InCommon CA and all associated public-key infrastructure. This is a CA independent from the current InCommon Certificate Service.
2. Create a new policy document to replace the CP/CPS that describes security practices for the protection of the signing key, particularly revocation practices.
3. For the foreseeable future, continue using the current signing key to sign metadata.
4. Replace the current signing certificate with a long-lived, self-signed certificate using the same key pair. The recommended certificate expiration date is 18 December 2037 (to avoid the so-called Year 2038 Problem in January).
5. Users of SimpleSAMLphp will have a problem since the new signing certificate will have a different fingerprint. We will contact the SSP developers as well as communicate the migration plan clearly to participants.
6. Communicate with known users of non-standard deployments and implementations. Of particular note are those who use unsupported software: NSF, NIH, and possibly those using ADFS. This is communication, not support. See InCommon Software Guidelines, which is under the advisement of the TAC.
7. A completely separate issue was also discussed: Expired certificates previously issued by the old InCommon CA still exist in participant metadata. The subcommittee recommend a separate communication about these old certificates, after the initial communication regarding the transition to a self-signed signing certificate has occurred. This has nothing to do with signing key; however, it is related in a distant way to the dismantling of the old InCommon CA, which is no longer in use.