W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

WebID-ISSUE-26: [WebID Spec]

From: WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 02 Feb 2011 13:51:44 +0000
To: public-xg-webid@w3.org
Message-Id: <E1Pkd7Y-0006DE-Gu@lowblow.w3.org>

WebID-ISSUE-26:  [WebID Spec]

http://www.w3.org/2005/Incubator/webid/track/issues/26

Raised by: Henry Story
On product: WebID Spec

On 2 Feb 2011, at 00:51, Peter Williams wrote:

> So what really matters, I implore, is focus of the design here is 
> on the properties of the handshake ( a well defined SEF), not the cert. 
> The cert is just one side-effect output thereof - upon which one then 
> can do exactly what you did - fashion a means of searching the graph 
> of profiles to chain together trust points that  talked to each other 
> "about" the subjects of certs (URIs).

Ok, attempting to paraphrase the above. 

When the TLS client responds with a Certificate or CertificateURL message it then needs to follow that by a CertificateVerify message where it proves that it owns the private key of the public key, that was (previously) named by a URL [1] or passed by value (SSLv3 default). 

The public key is found one way or another. In future extensions it could be found in the remote  Profile document in one of a number of content negotiated formats,  as suggested in ISSUE-19, and so there may be no need for X509 at all.

The spec text may need to take account of the possibility of the TLS v2 client_certificate_url extension [1], but without making it overly complicated to read.

This would be a  minimal TODO arising out of ISSUE-19.

[1] http://tools.ietf.org/html/rfc4366#page-12
Received on Wednesday, 2 February 2011 13:51:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC