On 03/10/14 13:11, Guido Witmond wrote: > On 03/09/14 20:25, Erinn Clark wrote: >> Hi everyone, >> >> In September last year I discovered a fake key for my torproject.org email >> address[1]. Today I discovered another one: >> >> pub 2048R/C458C590 2014-02-13 [expires: 2018-02-13] >> 1. That is NOT MY KEY. Do not under any circumstances trust anything that may >> have ever been signed or encrypted with this key. I looked around and was >> unable to find anything, but nonetheless, it is out there and that is creepy. > > > Hi Errin, > > The problem you mention here is that there is no way to verify who a > certain public key belongs to. > > I could not even verify yours. Replying to my own post: I would like to offer my suggestion for a solution to this problem. GPG has shown it only protects if someone can trace a path through the web-of-trust that they can trust. The Tor project has a different requirement. It needs to have a world wide global identity that states who is the package builder. Verifiable to anyone. Without them to enter the web-of-trust. That would defeat their anonymity requirements. The protocol for that is: *X509 S/Mime*. I don't consider that to be a 'dirty word'. An X509 certificate is effectively like a digital passport, verifiable to anyone who trusts the CA that signed it. The global cabal of Certificate Authorities are not the ones to provide that trust. For the sole reason that there was never a way to tie a domain name to a certificate authority. Any CA could sign any domain name. And every browser would accept every CA, shifting Erinn's problem to the torproject.org level. With DNSSEC and DANE, we have that missing link. DANE allows site operators to specify what CA they use for their site. It could be allows to set up your own CA and specify that. Here's why I think it can be used to solve the impersonated key problem: 1. The torproject admins create a private key and a self signed Root Certificate, say 4k RSA. 2. The admins create a server certificate for www.torproject.org and sign it using their own Root Certificate. 3. They publish the Root Certifificate fingerprint (or the whole public key) in a TLSA (DANE) record and sign their DNS-records with DNSSEC. These steps let every browser validate (via DNSSEC delegations) which is the Root Certificate for Torproject. The Firefox extension "Extended DNSSEC Validator" does that. 4. Then the project members create a private key and request a certificate at the admins. The admins sign it with the correct flags. Erinn would get a S/MIME certificate with message signing and object signing capabilities. Jacob could get a message signing certificate but no object signing. I, not involved in torproject except as relay operator, would not get a certificate bearing the torproject name at all. This is how the admins can delegate trust. I can trust the torproject-admins not to signs two different certificates bearing the name Erinn. And I can trust the tor using community to oversee the admins. Each of the Tor project members would keep their GPG-keys for private communication. S/MIME signed messages are for project use. Comments? With regards, Guido Witmond.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk