Issue 3: Determine whether there is a minimal set of certificates a Log must accept

[Ryan Sleevi]

https://github.com/GoogleChrome/ct-policy/issues/3

This recently came up with both https://bugs.chromium.org/p/chromium/issues/detail?id=698094 and https://bugs.chromium.org/p/chromium/issues/detail?id=712069 

It also applies a Log that's been included since Chrome 50, https://bugs.chromium.org/p/chromium/issues/detail?id=554549

At question is what root certificates MUST be accepted by a Log to demonstrate it is "operating in the public interest".

Additionally, in considering that question, what impact, if any, should such changes have on existing or pending Logs. That is, if the Policy is clarified in a way that an existing or pending Log does not meet such a policy, what timeframe, if any, should exist to allow it to adjust (aka: effective date).

My hope and desire is to see permissive logs, such as https://bugs.chromium.org/p/chromium/issues/detail?id=703699 or the Google logs. To phrase it more objectively, a Log must accept certificates from any Root recognized for TLS issuance by Chrome, which includes the set of roots on (Microsoft, Apple, Mozilla, ChromeOS, Android, iOS). Of course, defining that objectively should be incumbent on Google/Chrome, so that there's no ambiguity or misinterpretation.

Alternatively, it might be that the set of questions in https://github.com/GoogleChrome/ct-policy/issues/5 provides sufficient policy guidance for the ecosystem, and there's no need to normatively specify roots.

Do people have thoughts here?

[Andrew Ayer]

On Mon, 24 Apr 2017 17:30:10 -0400
Ryan Sleevi <rsl...@chromium.org> wrote:

> https://github.com/GoogleChrome/ct-policy/issues/3
>
> This recently came up with both
> https://bugs.chromium.org/p/chromium/issues/detail?id=698094 and
> https://bugs.chromium.org/p/chromium/issues/detail?id=712069
>
> It also applies a Log that's been included since Chrome 50,
> https://bugs.chromium.org/p/chromium/issues/detail?id=554549

Also this log, included since Chrome 53:
https://bugs.chromium.org/p/chromium/issues/detail?id=583208

[Alex Gaynor]

I agree that logs that broadly accept publicly trusted certificates are in the interest of the ecosystem and users of the web.

One complication I want to flag is the idea of "log families shared by CA", by which I mean arrangements like Skydive/Icarus, where in aggregate the logs cover all roots, but individual log servers do not. Such arrangements do not seem problematic.

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/20170424150651.61b1701bc040e09a6770c5bd%40andrewayer.name.

[Ryan Sleevi]

On Tue, Apr 25, 2017 at 9:33 AM, Alex Gaynor <aga...@mozilla.com> wrote:

I agree that logs that broadly accept publicly trusted certificates are in the interest of the ecosystem and users of the web.

One complication I want to flag is the idea of "log families shared by CA", by which I mean arrangements like Skydive/Icarus, where in aggregate the logs cover all roots, but individual log servers do not. Such arrangements do not seem problematic.

I'm not sure I'd agree; that is to say, I think they're problematic.

I think a good example of this is imagine you are a server operator (or CA) that wishes to obtain SCTs. In order to obtain an SCT, you need to be able to construct a valid chain to a Root accepted by a log.

In the "Log family" case, you need to determine what family the root belongs to. If you assume you only have a list of logs, you can always call /get-roots. However, how frequently should you call /get-roots - that is, when do you expect it to change? Should you observe HTTP caching directives related to the response or not? What happens if one log has older roots, and another log has newer roots - what complexity does that introduce for the (CA or client) to obtain?

I can understand that the overall goal is to manage the growth rate and load over a log. I know Kat has been giving a lot of thought to that for the logs Google operates, and the concerns related to CA acceptance policies are ones I've raised to that team as well.

It seems that if the Logs were consistently open, without grouping by families, we'd need another degree to manage growth rate and acceptance. If we're not sharding by organization, then the next logical place seems to slice temporally, either by validity period or expiration.

[Kat Joyce]

Yup, we have been thinking about the idea of sharding based on expiration a lot recently, and I plan to send out an email to ct-policy containing the proposal we have come up with sometime in the next day or two, so stay tuned!

[Rob Percival]

Since there are now a number of temporally-sharded logs, are we able to make progress on this policy issue?