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@lemuria.org> Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
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 <tom@lemuria.org> wrote:
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