Upcoming CT Log Removal: WoSign
Devon O'Brien
On December 15, 2017, it was reported to ct-policy that WoSign Log had failed to incorporate a SCT into the Log’s merkle tree over a year after issuance. Subsequent investigation revealed that there were at least 18 known unincorporated SCTs as of December, 2017. Each of these instances is a violation of the Maximum Merge Delay requirement as specified in Chromium’s CT Log Policy.
The response from WoTrus, the new name of the Log’s Operator, was lacking both sufficient detail to pinpoint the scope and nature of these failures as well as assurances that sufficient action has been taken to prevent such a failure in the future. Due to this repeated pattern of policy violation, we will be taking steps to disqualify this Log within Chromium.
The WoSign Log (https://ctlog.wosign.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 WoSign 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 WoSign Log, that complied with the Certificate Transparency policy will continue to do so. While SCTs from the WoSign 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 WoSign 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 which replace the WoSign Log SCTs with SCTs issued from another non-Google Log no later than 12 February, 2018 but are encouraged to make this change immediately. 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 WoSign 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 WoSign Log will be ignored.
Tom Ritter
> 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 WoSign Log, that complied with the Certificate
> Transparency policy will continue to do so. While SCTs from the WoSign 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 WoSign
> 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.
Extension; this might be too much to ask BUT it would be really nifty
if Google (maybe teaming up with SSLLabs?) would enable me to scan my
site and tell me if my configuration is good or will become not-good
in the future or something similar. =)
-tom