The root CA list accepted by the logs & does CT scheme support code signing certificates?

[by li]

Hi,

I found that the number of CAs accepted by the logs was much higher than the number of mainstream CAs. 

For example,  on mainstream browsers and platforms, including 300+ root CA certifcates pre-installed in Microsoft Windows, 100+ in Mozilla NSS, and 150+  in Apple macOS. The union consists of 300+ root CAs . 

While, the log operated by Google generally accepts 537 CAs (such as ct.googleapis.com/logs/argon2019). 

I compared the two sets of CAs and found that some mainstream CAs were not accepted by log, while some non-mainstream CAs were added to the acceptance  list.

More surprisingly, most of these CAs (100+ from 537) have expired (since 2015). 

I would like to know why log server (Google) accepts these CAs (for example, for testing?) .

When I used Censys to look up some certificates, I found that some of the code signing type certificates were also recorded in the CT Log. 

Such as:

https://censys.io/certificates/51b8c281c8f91a12720c4c5fcd3310bbb710bd8234db2bd8ab7117946ecfae29;

https://censys.io/certificates/9104937cc934e2aef43a45897fcbef875cf3cfa217a87f26508efee7e3a8f794;

https://censys.io/certificates/5e435560f11f72e37bb97d3e1046858d0566525a08e1c772bf5863199596ea52. 

I have checked the official website of CT, relevant literatures and RFC 6962. The literatures mainly discuss TLS/SSL type certificates and the application of CT in TLS. 

No one has mentioned whether Code signing certificates are allowed or necessary to be recorded in the log. 

There is only one blog on globalsign's website that mentions "you cannot post S/MIME or Code Signing Certificates to CT logs". 

(https://www.globalsign.com/en/blog/what-is-certificate-transparency/)

I really want to know whether CT log supports code sinning certificate, if not, why log server will accept such certificate. 

Thank you very much for your reply.

[Ryan Sleevi]

On Sun, Apr 28, 2019 at 9:29 AM by li <byl...@gmail.com> wrote:

Hi,

I found that the number of CAs accepted by the logs was much higher than the number of mainstream CAs. 

For example,  on mainstream browsers and platforms, including 300+ root CA certifcates pre-installed in Microsoft Windows, 100+ in Mozilla NSS, and 150+  in Apple macOS. The union consists of 300+ root CAs . 

While, the log operated by Google generally accepts 537 CAs (such as ct.googleapis.com/logs/argon2019). 

I compared the two sets of CAs and found that some mainstream CAs were not accepted by log, while some non-mainstream CAs were added to the acceptance  list.

More surprisingly, most of these CAs (100+ from 537) have expired (since 2015). 

I would like to know why log server (Google) accepts these CAs (for example, for testing?) .

Could you explain why you find this surprising?

It's unclear what you define "mainstream" CA as, but in general, logs have been updating their set of included CAs (as shown on the respective logs' inclusion bug) over time, and CAs that aren't included can and should reach out to logs to request inclusion.

In general, production logs don't include CAs for testing. They're included to further transparency.

You can find Logs' individual policies on the types of certificates they accept within their inclusion bugs.

[by li]

Thank you very much!
I was surprised to find that many of the root CA certificates accepted in these log had expired, and some had expired by 2015 or earlier.
TLS certificates issued by these expired CAse are usually subsequently invalid.
Some recently deployed Log servers still add these CA certificates to the acceptance CA list.
Can we just assume that Log supports these CAs for further transparency? 

在 2019年4月29日星期一 UTC+8下午9:58:29，Ryan Sleevi写道：

[Kat Joyce]

Hi there, 

The set of roots that a Log accepts is entirely up to the operators of that Log.  I can therefore only answer based on what we (the operators of the Google CT Logs) choose to do.

From our perspective, we regularly add roots to the set of accepted roots for our Logs to include all of the union of the Apple, Microsoft, and Mozilla trusted roots programs.  However, we rarely remove roots from their set of accepted roots, so the presence of expired CA root certs is likely because they were once in the union of the Apple, Microsoft, and Mozilla trusted roots programs, but no longer are.  We currently use the same set of roots for (almost) all of our production Logs, as it simplifies deployment, which is why the newer Logs still include these expired certificates.  However, this point has recently been raised in our team internally, and we are considering changing this for new Logs.  Of course, making this change requires work, and there is a question of prioritization of the work we currently have on, so we can't guarantee this will happen any time soon.

Ryan is right that we don't add roots to our production Logs for 'testing'.  We have dedicated testing Logs for those purposes.  See https://www.certificate-transparency.org/known-logs for details.

Hopefully that answers your question!

Kat & the CT team at Google

--
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/bbbbf2ac-cc38-4f0a-a754-e389d7c2f950%40chromium.org.