Re: Turning every Web Server into a CA

I had written this out a little late yesterday. Just filling in a little here.

On 3 Feb 2011, at 23:28, Henry Story wrote:

> 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.

All a web owner has to do is 
 1. create a good public/private key pair 
 2. publish his public key in DNSSEC
 3. use the private key for the SSL layer and for signing certificates he creates

> 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.

I mean of course that it will be publishing the public key corresponding to that public key in DNSSEC.

> Now the client has a certificate signed by a server. [2]
> 
> The person goes to some friend's SWS and logs in.

Ie. He clicks the login button that points to a TLS end point that requests his client certificate, which he then sends.

> His friends server will have to look up the WebID in DNS anyway to verify it, and get the public key for that DNS while it is at it.

That is, having seen that the CA sent to it was not signed by any of the well known CAs, the server does a DNS lookup and fetches the public key published there.

> 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

Social Web Architect
http://bblfish.net/

Received on Friday, 4 February 2011 08:07:30 UTC