Updating roots for Google logs

[Peter Bowen]

Based on the latest update from Microsoft, there are several roots now
trusted by Microsoft (and therefore Chrome on Windows) not in the root
list for the Google CT logs. Is there an automated sync process that
will kick in at some point or is there an appropriate bug reporting
system to request updates?

Also, I've recently run into an issue where certain CAs are
transitively trusted via cross-certificates but most servers using
certificates from these CAs fail to send a full chain. Has there been
any thought of extending the "root" list to include transitively
trusted CAs where CT has the transitive chain?

Thanks,
Peter

[Ben Laurie]

On 5 February 2016 at 14:48, Peter Bowen <pzb...@gmail.com> wrote:

Based on the latest update from Microsoft, there are several roots now
trusted by Microsoft (and therefore Chrome on Windows) not in the root
list for the Google CT logs.  Is there an automated sync process that
will kick in at some point or is there an appropriate bug reporting
system to request updates?

There is a non-automated sync process (as in it is manually initiated) which I have just requested be run... in accordance with best practice, it won't happen today, though.

Also, I've recently run into an issue where certain CAs are
transitively trusted via cross-certificates but most servers using
certificates from these CAs fail to send a full chain. Has there been
any thought of extending the "root" list to include transitively
trusted CAs where CT has the transitive chain?

We actually have a job that tries to fix such chains in order to submit them to the log, but only ones we've seen. We are working on a better version at the moment, as it happens.

That said, allowing CT to invent chains would be a pretty major change, and not something I really want to encourage: the fact that servers can get away with it is not without pain, since browsers' ad hoc mechanism for fixing the chain tend to not be entirely reliable. I'd hate to end up with that kind of randomness around CT submissions.

Seems to me its better to do as we are doing, which is to have the submitter make the fix.

[Ben Laurie]

Code here, btw: https://github.com/google/certificate-transparency/blob/879395cc4aeecdbe0452249b59c84795bb231638/cpp/client/fix-chain.py.

[Peter Bowen]

On Fri, Feb 5, 2016 at 8:05 AM, 'Ben Laurie' via
certificate-transparency <certificate-...@googlegroups.com>
wrote:

I was under the impression that only reason CT even used chains was to
avoid log spam and that the Transparency aspect was far more
interesting than the correctness of the server configuration.

I am also not as interested in the case where a server sends a single
bare certificate, rather the case where there is a path involving
cross-certificates where it works in some clients (due to intermediate
caching, especially so called "bridge" CAs) but not on the CT logs.
The server may send a chain to an Enterprise root, which is what it
expects clients to have installed, but it turns out that the
Enterprise root is also cross-signed by a public CA. As I understand
it, under the current system, the certs would never get logged, as CT
would reject them. Is that right?

Thanks,
Peter

[Ben Laurie]

On 5 February 2016 at 16:14, Peter Bowen <pzb...@gmail.com> wrote:

On Fri, Feb 5, 2016 at 8:05 AM, 'Ben Laurie' via
certificate-transparency <certificate-...@googlegroups.com>
wrote:
>
>
> On 5 February 2016 at 14:48, Peter Bowen <pzb...@gmail.com> wrote:
>>
>> Also, I've recently run into an issue where certain CAs are
>> transitively trusted via cross-certificates but most servers using
>> certificates from these CAs fail to send a full chain. Has there been
>> any thought of extending the "root" list to include transitively
>> trusted CAs where CT has the transitive chain?
>
>
> We actually have a job that tries to fix such chains in order to submit them
> to the log, but only ones we've seen. We are working on a better version at
> the moment, as it happens.
>
> That said, allowing CT to invent chains would be a pretty major change, and
> not something I really want to encourage: the fact that servers can get away
> with it is not without pain, since browsers' ad hoc mechanism for fixing the
> chain tend to not be entirely reliable. I'd hate to end up with that kind of
> randomness around CT submissions.

I was under the impression that only reason CT even used chains was to
avoid log spam and that the Transparency aspect was far more
interesting than the correctness of the server configuration.

No, chains are needed so we know who to blame for mis-issue. The reason we have a list of accepted roots is to avoid spam.

 

I am also not as interested in the case where a server sends a single
bare certificate, rather the case where there is a path involving
cross-certificates where it works in some clients (due to intermediate
caching, especially so called "bridge" CAs) but not on the CT logs.
The server may send a chain to an Enterprise root, which is what it
expects clients to have installed, but it turns out that the
Enterprise root is also cross-signed by a public CA.  As I understand
it, under the current system, the certs would never get logged, as CT
would reject them. Is that right?

Well, they will if:

a) Google's crawl ever sees them

b) Our chain fixer can fix them

Of course others may be fixing chains, too...

Do you have examples? I'd still prefer to have a tool that can be used on chain submission than make every log get involved in the mess that browsers have made for themselves.

[Peter Bowen]

On Fri, Feb 5, 2016 at 8:20 AM, 'Ben Laurie' via
certificate-transparency <certificate-...@googlegroups.com>
wrote:

> Do you have examples? I'd still prefer to have a tool that can be used on
> chain submission than make every log get involved in the mess that browsers
> have made for themselves.

May I introduce you to https://vpn.carillon.ca ?

It returns a chain of three certificates in the handshake, the last of
which is self-signed by CISRCA1. Appears to be an unremarkable
enterprise PKI.

But SSL Labs knows better:
https://www.ssllabs.com/ssltest/analyze.html?d=vpn.carillon.ca

Turns out that CISRACA1 has a cross-certificate that allows building a
chain back to not one, but two different roots!

Thanks,
Peter

[Ben Laurie]

If SSL Labs knows better, then SSL Labs should log it!