Not interleaving this time, but batch-replying: On 23 February 2016 at 04:41, Rob Stradling <[email protected]> wrote: > 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?
Yes. >>> [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 That's beneficial for our purposes though. > <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". ;-) What's the risk to clients who don't? Currently, in gossip clients who don't want to fetch proofs (because it's unacceptable to them privacy-wise or whatever) can use SCT Feedback. (If they talk to a site that doesn't use SCT Feedback, then they're sunk, but we hope this and other incentives will encourage uptake of SCT Feedback.) Because the say the client MUST submit the full chain in SCT Feedback... I think SCT Feedback does actually cover the clients who don't get the inclusion proof for the intermediate. And it would be simple enough to add the SHOULD to STH Pollination to grab a STH for the intermediate cert and pollinate that. So now I'm less worried. On 23 February 2016 at 05:06, Ben Laurie <[email protected]> wrote: > On 23 February 2016 at 06:03, Tom Ritter <[email protected]> wrote: >> 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. > > Hmm. That would be e and e + phi(n), I guess? This is a good walkthrough: http://crypto.stackexchange.com/q/8902 On 23 February 2016 at 19:59, Daniel Kahn Gillmor <[email protected]> wrote: > On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote: >> Fair point. At least two ways of doing this: >> >> a) Run a log that is not trusted for HTTPS connections. > > (trolling: i thought logs didn't have to be trusted...) > > what encourages any party in the ecosystem to log in this untrutsed log? Technically we don't need CAs to log to that log, the community can log to it. Google Crawler, the EFF's Distributed HTTPS Observatory, Firefox plugins, replication from other logs... On 24 February 2016 at 05:20, Rob Stradling <[email protected]> wrote: > Actually, issuer_key_hash is already included in the > TimestampedCertificateEntryDataV2 structure from which leaf hashes are > calculated. I think that's sufficient to guard against inclusion proofs > being considered valid in conjunction with a trick issuer public key (but > please correct me if I'm wrong!) To be 100% honest I have not tracked -bis as closely as I should have. So I need to take a pass through gossip and make sure that the types of things I expect 'intuitively' from bis align with what it provides. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
