Re: [keyassure] publishing the public key

On 22 Feb 2011, at 16:38, Paul Hoffman wrote:

> Henry: It feels like you are pushing for DANE and WebID to have "bare public key" as a way of doing certificate identification without justification for how this could be useful in DANE.
> Without taking any stance on WebID, I find this frustrating as the document co-author in DANE. The two protocols do not have the same targets and do not even run over the same transports.
> Could you please re-split the discussion and, in the DANE part, be much more specific about how you see bare public keys in DANE being used with just TLS? Thanks!

So splitting the discussion here, and stopping the cross posting.

Advantages for DANE
===================

I think my main reason for why this could be better for DANE were:

- much shorter entry in the DNS, which has to be fast and efficient
- simpler to understand (few people understand what is in X509)

I understand why others think that it's easier to put a full X509 in the DNS. The parsing libs are there, and there is the idea that they could re-use the semantics of X509, which I don't have enough understanding of. 

 So just by myself I would not know at this point what the right thing to do is. I hope my arguments have helped sort out some good arguments from some less good ones so that the right decision, whatever it is can be made.

WebID will work logically just as well with DANE if it has full X509 certs in the DNS as if it has bare public keys - especially if whatever the outcome, browser vendors adopt DANE for the purpose described in 1 above. 

WebID is putting bare public keys in the Profile Pages, so I was wondering why DANE does not do it too. 

Reasons for interest of WebID
=============================

Here are a few reasons for my interest in DANE, which does not get to answering the bare public key part of your question, but I'll just use it to frame my recent contribution.

1. DANE should make it easy for the self signed https end points that are currently 3 times more numerous than CA signed https end points to be authenticated by browsers. Those browsers will no longer need then to display ugly warnings messages that users are now taught to bypass. This is good for https, for security and so for WebID

2. The cheaper and easier https endpoint deployment is the better for WebID. Dane should make that possible I hope by allowing site owners to publish the public keys (bare or inside X509 certs) for the services in DNS

3. DANE and WebID are using different transports but the authentication logic are nearly the same. Where Dane can be used to authenticate servers, WebID is used to authenticate clients. Semantically it's nearly a mirror image - though WebId would end up building on top of DANE.


	

Henry


Social Web Architect
http://bblfish.net/

Received on Tuesday, 22 February 2011 16:25:55 UTC