WebID-ISSUE-26: [WebID Spec]

WebID-ISSUE-26:  [WebID Spec]


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