Re: [keyassure] WebID at W3C and keyassure

[Henry Story <[e-mail]>]

On 11 Feb 2011, at 15:14, Phillip Hallam-Baker wrote:

> [Before reading this in the context of 'PKI vendor speaks', I would like to point out to people on the list that Comodo is now an announced provider of DNS services under the brand DNS.com.]
> 
> 
> It is not very clear to me what is being proposed here.

I was not proposing anything to start of with, other than to show at what level the protocols are similar. That of course cannot be a proposal, only a point of interest. 

Noticing that similarity was useful in helping me understand what keyassure is doing.  And understanding that similarity also led me to ask why you don't also allow one to publish the plain and simple public key  in addition perhaps to the 4 methods listed in section 2.2 of draft-4. My point there was that that should be enough to do a lot of what you want. See the ==IDEA== section. The supporting evidence for this is that this is enough for us at the WebID level. 



> Let's start from first principles. As far as internet users are concerned, an Internet user identifier is [e-mail]

In WebID we consider essentially an http url such as http://bblfish.net/#me as it is immediately dereferenceable,

> I know that there are people trying to peddle URIs as user identifiers but the success of that approach is evidenced by the fact that OpenID support is contracting rather than expanding.

There are many reasons why OpenId is having trouble. The main one being that the user has to remember what to type, and has to type it. With WebID this is integrated into the SSL layer, so the user only needs to point and click. There is a 4 minute video on http://bblfish.net/ (the second one) that demonstrates this. 

There is a whole list of other reasons why TLS works better, many of them I have gathered here
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_want_distributed_identity.3F


> 
> Given [e-mail] as the identifier, 
> 
> DNS is an appropriate mechanism to resolve attributes bound to the 'example.com' portion.

exactly. DNS is the Canonical lookup method for a DNS name :-)

> 
> DNS is an appropriate mechanism to use to discover a service that can resolve the 'user' portion for 'example.com

yes (though if it can be avoided then that can be better) But it gives some useful flexibility.

> DNS is not an appropriate place to store attributes specific to '[e-mail]'.

Completely agree. 

> 
> 
> We already have a Web Service that is designed to serve as a key centric distribution mechanism for per-user data and it happens to be a W3C recommendation - XKMS.

Thanks for pointing that one out. It looks like one of the SOAPy specs. This should be useful.
WebID is working within the linked data architectural space, where you put things at their URI location, and you try to restrict yourself to the RESTful verbs (GET, PUT, POST, DELETE)

> 
> I think it would be entirely appropriate to use DNS assured keys to validate an XKMS service. 
> We could also take the XKMS schema and use it within FOAF.

yes, so with WebID we use the DNS assured keys, to power up TLS, so that https becomes a way to validate the foaf document returned - that it has not been corrupted on the way. So that way we have part of the work of what XKMS does, but using simple HTTP. (Need to study XKMS in more detail)

> I think that there are many possibilities here. But they are way off topic for this group. 

Yes.


> Would it be possible for people interested in this area to Bar BoF in Prague?

(I am in Paris btw. But let me know).

Don't forget the issue that I raised that is relevant to this group, namely the idea of putting the public keys in DNS, without all the extra stuff.

Henry


