ISSUE-26: take account of client_certificate_url extension in spec


take account of client_certificate_url extension in spec

Raised by:
Henry Story
Opened on:
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.

Related Actions Items:
No related actions
Related emails:
  1. Re: Formal WebID Teleconf Friday February 1 2013 15:00UTC (from on 2013-02-01)
  2. RE: WebID-ISSUE-26: [WebID Spec] (from on 2011-02-02)
  3. WebID-ISSUE-26: [WebID Spec] (from on 2011-02-02)

Related notes:

as with ISSUE-19 -- too complex for current efforts

Ted Thibodeau, 1 Feb 2013, 15:56:55

Display change log ATOM feed

Henry Story <>, Chair, Dominique Hazaƫl-Massieux <>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 26.html,v 1.1 2019/12/03 13:24:59 carcone Exp $