As a continuing part of improving compliance monitoring of the CT Ecosystem, Google has been investigating the presentation of SCTs by servers and certificates and whether or not they are incorporated within the Log, as required.
During this investigation, a pattern of incidents has been discovered with the StartCom Log ( https://bugs.chromium.org/p/chromium/issues/detail?id=611672
) that show a sustained pattern of non-compliant behaviour. We understand this pattern has also recently been observed by other participants in the CT ecosystem.
Some certificates have never been included in the log, while others have appeared within a tree head substantially later than permitted. Both are violations of the MMD property, but are both concerning.
We'd greatly appreciate the thoughtful feedback from the community regarding this incident.
Our proposed steps are as follows:
- StartCom to provide an Incident Report regarding this matter, including both the underlying cause, why StartCom fails to proactively detect it from their own systems monitoring, and any facts surrounding the SCT for https://crt.sh/?id=84153049
and its substantial delay in inclusion
- Freeze (Disqualify) the log on [a date to be determined].
- Any SCTs issued on or after that date will not count towards "qualified at time of certificate issuance" or "qualified at time of check"
- Any SCTs issued prior to that will count as "once qualified" (disqualified prior to check)
As noted, we welcome feedback on this proposal, and look to draw discussion on the proposed next steps to a conclusion within the next few days, to provide greater clarity to the ecosystem as to what actions are required. We hope others will take the opportunity to verify our data, as well as share any additional information they may find relevant to such discussions.
From an impact to end users:
- The requirement of multiple SCTs ensures that such certificates have been logged in one or more other (non-StartCom) logs. This example underscores the importance of CT redundancy, by ensuring that a single failure does not undermine the transparency requirements or goals. As such, the security of end users has not been undermined by this incident alone.
From an impact to site operators:
- If adopted as proposed, site operators employing the TLS extension will need to obtain SCTs from a different non-Google log to serve on or after [a date to be determined]. SCTs from StartCom's log after that date will no longer be accepted.
From an impact to CAs:
- If embedding SCTs in OCSP responses, CAs will need to obtain SCTs from a different non-Google log to serve on or after [a date to be determined]. SCTs from StartCom's log after that date will no longer be accepted.
- If embedding SCTs in Certificates:
- If the only SCTs included were from Logs that were once qualified, but no SCTS are qualified at time of check, the certificate will no longer be CT Qualified. As a practical matter, this means any certificates which only embedded SCTs from the Google Aviator Log and StartCom log would be affected.
- If at least one SCT is from a log still qualified in Chrome, and the certificate otherwise met the CT Qualified requirement, there will be no change to the CT Qualified status. However, CAs should be aware that if the remaining CT Logs included are all disqualified, that certificate will no longer be CT Qualified.
- CAs should update their systems no later than [a date to be determined] to obtain SCTs from one or more non-Google logs other than the StartCom log, to ensure newly issued certificates meet the requirement that the certificates are qualified at time of issuance.
What are the factors we considered in this proposal:
- In this particular case, what we observe appears to be a sustained practice of 'losing' certs and failing to incorporate them, along with a troubling 'retroactive' logging, without any corresponding incident report or discussion.
- Based on external data provided, which we believe will be shared soon, we believe this incident is still ongoing and unresolved. As such, a corrective step to 'freeze' the log provides mitigation against future risk of undisclosed certificates.
- Unlike some of the other discussions regarding uptime, the MMD failure is accompanied by cryptographic evidence of failure, so there is no ambiguity as to the expectations.
That said, we look forward to StartCom's Incident Report, so that as a collective ecosystem, the situation and facts surrounding this Incident can be used to improve and enhance Logs' implementations, including that of any future log that StartCom may run, which they are welcome to do so.