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.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
