What if CA fail to generate certificate when there has no CT log server reply with SCT

[edmond...@gmail.com]

We are revising our CA for CT.  We are really concern on the number of non-google CT log servers and their stability / availability.

At this moment, we can only find 2 non-google CT log servers that trust our CA. If the number of non-google CT log servers does not increase, our certificate generation service can only rely on these 2 non-google CT log servers.

We want to maintain our service level for certificate generation.  But once we have enabled CT, we may fail to generate certificate if all non-google CT log servers are down or DQ.  We also do not want to generate any certificate that is not "CT qualified".

What can we do if we fail to find any non-google CT log server reply us with SCT either all CT log servers down or have been DQ? We have to stop our service? Will google consider to review their policy if the number of non-google CT log servers is less after Apr 2018? 

Edmond

[Matt Palmer]

On Fri, Aug 11, 2017 at 03:02:11AM -0700, edmond...@gmail.com wrote:
> What can we do if we fail to find any non-google CT log server reply us
> with SCT either all CT log servers down or have been DQ?

You can issue without embedding SCTs, it'll just mean the server presenting
the certificate will have to acquire and present additional SCTs (via
stapled OCSP response or TLS extension) in order for the certificate to be
trusted.

> Will google consider to review their policy if the number of non-google CT
> log servers is less after Apr 2018?

CT logs are just another resource your business relies on. Just like you do
an analysis of failure rates of servers, HSMs, facilities, and personnel,
and pay for excess to ensure sufficient redundancy, you should do the same
thing for CT logs. If you believe you need access to additional CT logs to
ensure reliability, you should do the needful to ensure they are available
to you -- whether that's stand up one or more CT logs of your own, or
contract with a third party on a commercial basis.

- Matt

[Ryan Hurst]

Edmond,

As you point out the health of the CT ecosystem is dependent on there being a sufficient number of well operated independent logs in place. While we are actively working with several third-parties to support the deployment of new logs there are already a good number of them today, a machine readable list of the available ones can be found here:

https://www.gstatic.com/ct/log_list/log_list.json

Today there are active logs from DigiCert, Symantec (pending merger with DigiCert), Comodo, Venafi, and CNNIC (though there is an on going discussion on their MMD compliance). These companies run these logs in the public interest and in my experience are willing to extend the list of certificates they trust when encountered. Let me know if you need help reaching out to these log operators.

Generally it is our recommendation that you log to all available logs and embed the first set that come back that meet your log inclusion goals. If you were to be logging to all of the above 4 in addition to the google logs you would be strongly isolated from the case you discuss.

With that said, if we assume all of the logs were to become unavailable you do not need to block issuance, instead you can rely on the server sending the CT related data through OCSP or TLS. In some cases this model may even be considered ideal, however in mainline cases inclusion in the certificate is the more appropriate model at this time.

As such, as a CA the goal is to make sure you utilize the most robust set of logs so that the risks of issuance being delayed by this case are mitigated.

I hope this helps,

Ryan Hurst

Google

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.