Do you have an approximate timeline before we can expect to see chrome verify CT informations?
In order to improve trust in LE certificate what do you think about making CT mandatory for browsers (if vendors like chrome accept it) like it is for EV certificate (and another CA who had trust issues but I can’t remember which one) ?
Chrome checks for Signed Certificate Timestamps (SCTs), which are proof from a CT log that it received a certificate at a specific moment in time. There are several ways that SCTs could get to the browser, but the most common by far is that the CA obtains them by issuing a pre-certificate (currently this is a “real” x509 certificate that is deliberately “poisoned” so that it won’t work) and then includes the SCTs for that inside the certificate it issues for actual use. That way nobody needs to upgrade to newer server software, just the certs they obtain are a bit larger.
Although Let’s Encrypt certificates are already voluntarily logged (over 100 000 per week) with several CT logs, they do not provide SCTs in the certificates they issue. Given that LE has lots of other stuff to focus on, I would guess that they prefer to wait until 6962bis (an as-yet unnumbered successor to RFC 6962 which will standardise CT permanently, RFC 6962 is an “experiment” not a finished standard) is completed.
Voluntary logging, with no client enforcement is still valuable because it lets everybody see if LE make any mistakes. Obviously if they were actually Evil they’d hide their evil from the logs. But if they’re just screwing up (e.g. when they issued despite CAA mis-matches last year for a little while) with voluntary logging we can see it. Other CAs seem to be at least somewhat coming around on voluntary logging.
We definitely are interested in providing SCTs via OCSP. A generous community contributor has a pull request in progress here and here. We’re not waiting for 6962bis.
Yeah. One of my early criticisms of CT was “Well what if bad actor just tampers with the logging, issues cert(s) and then re-enables it later”
Enforcing CT later on is a good idea.
Thank you for that confirmation.
@jtl I agree with you. CT without enforcing it is not as usefull as it can be. And Chrome already enforce it for some CAs : Google Online Security Blog: Sustaining Digital Certificate Security
I think one CT is well installed in LE, it will be a huge step if LE commit to that and tells browsers vendors they can enforce CT checks. Unfortunately if CT informations are only provided by OCSP and not directly by the certificate, I think that step will not be possible.
“already” here is a reference to Symantec as mentioned in that blog post? That policy begins in June 2016, which is still almost two months away.
Right now Symantec and others are arguing vehemently in favour of redaction, which is a policy + technology whereby the certificate logs would not show the entire names for which the certificates were issued. Presumably their goal is to achieve a situation where the Chrome team agrees they can redact as much as possible from the CT logs before they’re mandatory, or as soon as possible after.
Today all CT logs are unredacted, because the redaction methodology has only been developed after they were deployed. But although most web PKI CAs log some certificates they issue, the big ones have said they’re not logging everything, that some (a few? lots? I would guess the former but they aren’t saying) certificates are withheld ostensibly by request of their customers. Let’s Encrypt are, I think, the only CA to come out against redaction.
redacting what exactly?
I thought I mentioned, but maybe it wasn’t clear enough. For certificate transparency redaction applies to the name(s) on the certificate so e.g. today a certificate might be for
devtest4.peaches-and-cream.deserts.example
but in future redaction could allow the logged version to say instead
?.peaches-and-cream.deserts.example
OR maybe
?.?.deserts.example
OR even
?.?.?.example
Someone actually receiving the real certificate would see the real name (otherwise the certificate is useless) but the logged version would no longer show some, or depending on policy most, of the name if the issuer chose to redact it.