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 MD metadata signing key certificate is rooted in a self-signed signed by a CA whose root certificate expires in March 2014. The phase 1 phase 1 goal of this subcommittee is to determine if continuing with a PKIX CA may be required in a traditional X.509 PKI is required for the foreseeable future in which to root the MD signing key. This . With this goal in mind, this subcommittee offers the following observations, recommendations and guidance to InCommon's Technical Advisory Committee and InCommon Operations.

The discussions documented here 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 to join these open discussions. Notes and archives are available on the subcommittee's wiki:https://spaces.at.internet2.edu/x/zRBOAg

...

home page.

Observations

In general, having a PKI gives one the ability to not take much of reconfiguration hit when the signing certificate provides flexibility when an end-entity certificate (which in our case is the metadata signing certificate) is re-keyed. InCommon can also revoke the metadata signing key without much reconfigurationAnother advantage is that an end-entity certificate can be revoked without much reconfiguration (provided end users are doing revocation correctly). However, reconfiguration headaches need to will 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 slimcertificate expires or otherwise needs to be replaced.

Furthermore, even in a full-blown PKIX modelPKI, 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 certificate being evaluated is trusted and currently valid. In practice, the only case for real-time cert verification certificate validation is software intentionally pulling MD live, and today Shib is the only candidate that offers the optionlive metadata.

The discussion continued, dividing the analysis into two use cases: is there any value in rooting a metadata (MD) signing key certificate 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 metadata aggregate's expiry date. The Online Certificate Status Protocol (OCSP) is also redundant, relying on a third party lookup, which is equivalent to re

...

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 traditional CA, so long as adequate practice for and documentation of the protection of the signing key is accomplishedprovided.

...

Impact

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

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

2. Non-standard deployments. There are few non-standard deployments that we know of. This may be is probably low risk with the exception of, for instance, government agencies relying on CA site minderSiteMinder. 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 regarding expectations with respect to metadata validation. We can remind participants if they are relying on the PKI that is thereCA today, 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 resign the signing certificate at that time, or simply have the signing key sign itselfwrap a PKI around a self-signed certificate. There are known examples of this. Edugain For example, eduGAIN uses a self-signed cert certificate for MDA online metadata signing.

...

Lifetime of the Signing Key and Signing Certificate

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 signing key prevent? Two vectors of attack were postulateddiscussed. First, there might be an attack which that relies on having large amounts of cypher text available for analysis. The more you generatecypher text available, the more vulnerable you aregreater the vulnerability. However, there are no known attacks of this nature type for RSA 2048-bit keys, and in our case the amount volume 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. relatively small (compared to, say, an IdP that is constantly exercising its signing key). Second, an attack might exist that relies on sheer computational power. Someone , that is, an attacker may have theoretically been applying resources over the XX year period to the public key 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 the lifetime of a 2048-bit key.

With respect to the signing certificate, if we no longer need a CA, we should wrap the public 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

in a self-signed certificate to avoid confusion. This begs the question of how to choose an appropriate expiration date for the signing certificate. In actuality, a certificate's expiration date has nothing to do with the security of the private key, which is an ongoing concern. If a key vulnerability were discovered some time in the future, we would of course take immediate action. Thus the logical conclusion is that the expiration date on the signing certificate should be far into the future, so as to avoid the situation where the signing certificate needs to be resigned unnecessarily.

Given that, it is recommended that all self-signed certificates be set to expire prior to January 2038 to avoid the so-called Year 2038 Problem. At some point, we may wish to generate a signing certificate with an expiration beyond this date for testing purposes.

Note: A self-signed signing certificate requires an effective and well understood revocation strategy.

Recommendations

1. For the foreseeable future, continue using the current signing key to sign metadata.
2. Retire the old InCommon CA (that signed the current signing certificate) and all associated public-key infrastructure. (This CA is not to be confused with the CAs associated with the InCommon Certificate Service.)
3. Replace the current signing certificate with a long-lived, self-signed certificate using the current key pair. The recommended certificate expiration date is 18 December 2037 (to avoid the Year 2038 Problem in January).
4. Create a new policy document (to replace the current CP/CPS) that describes security practices surrounding the metadata signing key, especially the revocation policy and practices associated with the new self-signed signing certificate.
5. It is anticipated that users of simpleSAMLphp will experience issues since the new signing certificate will have a different fingerprint. We will contact the SSP

...

1. developers as well as communicate the migration plan clearly

...

1. to participants.

...

1. Communicate with

...

1. known users of non-standard deployments and implementations. Of

...

1. particular note are those who use unsupported software, such as NSF, NIH, and

...

1. possibly those participants using ADFS. This is communication, not support. See InCommon Software Guidelines, which is under the advisement of the TAC.
2. Expired certificates signed by the old InCommon CA still exist in participant

...

1. metadata. After the initial communication regarding the transition to a self-signed signing certificate has occurred, send a separate communication to participants about expired certificates in metadata. Since the two issues are mostly unrelated, this will avoid confusion.
2. Review the X.509 Certificates in Metadata documentation page (and its child pages) in light of the observations and recommendations in this report.