DO NOT REVIEW: CT policy enforcement WIP

DO NOT REVIEW: CT policy enforcement WIP

BUG=

[Ryan Sleevi, 2016-04-13 15:52:22]

Description was changed from

==========
DO NOT REVIEW: CT policy enforcement WIP

BUG=
==========

to

==========
DO NOT REVIEW: CT policy enforcement WIP

BUG=
==========

[Ryan Sleevi, 2016-04-13 15:53:08]

rsleevi@chromium.org changed reviewers:
+ eranm@chromium.org

[Ryan Sleevi, 2016-04-13 15:53:08]

Eran: This is a very rough, very gross approach at trying to make sure I
understand the policy and that the code enforces it

awhalley: FYI

[Ryan Sleevi, 2016-04-13 15:57:41]

Eran: Note that rather than hang disqualification off of the CTLogVerifier, I
made it an attribute that can be looked up based on log_id. The reason for this
is because at the time we're parsing verified_scts, we only have the log IDs -
this is the same as why we didn't hang the Google-operated property off.

The difference between your CL and this approach is that we can't just trust
that the SCT timestamp from a disqualified log is necessarily trustworthy.
Instead, we require at least one valid SCT to establish when a certificate was
"issued", and that becomes the basis for determining whether or not to count the
disqualified log towards quorum - if the earliest SCT was less than that logs
disqualification date, and the log's SCT was less than the disqualification
date, we can accept it; otherwise, if the earliest (trusted) SCT is greater than
the disqualification date, we can't reasonably trust the SCT for quorum
(otherwise, the disqualified log could continue issuing SCTs at T-1, while all
trusted SCTs are T+20, and that'd still end up counting towards quorum, which it
shouldn't)

The inconsistently I've highlighted here is that for OCSP/TLS, we require both
the Google and non-Google log to still be qualified, while for precerts, we only
require 'at least' one to be qualified. Seems a little weird, but that's
something to think about

[Eran Messeri, 2016-04-13 16:15:29]

https://codereview.chromium.org/1888463003/diff/1/net/cert/ct_known_logs_stat...
File net/cert/ct_known_logs_static.h (right):

https://codereview.chromium.org/1888463003/diff/1/net/cert/ct_known_logs_stat...
net/cert/ct_known_logs_static.h:122: const int64_t disqualification_date;
Can the date be specified in a non-internal way? That will allow us to continue
using the open-source Python script for generating this file (while providing
the disqualification information).

[Ryan Sleevi, 2016-04-13 16:29:33]

https://codereview.chromium.org/1888463003/diff/1/net/cert/ct_known_logs_stat...
File net/cert/ct_known_logs_static.h (right):

https://codereview.chromium.org/1888463003/diff/1/net/cert/ct_known_logs_stat...
net/cert/ct_known_logs_static.h:122: const int64_t disqualification_date;
On 2016/04/13 16:15:29, Eran Messeri wrote:
> Can the date be specified in a non-internal way? That will allow us to
continue
> using the open-source Python script for generating this file (while providing
> the disqualification information).

Can you explain the concern a bit more? I'm loathe to add the complexity to the
Chromium side, and I'd rather keep the full fidelity here.

As far as I can tell, there's no other internal users of the Python script. It
appears to just be used by Chromium. Realistically, that means we should move
the Python script into Chromium, integrate it into the build scripts, and keep
those in sync - presumably, sourcing from the JSON. That way ensures everything
is kept in sync.

I don't think keeping the generator script outside of Chromium is something
sustainable/desirable.

[Eran Messeri, 2016-05-03 11:05:46]

Apologies for the late reply - I agree that overall it will be simpler if the
generator would be checked into Chromium.
It will ease changing the generator, for sure.

https://codereview.chromium.org/1888463003/diff/1/net/cert/ct_known_logs_stat...
File net/cert/ct_known_logs_static.h (right):

https://codereview.chromium.org/1888463003/diff/1/net/cert/ct_known_logs_stat...
net/cert/ct_known_logs_static.h:122: const int64_t disqualification_date;
On 2016/04/13 16:29:33, Ryan Sleevi wrote:
> On 2016/04/13 16:15:29, Eran Messeri wrote:
> > Can the date be specified in a non-internal way? That will allow us to
> continue
> > using the open-source Python script for generating this file (while
providing
> > the disqualification information).
> 
> Can you explain the concern a bit more? I'm loathe to add the complexity to
the
> Chromium side, and I'd rather keep the full fidelity here.
> 
> As far as I can tell, there's no other internal users of the Python script. It
> appears to just be used by Chromium. Realistically, that means we should move
> the Python script into Chromium, integrate it into the build scripts, and keep
> those in sync - presumably, sourcing from the JSON. That way ensures
everything
> is kept in sync.
> 
> I don't think keeping the generator script outside of Chromium is something
> sustainable/desirable.

I agree - seems like the generator should be in the Chromium code base.