Re: [foaf-protocols] WebID status recap?

On Tue, Jul 2, 2013 at 4:37 PM, Henry Story <henry.story@bblfish.net> wrote:

>
> On 2 Jul 2013, at 16:02, Andrei Sambra <andrei.sambra@gmail.com> wrote:
>
> On Tue, Jul 2, 2013 at 3:45 PM, Henry Story <henry.story@bblfish.net>wrote:
>
>>
>> On 2 Jul 2013, at 15:39, Andrei Sambra <andrei@fcns.eu> wrote:
>>
>> >
>> > On 07/02/2013 03:07 PM, peter williams wrote:
>> >> Why the focus on that tls spec? It focuses on an applied variant of
>> >> channel bindings tokens (that more generally address non-detection of
>> >> cert-based mitm).
>> >>
>> >> I thought webid made the assumption that states and corporations dont
>> >> engage in such activities (perhaps as ordered, in the case of large
>> >> corporations) and thus such vulnerabilities are just "defined" as out
>> of
>> >> scope for webid?
>> >>
>> >
>> > Peter, even though you see TLS in the WebID-TLS spec name, it has
>> > nothing to do with the classic PKI trust chain verification. The only
>> > aspects of TLS involved in WebID-TLS authentication relate to the
>> > verification of a private key corresponding to the certificate you
>> > authenticate with. In other words, we're just using TLS to make sure
>> > that there is a private key that matches the public key. Nothing more.
>>
>> Not quite: there is still the CA infrastructure for the server that
>> requires a CA for now. IETF Dane replaces that while creating security
>> issues elswhere. One can perhaps use Tor, or i2p to get over that.
>> Things just get more complex, and are less widely used, and have their
>> own problems of course.
>>
>
> The CA for the server can be self-signed, hence why I said that we're not
> following the standard PKI trust chain. There is no trust assertion during
> WebID-TLS, other than private/public key verification.
>
>
> It can be self signed, but then you loose the certainty that you have
> received the right WebID Profile, and so your guarantee of authenticity
> falls a lot too, for at a number of reasons such that DNS can relatively
> easily be cracked now, and we don't have DNSSEC.
>

I see what you mean. I think there's been a confusion. What you are
referring to is the dereferencing of the user's profile document over TLS
(HTTPS). I think Peter was talking about the TLS handshake phase taking
place when you provide the certificate.

By the way, it should be interesting to put together a list of libraries
that also check the validity of a Web server's certificate when
dereferencing RDF documents. I think most libs ignore this step at the
moment, while also ignoring all the advantages of HTTPS.


>
> There is no absolute security of course.  But self signed server
> certificates alone, unless you have other systems to test them, don't
> tell you a lot. You
>
>
>
>>
>> >
>> > Andrei
>> >
>> >
>> >> Stéphane Corlosquet <scorlosquet@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Jun 14, 2013 at 5:34 AM, Henry Story <henry.story@bblfish.net
>> >> <mailto:henry.story@bblfish.net>> wrote:
>> >>
>> >>
>> >>    On 13 Jun 2013, at 22:31, Henry Story <henry.story@bblfish.net
>> >>    <mailto:henry.story@bblfish.net>> wrote:
>> >>
>> >>     > Yes, we have two specs:
>> >>     >
>> >>     > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
>> >>     >
>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>> >>     >
>> >>     > I am not sure why we don't get the full html view anymore.
>> >>     > Anyone know what we need to change?
>> >>
>> >>    I fixed these. The problem is related to the move to the new
>> >>    respec.js https://github.com/darobin/respec/
>> >>
>> >>    It no longer allows one to add spec refs to the js as one used
>> >>    to be able to
>> >>
>> >>    see diff https://dvcs.w3.org/hg/WebID/rev/7f01174c75b0
>> >>
>> >>    So the TLS spec now is missing two references
>> >>
>> >>    [[
>> >>       berjon.biblio["RFC5746"] = "E. Rescorla, M. Ray, S. Dispensa, N.
>> >>    Oskov,  <a
>> >>    href=\"http://tools.ietf.org/html/rfc5746\<http://tools.ietf.org/html/rfc5746/>"><cite>Transport
>> Layer
>> >>    Security (TLS) Renegotiation Indication Extension</cite></a>
>> >>    February 2010. Internet RFC 5246. URL: <a
>> >>    href=\"http://tools.ietf.org/html/rfc5746\<http://tools.ietf.org/html/rfc5746/>
>> ">http://tools.ietf.org/html/rfc5746</a>
>> >>    ";
>> >>
>> >>       berjon.biblio["WEBID"] =  "Andrei Sambra, Stéphane Corlosquet. <a
>> >>    href='
>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html'
>> >>    ]]
>> >>
>> >>    Any idea how one can get those added to the code using the new
>> specref?
>> >>
>> >>
>> >> I've fixed that with [1]. The updated TLS document doesn't show errors
>> >> now [2].
>> >>
>> >> Steph.
>> >>
>> >> [1] https://dvcs.w3.org/hg/WebID/rev/49894597ee18
>> >> [2] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> foaf-protocols mailing list
>> >> foaf-protocols@lists.foaf-project.org
>> >> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> >>
>> >
>> >
>> >
>> >
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>>
>
>    Social Web Architect
> http://bblfish.net/
>
>