On Fri, Sep 09, 2016 at 12:41:31PM +0100, Rob Stradling wrote: > For CAs that are on (borrowing Matt's wording) "quintuple secret > probation" due to a "history of shenanigans with notBefore dates", > browsers could require that: > 1. The certificate MUST be "CT qualified" via SCTs embedded in the > certificate. (SCTs distributed by the two TLS extension mechanisms are > not permitted for these CAs).
I'd be OK with SCTs delivered via TLS extension or OCSP stapling, as long as the SCTs had an appropriately aged timestamp. That's not practical for site operators to enforce, but from an "assurance of non-backdating" perspective, it'd be fine. The problem with embedding precert SCTs into the certificate is that in order to ensure compliance, *every* cert (including previously issued certs) from the CA in question must have the SCTs embedded (you can't use notBefore as a cutoff, because that's the problem we're trying to solve!). That means that every site operator of the CA in question has to get a new cert issued and installed. If we're going to force every site operator to get a new cert, we may as well just pull the root and force site operators to get a new cert issued from a different CA entirely. It's the same amount of effort for site operators, and avoids the need to modify user agents to cope with checking SCTs against notBefore. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
