Retiring DigiCert Yeti2022 Log in Chrome
Devon O'Brien
On 30 June 2021, Google’s CT Log monitoring detected an issue with the DigiCert Yeti2022 Log, which was reported to ct-policy@ by others observing the same issue. The issue was tracked down to a bit flip in a single leaf hash in the CT Log, corresponding to the entry at tree size 65562066 (get-entries call, proof-by-hash call with latest tree head).
Because the bit flip occurred in the leaf hash itself, this unfortunately is a non-recoverable error for this CT Log. Fixing this entry would require generating a SHA-2 preimage for the bit-flipped leaf hash (something currently considered cryptographically infeasible). As long as this CT Log is still in use, this error will interfere with monitoring and auditing due to errors in get-entries calls and consistency proofs spanning this entry. This unfortunately requires that we Retire this CT Log.
I would like to emphasize that there is no evidence that this error is due to the fault of DigiCert as the operator of this CT Log. Bit flips such as this can occur in extremely rare circumstances due to hardware faults or even cosmic rays.
------
Effective July 21, 2021, the following Log(s) will transition to Retired, with the last ‘Qualified’ SCT having a timestamp no later than 1626825600, or 2021-07-21T00:00:00Z in ISO 8601 format:
After July 21, 2021, SCTs from DigiCert Yeti2022 Log will no longer count towards the CT Compliance requirements stating that at least one SCT must come from a CT Log that was Qualified, Usable, or ReadOnly at time of check. As such, after this point, it is no longer appropriate to serve SCTs from this Log in the TLS handshake, in OCSP responses, or embedded in certificates issued on-or-after 2021-07-21T00:00:00Z.
Embedded SCTs dated prior to 2021-07-21T00:00:00Z will still satisfy CT Compliance requirements that permit SCTs to come from CT Logs that are Qualified, Usable, ReadOnly, or Retired at time of check; however, at least one other SCT must come from a non-Retired CT Log in order for the certificate to successfully validate in Chrome.
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 previously-issued certificates containing SCTs from this Log that complied with the Chrome CT Policy will continue to do so.
If you are currently serving SCTs via OCSP, 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, Usable, or ReadOnly. Once done, you must refresh the OCSP response stapled to the connection. Alternatively, you may choose to provide a policy-satisfying set of SCTs via another mechanism outlined in the Chrome CT Policy.
If you are currently delivering SCTs via a TLS extension, SCTs issued by this Log will no longer contribute towards CT Compliance. As such, you must begin to serve SCTs from a separate non-Retired, non-Google Log by July 21, 2021, in order to satisfy the CT requirements for SCTs delivered via TLS.
What does this mean for CAs?
If you are embedding SCTs in your certificates, SCTs from this Log for newly-issued certificates will no longer meet CT Compliance requirements stating that at least one SCT must come from a CT Log that was Qualified, Usable, or ReadOnly at time of check. In order to ensure that newly-issued certificates will be CT-compliant, you should update your CT Log configuration to remove DigiCert Yeti2022 Log while also ensuring that you are still logging a policy-satisfying set of CT Logs after the removal.
While it is not required by policy, CAs with existing certificates embedding SCTs from this Log may wish to proactively reissue affected certificates to increase the resilience of these certificates to possible future Log incidents.
If you are embedding SCTs from this Log in your OCSP responses, you must issue new OCSP responses before July 21, 2021, which replace these SCTs with SCTs issued from another non-Retired, non-Google Log. Your customers must then begin to serve these new responses or provide a policy-satisfying set of SCTs via another mechanism.
What does this mean for Log Operators?
If you are operating a CT Log not listed in the above Retirement announcement, you do not need to take any action.