- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 10 Mar 2014 20:35:12 +1100
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- Cc: public-webid <public-webid@w3.org>
Agent = a certified or authorised actor of a legal entity? A machine or account is not a legal entity; vs. a natural or incorporated legal entity. Therein, a legal entity provides a machine the authority to do something on it's behalf.... Ie: I authorise my rww data space to share specific protected resources / data, to others (inc other agents) on my behalf without human intervention on an event basis? A bit WAC (or alternative) but hope u see the webID/foaf/IoT (Internet of things / web of things) concept therein... Timh. Sent from my iPad > On 10 Mar 2014, at 8:23 pm, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote: > > The draft-thomson-tls-care comes with a draft-thomson-httpbis-catch. > I wrote to the https-bis mailing list with the following suggestion. > > Begin forwarded message: > >> From: "henry.story@bblfish.net" <henry.story@bblfish.net> >> Subject: Re: FYI: proposal for client authentication in TLS >> Date: 10 March 2014 10:16:01 CET >> To: Martin Thomson <martin.thomson@gmail.com> >> Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tim Berners-Lee <timbl@w3.org> >> >> >>> On 9 Mar 2014, at 08:37, Martin Thomson <martin.thomson@gmail.com> wrote: >>> >>>> On 8 March 2014 11:39, Martin Thomson <martin.thomson@gmail.com> wrote: >>>> Pursuant to our discussion on TLS renegotiation, I've submitted part 1 >>>> of the solution I proposed as an internet draft. >>>> >>>> http://datatracker.ietf.org/doc/draft-thomson-tls-care/ >>>> >>>> If we agree to a mechanism whereby we augment the 401 status code with >>>> a "go away and make a new TLS connection with client authentication", >>>> then this is necessary, so that the server knows to request a client >>>> certificate. >>> >>> Now with part 2: >>> >>> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ >> >> I really like both of these. I allready responded on the TLS mailing list >> about draft-thomson-tls-care [1]. For draft-thomson-httbis-catch I would >> like to suggest an improvement that would be essential for "self-signed" >> or rather "unknown server signed" certificates, i.e., certificates signed >> by some server that is not a CA. This allows for much more widespread >> creation of client certificates, since they don't anymore need to be >> verified by a few CAs, but instead allows the deployment of a web of >> trust - a linked data web of trust to be precise. This allows one client >> side certificate to be used to sign on to any web site. >> >> A WebID is just an http(s) URL that refers to an Agent ( human, robot, >> organisation, ...) We have defined it in the spec "WebID 1.0" [2]. One >> can then place a WebID in the Subject Alternative Name (SAN) field of an X509 >> certificate as shown in WebID Authentication over TLS [3] ( or even in the >> Issuer Alternative Name field (IAN)). The last spec relies on TLS as it is >> currently, but would be redundant if draft-thomson-httpbis-catch went through. >> (Until wide deployment of TLS1.3 which I suppose may take some time). >> >> Now I am not absolutely sure where this improvement I want to suggest, >> needs to be added: at the HTTP layer, or at the TLS layer. Currently TLS >> allows a server to specify using the certificate_authorities list what >> the list of Certificate Authorities the server accepts, so that the client >> does not send Certificates that are not signed by one that is known to the server, >> and which the server would then have to refuse. >> But with WebID Authentication we don't need a CA, so it would be nice to be >> able to specify that the server knows how to do WebID verification, ie part >> 5 and 6 of >> http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence >> bB >> If in TLS the server sends the empty certificate_authorities list. But that >> is too wide, since that means the client can send ANY Certificate. The >> server may not know what to do with most of them ( other than perhaps >> identify the user indirectly by the public key, but that is only minimally >> interesting - it does not allow one to build a web of trust ). >> >> My guess is that since this could evolve faster than the TLS layer, it may >> be better if this were done in the HTTP header. So perhaps a header like >> >> WWW-Authenticate: ClientCertificate,SAN=WebID >> >> would do. One could also imagine a >> >> WWW-Authenticate: ClientCertificate,IAN=WebID >> >> so that services with a lot of WebIDs could allow people to verify certificates >> by verifying the issuer. A client seeing this would know that if the >> server sent the empty certificate_authorities list, that it could filter its >> available certificates by those that have the SAN or IAN fields filled in. >> >> We have quite a few implementations of WebID on numerous servers, and in >> pretty much every language, and we are finding it very useful. To get >> a full overview of how this ties into a bigger picture including Web Access >> Control, other authentication schemes, Linked Data Protocol, etc... see our main >> intro page >> >> http://www.w3.org/2005/Incubator/webid/spec/ >> >> Hope this helps. >> >> Henry >> >> >> [1] http://www.ietf.org/mail-archive/web/tls/current/msg11449.html >> [2] http://www.w3.org/2005/Incubator/webid/spec/identity/ >> [3] http://www.w3.org/2005/Incubator/webid/spec/tls/ >> >> >> Social Web Architect >> http://bblfish.net/ > > Social Web Architect > http://bblfish.net/ > >
Received on Monday, 10 March 2014 09:35:46 UTC