Upcoming CT Log Removal: Certly.IO

[Ryan Sleevi]

As part of our ongoing maintenance and monitoring of the Certificate Transparency logs included in Chrome, we have determined that the Certly.IO Log, https://log.certly.io, has been having ongoing issues and is no longer measured at 99% uptime. As the Chromium Certificate Transparency Log Policy states, 99% uptime is part of the initial and ongoing requirements that Log Operators are expected to abide by.

Because of this, the Certly.IO Log will be no longer be a qualified log, effective 15 April 2016. While SCTs from Certly.IO may continue to be included after that point, they will not count towards the requirement of one non-Google log, and if embedded in certificates after that point, they will not count towards the minimum number of SCTs required. All SCTs from Certly.IO, past, present, and future will not count towards the requirement that at least one SCT is from a valid log at time of evaluation.

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 Certly.IO, will count towards the quorum requirement. While they will not count towards validity, which requires at least one valid SCT be served, the presence of the Google logs within the quorum set 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 qualifying. 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 quorum is met.

If you are delivering SCTs via a TLS extension, SCTs issued by Certly.IO will not count towards the non-Google Log requirement. As such, you must begin to serve SCTs from a different, non-Google log by 15 April 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 15 April 2016, which replace the Certly.IO 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 Certly.IO for newly issued certificates will not count towards the minimum requirements after 15 April 2016, either in the number of SCTs or as a non-Google operated log. You must provide SCTs from a diverse set of logs which are qualified at the time of issuance. SCTs from Certly.IO will be ignored.

[Fabrice Gautier]

Does this removal means we can expect the log list schema and log list
(published at http://www.certificate-transparency.org/known-logs) to
be updated to included a "disqualified on" date ?


-- Fabrice

> --
> 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 post to this group, send email to ct-p...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/7c2de7f6-7c58-44db-9e9b-788af4580600%40chromium.org.

[Ryan Sleevi]

I haven't the slightest. You would need to ask the operators of that page. I can only speak for Chromium.

[Fabrice Gautier]

Ah, I was under the impression that that list - being signed by Google
- was the "official" reference.

Is there another list I'm missing, or is the chromium source code the
official reference ?

-- Fabrice

[Ryan Sleevi]

On Apr 4, 2016 11:10 AM, "Fabrice Gautier" <fabrice...@gmail.com> wrote:
>
> Ah, I was under the impression that that list - being signed by Google
> - was the "official" reference.
>
> Is there another list I'm missing, or is the chromium source code the
> official reference ?
>

The official reference is the source (and this is clarified on the Chromium CT page that includes the policies)

The bits on certificate-transparency.org is maintained by a team at Google, but it is not the canonical source. For example, it includes information about logs not trusted by Chromium and various other aspects of the CT ecosystem.

If it helps, as Mozilla and Apple continue implement support for CT (both have partial implementations), you can imagine that the certificate-transparency.org site will include information relevant to their operations as well, but the canonical source of truth for Chromium will remain Chromium source.

Does that help clear it up?

[Ryan M Hurst]

Fabrice,

First, thanks for bring this up. 

This page is maintained by the Certificate Transparency team who is responsible for the CT infrastructure itself, we view and operate this infrastructure independently from Chrome as we see CT as being something that is applicable to many UAs and scenarios.

With that said, this is the right list for any discussions relating to this.

As for your specific request, yes we intend to add this field to the JSON schema, and once we have a plan for that we will communicate it here.

Ryan Hurst

- Google, Certificate Transparency Team

[Ryan Sleevi]

On Mon, Apr 4, 2016 at 11:31 AM, Ryan M Hurst <r...@google.com> wrote:

With that said, this is the right list for any discussions relating to this.

Hi Ryan,

Slight correction - the ct-policy@ list is only for policies related to Chrome/Chromium. This is explained in https://www.chromium.org/Home/chromium-security/certificate-transparency and the group description.

As captured on http://www.certificate-transparency.org/mailing-lists , I believe the correct list for your site is https://groups.google.com/forum/#!forum/certificate-transparency 

[Ryan Hurst]

Agreed, that would be a clearer separation which would help.

Ryan

[Richard Salz]

And while we're at it, could one of you change your name?

--
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 post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAKexNNNwa21-rQ7TQ8NXouog59h5HKdn3af3kc0DMXe9CguAMA%40mail.gmail.com.

[Ryan Hurst]

I believe I called dibs to it ;)

