Re: [Trans] can CT defend against dual CA compromise?

[Tom Ritter <[e-mail]>]

I'm interleving Ben's and Rob's responses here:

>> Note that in this scenario, it's unlikely that space-constrained
>> blacklist-style client updates (e.g. CRLset) will include every leaf
>> certificate that chains to A after A is known-compromised.  So TLS
>> clients won't necessarily be warned off of C directly.
>
> [Ben]
> It seems to me there are multiple solutions here. The easiest is to not
> blacklist A_X, but instead to blacklists A_X's subject, which will also
> blacklist B_X.

Perhaps.

> [Rob]
> I think that blacklisting the shared issuer public key would be better than
> blacklisting the shared issuer name.

At first glance, I agree - but there is that annoying trick where you
can generate multiple (or at least two) public keys that all certify
the same signature. So I'm not sure this would actually work.

> [Rob]
> AIUI, MS CryptoAPI prefers to build certificate chains using the
> Authority/Subject Key Identifiers, and it only cares about whether or not
> the Issuer/Subject Names match if AKI/SKI are absent.

AKI would _not_ match on these trick public keys, but presumably the
algorithm would fall back to the Issuer name...?

> [Ben]
> To be more selective, blacklist the individual certs that were mis-issued
> (we have a complete list, of course, in the logs) and stop accepting new
> certs signed by X.

The "stop accepting new certs" thing might trip us up. We would like a
mechanism to track the misissued certs of a compromised CA. Trust
Stores have age. We don't distrust X all at once, and it'd be good to
know what X is doing so we can understand our risk on the older
devices.


>>  * logs could refuse to log any certs that chain back to a known-failed
>>    CA (or through a known-bad intermediate CA).  This would constrain a
>>    dual-compromise attacker from minting new certs after the first CA is
>>    known to be compromised.  This seems like a useful mitigation, but
>>    it's also complictated and delicate.  What does "known-failed" mean?
>>    What if there is a dispute over the validity of a cert, with one
>>    party claiming that it was misissued, and the CA claiming its
>>    legitimacy?  What if some browser vendors have dropped the CA, and
>>    others have not?  This puts the logs in a position of being some kind
>>    of arbiter of the root store, with very subtle knock-on effects to
>>    security of the whole ecosystem if they decide to not drop a CA.
>
> [Ben]
> Not all that subtle, surely, and completely visible so we can see its going
> on...

As I said above - up until here the CT logs have been a good viewpoint
on the CA ecosyetem. Aggressively removing CAs seems dangerous from a
"track the ecosystem and ensure accountability" perspective.


> [Rob]
>   - say that TLS clients SHOULD fetch and verify inclusion proofs for all
> intermediate certs that they rely on.

I'm nervous about this.

-tom