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

[Rob Stradling <[e-mail]>]

On 23/02/16 06:03, Tom Ritter wrote:
<snip>
>> [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.

SCTs in 6962-bis already contain the issuer_key_hash (which is the DER 
encoding of the issuer's SubjectPublicKeyInfo).  Is that enough to 
defeat your trick key attack?

Hmmm, I wonder if we need to add issuer_key_hash to inclusion proofs as 
well (i.e. the InclusionProofDataV2 struct) ?

>> [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...?

For Win2K and WinXP, it appears that it only attempts name matching if 
the AKI extension is absent.

"If there is no information in the AKI, or the AKI does not exist in the 
certificate being evaluated, a certificate whose subject name matches 
the evaluated certificate's issuer name will be chosen. This selection 
method is known as a name match."
https://technet.microsoft.com/en-us/library/cc700843.aspx

I can't find any more recent documentation.  :-(

<snip>
>> [Rob]
>>    - say that TLS clients SHOULD fetch and verify inclusion proofs for all
>> intermediate certs that they rely on.
>
> I'm nervous about this.

Why so?  I wasn't suggesting a "MUST".  ;-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online