> 
> On Fri, Feb 11, 2011 at 7:19 AM, Henry Story <[e-mail]> wrote:
> 
> On 11 Feb 2011, at 01:48, Paul Hoffman wrote:
> 
> > On 2/10/11 2:41 PM, Henry Story wrote:
> >> Keyassure will probably use the DNS-ID typed subject alternative name
> >> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes
> >> to identify the server as suggested is good practice by
> >> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3
> >
> > In your earlier message, you said:
> >
> >> (I have not seen a draft spec yet, and am going from the group
> >> description).
> >
> > Please do read the draft. What you say here, which predicates the rest
> > of your message about similarities with the WebID work, is not at all
> > correct.
> 
> Yes, I just read the draft dane 4
> http://tools.ietf.org/html/draft-ietf-dane-protocol-04
> 
> I don't think I was far off, but still perhaps too cryptic. In section 2.2 it states that there are four types of things that can be published in the TLSA record
> 
>  1 -- Hash of an end-entity certificate
>  2 -- Full end-entity certificate in DER encoding
>  3 -- Hash of an certification authority's certificate
>  4 -- Full certification authority's certificate in DER encoding
> 
> So if in 2 the certificate is a DER encoded X509 cert, then if it is a server certificate it should contain according to draft-saintandre the Domain Name in the SAN field. There are a few different types of SAN fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot closer to what you are specifying in the RDATA format. (Though it looks like that RFC could be improved to allow port numbers to be specified, as you do)
> 
> So if someone came across such a certificate with such a SRV-ID, they could after finding the SAN do a lookup in DNSSEC and verify that this is indeed the correct/current certificate. In some ways this is similar to finding an html page with a
>    <link rel="self" href="http://bblfish.net/"/>
> You could use it to lookup the current version of the page. What you have in your hand is a cached copy.
> 
> Now if you do one more little conceptual jump and you allow that one can name things including agents with an http(s) URI then he can put that URI in the SAN field. So I have a WebID
> 
>   http://bblfish.net/people/henry/card#me
> 
> Doing a lookup using HTTP will get the meaning of that URI - and so a description of me. That URI could return a PEM certificate too, just as you do in the DNS lookup (we are discussing allowing this in addition to RDF/XML, rdfa, or other XML representations)
> 
>   Good so I think we have two protocols - yours and WebID - that both can do the following and that are very similar in those respect:
> 
>   1. place an identifier in the X.509 SAN field.
>      - for keyassure this is a service identifier (SRV-ID)
>      - for webid this is a URI identifier
>   2. dereference the ID to get the latest version
>      - using DNS lookup for keyassure
>      - using HTTP/HTTPS/ftp... lookup for WebID
>   3. Proving authenticity
>   both protocols use the information retrieved canonically at the identifier to prove authenticity.
>      - with WebID the relying party uses the public key published there to verify that the agent connecting to it is indeed named by that URI. He is if he could prove in the TLS handshake that he knew the corresponding private key.
>      - with keyassure by proving that there is the appropriate link between the keys/signature published in 1-4 and the certificate sent by the TLS server.
> 
>   Essentially point 3 - proving authenticity - works because of what you name a trust anchor. I am just pointing out that this trust anchor is tied to a naming system and a canonical lookup procedure in both cases.
> 
>   Ok, so I think that demonstrates quite clearly that there are a lot of similarities. So what is the use of knowing that?
> 
>   Well I think for me that helps confirm my WebID intuitions. When I spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a few years ago, the possibility of something like keyassure helped me feel we could bypass the most damaging of his critiques against the current PKI setup. WebID does not need CAs, and with keyassure web servers won't need them either. We are still left with the clumsy ASN.1 format, but that can be solved over time with better parsers, or, since TLS allows it, to some better defined format such as binary xml perhaps.
> 
>   Another advantage of having two very similar protocols developing, especially as they are not stepping on each others toes, is that we may be able to learn a few tricks from one another. So here is one initial idea that occurred to me reading your spec today.
> 
>   == IDEA ==
> 
>   Currently you are publishing either a signature or a certificate in the DNS. Why not publish the only piece of the certificate that is important: the public key. This is what WebID does. This should be shorter than the certificate, and though it will be longer than the signature, it will be a lot more useful, tying you much less to a particular serialisation format.
> 
>  There is no need to send a full certificate. All you need is to tie a name to a public key and to guarantee to the end user the integrity of the information. But the integrity is itself assured by DNSSEC. The tying of the name to the public key is done by the lookup in DNS. So all that is really required is to return the public key - the type and the fields.
> 
>  One could then even imagine a TLS improvement where the server would not need to send his certificate either. All the TLS server would need to do is prove that he can encrypt something with his private key. The public key would be fetched from the DNS. So at that point we will have gotten rid of ASN.1 or at least just kept the minimum needed. This would be the server equivalent of the client_certificate_url extension of TLS 1.2 where the client can send a URL to a location of his certificate, instead of sending his certificate. Here the server would not need to send his certificate, and for self signed certificates, the DNS sending the public key would be enough anyway.
> 
>  So I hope this helps clarify the similarities of the two protocols as well as the usefulness of our interaction.
> 
> > This is not to say that what WebID is doing can't work with the DANE effort, just that we are doing completely different things. DANE is about getting a temporary trust anchor for a particular port/transport/domainname triple for a server, whereas WebID is about identifying clients through an HTTPS lookup. There has been discussion of using DANE to get a temporary trust anchor for S/MIME clients, and that might be extended to doing so for TLS clients, but it would be done using the DNS protocol.
> 
> yes, that is where each of us understanding the other could help see where some of these things would fit best. S/MIME it seems to me is closer to client authentication, and so would better fit in with WebID.
> 
>        Henry Story
> 
> [1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009
> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
>