- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 5 Jan 2015 19:18:58 +1100
- To: carmen <_@whats-your.name>
- Cc: public-rww <public-rww@w3.org>
- Message-ID: <CAM1Sok22BsFjwFfvAZxvFV7vBGejhvUpWG3WeET461eiExL5Wg@mail.gmail.com>
sorry correction... On 5 January 2015 at 19:16, Timothy Holborn <timothy.holborn@gmail.com> wrote: > > > On 5 January 2015 at 16:43, carmen <_@whats-your.name> wrote: > >> > wildcard certs not currently supported? >> >> expending effort on this front probably isn't worth it, vs other things.. >> >> even in HTTPS timing and size of packets leak some info. depending on how >> determined you are, maybe a decent amount: >> >> http://eprint.iacr.org/2014/959.pdf >> http://eprint.iacr.org/2014/724.pdf both featured at >> http://fc15.ifca.ai/ >> >> one unencrypted port 53 lookup and you might additionally be able to tie >> what you've gleaned to a particular username, >> >> client-cert support is something that some people complain about.. >> >> on public machines , in coffee-shops, libraries or otherwise, how do you >> login ? >> maybe security is lax enough that you can plug in a phone on USB, load >> the private-key/cert .p12 file and remember to delete it, but.. >> >> network-effects of supporting certificate-based single-sign-on might have >> legs >> >> > Initial thoughts (that have stuck around for sometime now) are that the > cert. identifies the *machine account*, not the *user's cloud account* > (specifically). In-turn, creating a IoT ACL list (which then needs a > second auth factor at a minimum). > > IE: Phone might have google authenticator loaded. Goto the Right URL, > set a period, shut it down when you leave. > > Also; given credentials are used for dataspaces rather than apps; makes it > easier to use passwords... > > timh. >
Received on Monday, 5 January 2015 08:19:25 UTC