I'll sign my mails rmh from now on though.

- rmh

[Fabrice Gautier]

On Mon, Apr 4, 2016 at 11:39 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>

> On Mon, Apr 4, 2016 at 11:31 AM, Ryan M Hurst <r...@google.com> wrote:
>>
>> With that said, this is the right list for any discussions relating to
>> this.
>
>
> Hi Ryan,
>
> Slight correction - the ct-policy@ list is only for policies related to
> Chrome/Chromium. This is explained in
> https://www.chromium.org/Home/chromium-security/certificate-transparency and
> the group description.

Ah, that URL is the one that I was missing.

> As captured on http://www.certificate-transparency.org/mailing-lists , I
> believe the correct list for your site is
> https://groups.google.com/forum/#!forum/certificate-transparency

I think the certificate-transparency.org site might benefit of
clarifying their mission, that they are different from the Chromium
team, and referencing the actual chromium docs about CT where
appropriate.

> --
> 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 post to this group, send email to ct-p...@chromium.org.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvaLO1EmXyGH79unbZGJCC5N%3D0DcCbJyWYmcJQbgPE6fjw%40mail.gmail.com.

[Ryan Hurst]

Fabrice,

Also good feedback, we intend to update the site and this should address that concern.

Ryan

[Eran Messeri]

Ryan, can you please clarify regarding the removal date, April 15th:

Is the intention that SCTs from Certly's log with timestamp past April 15th not be accepted anymore? What's the latest time Certly's log can issue SCTs (that would be accepted by Chrome)?

--

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 post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/7c2de7f6-7c58-44db-9e9b-788af4580600%40chromium.org.

[Ryan Sleevi]

On Fri, Apr 8, 2016 at 6:10 AM, Eran Messeri <er...@chromium.org> wrote:

Ryan, can you please clarify regarding the removal date, April 15th:

Is the intention that SCTs from Certly's log with timestamp past April 15th not be accepted anymore? What's the latest time Certly's log can issue SCTs (that would be accepted by Chrome)?

You're asking the wrong question, but I appreciate the chance to clarify :)

As per the policy, regardless of when the SCTs were issued, if, on or after April 15, the SCTs are delivered in OCSP responses or included in the TLS extension, they will not be accepted. That is because, as per the CT policy, the log will not be qualified at the time of TLS handshake. That is, they will not count towards the "two SCT minimum" or "One Google and one non-Google" requirements for these methods.

As per the policy, if the log is qualified at the time of issuance (e.g. as it is, up until April 15), it will count towards the diversity requirement if, and only if, delivered via a precertificate. However, on or after April 15, all SCTs from Certly.io will no longer count as qualified - that is, a certificate MUST include at least ONE SCT from a qualified log at the time of the TLS handshake.

So:

1) By April 15, all SCTs - past or present - will no longer be accepted as qualified if from Certly.io

2) All SCTs issued before April 15 will count towards the log diversity requirement (one Google log, one non-Google log) if, and only if, delivered via a precertificate.

[Eran Messeri]

Thanks, that's what I was looking for a clarification on (even though my question wasn't phrased correctly :)).

That implies we can grab a Signed Tree Head from Certly's log on the 15th to indicate the timestamp after which SCTs no longer count towards the log diversity requirement and after which there's no point in auditing that particular log, IIUC (i.e. no point in auditing SCTs issued after that date, but SCTs issued before that date should be audited like any other SCTs from known logs). 

[Ryan Sleevi]

On Mon, Apr 11, 2016 at 8:59 AM, Eran Messeri <er...@google.com> wrote:

Thanks, that's what I was looking for a clarification on (even though my question wasn't phrased correctly :)).

That implies we can grab a Signed Tree Head from Certly's log on the 15th to indicate the timestamp after which SCTs no longer count towards the log diversity requirement and after which there's no point in auditing that particular log, IIUC (i.e. no point in auditing SCTs issued after that date, but SCTs issued before that date should be audited like any other SCTs from known logs).

I'm not sure why you would necessarily audit SCTs issued before that date; the SCTs will not be trusted, simply counted for diversity, and the presence of other SCTs from other logs provides the assurance that the certificate was appropriately logged and disclosed, and that disclosure is publicly available.

So I don't believe you should need to do what you described. 

[Eran Messeri]

(Warning: Theoretical discussion below. Has no real security implications for Chrome users, as far as I can tell.).

