Re: Verifying WebID fails

On 6/28/17 12:01 PM, Martynas Jusevičius 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
> <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?

Why is this important if the protocol is matching two public keys across:

1) Local Key Store
2) WebID-Profile Document.

Remember, WebID-TLS is an additional lookup applied  TLS-Handshake.  The
"TLS" part handles all matters required for successful TLS-handshake.
The "WebID" part boils down to locating Public Key in WebID-Profile doc
by dereferencing WebID in X.509 Cert SAN (the very X.509 Cert used
during TLS CCA to provide data for handshake).

Bottom line, if there is something wrong authentication fails. The
entire process is about verify the claims associated with a WebID.

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

Note use of "may".
>
> 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.

"key" meaning "Public Key" which is located in the WebID-Profile doc.

Question:

How do you successfully complete a TLS-handshake with an invalid Public
Key?

Kingsley
>
> On Wed, 28 Jun 2017 at 16.16, Kingsley Idehen <kidehen@openlinksw.com
> <mailto: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 <mailto: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
>>         <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
>>         <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
>>         <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)
>>
>>         Weblogs (Blogs):
>>         Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
>>         <http://www.openlinksw.com/blog/%7Ekidehen/>
>>         Blogspot Blog: http://kidehen.blogspot.com
>>         Medium Blog: https://medium.com/@kidehen
>>
>>         Profile Pages:
>>         Pinterest: https://www.pinterest.com/kidehen/
>>         <https://www.pinterest.com/kidehen/>
>>         Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>>         <https://www.quora.com/profile/Kingsley-Uyi-Idehen>
>>         Twitter: https://twitter.com/kidehen
>>         Google+: https://plus.google.com/+KingsleyIdehen/about
>>         <https://plus.google.com/+KingsleyIdehen/about>
>>         LinkedIn: http://www.linkedin.com/in/kidehen
>>         <http://www.linkedin.com/in/kidehen>
>>
>>         Web Identities (WebID):
>>         Personal:
>>         http://kingsley.idehen.net/dataspace/person/kidehen#this
>>         <http://kingsley.idehen.net/dataspace/person/kidehen#this>
>>                 :
>>         http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>>         <http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this>
>>
>>
>
>     -- 
>     Regards,
>
>     Kingsley Idehen       
>     Founder & CEO 
>     OpenLink Software   (Home Page: http://www.openlinksw.com)
>
>     Weblogs (Blogs):
>     Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
>     <http://www.openlinksw.com/blog/%7Ekidehen/>
>     Blogspot Blog: http://kidehen.blogspot.com
>     Medium Blog: https://medium.com/@kidehen
>
>     Profile Pages:
>     Pinterest: https://www.pinterest.com/kidehen/
>     <https://www.pinterest.com/kidehen/>
>     Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>     <https://www.quora.com/profile/Kingsley-Uyi-Idehen>
>     Twitter: https://twitter.com/kidehen
>     Google+: https://plus.google.com/+KingsleyIdehen/about
>     <https://plus.google.com/+KingsleyIdehen/about>
>     LinkedIn: http://www.linkedin.com/in/kidehen
>     <http://www.linkedin.com/in/kidehen>
>
>     Web Identities (WebID):
>     Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this
>     <http://kingsley.idehen.net/dataspace/person/kidehen#this>
>             : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>     <http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this>
>

-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software   (Home Page: http://www.openlinksw.com)

Weblogs (Blogs):
Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
Blogspot Blog: http://kidehen.blogspot.com
Medium Blog: https://medium.com/@kidehen

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this
        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this

Received on Wednesday, 28 June 2017 21:39:08 UTC