
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Tor-Dev, One of the criticisms of Namecoin which seems to be raised sometimes is that the current domain namespace spec doesn't have a method for a .bit domain owner to prove that they are in control of a .onion. (This is also an issue for .bit domains that point to .i2p.) I'm interested in improving this situation, and am looking for feedback. First off, I'm curious what the various use cases are for this. The main use case I'm aware of is if a user is aware of a .onion domain already, and is trying to find a human-memorable way to access it. (As far as I can tell, the reverse is not a use case, because if you already trust the .bit domain by name but don't know what .onion you're looking for, presumably Namecoin already does what you want.) Is this correct? Am I missing any other significant use cases? Second, I'm looking for feedback on my rough approach. The approach I'm looking at right now is to have a Namecoin namespace for .onion backlinks to .bit domains, which is separate from the Namecoin namespace for .bit domains. The backlink namespace would have a name field whose prefix is the .onion domain. We can't prevent a squatter from registering an exact match of the .onion in Namecoin, but by using a prefix and checking the signature on all matches, we can avoid the impact of squatters. (The cost of obtaining new names would be a deterrent for someone trying to flood a .onion prefix with invalid backlinks as a DoS.) The value field would contain a signature of the domain name being pointed to, signed by the .onion key. The .onion key could also sign revocations of an endorsement of a .bit domain; these would also be in that namespace. Is this generally a good approach? I'm aware that cross-protocol attacks need to be carefully considered when signing things with a .onion key -- do you have suggestions on how I can sign a short JSON string of the rough form {"name": "d/domain", "rev": 0} (which corresponds to endorsing domain.bit, and not being a revocation of that .bit domain) in a way that won't open up attacks on the .onion key's normal protocol usage? I'll write up a more formal spec after feedback is received, just to make sure I'm not missing some important details. Cheers, - -Jeremy Rand https://namecoin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVW0v7AAoJEAHN/EbZ1y06C+AP/3RxO99cPoBQ6eRcY9cefqlC HGnfUtxfAa7Ao2Ea2ZatHjA36ordtz6vo9UpJKDXXLPuQFMnsW/Xf6m2ePCKPssG uivWnAqoZ/zFaJFXf6RqgADrbUei7jW75DFmJfwhPka3kh76mF/B3mMIRx9bCOIq r8XcKRlmbFv55j0srg2Z6SBpq8aMumxGjStjyzsW8L6bVtBvz4DwN5rAZG958Hm3 ji7b6r+v05s4dIbJ6ZAqerOVmy6PA+sAZ0cqwzCBBttdIoVzGiuc9S6aAn8+XjWa ycx7wUi3YM27Kyor8N2+pYDgECmMYEC9QBKN6XwtsW6Lwz9UCNaZ4BQR5JWIxwLg FTZ1uV/E7o3cKdiPzlCkzoQetifom8la6ezPOpr4XhVuzLWqHJBm4eA+qEwEPSFC DA4k/HEgJKNUZGFWuXpIyEAl3Nvyy3cxTYyrzzMmbvBJnzMGM18Sa+D9N78ih3Sw GgXIET336wnvd+HqcVT85io7Ee3Wj+05IOyH4mhV06AXJuP1RvFAKJk6d1i5lOKC Sr2GrJNnP8zP1uq57XQxpKg7fkVqBMzjFY9JJ6HIkffLsGzLpZ8CUSU2+8tPGeDt T3MAT3GKqXCIjIiQy39Ban27ixeJyxzq8dN3T2HvnUNna0M9v3VhxQjeauNzjHTk 9ekMPDGGT7X9TmLOvSXq =WbCd -----END PGP SIGNATURE-----