On Sun, Dec 16, 2012 at 7:52 AM, ianG <[email protected]> wrote: > On 16/12/12 02:41 AM, Ben Laurie wrote: >> >> On Sat, Dec 15, 2012 at 10:01 PM, James A. Donald <[email protected]> >> wrote: >>> >>> On 2012-12-16 6:23 AM, Andy Steingruebl wrote: >>>> >>>> >>>> given some of the more recent attacks against Google (and Facebook's) >>>> customers they believe that active MiTM is actually a real threat, and >>>> would >>>> rather not pretend to protect you from it when they aren't, by using a >>>> self-signed certificate that they haven't verified in any way, even by >>>> you >>>> presenting it. >>> >>> >>> >>> Recent MITM attacks have been by entities that are likely to be able to >>> coerce a CA. >> >> >> This is why you need Certificate Transparency. > > > > Actually, we need a secure and private authentication system. If I was > reading that in Gmail I'd suppose that it would transparently link to here: > > http://www.certificate-transparency.org/ > > ;) As you say, that idea is a research idea.
I didn't say that (that site may say it, I don't know, I haven't been keeping that site updated). In fact, Google is building it, right now. > We can only want it, we > cannot need it. I see several issues (4). > > Just looking at CAcert, by way of counter example. CAcert does not publish > its certificates because of privacy. That's actually quite a strong result, > and hard to avoid [1]. CT applies to public certificates. By definition, these are not private. If CAcert wants to issue private certs in a CT world, then I suspect some changes will be needed... > If one looks at Bitcoin or the recent many efforts > to track all certificates, this represents a gold mine of datamining > opportunities. Do our customers really want their security model to become > a public spectacle? Public certificates are already a public spectacle. I have no idea what Bitcoin has to do with this. > Also (2), the notion that an auditor would be a fair arbiter of what the > public wants is dead in the water. It's a non-starter. CT is not an arbiter of anything, it is an audit trail. > Also (3), as you > acknowledge, getting the CAs to change anything is difficult, the OODA cycle > is estimable at about a decade. I think we can move faster than that. CAs have already signed up to CT. > Which (thinking aloud) leaves cryptographic proofs that test the audit claim > needed, without revealing the certificate body. But that's a fairly tough > burden. Proving that my certificate is in the chain seems doable. But what > we are trying to prove is that every certificate is in the chain. Without > seeing every certificate. I do not agree that that is a goal. > Or more importantly, we want to prove that a certificate found in an MITM > was in the chain or not. > > But (4) we already have that, in a non-cryptographic way. If we find a > certificate that is apparently signed by say VeriSign root and was found in > an MITM, we can simply publish it with the facts. Verisign are then > encouraged to disclose (a) it was ours, (b) it wasn't ours, or (c) > mmmmummm... The point of CT is precisely to make it possible to find MITM certs even when you are not the victim. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