My assumption is that we audit CT logs to detect logs that misbehave by issuing SCTs but not incorporating the certificate into the tree.

The reason for auditing "frozen" logs is to find out if, before they were frozen, they issued any SCTs for certificates that were not incorporated into the tree.

If a frozen log was found to misbehave in that way, one could argue that the sensible course of action is to completely distrust the log, except for a whitelist of precertificates extracted from this log (which we are confident are public because we could extract them).

However, the reason I believe it has no security implications for Chrome users as SCTs from other logs (in addition to Certly's log) are needed and it is enough that one of the SCTs could be audited for the client to be (mostly*) confident the certificate is public.

* - mostly confident because the client could still be presented with a split view of the log, but that attack is much harder to mount, especially when Signed Tree Heads are distributed to Chrome clients centrally.

 

[Ryan Sleevi]

On Mon, Apr 11, 2016 at 1:05 PM, Eran Messeri <er...@chromium.org> wrote:

On Mon, Apr 11, 2016 at 8:45 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Mon, Apr 11, 2016 at 8:59 AM, Eran Messeri <er...@google.com> wrote:

Thanks, that's what I was looking for a clarification on (even though my question wasn't phrased correctly :)).

That implies we can grab a Signed Tree Head from Certly's log on the 15th to indicate the timestamp after which SCTs no longer count towards the log diversity requirement and after which there's no point in auditing that particular log, IIUC (i.e. no point in auditing SCTs issued after that date, but SCTs issued before that date should be audited like any other SCTs from known logs).

I'm not sure why you would necessarily audit SCTs issued before that date; the SCTs will not be trusted, simply counted for diversity, and the presence of other SCTs from other logs provides the assurance that the certificate was appropriately logged and disclosed, and that disclosure is publicly available.

So I don't believe you should need to do what you described.

(Warning: Theoretical discussion below. Has no real security implications for Chrome users, as far as I can tell.).

My assumption is that we audit CT logs to detect logs that misbehave by issuing SCTs but not incorporating the certificate into the tree.

The reason for auditing "frozen" logs is to find out if, before they were frozen, they issued any SCTs for certificates that were not incorporated into the tree.

If a frozen log was found to misbehave in that way, one could argue that the sensible course of action is to completely distrust the log, except for a whitelist of precertificates extracted from this log (which we are confident are public because we could extract them).

However, the reason I believe it has no security implications for Chrome users as SCTs from other logs (in addition to Certly's log) are needed and it is enough that one of the SCTs could be audited for the client to be (mostly*) confident the certificate is public.

Arguably, only SCTs from logs that are trusted should be audited by clients.

 

* - mostly confident because the client could still be presented with a split view of the log, but that attack is much harder to mount, especially when Signed Tree Heads are distributed to Chrome clients centrally.

This theoretical attack is only relevant if some solution other than "Don't accept these certificates" was to be accepted or expected, in the event that all of the logs included in a precertificate failed.

I don't believe that's been stated, or necessarily desired. That seems more an aspect of providing mirroring capabilities for logs and historical accuracy, which is useful for monitors/auditors after the fact.

[Fabrice Gautier]

On Monday, April 4, 2016 at 11:28:11 AM UTC-7, Ryan Sleevi wrote:

On Apr 4, 2016 11:10 AM, "Fabrice Gautier" <fabrice...@gmail.com> wrote:
>
> Ah, I was under the impression that that list - being signed by Google
> - was the "official" reference.
>
> Is there another list I'm missing, or is the chromium source code the
> official reference ?
>

The official reference is the source (and this is clarified on the Chromium CT page that includes the policies)

Note that the link to the source code on that page (https://www.chromium.org/Home/chromium-security/certificate-transparency) is broken right now.

[Ryan Sleevi]

On Mon, Apr 18, 2016 at 3:26 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

On Monday, April 4, 2016 at 11:28:11 AM UTC-7, Ryan Sleevi wrote:

On Apr 4, 2016 11:10 AM, "Fabrice Gautier" <fabrice...@gmail.com> wrote:
>
> Ah, I was under the impression that that list - being signed by Google
> - was the "official" reference.
>
> Is there another list I'm missing, or is the chromium source code the
> official reference ?
>

The official reference is the source (and this is clarified on the Chromium CT page that includes the policies)

Note that the link to the source code on that page (https://www.chromium.org/Home/chromium-security/certificate-transparency) is broken right now.

Thank you for the reminder. I moved that file Friday and forgot to update the link.