Proposal to require all new CT Logs be sharded annually

[Devon O'Brien]

Hello ct-policy,

Chrome has allowed for temporally-sharded CT Logs since 2017 and as they’ve grown in popularity, we’ve come to strongly prefer them over “monolithic” CT Logs that grow indefinitely. At a moderately small marginal cost to Log Operators and CAs, sharded CT Logs provide:

• Reasonable caps for Log Operators on the growth of their Qualified CT Logs

• More predictable CT Log lifecycle for user agents and CAs

• Lower cost of entry and ongoing storage costs for CT Monitors and Auditors

After the first batch of sharded CT Logs were stood up, most Log Operators coalesced around annual, non-overlapping shards, but this was never put into policy and we’re currently reviewing a new CT Log with a much larger expiry range (2021-2025). Given the benefits of moving the CT ecosystem to predictably sharded CT Logs, we’re proposing to require all new CT Logs be sharded on an annual basis. Each set of sharded CT Logs should keep enough shards to cover the current year plus 2-3 subsequent years to ensure continuity of coverage for certificate logging.

I’d like to hear feedback from the community about whether there are any concerns with us updating our CT Policy to reflect the above suggested changes.

Best,

Devon

[Alex Cohn]

One concern is intermediate certificates, which can have expiration dates after the last shard of most logs. I believe Mozilla requires intermediates to be disclosed in the CCADB - https://crt.sh/mozilla-disclosures is a list of known intermediates drawn from CT logs used to enforce this requirement. There's also the possibility that a CA misissues a leaf certificate with a far-future expiration date. I feel it's important to provide a place to log such certificates.

Maybe it would make sense to have an open-ended shard for certificates that expire, say, after 2024-01-01, akin to Daedalus? This date could be rolled forward as new yearly shards are brought online. IIRC Chrome (and Safari) don't require an SCT for intermediate certificates and wouldn't accept a certificate with a far-future expiration date, so I don't believe such a log would need to be trusted by Chrome.

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/29f53e01-b1e5-456c-aff6-21e1ca32c6df%40chromium.org.

[Andrew Ayer]

Hi Devon,

I'm strongly in favor of forbidding new logs with expiry ranges greater
than one year.

But I believe the policy should still permit logs with shorter ranges,
to allow flexibility in case the WebPKI growth rate requires
transitioning to shorter ranges.

Regards,
Andrew


On Mon, 16 Mar 2020 09:29:23 -0700 (PDT)

Devon O'Brien <asymm...@chromium.org> wrote:

>
>

> Hello ct-policy,
>
> Chrome has allowed for temporally-sharded CT Logs

> <https://groups.google.com/a/chromium.org/d/msg/ct-policy/_eXIfMf7LQQ/rt9GG3orAwAJ>
> since 2017 and as they___ve grown in popularity, we___ve come to strongly
> prefer them over ___monolithic___ CT Logs that grow indefinitely. At a

> moderately small marginal cost to Log Operators and CAs, sharded CT
> Logs provide:
>

> -

>
> Reasonable caps for Log Operators on the growth of their Qualified
> CT Logs

> -

>
> More predictable CT Log lifecycle for user agents and CAs

> -

>
> Lower cost of entry and ongoing storage costs for CT Monitors and
> Auditors
>
>
> After the first batch of sharded CT Logs were stood up, most Log
> Operators coalesced around annual, non-overlapping shards, but this

> was never put into policy and we___re currently reviewing a new CT Log

> with a much larger expiry range (2021-2025). Given the benefits of

> moving the CT ecosystem to predictably sharded CT Logs, we___re

> proposing to require all new CT Logs be sharded on an annual basis.
> Each set of sharded CT Logs should keep enough shards to cover the
> current year plus 2-3 subsequent years to ensure continuity of
> coverage for certificate logging.
>

> I___d like to hear feedback from the community about whether there are

> any concerns with us updating our CT Policy

> <https://goo.gl/chrome/ct-policy> to reflect the above suggested
> changes.
>
> Best,
>
> Devon
>

[Devon O'Brien]

Currently, intermediate CA certificates are not covered by the CT Policy for either Chrome [1] or Apple products [2], which strictly focus on TLS server certificates. Additionally, CCADB's intermediate CA certificates are required to be disclosed by the CA themselves [3] and should not specifically rely on intermediate CAs being logged to CT.

I agree with you that there is value in knowing whether a CA issues a BR-violating leaf certificate; however, we are strongly motivated to ensure that such certificates never function in user agents, which is achieved by enforcing limits on certificate lifetime during certificate validation. It's important to note that failure to log certificates to CT is not a root program violation today, and we worked closely with CAs to ensure that opt-out mechanisms exist for CA customers for edge use cases where certificates are not required to function in Chrome or other CT-enforcing user agents. This means we already do not have guaranteed visibility into issuance of BR-violating certificates (i.e. with long validities).

From the perspective of what it means for a CT Log to be Qualified or Usable, I don't think we should conflate CA archival use cases or even BR violations for certificates that already fail to validate with the need to ensure TLS certificates that function in CT-enforcing user agents are logged. Those are both compelling use cases, so maybe we can work to find a separate mechanism to address these concerns?

-Devon

[1] https://goo.gl/chrome/ct-policy

[2] https://support.apple.com/en-us/HT205280

[3] https://www.ccadb.org/policy

[Devon O'Brien]

Hi Andrew,

Thanks for the input! Given the trajectory to shorter certificate lifetimes and a generally increasing trend of certificate issuance, it may be necessary to re-examine recommended CT Logs' certificate expiry ranges in the future, but right now, 1 year seems to be a good place. We're looking at about 1B certificates logged for a highly-used annual shard, which appears to be supportable by both Log Operators as well as existing Monitors. 

Not that anyone has been asking for super short CT Logs just yet, but there is a cost of additional churn, especially for CAs who need to reconfigure their CT logging manually. I would prefer future concerns with annual CT sharding be raised and addressed as they come up, so we can communicate more solid expectations to those affected by increased churn. Would this approach be agreeable to you?

-Devon

> ct-policy+unsubscribe@chromium.org. To view this discussion on the
> web visit
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/29f53e01-b1e5-456c-aff6-21e1ca32c6df%40chromium.org.