- 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
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