Retiring TrustAsia Log2020 and Log2021
Devon O'Brien
Hello ct-policy@,
As was reported in a thread to this forum earlier this month, two of TrustAsia’s newly-Qualified CT Logs have produced inconsistent STHs, which means we will need to Retire the affected Logs. A detailed description of this incident and the follow-up investigation by TrustAsia can be found here. We welcome TrustAsia to replace the 2021 Log (since by the time new Logs could be added, it would be past 2020), and there will be no changes to the 2022 and 2023 Logs since they were unaffected. Since the affected Logs had not yet progressed to Usable, we expect there to be minimal impact from this change; however, we’re including our usual information and disclaimers below:
Effective 12/01/2020, the following Log(s) will transition to Retired, with the last ‘Qualified’ SCT having a timestamp no later than 1606780800, or 2020-12-01T00:00:00+00:00 in ISO 8601 format:
Trust Asia Log2020 (https://ct.trustasia.com/log2020/)
Trust Asia Log2021 (https://ct.trustasia.com/log2021/)
No SCT from these Logs - 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 that are dated prior to 2020-12-01T00:00:00+00:00 and embedded within existing will continue to count as once or currently Qualified, but certificates issued on-or-after 2020-12-01T00:00:00+00:00 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 these Logs, that complied with the Certificate Transparency policy will continue to do so. While SCTs from these Logs will not be considered as being from a Log Qualified at the time of check, the presence of SCTs from 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 these Logs 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/01/2020, in order to satisfy the CT requirements.
What does this mean for CAs
If you are embedding SCTs in your certificates, SCTs from these Logs for newly issued certificates will not count towards the minimum requirements after 12/01/2020, 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 these Logs will be ignored.
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.
If you are embedding SCTs from these Logs in your OCSP response, you must issue new OCSP responses before 12/01/2020, which replace these 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.
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.
Jerry Hou
We resubmitted TrustAsia CT 2021 log service (https://bugs.chromium.org/p/monorail/issues/detail?id=8827), but marked as spam, where else can we submit?
Rob Stradling
Sent: 29 December 2020 09:08
To: Certificate Transparency Policy <ct-p...@chromium.org>
Cc: Devon O'Brien <asymm...@chromium.org>
Subject: [ct-policy] Re: Retiring TrustAsia Log2020 and Log2021
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/d8822116-4a66-4223-9be0-209478490ec0n%40chromium.org.