| I'm thinking end-to-end. I think it's important to put the directory server into context, or you could end up building the wrong thing, or perhaps building something more complicated than it needs to be. In particular, to decide what's in scope, it's important to distinguish between users and their client software, and to decide what the user's input is to the client software. The user has to somehow get their intention across to their messaging software about who they want to contact. For TLS, there's an assumption that people know which domain name they want already. Figuring out the right domain name is out of scope; that's a social thing. A lot of times, it's part of a URL. Maybe they're trusting Google. Or when sending email, we assume the email address is already known to the user, somehow. For TLS, the IP address doesn't matter, because the domain name is part of the URL and part of the certificate and what matters is which server holds the private key. Securing DNS isn't part of the system [1] and transparency logging isn't needed for IP address changes. Domain names are kind of trust-on-first-use. People hear about a domain name somehow and the important thing is that the owner doesn't lose control of their domain name after they've publicized it and people start linking to it. Similarly, here, I think the important thing is the user doesn't lose control of their username unless they really screw up, like in the scenario you describe. I don't entirely follow what you're doing and I'm not sure if a directory needs transparency logging as a directory. It's sort of like DNS. The sensitive bit is generating the public/private key pair. But I think maybe you've combined roles, so that the directory server is also the certificate issuer? About Scenario A: > The instance admin can pretend to be them and push an AddKey on behalf of the user, thereby locking them out of enrolling. Evidence of this becomes immutable and public, and the user can mitigate this by getting the hell off that instance. There will be lots of AddKeys happening all the time. If the AddKey doesn't contain the username and they don't recognize the ID (because they had nothing to do with it), how does anyone know when an AddKey refers to them? Maybe the server tells other people that an AddKey refers to them, but privately? Possibly the user would find out through gossip, but the log isn't enough evidence by itself, and if the gossip isn't entirely trusted either, they don't have a clear case. It seems a lot less straightforward than scanning a transparency log for your domain name. [1] Though, it comes back in again when Let's Encrypt checks that you control your domain name. |