Should there be a lint for CT compliance?

[rmhrisk]

For quite a long time Chrome has checked CT for EV certificates, very soon they will do the same for OV and DV certificates.

It seems it would be good to add a (W) or (N) when the CT policy of chrome is not met.

[zakird]

I'm a bit hesitant to add something Chrome-specific as a warning. It's perfectly reasonable that an organization has an internal CA that doesn't have CT, and that's not against any written standard. I'd be fine having a notice for this.

[rmhrisk]

Notice would be good in my book.

[srdavidson]

Useful, given the nearly universal adoption of CT in trusted SSL.

[fotisl]

I agree with @rmhrisk that CT compliance would be a nice feature. Furthermore, I do not consider it chrome specific since most browsers have stated that they will require it. For example, apple has already created a trusted CT log program. An organization running an internal CA may not log certificates to any log, but on the other hand they don't have to be compliant with the CA/B forum baseline requirements, which are already supported in zlint. Thus I do not consider the use of a feature by public or private CAs as a criterion for support by zlint.

[RufusJWB]

I would like to support this issue. Since CT is more or less universal we should have this checked by ZLint as well, probably as a Info until Googles CT policies are incorporated into BRGs.

[robstradling]

How fully-fledged would ZLint's CT compliance check need to be? For example, would it need to keep an up-to-date list of which logs are accepted by which CT clients, and validate that the cert has a sufficient number of embedded SCTs from accepted logs? Or would it merely count the number of embedded SCTs?

[rmhrisk]

I was thinking simply counting.

[fotisl]

I was thinking of counting logs under the google domains and non-google ones and requiring at least one from every group. If current google policy is adopted by other browsers or the ca/b forum, then counting based on duration would be nice. Keeping state, especially for some cases like disqualified logs, would make it pretty complex and may return false results.

[robstradling]

@fotisl Counting google vs non-google would require ZLint to maintain, at the very least, an up-to-date list of Google LogIDs.

[fotisl]

@robstradling Yes, you are correct. Counting and maybe selecting a minimum number of scts based on duration is better.

[robstradling]

It's also worth bearing in mind that the "1 Google, 1 non-Google" requirement in the Google CT Policy is a bootstrapping mechanism. Once the CT ecosystem reaches a to-be-defined level of maturity, I think we're all expecting Google to drop this requirement.

[robstradling]

Apple now have a CT Policy (https://support.apple.com/en-us/HT205280) and they intend to enforce CT compliance for all TLS connections (https://twitter.com/BasileBailey/status/1003911999506575360) at the end of 2018. This policy seems to be a strict subset of Google's CT Policy. (Apple don't have a "1 Google, 1 non-Google" requirement).

[dadrian]

We'd be happy to take a lint that just counts SCTs (probably notice-level), and anyone is welcome to open a PR that does this.

[cpu]

We'd be happy to take a lint that just counts SCTs (probably notice-level), and anyone is welcome to open a PR that does this.

I took a crack at this: https://github.com/zmap/zlint/pull/278

:mag:'s welcome!

[cpu]

We'd be happy to take a lint that just counts SCTs (probably notice-level), and anyone is welcome to open a PR that does this.

There's a basic lint for counting SCTs in-tree now modelled after Apple's policy (with some caveats): https://github.com/zmap/zlint/commit/f13105e53ee699f027a0751ea0d25964776948e7.

@rmhrisk In your original issue description you specifically call out having an informational lint for Chrome's CT policy so I haven't closed this issue as resolved because I don't think my counting lint meets this bar.

---

On the question of how to close this issue and more accurately lint Chrome and Apple's CT policies, I have some thoughts.

I think there's value in improving the quality of SCT linting by having the zlint project treat log information similar to TLDs, e.g. refreshing an in-tree representation from a known source of truth using tooling like I wrote in zlint-gtld-update.

Unlike for TLDs we're looking at multiple sources of truth and at present it seems like there isn't one schema that would cover both Chrome's trusted log information and Apple's trusted log information. There's ongoing discussion about a common schema but as best I can tell from an outsider's perspective it isn't reality yet.

Do folks think it makes sense to wait for a single schema or would it be better to build tooling that can process the current Apple schema and the current Chrome schema and produce a common representation for linting?

I can't promise I'm signing up to implement anything further but as a minimum I'd be happy to file issues that map out an implementation plan if we can arrive at some rough consensus on the open design questions in this thread.

[titanous]

I think a separate Go package that can fetch/normalize the data from the Google and Apple feeds would be the best way forward. This package could also be useful for server software that wants to check if a certificate meets CT requirements, so might be a good place for some of the linting logic in reusable form?

[rmhrisk]

I agree with @titanous. It seems that a re-usable module like that would be needed by many and isnt really core to zlint itself.

[robstradling]

Could any of these packages be (re-)used by ZLint for this purpose? https://github.com/google/certificate-transparency-go/tree/master/ctpolicy https://github.com/google/certificate-transparency-go/tree/master/loglist https://github.com/google/certificate-transparency-go/tree/master/loglist2

[cpu]

@robstradling Those look perfect, great find! I didn't realize ct-go implemented this.

[zakird]

Now that we have lint "Sources" that folks can include or exclude, this seems reasonable to me to take on as an error in the appropriate class.