Date: Thu, 28 Mar 2024 13:05:28 +0000 (UTC) Message-ID: <1727539361.6439.1711631128130@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6438_1995437037.1711631128130" ------=_Part_6438_1995437037.1711631128130 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Terminology
The InCommon metadata signing certificate is signed by a CA whose certif= icate 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 fut= ure. With this goal in mind, this subcommittee offers the following observa= tions, recommendations and guidance to InCommon's Technical Advisory Commit= tee and InCommon Operations.
The discussions documented here occurred over a series of weekly phone c= alls with email discussion on the md-distro@incommon.org email list. Member= s of the InCommon participant community were invited to join these open dis= cussions. Notes and archives are available on the subcommittee's home page.
In general, a PKI provides flexibility when an end-entity certificate (w= hich in our case is the metadata signing certificate) is re-keyed. Another = advantage is that an end-entity certificate can be revoked without much rec= onfiguration (provided end users are doing revocation correctly). However, = reconfiguration headaches will occur when the PKI's root certificate expire= s or otherwise needs to be replaced.
Furthermore, even in a full-blown PKI, the root of a trust path does not= have to be a CA. Path validation and trust in the path is what is importan= t. The goal is that the certificate being evaluated is trusted and currentl= y valid. In practice, the only case for real-time certificate validation is= software intentionally pulling live metadata.
The discussion continued, dividing the analysis into two use cases: is t= here any value in rooting a metadata signing certificate in (1) an online o= r (2) an offline CA?
It was also noted that relying on Certificate Revocation Lists (CRLs) ex= tends the vulnerability window in relation to a given signed metadata aggre= gate's expiry date. The Online Certificate Status Protocol (OCSP) is also r= edundant, 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 du= ration in SAML.
Although there may be reason to further explore online signing and there= fore related security measures of online signing keys (e.g., hardware secur= ity modules), the group found no compelling reason for a traditional CA, so= long as adequate practice for and documentation of the protection of the s= igning key is provided.
We can't be 100% certain that no one is relying on the current CA. Howev= er, there is no practical reason or known deployment to make us think this = is true. What might break if we adjust current infrastructure?
1. SimpleSAMLphp deployments rely on the fingerprint of the signing cert= ificate (rather than the key itself). So if we decide to resign the signing= certificate, migration and reconfiguration issues will exist for all simpl= eSAMLphp users. This was the case every time we renewed the signing certifi= cate (every two years), so this represents no significant increase in the r= ate of reconfiguration (since the current signing certificate expires 2&nbs= p;May 2014 and needs to be resigned anyway).
2. There are few non-standard deployments that we know of. This is proba= bly low risk with the exception of, for instance, government agencies relyi= ng on CA SiteMinder. We also need to explore the limitations of ADFS.
This raises an opportunity to be more explicit in our documentation rega= rding expectations with respect to metadata validation. We can remind parti= cipants if they are relying on the CA today, they're relying on security pa= tterns 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 kn= own examples of this. For example, eduGAIN uses a self-signed certificate f= or online metadata signing.
We discussed whether the current 2048-bit metadata signing key needs to = be replaced. The question is: What would restricting the lifetime of the si= gning key prevent? Two vectors of attack were discussed. First, there might= be an attack that relies on having large amounts of cypher text available = for analysis. The more cypher text available, the greater the vulnerability= . However, there are no known attacks of this type for RSA 2048-bit keys, a= nd in our case the volume of cypher text is relatively small (compared to, = say, an IdP that is constantly exercising its signing key). Second, an atta= ck might exist that relies on sheer computational power, that is, an attack= er may have theoretically been applying resources over the key's lifetime t= o compute the value of the private key. We found no evidence to suggest tha= t 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 s= hould wrap the public key 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 con= cern. If a key vulnerability were discovered some time in the future, we wo= uld of course take immediate action. Thus the logical conclusion is that th= e 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 res= igned unnecessarily.
Given that, it is recommended that all self-signed certificates be set t= o expire prior to January 2038 to avoid the so-called Year 2038 Pro= blem. 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 u= nderstood revocation strategy.