Yup, Sovereign Keys is awesome. I hadn't looked it up since thinking more about the importance of having a single mapping but on a quick re-read I understand it as follows:
Sovereign keys has a very strict requirement for changing this mapping as domain names should. ie. Only a key revocation can change the mapping, and thus, a simple append only structure works great. If domain operator loses control for their domain name, they can revoke their key. This works as long as each party is trusted to never lose access to both their key AND revoke cert. You are also relying on these keyservers to establish validity of domain names through possibly DNSSEC and existing CAs. I'm OK with this and would gladly use it over the CA system and this would be an excellent start. I think you might be able to do more, but its up for debate. DNS is unique compared to common user-user authentications in that it is one-way authentication. A user validates a key for a TLS connection, but the TLS connection doesn't care what identity connects to it. Using a WOT between DNS owners and user keys could be used to find valid paths, but since the keyservers in this case already plan to maintain a fairly exhaustive list of domain names, it might not be that valuable. Particularly, because users don't have any meaningful way to capture strong validity of a Domain owners key ( maybe if they know the admin who captures verification with people he knows through ZTRP...) Although you could allow users to publish a special type of signature for every site they visit. It wouldn't establish validity, but you could see if their is a consenus among what users are seeing when they visit a website. Now you have a consensus on network perspectives. This could be used to prune any initial bad seeds in the mapping. If Google is seen all over the world as having cert X but the newly installed keyservers say its Y, I'm likely to believe the massive network perspective. One question I have about Sovereign Keys: 1) It might be an easy assumption to make that a small subset of domain admins might lose access to their revoke certificate and private key. How can they appeal this? If this append only structure is *absolutely* immutable in its mappings without a revocation cert, then they shouldn't be able to use DNSSEC or a CA to re-establish a mapping. Some resolution protocol is needed to not lock a domain out of all future TLS communication. The doc suggests just using extreme caution in preventing this. Storing revoke certs in key-escrow and things like this. Maybe this is a good/necessary security trade off? I'd like to see this enforcement of a single mapping applicable to each domain in a way that makes sense, I tend to agree that a WOT wouldn't make much sense for DNS, but I think it adds a lot of value for mediums with user-to-user interaction. So, ideally, you have a trusted set of keyservers to which you have somewhat sercurly bootstrapped (and pinned) keys to talk with. You trust them to be responsible in establishing single mappings in a way that balances the ability to change mappings with the ability to prevent malicious or bad mappings from being populated. You rely on a WOT built through user interaction to provide independent validity beyond "mapping exists on keyserver". A question I'm not sure about here though is: For a keyserver that is establishing mappings, what happens when someone in the mapping publishes a bad signature (ie a signature to a mapping that is not considered the standard)? Maybe keep track of these signatures, but don't present them for validation. This way you can have a reference count of what the communitiy is seeing as the mapping in real-ilfe. Again, this is the idea of consensus around a mapping. So I guess the point is that any project like convergence.io/tack.io and Soverign Keys that forces domain name owners to establish their own keys is a huge step in the right direction. I like the Soveirgn Keys approach of establishing a set of keyservers that check each other. Convergence captures network perspectives. Combine them? Also, I really like the idea of failing back to an .onion address of the public key in the presence of a MITM. Also, I just realized that when I've been trying to separate the different characteristics of email authentication vs domain authentication and referring to them as 'communication domains' for lack of a better reason. This is confusing. All the accounts are addressable by domain names. The difference is that an email account is a personal account separately authenticated that is just addressed with and @domain.tld. Its uniqueness is guaranteed by the provider and not the domain registration system. Overall, the separation of mappings is based on the communication medium that needs authentication. On Sun, Dec 2, 2012 at 10:25 PM, Miron (devrandom) <c1.andr...@niftybox.net> wrote: > Hi Patrick, > > Have you seen EFF's Sovereign Keys project? It attempts to establish a > distributed single-mapping database of cert <-> domain. > > Also see the schemes in https://en.bitcoin.it/wiki/BIP_0015, altough they > create new handles rather than try to capture existing ones. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
