On Thursday, September 8, 2016 at 4:09:25 AM UTC-7, Rob Stradling wrote: > > 1. Enforce CT only after a certain date, after which WoSign will need > > to embed qualified SCTs. This check can be bypassed if the CA > > backdates certificates (which is problematic, given the history of > > backdating certificates in this particular case.) > > AIUI, Chrome doesn't currently consider the difference between the > certificate's notBefore date and the corresponding SCTs' timestamps when > evaluating whether or not the certificate is "CT qualified". > > To guard against backdating, ISTM that future versions of Chrome (and > hopefully Firefox too) could require, for certain CAs, that: > 1. The certificate MUST be "CT qualified". > and > 2. In addition to the standard requirements for being "CT qualified", > the SCT timestamps MUST be within N seconds of the certificate's > notBefore date.
Without wanting to derail this thread with discussions of Chrome's CT implementations, to the point it's relevant to a Firefox implementation, this is something better as part of the monitoring ecosystem (and with a CA/B Forum Guideline) than as a client enforcement. For pre-certificates: The earliest (trusted) SCT represents a reasonable lower-bound of the issuance date, for purposes of policy. That is, for certificates issued with embedded SCTs, any policy controls can be applied on the basis of the embedded SCT, if present. However, for SCTs delivered via OCSP or TLS extensions, there is zero relationship between the notBefore and any SCTs. This is because the set of SCTs delivered with a certificate - or the logs in which a certificate is logged - may change over a certificate's lifetime, as part of the normal operation of trusting and distrusting logs. Consider a hypothetical situation, possible today, in which a certificate is logged to two logs (Google Pilot and DigiCert). These are the only logs the certificate is logged in, and the cert is logged within a few hours of issuance, and SCTs delivered via OCSP. Now, let's imagine that the Pilot log is distrusted one year into the cert's 3 year lifetime. In order to comply with Chrome's policy (and what Chrome believes is a good guideline for other UAs, at least at present), the cert would need to be logged to Google's Aviator or Rocketeer logs, which have as-of-yet never seen the certificate. When the CA does so, the SCT will be issued at least 1y > the cert's notBefore, and then embedded in the OCSP response (such that the new set is Aviator, DigiCert). Now, imagine that 2y into the cert's lifetime, DigiCert's log is distrusted, and so the cert is then logged to Symantec's log. Now, the SCT set is Aviator, Symantec, and the SCTs are respectively 1y and 2y newer than the cer t. This is not proof of backdating. While the above example is, arguably, convoluted, and ignores the ways in which a log may and has been distrusted (e.g. 'freezing' a log at a particular timestamp, as has been done so far for the operational failures that have caused log distrust), it's meant to highlight that the assumption and design of CT don't require a relationship between the notBefore and the SCT validity period of the date. Obviously, for pre-certificates, the act of backdating can be trivially detected, since it's cryptographically guaranteed that the cert cannot have been issued earlier than the latest SCT embedded within it (assuming the log's clock is functioning correctly), but this doesn't apply to other SCT delivery mechanisms, and this is arguably by design. Among other reasons, I believe this is why the client complexity is not worth it, but that this can and should be addressed through a combination of explicit policy actions (within Mozilla policy) and within the Baseline Requirements, and there are many ways in which we can further an auditable criteria to ensure this, and in a programatically detectable way, without foisting this upon clients to enforce. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
