On Nov 13, 2013, at 11:30 AM, Learmonth, Iain Ross <[email protected]> wrote: > How would this key server work? Looking at X.509 key servers, they only ever > seem to store the public key, which the website would already have anyway. I > know with gpg-agent you can forward that to remote servers, but I've never > seen anyone pulling it from somewhere.
The key server would have a collection of public/private key pairs. When you establish an account at a new site, your browser contacts the server and asks it to generate a new master key pair for the site. The browser generates a per-site key pair and sends the public half to the server; the server hands back a cert signing that key with the new per-site master key it generated. Your other devices are notified asynchronously of the new relationship, and generate their own keys, which are signed with the same per-site master key. No secret key ever crosses the network. > A privacy bonus: if you have a key for each site you have an account on, you > know where you have accounts and don't have old inaccessible accounts leaking > information (unless you lose the keys). Yup. And if you lose your key server, the usual strategies for recovering your password would still work. And your key server can do live certificate revocation. So if someone manages to associate a device with your key server that you didn't intend, you can see it on the list of devices and revoke all its keys. Which means that the compromise of the key store on one of your devices need not require that you re-key all your accounts—only the compromise of the server would require that. Of course, live certificate revocation loses you the privacy win of using separate keys, since the IP address would be the same for all queries, so maybe that part isn't such a good idea. A distributed revocation service would prevent that, but it probably wouldn't be possible to notice keys quite as easily. And of course if all your HTTP queries come from the same IP address, sites that communicate can do correlation that way anyway, which means that the per-site master key isn't that useful without a scheme for obfuscating IP addresses. Sigh. Privacy is hard. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
