As documented in the EV/CT Plan, certificates defined to meet the CT policy must meet one of the following:

1) At least the number of certificates in Table 1 (varies based on cert validity period), all of which must be qualified or pending qualification at time of issuance, all of which must have been accepted prior to the TLS handshake, with at least one Google log and at least one non-Google log
2) Two or more SCTs from logs that are qualified at the time of TLS handshake, embedded within a stapled OCSP response, with at least one Google log and at least one non-Google log. All SCTs delivered via this mechanism must be qualified at the time of TLS handshake.
3) Two or more SCTs from logs that are qualified at the time of TLS handshake, embedded within the TLS extension, with at least one Google log and at least one non-Google log. All SCTs delivered via this mechanism must be qualified at the time of TLS handshake.

In addition to the above, at least one SCT must be from a log qualified at the time of TLS handshake.


Chromium currently diverges from this in several ways:
* It will accept 1 qualified SCT delivered via OCSP, and 1 qualified SCT delivered via TLS extension
* It will accept 2 qualified SCTs delivered via OCSP (from a non-Google log), with 1 qualified SCT delivered by embedded in the certificate (from a Google log)
* It does not require all SCTs delivered via TLS or OCSP Stapling to be qualified at time of check

By separating out the "Google/non-Google" compliance check and the "minimum number of qualified SCTs", it effectively allows a mix/match.

Unfortunately, the above logic makes it significantly more confusing to handle the "accepted at time of issuance (but no longer qualified)" logic necessary to handle distrusting logs. We should update the policy or implementation.