| It depends on what your objectives are. If they are to ensure that no single legal jurisdiction can force a domain that has already been issued to stop working by taking actions in that jurisdiction (except via the domain owner), that is easily achievable without major problems. E.g. the system could have the following components: 1) A centralised issuer (CI) of time-stamped certificates for a TLD, which certify someone is the owner of a domain. Certificates are only issued for domains that don't exist yet. The public key is in the certificate, and the private key is kept by the owner. 2) A network of TLD nameserver operators (TLDNSO) for the TLD. TLDNSOs have stable IP addresses which are distributed to client software in advance - and there is a centrally agreed on list. TLDNSOs are geographically dispersed, and spread across many different legal jurisdictions. 3) All certificates from the CI are sent to all TLDNSOs. Certificates without a timestamp that corresponds within a limited threshold to the time the certificate was received are rejected, as are certificates for domains when another certificate for the same domain is held by the TLDNSO. 4) TLDNSOs accept domain resource record (RR) updates - e.g. nameserver records - from anyone, provide they are signed with the private key that only the domain owner has. Likewise for the equivalent of WHOIS details. 5) Domain owners can sign a transfer certificate, which includes the public key of the new owner, and is signed with their private key, and sending the transfer certificate to the new owner. The new owner sends it to all TLDNSOs, who will from then on accept requests with the new owner's key, rather than the old one. 6) Clients can query TLDNSOs using DNS or DNSSEC, or using a new protocol which lets them inspect the certificates from the CI and any ownership changes. Clients using the new protocol query several TLDNSOs in several jurisdictions - there could be a fairly complex set of conflict resolution rules, but one of the most important would be that if two CI certificates were received, more TLDNSOs get queried, and the most frequent answer is the one that is accepted. This makes most kinds of attacks on existing domains difficult: 1) The CI can be compelled by authorities in its jurisdiction to issue certificates, possibly backdated, but they won't be accepted by TLDNSOs except the ones that can be compelled to accept them (a minority in the case of unilateral government action), because they already have a certificate for the domain. The new CI certificate will be rejected by clients if only a minority of TLDNSOs present it. 2) TLDNSOs can be compelled to remove CI certificates for individual domains, but if only a minority are in any one jurisdiction, clients will get the record from other TLDNSOs. 3) Only the domain name owner has the private key needed to revoke or transfer a domain name. Obviously, the domain name owner can be compelled to reveal they private key (if they have it in that jurisdiction anyway), but that is outside the scope of this document. They could encrypt the key with a secure password and refuse to disclose it - that would be legal in some jurisdictions and illegal in others. By this point, authorities would probably focus on taking down the servers hosting the website rather than the DNS. |
I like it - it can be implemented along-side DNS, mirroring DNS entries where the owners will agree to create a key. A progressive take-over is possible, layered on top of existing services.
It's not really "p2p" in that it needs hosts that must still be large and unmovable, thus a target, but a definite improvement. I'd still like to see/find/come up with a way to make something as totally host-free as possible, but no doubt it'd be incredibly slow compared to a more centralized solution.