Issue 8: Require SCTs for Intermediate Certificates

[Andrew Ayer]

GitHub Issue: https://github.com/GoogleChrome/ct-policy/issues/8

Chrome CT Policy only requires that the end-entity certificate be
logged to achieve CT qualification. It does not require that any of
the intermediate certificates used to construct the chain be logged.
At the same time, Chrome Log Policy does not place any restrictions on
what root certificates may be accepted by a log.

This combination leads to challenges for monitors. Imagine a CA asked
logs to accept a root not trusted by browsers, and then issued and
logged certificates chaining to this root for other people's domains.
What is a monitor supposed to do with these certificates?

It has been suggested that monitors should do chain validation on logged
certificates and ignore certificates that don't chain to a root they
care about[1]. However, monitors cannot do this as long as TLS clients
do not require logging of intermediate certificates, since unbeknownst
to a monitor, there may be an undisclosed cross-sign from the root
trusted by the log to a root trusted by Chrome. This cross-sign can be
included in the chain presented to Chrome, and as long as the
end-entity certificate has sufficient SCTs, it will be considered CT
qualified. If a monitor raises an alarm for such a certificate, the
best-case scenario is that there is no undisclosed cross-sign and the
alarm is a false positive. The worst-case scenario is that there is an
undisclosed cross-sign, and the domain owner has no way of knowing
which CA is ultimately responsible for the misissuance.

To solve this problem, Chrome could require that logs accept only
"trusted" roots, but this risks fragmenting the log ecosystem, since
different browsers have a different notion of what roots are trusted.
Instead, I think Chrome should require that any certificate used to
construct a certificate chain be logged, so that intermediate
certificates cannot be hidden from monitors.

Regards,
Andrew


[1] https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/Itoq0YUZTlA/abf6cmjyCwAJ

[Kurt Roeckx]

On Tue, Jun 06, 2017 at 10:06:52AM -0700, Andrew Ayer wrote:
> GitHub Issue: https://github.com/GoogleChrome/ct-policy/issues/8
>
> Chrome CT Policy only requires that the end-entity certificate be
> logged to achieve CT qualification. It does not require that any of
> the intermediate certificates used to construct the chain be logged.
> At the same time, Chrome Log Policy does not place any restrictions on
> what root certificates may be accepted by a log.

If you're going to require SCTs for the intermediates, they'll
likely not have embedded SCTs. I think it's going to be harder to
get them to the browser.


Kurt

[Alex Gaynor]

Rolling out such a requirement would probably need a separate date for enforcement than for EE certs -- 6962 doesn't have a way to send SCTs in the TLS handshake for anything but the leaf, and I don't think anyone does OCSP for intermediates, so that means only embedded SCTs work.

I think some folks will be tempted to see this as largely an academic concern, but if memory serves just a month or two ago someone took all the AIA cAIssuer URLs found in CT and fetched those intermediates and found a few that had not been seen before.

Alex

--
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+unsubscribe@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/20170606172221.3iowehmw7455pdfq%40roeckx.be.

[Ryan Sleevi]

Thanks for raising this issue, Andrew.

It's been discussed a few times in the past, although I'm having trouble finding links - that CT has been discussed for going on five years means there's a lot of messages on that point! 

From a Chrome perspective, this is one of the important reasons we've been re-evaluating how we build and validate trusted certificate chains. With a more heremetic, consistent build, then we create the opportunity to whitelist all existing intermediates, and require SCTs for all new intermediates - which would accomplish what you propose.

As Alex mentions, it's not been our high-order bit of concern, given all the other priorities, but it's certainly been one.

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

[Todd Johnson]

A random thought: Intermediates *could* have a longer lifetime. If using an SCT within a long lived intermediate, would that not increase the logs lifetime?

Another random thought: What is the "Year 2038" impact on the use of the RFC 5905, vs using ISO 8601 for the timestamp? [http://xkcd.com/1179/]