Upcoming CT Log Removal: StartCom
Devon O'Brien
On December 12, 2017, it was reported to ct-policy that StartCom had failed to incorporate numerous SCTs into the Log’s merkle tree within 24 hours, with some still not present at time of reporting. Moreover, there appeared to be a set of precertificates corresponding to unincorporated SCTs that were logged again months after the original SCT was created, suggesting a retroactive effort to log these certificates. There was no disclosure of these failures by StartCom either when the MMD was violated or when the precertificate was relogged (thus producing a different SCT).
Each of these unincorporated SCTs violates the Maximum Merge Delay requirement as specified in Chromium’s CT Log Policy. In the period of time following this report, StartCom acknowledged these incidents but has failed to provide an Incident Report regarding this matter and, moreover, has not confirmed that the root cause of this pattern of non-compliant behavior has been identified and rectified.
While we acknowledge that StartCom blocking the Log’s add-chain and add-pre-chain APIs would ensure no new issuance of unincorporated SCTs, we will be taking further steps to disqualify this Log within Chromium according to the previous proposal on this thread.
The StartCom Log (https://ct.startssl.com) will no longer be a qualified Log, effective 12 February, 2018, with the last ‘qualified’ SCT having a timestamp no later than 1518479999, or 2018-02-12T23:59:59+00:00 in ISO 8601 format.
No SCT from the StartCom Log - past, present or future - will count towards the requirement that at least one SCT is qualified at time of check and, as such, will not be appropriate for inclusion within the TLS extension or embedded within a stapled OCSP response. SCTs whose timestamp is less than or equal to 1518479999 and are embedded within existing will continue to count as ‘once or currently qualified’, but certificates issued after that point will need to ensure that there are a sufficient number of SCTs from Logs which are qualified or pending qualification at time of issuance.
What does this mean for site operators
If you are delivering SCTs embedded in the certificate, this should require no action on your part. All certificates previously issued, and which contain SCTs issued by the StartCom Log, that complied with the Certificate Transparency policy will continue to do so. While SCTs from the StartCom Log will not be considered as being from a Log qualified at the time of check, the presence of qualified Google Logs in the certificate will ensure there is no disruption. If you refresh or renew your certificate, your CA should be including sufficient and diverse SCTs from other Logs that it should require no action on your part.
If you are delivering SCTs embedded in the OCSP response, via OCSP stapling, then your CA must take appropriate action to update their OCSP pipeline to include at least one SCT from a non-Google operated Log that is qualified at time of check. Once done, you must refresh the OCSP response stapled to the connection. Alternatively, you may also enable the TLS extension mechanism to deliver additional SCTs from non-Google operated Logs, in order to ensure that at least one SCT from a non-Google Log, qualified at time of check, is presented.
If you are delivering SCTs via a TLS extension, SCTs issued by the StartCom Log will not be considered qualified at the time of check. As such, you must begin to serve SCTs from a different, non-Google Log by 12 February, 2018 in order to satisfy the CT requirements.
What does this mean for CAs
If you are embedding SCTs in your OCSP response, you must issue new OCSP responses before 12 February, 2018, which replace the StartCom Log SCTs with SCTs issued from another non-Google Log. Your customers must then begin to serve this new response. Alternatively, your customers must include SCTs delivered via the TLS extension until you are able to update the SCTs included in your responses.
If you are embedding SCTs in your certificates, SCTs from the StartCom Log for newly issued certificates will not count towards the minimum requirements after 12 February, 2018, either in the number of SCTs from Logs once or currently qualified or as a non-Google Log. You must provide SCTs from a diverse set of Logs which are qualified at the time of issuance. SCTs from the StartCom Log will be ignored.