Benefits of running a CA=TRUE Log

[Kat Joyce]

Hi all,

I hope everyone enjoyed last month's virtual CT days as much as I did - it was great to actually see so many of the CT community "in person" again!

One of the things that came up on the first day was that, given we have moved to temporal Logs for server certificates now, having a Log that accepted certificates for which CA=TRUE would be useful.

I made the mistake of not noting down all of the reasons that this would be useful that were discussed that day, and I know there were a few from a few different people.  In the hope of enumerating all of the benefits of running this Log, would people please reply to this email with the reasons you'd like to see a CA=TRUE Log run?  I have a couple, but I don't want to miss any, so no matter how obvious or subtle you may think a reason is, please do post it!

Thanks in advance!

Kat

CT at Google

[Jacob Hoffman-Andrews]

As a concrete example, Let's Encrypt recently issued a new root and some new intermediates. We haven't yet configured these for live issuance, but wanted to disclose these as soon as possible. We disclosed via CCADB and via our website, but disclosing via logs is particularly valuable for a few reasons: They are a known, public location with tamper resistant properties, and they are a channel for the certificates to get ingested by log monitors, from where they can be readily analyzed by the community.

[Alex Gaynor]

From the inverse perspective, using CT logs, some of us who are active on mdsp have found quite a few intermediates that are required by policy to be disclosed (and audited!) but which hadn't been.

Alex

On Mon, Oct 5, 2020 at 6:51 PM Jacob Hoffman-Andrews <js...@letsencrypt.org> wrote:

As a concrete example, Let's Encrypt recently issued a new root and some new intermediates. We haven't yet configured these for live issuance, but wanted to disclose these as soon as possible. We disclosed via CCADB and via our website, but disclosing via logs is particularly valuable for a few reasons: They are a known, public location with tamper resistant properties, and they are a channel for the certificates to get ingested by log monitors, from where they can be readily analyzed by the community.

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAN3x4QmCf78MdTu8nzNTYWfon5RiyDq4z2b0u5-rEWOJe%3DCnZQ%40mail.gmail.com.

--

All that is necessary for evil to succeed is for good people to do nothing.

[Andrew Ayer]

On Mon, 5 Oct 2020 12:57:31 +0100
"'Kat Joyce' via Certificate Transparency Policy"

<ct-p...@chromium.org> wrote:

> I hope everyone enjoyed last month's virtual CT days as much as I did
> - it was great to actually see so many of the CT community "in
> person" again!

Agreed!

> One of the things that came up on the first day was that, given we
> have moved to temporal Logs for server certificates now, having a Log
> that accepted certificates for which CA=TRUE would be useful.
>
> I made the mistake of not noting down all of the reasons that this
> would be useful that were discussed that day, and I know there were a
> few from a few different people. In the hope of enumerating all of
> the benefits of running this Log, would people please reply to this
> email with the reasons you'd like to see a CA=TRUE Log run? I have a
> couple, but I don't want to miss any, so no matter how obvious or
> subtle you may think a reason is, please do post it!

The benefit is the discovery of CA certificates capable of issuing
TLS server certificates, whether or not they have actually done so.

Over the years, many unaudited and otherwise undisclosed
TLS-capable CA=TRUE certificates have been submitted to CT logs,
which the community has leveraged to create useful tools like
<https://crt.sh/mozilla-disclosures>. This has unquestionably improved
the security of the WebPKI: unaudited CA=TRUE certificates are dangerous
since there are no assurances of how their key material is protected.
Although CT lets us know if their key material is ever used to
misissue a TLS certificate, it's preferable to prevent misissuance than
detect it after the fact - CT is not a replacement for audits.

As the CT ecosystem moves to temporally-sharded logs that only
accept TLS certificates, the WebPKI will lose a place for these
CA=TRUE certificates to be submitted. The CCADB is not a sufficient
replacement because only CAs can submit there, and historically
CAs have been very bad at disclosing intermediate certificates.
(After all, if we could trust CAs, there would be no need for CT.)
And although CT log entries can contain CA=TRUE certificates
in extra_data, this only suffices if the submitter who finds the CA=TRUE
certificate also finds an end-entity certificate which is accepted by
the log. This is not always the case. For example, Tavis Ormandy
found undisclosed, TLS-capable intermediates embedded in PDF files,
and most of the end-entity certificates were not TLS certificates:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/sNDN6q26_uM/uaOthN1yAAAJ

Arguably, the verifiable properties of CT are not needed for storing
CA=TRUE certificates. However, we already have a CT ecosystem consisting
of a specification, log implementations, monitor implementations,
submission tools, and awareness among security researchers. It would be
easier to reuse CT for storing CA=TRUE certificates than to undertake
the effort of building and evangelizing a new system. Presumably, the
overhead from CT's verifiability won't be a problem - there are fewer
than 200,000 CA=TRUE certificates in CT right now and new ones are not
created at a very fast rate.

Regards,
Andrew