European Data Retention and Encryption for Dummies
Hi everyone, I've been on this list before, but didn't have time for it
for a while. Now I'm back because I need some input:
You probably heard that the EU is currently passing data retention
laws. One part of them would require that ISPs keep logs of customer
traffic. It isn't entirely clear what exactly they need to store, but
the discussion goes into URL storage (i.e. what file on which virtual
host) and even full data storage (i.e. copies of the IP packets).
Obviously, at least the later is bullshit. However, it is absolutely
possible that it's just a smokescreen and the usual "compromise" will
be that the ISPs don't have to store the data except on request...
Enter a simple idea to solve the obvious privacy problem, at least in
parts. We do have the infrastructure in place to achieve end-to-end
encryption for the by far most-often-used web services, all we need is
to use it. I am, of course, talking about HTTPS and SMTPS.
Setting up apache so that it does HTTPS instead of HTTP, and all
requests to HTTP pages are redirected to a page pointing to the HTTPS
equivalent and explaining why is trivial.
Getting the various MTAs to use SMTPS isn't too difficult, either.
The problem with both is the need of SSL certificates. So I was
thinking of setting up a "Joe Doe's CA". A simple webpage where you can
request a certificate. It would do two check:
a) check if IP you are using is identical to the IP you are requesting
for, i.e. you'll have to ssh into your webserver and use lynx from
there.
b) the certificate will be mailed to the admin-c of the domain you
requested it for (whois lookup).
This is not 100% secure, but then again how much checking does Verisign
really do on certificates? I believe this is "good enough" in that it
establishes a reasonable safety that you are talking to the right site,
at least much better than regular HTTP can offer.
The purpose of this is to get as many sites to switch to using HTTPS
and SMTPS as possible. Therefore, the required work must be kept
minimal. Once considerable parts of the internet traffic are encrypted,
they can pass as many data retention laws as they please.
Any comments? What did I miss? Where does this idea come apart? Does it
make sense at all?
--
New GPG Key issued (old key expired):
http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt
Tom wrote:
The problem with both is the need of SSL certificates. So I was thinking of setting up a "Joe Doe's CA". A simple webpage where you can request a certificate. It would do two check:
a) check if IP you are using is identical to the IP you are requesting for, i.e. you'll have to ssh into your webserver and use lynx from there.
b) the certificate will be mailed to the admin-c of the domain you requested it for (whois lookup).
I have been meaning to set up a similar CA for years now, but never found the time. While you are at it, you might want to configure your CA to offer S/MIME certs subject to an email ping. (Which is what exactly what Thawte (a.k.a. VeriSign) is using to authenticate their free S/MIME certs). Make sure that your CA will only sign sufficient size keys, responding with a meaningful error message if a smaller key is submitted. There is a commercial SSL cert provider with roots in the browsers that uses just authentication method b) that you propose. However, for your CA, I would recommend doing away with b) since that will limit even "legitimate" (whatever that would mean in this context) users of your CA. Do a whois on cypherpunks.to to see why b) won't work for everybody. If you don't care about serving users of some CCTLD's, you can leave b) in. Your CA, your CSP. YMMV, --Lucky
I strongly support your idea. Although it would even be more
useful if you added:
c) e-mail address user certs authenticated via confirmation
message sent to the e-mail address being certified
(as Lucky suggested)
d) fully enable all certificates for all purposes, thereby
allowing the certificate to sign code.
I hope that you are able to implement this idea, as all efforts
to increase the volume of encryption on the internet will
ultimately increase privacy and show strong public support for
cryptography in general.
Curt
--- Tom
Hi everyone, I've been on this list before, but didn't have time for it for a while. Now I'm back because I need some input: ... Setting up apache so that it does HTTPS instead of HTTP, and all requests to HTTP pages are redirected to a page pointing to the HTTPS equivalent and explaining why is trivial. Getting the various MTAs to use SMTPS isn't too difficult, either.
The problem with both is the need of SSL certificates. So I was thinking of setting up a "Joe Doe's CA". A simple webpage where you can request a certificate. It would do two check:
a) check if IP you are using is identical to the IP you are requesting for, i.e. you'll have to ssh into your webserver and use lynx from there.
b) the certificate will be mailed to the admin-c of the domain you requested it for (whois lookup).
This is not 100% secure, but then again how much checking does Verisign really do on certificates? I believe this is "good enough" in that it establishes a reasonable safety that you are talking to the right site, at least much better than regular HTTP can offer.
The purpose of this is to get as many sites to switch to using HTTPS and SMTPS as possible. Therefore, the required work must be kept minimal. Once considerable parts of the internet traffic are encrypted, they can pass as many data retention laws as they please.
Any comments? What did I miss? Where does this idea come apart? Does it make sense at all?
===== end eof . Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
participants (3)
-
Curt Smith -
Lucky Green -
Tom