[148186] in cryptography@c2.net mail archive
Re: [Cryptography] Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (James A. Donald)
Fri Nov 15 13:04:12 2013
X-Original-To: cryptography@metzdowd.com
Date: Fri, 15 Nov 2013 16:02:44 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
In-Reply-To: <CAHOTMVJ=rhGhgeZ6a4aLKOcRwvj7CpnXF64+V4XH4GPVxjzrVA@mail.gmail.com>
Reply-To: jamesd@echeque.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 2013-11-15 05:50, Tony Arcieri wrote:
> And what of other solutions like CT or Tack?
With CT, when your browser hits a site, gets a certificate, it needs to
check if the certificate is in a CT file, which is cryptographically
secured to be the same for everyone.
But, if you have check each newly encountered certificate in real time,
why does it need the CA's signature? (Other than to avoid threatening
the CA business model.)
The social mechanism underlying CT is:
1. not everyone is allowed to write to the CT files. It is a valuable
privilege.
2. the cryptographic properties of CT files make it easy to detect
misbehavior.
3. Denying someone the right to make further writes to the CT files is
not disruptive, whereas trying to delete a CA is immensely disruptive,
thus the threat to withdraw the privilege to write to CT files for
misbehavior is far more credible than the threat to take a CA off the
browser CA list.
This being so, why should we care about CA signatures? If a certificate
is in the CT files, that is far more credible evidence of being a good
certificate than if it is signed by a CA. Let us allow all domain name
registrars to write to the CT files, conditional, of course, on correct
behavior.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
