[tor-talk] X509 S/MIME certificate. Was: Another fake key for my email address

Guido Witmond guido at witmond.nl
Tue Mar 11 12:30:46 UTC 2014

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.


With regards, Guido Witmond.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20140311/7ce1b5f3/attachment.sig>

More information about the tor-talk mailing list