On Mon, Aug 18, 2014 at 12:09 AM, Trevor Perrin <[email protected]> wrote:
> A different approach is to have Bob's service provider, as specified > in his username, be his keyserver (LEAP, STEED, UEE). For example, > the keyserver for [email protected] would be example.com. This > eliminates the coordination problem, makes registration easier (Bob > authenticates to his provider), *might* address the incentive problem > (Bob's service provider would run the keyserver as part of providing > him service), and gives Bob flexibility to choose the keyserver (by > choosing his provider). > > Of course, now Alice needs to authenticate example.com. A DNS > solution (DNSSEC or DNSCurve) seems elegant - if [email protected] is > vouched for by example.com, then example.com could be vouched for by > com, who's vouched for by the DNS root. But since example.com is a > public server with administrators, it has plenty of other options > (HTTPS certs, CT logs, pinning via HPKP/TACK or curated pin lists, > etc.). So we can handwave "Alice authenticates example.com" as being > solvable a bunch of ways. > +1 on this. See also: DANE for X.509, and WebFinger for tying profiles to their email provider. > A sharper criticism is that changing providers and usernames is > costly, so Bob's flexibility is limited. This is going to be true of whatever scheme you use, unless you have a convenient mechanism for bootstrapping a new identity from an old one, but that could be exploited by attackers in an account takeover scenario to transfer control of someone's identity to an attacker-controlled account. There are also protocol design questions that could be tackled > independent of who runs things, e.g. > * How to make keyservers auditable I think whatever the solution is, it needs a CT-like scheme to help detect spoofed IDs. I think a CT like system is the sort of thing people expect out of a web-of-trust, except instead of relying on random people to be the trust anchors, you depend on services run (and hopefully hardened) specifically for this purpose. -- Tony Arcieri
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
