Retiring DigiCert Nessie2024 Log in Chrome
Carlos Joan Rafael Ibarra Lopez
On May 9, 2023, an issue was detected in the DigiCert Nessie2024 log, which was reported to ct-policy@ by Andrew Ayer. A bit flip in entry 65051339 (get-entries call) caused the SubjectPublicKeyInfo field in the tbs_certificate field of the MerkleTreeLeaf to not match the PreCertificate for that entry.
Since altering the MerkleTreeLeaf would result in a tree head that doesn’t match existing signed STHs, this issue is non-recoverable, and we unfortunately have to retire this log.
Effective May 30 2023, the Digicert Nessie2024 Log (https://nessie2024.ct.digicert.com/log/") will transition to Retired, with the last ‘Qualified’ SCT having a timestamp no later than 1685404800, or 2023-05-30T00:00:00Z in ISO 8601 format.
After May 30 2023, SCTs from Nessie2024 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 2023-05-30T00:00:00Z.
Embedded SCTs dated prior to 2023-05-30T00: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 these logs that complied with the Chrome CT Policy will continue to do so.
If you are currently serving SCTs via stapled OCSP, then your CA must take appropriate action to update their OCSP pipeline to ensure they are embedding a policy-satisfying set of SCTs. Once done, you must refresh the OCSP response stapled to the connections. 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 these logs will no longer contribute towards CT Compliance. As such, you will need to update the SCTs included in the handshake to comply with the Chrome CT Policy in order to satisfy the requirements for SCTs delivered via TLS.
What does this mean for CAs?
If you are embedding SCTs in your certificates, SCTs from these logs 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. To ensure that newly-issued certificates will be CT-compliant, you should update your CA’s CT log configuration to remove these logs while also ensuring that you are still logging to a policy-satisfying set of CT logs after the removal.
While it is not required by policy, CAs with existing certificates embedding SCTs from these logs may wish to proactively reissue affected certificates to increase the resilience of these certificates to possible future log incidents.
Finally, if you are embedding SCTs from these logs in your OCSP responses, you must issue new OCSP responses that replace these SCTs with new ones from a set of CT logs that satisfies the Chrome’s CT Policy. Your customers must then begin to serve these new responses or provide a policy-satisfying set of SCTs via another mechanism before the effective date above.
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.
Seo Suchan
Andrew Ayer
Seo Suchan <tjt...@gmail.com> wrote:
> Isn't this second time DigiCert had bit filp in their logs? I don't
> think there was other log with this kind of bitflip cause log retire-
> is this because people doesn't check other logs or system used by
> digicert is more prone to bitwise corruption? (filesystem?)
pending, qualified, or usable in Chrome or Apple.
Note that my monitor only checks log entries once, shortly after they
are published. If a bitflip occurs later, my monitor will not detect it.
It might be illuminating to scan the entirety of every log to see if
any bit flips have since occurred, to see if any particular log or log
operator is more prone to corruption. (If any such corruption were
detected, it would be recoverable since the Merkle Tree would have
already incorporated the correct data.) Does anyone know of existing
efforts or software to do this?
Regards,
Andrew