Upcoming CT Log Removal: Izenpe
509 views
Skip to first unread message
Ryan Sleevi
May 18, 2016, 12:24:01 PM5/18/16
to ct-p...@chromium.org
As part of our ongoing maintenance and monitoring of the Certificate Transparency logs included in Chrome, we have determined that the Izenpe Log, https://ct.izenpe.com, has presented two conflicting views of the Merkle Tree at different times. While this was caused by reusing the key between a production instance and a testing instance of the CT log, presenting a consistent view of the tree is a critical security requirement for CT logs.
Because of this, the current Izenpe Log will no longer be a qualified log, effective 30 May 2016. No SCT from the current Izenpe 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 embedded within certificates issued prior to 30 May 2016 will continue to count as once or currently qualified, but certificates issued on-or-after 30 May 2016 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 Izenpe Log, that complied with the Certificate Transparency policy will continue to do so. While SCTs from the Izenpe Log will not be considered as being from a log qualified at the time of check, the presence of the 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 Izenpe 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 30 May 2016, 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 by 30 May 2016, which replace the Izenpe 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.
If you are embedding SCTs in your certificates, SCTs from the Izenpe Log for newly issued certificates will not count towards the minimum requirements after 30 May 2016, 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 Izenpe Log will be ignored.
Because of this, the current Izenpe Log will no longer be a qualified log, effective 30 May 2016. No SCT from the current Izenpe 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 embedded within certificates issued prior to 30 May 2016 will continue to count as once or currently qualified, but certificates issued on-or-after 30 May 2016 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 Izenpe Log, that complied with the Certificate Transparency policy will continue to do so. While SCTs from the Izenpe Log will not be considered as being from a log qualified at the time of check, the presence of the 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 Izenpe 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 30 May 2016, 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 by 30 May 2016, which replace the Izenpe 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.
If you are embedding SCTs in your certificates, SCTs from the Izenpe Log for newly issued certificates will not count towards the minimum requirements after 30 May 2016, 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 Izenpe Log will be ignored.
Remo Ronca
May 18, 2016, 1:08:26 PM5/18/16
to Certificate Transparency Policy, rsl...@chromium.org
Hi Ryan,
Can you please elaborate why "past, present or future" (emphasis on past) SCTs will not count towards the requirement unless embedded in certificates issued prior to the cut-off date? Is there a security-based distinction I am missing or can it be attributed to pragmatism?
Kind regards
Remo
Fabrice Gautier
May 18, 2016, 1:29:30 PM5/18/16
to Certificate Transparency Policy, rsl...@chromium.org
-- Fabrice
Ryan Sleevi
May 18, 2016, 1:37:57 PM5/18/16
to Remo Ronca, Certificate Transparency Policy, Ryan Sleevi
On Wed, May 18, 2016 at 10:08 AM, Remo Ronca <office...@gmail.com> wrote:
Hi Ryan,Can you please elaborate why "past, present or future" (emphasis on past) SCTs will not count towards the requirement unless embedded in certificates issued prior to the cut-off date? Is there a security-based distinction I am missing or can it be attributed to pragmatism?
Effectively explained in the "Certificate Transparency in Chrome" policy available at https://www.chromium.org/Home/chromium-security/certificate-transparency
The options are, in essence, "qualified at time of check" and "qualified at time of issuance". Regardless of the SCTs timestamp, or when it was obtained (in the event the timestamp differs), after 30 May 2016, no SCTs from Izenpe will be able to meet the "qualified at time of check" requirement. That only leaves the "qualified at time of issuance" case, and that is only accepted for cases where the SCT is embedded within the certificate (e.g. it was logged as a precertificate)
As deploying SCTs via the TLS extension or via OCSP Stapling is a clear demonstration of the ability to configure SCTs, it is an easy requirement to ensure the SCTs presented are qualified. OCSP Stapled responses can't exceed 10 days, at least from a Baseline Requirements complying CA, and if a server operator is sending via TLS extension, then they can simply update the server configuration with alternative SCTs.
Ryan Sleevi
May 18, 2016, 1:38:44 PM5/18/16
to Fabrice Gautier, Certificate Transparency Policy, Ryan Sleevi
On Wed, May 18, 2016 at 10:29 AM, Fabrice Gautier <fabrice...@gmail.com> wrote:
This is the same response (beside the cut-off date) as for the Certly.io log, is that correct ?
Yup. There were slight wording tweaks to this announcement, based on confusion/concerns from the last announcement, but the actual execution and result are the same.
Fabrice Gautier
May 18, 2016, 2:22:02 PM5/18/16
to Certificate Transparency Policy, fabrice...@gmail.com, rsl...@chromium.org
Not to be too pedantic, but I think you should also specify the cut-off time, and timezone.
If I read the code correctly, the April 15 date for the Certly.io log actually meant April 15th at 00:00 UTC time.
And I assume this means the same here (00:00, UTC time)
Ryan Sleevi
May 18, 2016, 2:44:52 PM5/18/16
to Fabrice Gautier, Certificate Transparency Policy, Ryan Sleevi
On Wed, May 18, 2016 at 11:22 AM, Fabrice Gautier <fabrice...@gmail.com> wrote:
Not to be too pedantic, but I think you should also specify the cut-off time, and timezone.If I read the code correctly, the April 15 date for the Certly.io log actually meant April 15th at 00:00 UTC time.And I assume this means the same here (00:00, UTC time)
Pedantry welcome :)
Yes, that's correct, and future notices (although hopefully there won't be) will also specify that.
Reply all
Reply to author
Forward
0 new messages