Re: [keyassure] WebID at W3C and keyassure

Henry Story <henry.story@bblfish.net> Fri, 11 February 2011 12:19 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298BA3A6823 for <keyassure@core3.amsl.com>; Fri, 11 Feb 2011 04:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITuzEBNkn91q for <keyassure@core3.amsl.com>; Fri, 11 Feb 2011 04:19:54 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3D4CB3A688C for <keyassure@ietf.org>; Fri, 11 Feb 2011 04:19:53 -0800 (PST)
Received: by bwz12 with SMTP id 12so3418091bwz.31 for <keyassure@ietf.org>; Fri, 11 Feb 2011 04:20:08 -0800 (PST)
Received: by 10.204.14.6 with SMTP id e6mr383659bka.9.1297426807369; Fri, 11 Feb 2011 04:20:07 -0800 (PST)
Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id 12sm424811bki.19.2011.02.11.04.19.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Feb 2011 04:19:49 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <4D54876A.4090302@vpnc.org>
Date: Fri, 11 Feb 2011 13:19:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net>
References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
Subject: Re: [keyassure] WebID at W3C and keyassure
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2011 12:19:59 -0000

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