- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 29 Jun 2017 07:50:28 +0200
- To: Martynas Jusevičius <martynas@atomgraph.com>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-webid <public-webid@w3.org>
> On 28 Jun 2017, at 18:01, Martynas Jusevičius <martynas@atomgraph.com> wrote: > > Kingsley, > > I am speaking about the WebID-TLS spec, more specifically Authentication sequence and Verifying the WebID: > https://www.w3.org/2005/Incubator/webid/spec/tls/#the-webid-authentication-protocol > > None of the sections (see below) on WebID verification address the failure to verify the public key, and I think a robust protocol should. Am I missing something? > > 4.1. step 6.2 > > The graph returned in the previous step is then queried as explained in Verifying the WebIDs. If the query is answered positively, then that WebID is verified. If the query fails and the graph was not up to date, then the Verifier may start again at point 6.1.2 by making a request to an up to date graph. > > 4.2.5.2 Verifying the WebID Claim > > To check a WebID Claim one has to find if the graph returned by the profile relates the WebID to the Certificate Public Key with the cert:key relation. In other words, one has to check if those statements are present in the graph. > > 4.2.5.2.1 Verifying the WebID Claim with SPARQL > > An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim is verified. Again, the failure will then be sent on at the TLS level, which deals with this - there are TLS error codes - though it is not clear how well the information is used by the browsers. The problem in is that the TLS level is below the HTTP layer, so there is an interaction between layers that is taking place, that is frowned on in most cases. This is a problem for HTTP 2.0 and is actually very clearly explained in the RFC Draft "Secondary Certificate Authentication in HTTP/2" https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-04 Read the introduction of that document to understand the context, and then look in particular at chapter 4 Indicating failures during HTTP-Layer Certificate Authentication So they are proposing adding the right failure modes to the HTTP layer there. > > On Wed, 28 Jun 2017 at 16.16, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 6/27/17 8:44 PM, Martynas Jusevičius wrote: >> Kingsley, >> >> I am implementint WebID authentication in our software, and key mismatch is a real scenario. >> >> Can you show me where in the spec it is addressed? > > Martynas, > > Your comments are confusing. > > Are you speaking of the WebID+TLS protocol which is basically a TLS-handshake extension that uses a WebID lookup (using value of SAN attribute in an X.509 Cert) to locate a Public Key in a WebID-Profile document? If not, then we are not speaking about the same thing, and as a result not communicating effectively. > > Terms: > > 1. WebID -- HTTP URI that identifies an Agent and adheres to Linked Data principles > 2. WebID-Profile Document -- a collection of RDF statements in an RDF document that describe an Agent identified by a WebID > 3. WebID+TLS -- TLS handshake extension that matches Public Keys in an X.509 cert and a WebID-Profile document by way of WebID de-reference > 4. WebID+TLS+Delegation -- adds an additional lookup route to #3 via acl:delegates relation > > > Kingsley >> >> On Wed, 28 Jun 2017 at 02.04, Kingsley Idehen <kidehen@openlinksw.com> wrote: >> On 6/27/17 6:33 PM, Martynas Jusevičius wrote: >> > Hi, >> > >> > I think there is another case where failure scenario is not defined in >> > protocol: verifying the WebID. >> > >> > What happens if the certificate key does not match the WebID key? None >> > of the verification steps or sections seem to consider that. I suggest >> > again that a 400 Bad Request should be returned. >> > >> > I think it is important for the protocol to handle failures if we want >> > robust implementations. >> > >> > Is this group active enough to fix such issues? >> > >> > >> > Martynas >> >> >> Hi Martynas, >> >> What do you mean by Certificate Key? Are you referring to the Public Key >> component of an X.509 Certificate? >> >> Bearing in mind that WebID+TLS isn't new, are there are implementations >> out in the wild, wouldn't it be better if you started off by testing >> authentication of your WebID against existing implementations? >> >> You might also find the YouID browser extension we built interesting >> since its sole purpose is simplification of WebID+TLS and/or >> WebID+TLS+Delegation protocol usage (e.g., negating the UX headache >> introduced by browsers when toggling WebIDs over and existing TLS >> session) [1]. >> >> You can try: >> >> [1] http://linkeddata.uriburner.com/sparql -- click on "login" button >> >> [2] http://osdb.openlinksw.com -- click on the "login" button >> >> [3] http://id.myopenlink.net/ods/webid_demo.html -- most basic WebID+TLS >> authentication tool we have >> >> Links: >> >> [1] >> https://medium.com/openlink-software-blog/simple-youid-browser-extension-usage-exercise-57fa3ff6c6b7 >> -- Simple YouID Browser Extension Usage Exercise. >> >> -- >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software (Home Page: http://www.openlinksw.com) >> >> Web Identities (WebID): >> Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this >> : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this >> >> > > -- > Regards, > > Kingsley Idehen
Received on Thursday, 29 June 2017 05:51:04 UTC