- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 5 Jan 2015 19:16:08 +1100
- To: carmen <_@whats-your.name>
- Cc: public-rww <public-rww@w3.org>
- Message-ID: <CAM1Sok1+OVayqJHnas81vHKHWrYMaEVgQsYd4uxsnrpDm4FOFQ@mail.gmail.com>
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, not the account. 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:16:36 UTC