Oh, also: 4. Require SCTs for all certs in the chain, which prevents hiding the alternate intermediate.
On 15 March 2016 at 13:50, Ben Laurie <[email protected]> wrote: > On 14 March 2016 at 22:15, Rob Stradling <[email protected]> wrote: >> On 14/03/16 21:39, Ben Laurie wrote: >>> >>> On 14 March 2016 at 14:39, Stephen Kent <[email protected]> wrote: >>>> >>>> The logged bogus certificate can be detected by a Monitor (third party or >>>> self), that is watching the log(s) to which the certificate was posted. >>>> Thus >>>> the detection aspect of CT still works with regard to this certificate. >>>> When >>>> this certificate is detected, the CA that logged the certificate may >>>> revoke >>>> it, i.e., place it on a CRL or create an OCSP response for it. However, a >>>> browser checking a CRL or OCSP response will not match this revocation >>>> status data against the other, not-logged bogus certificate. (This is >>>> because revocation status checking is performed in the context of a >>>> certificate path and the two bogus certificates have different >>>> certificate >>>> paths.) Revoking a detected, bogus certificate may be the best strategy >>>> for >>>> the malicious CAs. It makes issuance of the bogus certificate appear to >>>> be >>>> an accident, and thus browser vendors may not feel the need to make an >>>> entry >>>> on their blacklists for the bogus certificate or the CA that issued it. >>> >>> >>> I do not believe this is correct. And if it is, it is a serious bug in >>> revocation that has nothing to do with certificate transparency. >>> >>> Also, I don't get the logic of the "not-logged bogus certificate", >>> which is identical to the logged certificate - and is therefore >>> logged. And not bogus. >> >> >> +1 >> >> The "two" bogus certificates are one and the same. They will contain the >> same CRL and/or OCSP URLs. The outcome of a CRL/OCSP check will be exactly >> the same for both certs. >> >> AIUI, for DKG's attack to work, it is necessary for: >> - the "two" bogus certificates to _not_ be revoked. >> - one of the doppelganger intermediates to be logged and revoked. >> - the other one (or more) of the doppelganger intermediates to be neither >> logged nor revoked. >> >> I think that there are two possible ways to thwart this attack: >> >> 1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain >> Timestamps) - i.e. the signature is calculated over the entire chain >> submitted. I think this is unworkable, because there are too many cases >> where different chains are legitimate and even expected. >> >> 2. Declare that this is not a problem with CT. It's a problem with using >> CRL and/or OCSP to revoke intermediates. So we (where "we" may or may not >> be TRANS) need to fix revocation! >> Revoking an intermediate _certificate_ just isn't sufficient. >> To be effective, the intermediate _public key_ needs to be revoked somehow. > > 3. Always revoke bad certs that appear in logs! _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
