Hi Iain,
On 12 Nov 2013, at 16:28, Learmonth, Iain Ross wrote: >> 1) The user decides to unilaterally use a password in the cloud scheme that >> allows them to store their passwords on one machine and access them from any >> of their browsers. > > I already do this with LastPass[1]. > > If we want to move forward with authentication for things like websites > though, I'd rather see the cloud storing encrypted client certificates that > are synchronized and then decrypted client side by a password. This sounds interesting and rational, but it contains a lot of implied detail. Can you unpack it a little, e.g. explaining what's in the certificate, why it needs to be stored in that form, why it's encrypted, which steps of the protocol are assumed to depend on session-level encryption, and so on? Thx, Robin > >> 3) The browser implementing the password in the cloud scheme alerts the site >> being contacted to the fact that it can support a direct user authentication >> exchange that would make the user experience seamless and support single >> sign on. > > LastPass can do an "auto-login", but this would be completely seamless with > TLS client certs. If the site has to be changed anyway, why not do it > properly? > > This also leaves the option of having my certs on a smartcard, USB dongle, > floppy disk, etc. instead of just in the "cloud". > > Of course, if you wanted to build a system that syncs client certs, you could > also add synchronizing of passwords into it, but I think that would only > really discourage the adoption of the client certs. > > Iain. > > [1]: https://lastpass.com/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
