Bug 1349312 will add a basic positive and negative test case for certificate transparency integration tests. We need some more: (this is directly from an email I sent on the 26th of April) To determine what we need here, I came up with a list of reasons why an SCT might not be valid: * invalid signature * invalid data/encoding * future timestamp * duplicate of another SCT (so it adds no new information) * from the same log but with a different timestamp (I'm actually not sure if this is invalid, but it seems like it should be) * from the same log but precert_entry vs. x509_entry (again, I'm not actually sure if this is invalid) * from an unknown log * from a disqualified log with a timestamp after the disqualification time For each of {embedded SCTs, TLS handshake / OCSP stapled SCTs}, we should test that for each of these reasons, if there aren't otherwise enough valid SCTs, the platform should consider that connection as not passing CT checks. We should also test that if there are otherwise enough valid SCTs, the platform should consider the connection as passing CT checks. We also need to check that the platform does the right thing during session resumption (if a connection passed CT checks before, it should again, and if not, then it shouldn't upon resumption). Finally, from my reading of the specification, it seems SCT information from OCSP must be stapled, but as far as I can tell, the current implementation does not enforce this. That is, the platform will both note SCT information gleaned from active OCSP responses and cache SCT information from previous connections such that it could make use of them in connections where that information is not present. I'm not sure if this is a feature or a bug. Either way, we should add tests to ensure the implementation behavior doesn't change unintentionally. There are also a couple of one-off cases to consider: * a certificate with a longer lifetime such that there aren't enough SCTs * ensuring that SCTs from a disqualified log with timestamps before the disqualification time are valid * SCT collections with insufficient log operator diversity (we require at least 2 currently)