ISSUE-26: take account of client_certificate_url extension in spec
bblfish
take account of client_certificate_url extension in spec
- State:
- POSTPONED
- Product:
- WebID-authn-TLS-spec
- Raised by:
- Henry Story
- Opened on:
- 2011-02-02
- Description:
- 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
- Related Actions Items:
- No related actions
- Related emails:
- Re: Formal WebID Teleconf Friday February 1 2013 15:00UTC (from henry.story@bblfish.net on 2013-02-01)
- RE: WebID-ISSUE-26: [WebID Spec] (from home_pw@msn.com on 2011-02-02)
- WebID-ISSUE-26: [WebID Spec] (from sysbot+tracker@w3.org on 2011-02-02)
Related notes:
as with ISSUE-19 -- too complex for current efforts
Ted Thibodeau, 1 Feb 2013, 15:56:55Display change log
