- From: Andrei Sambra <andrei.sambra@gmail.com>
- Date: Tue, 2 Jul 2013 16:02:19 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: Andrei Sambra <andrei@fcns.eu>, "public-webid@w3.org >> public-webid" <public-webid@w3.org>
- Message-ID: <CAFG79egJWkHLzqNKPkULE5WHhJRM13Wa53mOVR8Yn-=h7KF8QQ@mail.gmail.com>
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. > > > > > 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\"><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</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/ > > >
Received on Tuesday, 2 July 2013 14:03:10 UTC