W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

Turning every Web Server into a CA

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 3 Feb 2011 23:28:09 +0100
Message-Id: <09FB11BF-427D-4F57-BBB1-5616A73F6874@bblfish.net>
To: WebID XG <public-xg-webid@w3.org>

On 3 Feb 2011, at 20:03, Peter Williams wrote:

> concerning ISSUE-2: Explore the role of Issuer Alternative Names in WebIDs
> 
> I see two argument FOR working with IANs that are focussed on domains, vs http. I'd never considered this before coming her (IANs were always only about cert path linking and link-path discovery, before now).

I was thinking about something in this space yesterday, following on a thought you suggested a year ago.

In short: With DNSSEC and the IETF keyassure work [1] every server can become essentially a CA for free. This means that servers can sign the certificates of the WebIDs they hosts in a verifiable way. So if a user with such a WebID authenticates himself on some service somewhere (known as the Relying Party in OpenId land), that service will not need to necessarily dereference the WebID to trust it. It can simply check that signature to see if it is authentic by using the  public key published in the DNS. Of course this means it won't get the extra information at the WebID either, it means it won't know if the certificate is no longer valid, but it does make the system more reliable, and resistant to temporary downtimes of the server hosting a users WebID. 


To put this with in terms of a specific example that can speak to us a lot more. Let us imagine a Social Web Server (SWS) hosting a family, a company, a government or a churches members profiles. That SWS will allow users to create their WebID by using the html5 <keygen ...>  element, which will create a public/private key from the browser, send that public key to the server, which will then be able to use it create a certificate, which it can sign using its private key before sending it back to the browser. The private key will be the one it published in DNSSEC. Now the client has a certificate signed by a server. [2]

The person goes to some friend's SWS and logs in. His friends server will have to look up the WebID in DNS anyway, and get the public key for that DNS while it is at it. At that point it can already verify the authenticity of the client (modulo, the possibility that the client cancelled his certificate that only can be verified by dereferencing the cert), and can return the resource without having to let the user wait.

This removes the only criticism of WebID I could think of: the requirement for dereferencing the WebID all the time. Higher security services should dereference the WebID when an important transaction is going on.

Henry


[1] http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
    Still looking for their draft spec. I hope they publish a public key in the DNS.
[2] illustrated in the short video http://www.youtube.com/watch?v=S4dlMTZhUD
Received on Thursday, 3 February 2011 22:28:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC