Does CA have their own CT policy in log selection?

[Susan Ven]

Hi CT Team,
 
I am curious about whether the CA has a CT policy for the log servers it selects for submitting certificates when issuing CT-compliant certificates, including the number, operator, and preference. For example, 1) CA only select the logs pre-installed by the browser (e.g., Chrome and Apple platform)?  or 2) CA just pick some from all valid existing log servers randomly?

 

Could someone please answer this question, as it would clear up some of my confusion?

[Aaron Gable]

Hi Susan,

I'm sure that every CA has their own separate set of practices, so I can't speak for most of them. But Boulder, the software used by Let's Encrypt, is open source, so I can show you exactly the logic used there.

Boulder starts by loading a log list file. This file is in the v3 format, and is generally expected to be identical to the log list published by Chrome. From this list, it then extracts three subsets: logs that we will submit precertificates to in order to get SCTs, logs that we will submit precertificates to on a best-effort basis (i.e. not waiting to get an SCT in reply), and logs that we will submit final certificates to. Each of these subsets is created using two criteria: whether the log is in an appropriate state (e.g. only Usable logs will be selected for SCT submissions), and whether the log's name matches a hand-curated list of logs we want to use for each purpose. Finally, when it comes time to actually submit precertificates to CT logs, it randomizes the order of the operator groups, and then picks one log at random from each operator.

There's a little bit of additional magic in there, but that's the core logic. So I think to address your questions directly:

- Let's Encrypt submits to a curated subset of the logs listed in Chrome's V3 CT Log List

- Among that subset, Let's Encrypt spreads submissions randomly while abiding by the "two independent operators" requirement

I hope this was helpful,

Aaron

--
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/173e52bc-5d18-4137-bac3-7016e53a4062n%40chromium.org.

[Antonios Chariton]

Hello Susan,

It seems that according to Cloudflare’s CT Monitor: https://ct.cloudflare.com/ that CAs pick different logs with different weights.

I think all CAs pick from a list of the common logs (set intersection) listed by Chrome, Apple, etc. as including any others won’t make a lot of sense.

I know that some CAs may use a subset of that list either in the operator level or the log level.

Also, I am aware of CAs preferring logs that have faster response times so they can accelerate their issuance. If a log is too far away, and adds many seconds, they may prefer to not use this if latency or capacity are important.

To summarize, some CAs seem to have a policy, where at least some logs are (or could be) excluded, but it may happen for different reasons (policy, performance, etc.).

I hope that’s helpful.

Antonis

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

[Susan Ven]

Hi Aaron,

Wow, thank you so much for your detailed replying. That's helpful to me.

But I still have some questions: 

First,  How let's encrypt to sync with Chrome's list? Is it regular or real-time automatic? We found that Let's encrypt also occasionally submits certificates to log servers that Chrome doesn't trust[1]. For example, in [1], the precertificate was submitted to the 360 browser log, but it seems to be rejected by Chrome[2].

Second, why not consider Apple's log list(although Chrome's list is usually covered)? 

Best wishes,

Susan

[1] https://crt.sh/?id=3251229993

[2] https://www.gstatic.com/ct/log_list/v3/all_logs_list.json

[Susan Ven]

Hi Antonios,

Thanks for your replying. I couldn't agree with you more. That's what I'm curious about. As you say, is it possible for the CA to select logs that are responsive but not on the approved list? Will CA choose logs outside the approved list(e.g., Chrome or Apple) when issuing a CT-compliant certificate normally? According to the statistical analysis [1], the number of certificates in those log servers which outside the approved list is also increasing. 

[1] https://sslmate.com/labs/ct_growth/

[Antonios Chariton]

Hello Susan,

I’m responding here but it also applies to Aaron’s e-mail and the certificate you linked to.

When a certificate is issued, a pre-certificate is created, and the CA obtains 2 or more SCTs to include inside. How they select which two is up to the various practices, such as the code that Aaron walked you through before.

After these two or more SCTs are obtained, they are included in the certificate, which is only then issued, and given to the client.

If there is a valid pre-certificate or certificate, anyone can take this later and submit it to any log. There are two anonymous endpoints in all CT logs, specified in the CT RFC, where any entity can submit a valid pre-certificate or a valid certificate, and it will receive an inclusion proof.

crt.sh is following a lot of logs, and will find a certificate multiple times. If it finds it in logs, it will add it in the section at the top ("Log entries for this certificate:”) but it does not mean that this pre-certificate’s corresponding certificate contains SCTs from these logs.

With curl you can try yourself to submit an existing certificate (e.g. from example.com) to all CT logs, including ones outside the list, and then after 24 hours or so, you’ll see them appear at that section of crt.sh even much later, after the certificate is issued.

CAs choose usually from the intersection of Chrome and Apple because they need their certificates trusted by Chrome and Apple, and this is the smallest number of SCTs they can include. In theory, they could include multiple SCTs, or even have a certificate with an SCT from every log, but this is not necessary, it increases the size of the final file, and therefore it’s not being done.

The corresponding certificate for the pre-certificate you linked to is this one: https://crt.sh/?id=3251237119

You can see the pre certificate is included in many logs:

2020-08-17  00:13:56 UTC 522360318 Let's Encrypt https://oak.ct.letsencrypt.org/2020

2020-08-17  00:13:56 UTC 858899937 Google https://ct.googleapis.com/logs/xenon2020

2020-08-17  23:34:12 UTC 26571 360 Browser https://ct.browser.360.cn/2020

2020-08-17  23:34:24 UTC 344732949 Cloudflare https://ct.cloudflare.com/logs/nimbus2020

2020-08-17  23:34:53 UTC 183799990 DigiCert https://yeti2020.ct.digicert.com/log

2020-08-17  23:35:07 UTC 833836629 Google https://ct.googleapis.com/logs/argon2020

2020-08-17  23:35:18 UTC 23790110 DigiCert https://nessie2020.ct.digicert.com/log

But the certificate only has 2 SCTs:

Let's Encrypt Oak 2020

Google Xenon 2020

And crt.sh only found this to be included (the certificate, not the pre-certificate) in 2:

2020-08-17  00:13:56 UTC 831159288 Google https://ct.googleapis.com/logs/argon2020

2020-08-17  00:13:56 UTC 858900312 Google https://ct.googleapis.com/logs/xenon2020

I hope this helps.

Antonis 

[Matthew McPherrin]

Hi Susan,

Great questions!  I work with Aaron at Let's Encrypt.

The list of CT logs is updated manually by Let's Encrypt staff - it is checked into our configuration repository and deployed through our normal mechanisms.  We update it in response to events like new log shards coming online.

Let's Encrypt doesn't submit to the 360 browser log.  Anyone can submit to CT, so somebody must have pulled that precertificate from another log and submitted it to the 360 log.

The choice of log list doesn't matter so much:  We'd only ever submit to logs trusted by both Chrome and Apple, so either list is suitable.  A possible enhancement would be to use both logs and verify we only submit to logs that are trusted by both, but as of now we do that validation when "hand curating" which logs we submit to.

Besides just ensuring the logs are trusted, hand curation is important because Let's Encrypt issues a very large portion of all certificates in CT, we do want to be careful where we submit to avoid overloading logs and to manage our own availability if a log becomes unreliable for any reason.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/da739d15-9b21-4eb4-b2db-0d3c61289a88n%40chromium.org.

[Susan Ven]

Hi Antonios,

Thanks for your detailed description. Yeah, that's helpful to me.

Best wishes,

Susan

[Susan Ven]

Hi Matthew,

Thanks again for your and your colleague's detailed reply, which cleared up a lot of confusion for me.

Best wishes,

Susan

在2023年3月1日星期三 UTC+8 00:05:22<Matthew McPherrin> 写道：