Re: [keyassure] publishing the public key

[Henry Story <[e-mail]>]

Ok so the following off list conversation between me and Paul, should have helped reduce the 
bandwidth pressure on the group. I'll send it back to the list because I think that at least
I am in sync with how Paul is thinking, so that should help.

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

> On 2/22/11 9:28 AM, Henry Story wrote:
>> 
>> On 22 Feb 2011, at 18:23, Paul Hoffman wrote:
>> 
>>> On 2/22/11 9:14 AM, Henry Story wrote:
>>>> The TLS protocol currently has the server send the client a
>>>> certificate. The client then just needs to look in DNS to find out if
>>>> the public key in the certificate sent by the server matches the
>>>> public key for the service in DNSsec. So bare public keys in DNSsec
>>>> should work.
>>> 
>>> You have yet to say how the TLS client knows what the public key is for the cert they get in TLS. This was discussed multiple times on the list, and (all?) the other supporters of bare keys have agreed that this is not a trivial thing to do, and have backed down from it. You haven't even addressed the issue. Instead, you keep coming back to "we want to do this in WebID".
>> 
>> Does the following sound ok, or am I answering a different question:
>> 
>> 1. TLS client receives cert from TLS server.
>> 2. TLS client extracts key from cert using normal x509 libs
>> 3. TLS client looks up hosname:port in DNSsec, and finds the bare key
>> 4. TLS client matches key found in 2 with the one found in 3
>> 
>> Is that the kind of thing I should send to the list?  I am not sure at which point the problem arises.
> 
> You can send it to the list, but as has been said on the list already, normal X.509 libraries do not let you extract the key. The few that do might have it in different formats, so doing a direct comparison is impossible. So it feels like the relevant part of your list, step 2, is not based in reality. If you can show me wrong, that's great, but if not, you posting the above list doesn't really help.

Ok. So at this point we are back to WebID.  I am speaking here of WebId only because we needed the same tools as you need in Dane. So we have some experience - not perfect - to go by.
   
  WebID  also requires the public key from the X509 certificate to be extracted. It needs to be extracted on the server (in Dane it will be on the client), and the certificate is the client certificate (in Dane it is the server certificate), but the tools to do that will be the same. 

  http://esw.w3.org/foaf+ssl has listed the many implementations of the above on servers for every widespread programming language. That is we have WebID working in perl, python, c, java, ruby(?), javascript, and others....  Now it is true that for php and javascript there was a lack of ASN.1 parsing tools, so people initially used opensso to parse the key, and extract the relevant information that way. Not very nice but we were trying to see if it works.

The Scala code which we can launch directly into the java SSL layer, and which is an OSGI component is here

https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.security.foafssl/core/src/main/scala/org/apache/clerezza/foafssl/ssl/X509TrustManagerWrapperService.scala

as you can see there getting the public key from the certificate is one line of code

    val publicKey = cert0.getPublicKey


In WeBID there is a reason to publish the "bare" public key in a web format such as XML, RDF, html, ... If one wants to put they key in HTML it makes more sense to put the key in a format where people can verify visually the correspondence with what their browser tells them. A big ugly PEM blob is just in my view too much of an eysore, and contains too much mystification.

This issue does not perhaps exist in the same way in DNS and so with DANE, as I think the format there is also quite old, and it is unlikely that people will be looking at DNS records without tools. I just don't know that aspect of DNS very well, so I may be wrong.

   I think that if there were java libs to do a DNSSEC lookup it probably would not be that much work to change the SSL layer reasoner to do a Dane lookup. 

	Henry




Social Web Architect
http://bblfish.net/