[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] X509 S/MIME certificate. Was: Another fake key for my email address - WebID
On 11 Mar 2014, at 21:52, Guido Witmond <guido@xxxxxxxxxx> wrote:
> Public response to a private message
>
> On 03/11/14 16:35, (..xxx..) wrote:
>> On Tue, 2014-03-11 at 13:30 +0100, Guido Witmond wrote:
>>> 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.
>>
>> Hey Guido, I think this idea is interesting, but I thought that
>> DNSSEC was just as centralized as the CA infrastructure. What
>> prevents the DNS authorities from acting in the same manner as the CA
>> cartel?
>
> Hi, (xxx)
>
> DNSSEC and DANE change the landscape.
>
> 1. With DNSSEC and DANE you don't need one of the global CA certificates
> anymore; You can run your own CA. If that proves too difficult , you
> might outsource it to one. This puts the global CA in a position where
> they have to provide value for service, instead of just rent-collecting
> for a green url-bar.
>
> If these global CA's are smart they would offer services where they will
> guard your own Root CA key. But I can dream...
>
> 2. DNSSEC itself is quite a hassle to set up and run correctly too. It's
> best to outsource that to a DNS-registrar. Although this is still a
> niche market for DANE records in DNSSEC, the same market forces apply.
> If not satisfied with one registrar, take your domain name and shop for
> another registrar.
>
> 3. The registrars in the DNS-hierarchy can still be persuaded to delete
> your certain domain name. (censorship.) Or point it towards a different
> server (hijacking). I'll show later how to protect against that.
>
>
> When everyone can run their own Root CA, all sorts of new avenues open up.
>
> With their own Root CA, companies can provide certificates for their
> spokespeople. Or they can sign certificates for clients (at a slightly
> different domain name). This way, banks can send out encrypted
> statements directly to customers. No more emails asking you to log in
> with a username and password. This reduces MitM attacks drastically.
>
> It increases privacy, I would have a certificate for each of my banks,
> one for my pension fund. Another at this mailing list and yet another at
> another mailing list. My browser would keep them apart.
>
> With a small addition to the browser, it can make sure that it only
> offers me client certificates to log in at the server whose server
> certificate has been signed by the same Root CA. This makes logging in
> even easier for the end user. And it really eliminates MitM-attacks.
> While crooks can create a pixel-perfect copy of a banks' site, the
> crooks cannot impersonate the Root certificate of the bank, so the
> browser will correctly identify the crooks' site as a different site and
> not offer my banks' client certificate to log in. My browser protects me
> against phishing.
>
> We can go one step further. It is the Root CA of a site that is used to
> select the client certificates that the browser offers the user to log
> with. The domain name is not used in the selection. It means that the
> site owners (who own their own Root CA) can create a new domain name,
> sign a server certificate using their root CA and point these new
> DNS-records to their server. The site has changed domain name but the
> client certificates stay valid. How's that for censorship resistance?
Completely agree, except that I think one can do better with ClientCertificates
by using WebID http://webid.info/spec/ . These allow one to create certificates
witout even needing a CA at all (given DNS-SEC and DANE )( We just released a new
more modular spec at the W3C for that )
I am developing an implementation of WebID+TLS+LDP+WebAccessControl in a small
company http://stample.co/ . Some available info:
• git wiki https://github.com/stample/wiki/wiki
• main git repo: https://github.com/stample/rww-play
This currently does not use TOR, but it should not be too difficult to add.
We are just doing the "simple" things first.
Btw. there was an interesting thread on the TLS mailing list recently on
an improvement for TLS1.3
http://lists.w3.org/Archives/Public/public-webid/2014Mar/0022.html
For those of you who are really good at crypto, please follow up on those.
Much more info on http://bblfish.net/ on these protocols.
All the best,
Henry
>
>
>
> But that is the realm of what I call Eccentric Authentication.
>
>
> With regards, Guido Witmond.
>
> --
> 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
Social Web Architect
http://bblfish.net/
--
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