On Wed, September 25, 2013 10:15 pm, Joseph Bonneau wrote: > I'd like some elaboration on the plan for step 6, creating a whitelist of > valid EV certificates without an SCT. How is this going to be achieved? > Also, if we could do this, why not do it for all certificates and > bootstrap > CT that way? Are the parameters of EV special for this (fewer certs, > better > records, etc.)?
Fewer certs, by many orders of magnitude, such that whitelisting is a reasonable approach. > > An alternate approach to a whitelist is to require SCTs for certs with a > "not before" validity period after time T (presumably this requirement > kicksn in around time T). With a stolen/compromised EV CA key you could > still issue a fraudulent cert and backdate it, so you'd have to more > strictly enforce the limits on validity periods for EV certs which I > believe are 27 months in the CA/Browser forum guidelines and 39 months in > the EV code-signing cert proposal. Of course this isn't attractive in that > it means years before you really have protection against fraudulent EV > certs. Has this approach been considered? > > Joe As you note, with a stolen/compromised EV CA key, you can still backdate certs. The whitelist approach balances the tradeoffs and brings the delta for practical checking on the client side down to a reasonable value and with acceptable (and negligible) performance overheads, which decrease over time. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
