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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
