Similar to If/when will LE support .onion addresses? it’d be great to be able to issue certs for .bit domains, where domain registration and renewal happens on the Namecoin blockchain.
Maybe you had conversations about this too already?
Namecoin/DNSChain/.bit support
1 Like
As with .onion, this may need an RFC establishing that .bit is reserved for this purpose, so that there won’t be ambiguity about what a .bit name means (for example, due to ICANN issuing it as a future DNS gTLD).
People working on Let’s Encrypt appreciate the potential value of non-DNS name resolution mechanisms, but browser vendors are quite cautious about saying that certs from browser-trusted CAs should only be issued when the meaning of the subject name in the cert is clearly established and unambiguous. They’ve indicated that this isn’t the case if the name is issued in some namespace that might conflict with an ICANN-assigned TLD in the future. This has been a practical problem in the past when CAs issued certs for “internal” names, for example on corporate intranets, that then were also used on other organizations’ intranets, or were the same as names that ICANN was proposing to create as future public gTLDs. For example, imagine that a CA issued a cert for networkservices.corp, referring to a machine on a particular company’s internal network, and that later ICANN allowed a public TLD called .corp; at some point someone might then register the public name networkservices.corp, and the existing cert would then be accepted by browsers trying to connect to that machine, even though the CA hadn’t intended for it to be interpreted that way.
You can imagine an analogous concern for .bit, where someone uses Namecoin to register giga.bit or tera.bit or something, and gets a cert for it, and then perhaps ICANN decides that there will be an unrelated .bit hierarchy in the DNS, and someone else registers giga.bit there. Now the meaning of the cert is ambiguous and a browser might mistakenly accept it in the wrong context!
So, browser developers have become more cautious about the scope and interpretation of names that are included in CA-issued certs.
As I think I said in another thread, there seem to be processes trying to address this at IETF and so interested people may be able to get involved in that.
3 Likes
By the way, when I said
I mean that the browser vendors do say this, not that they’re reluctant to say this.
@schoen Makes sense, of course. Thanks for your detailed response!
If anyone stumbling upon this thread has links to specific discussions being led online at these bodies, it’d be fantastic if you could post those.
1 Like
Alec Muffet just said that the .onion RFC is about to be approved over at IETF.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/
(It just passed the IESG review.)
It seems like there’s still not clear agreement within IETF about what procedure should be followed for doing things like this in the future. You can see some of the IESG members are not sure how good a model this is for the future. This registration was done pursuant to an earlier process that was created by RFC, and it’s brought into the open a fair amount of uncertainty about that process.
Congratulations to the authors of the RFC, and thanks to the authors of the earlier P2P Names Internet-Draft. I hope this leads the CA/B Forum to agree that it’s appropriate for CAs to issue certs for .onion names in the long run.
2 Likes
Not just .bit or .onion domains, but a plethora of ‘new’ / ‘alternative’ TLD’s, generally inaccessible via the clearnet could be supported i.e.
Emercoin - .emc, .coin, .lib, .bazar - http://emercoin.com/EMCDNS_and_NVS
Namecoin - .bit
New Nations - .uu, .ti, .te, .ku
Open NIC - .bbs, .dyn, .free, .fur, .geek, .gopher, .indy, .ing, .micro, .neo, .null, .oss, .oz, .parody
@emerproxy, if you’re supporting these names by having people use a proxy, they can reach that proxy over the clearnet (or even run it locally on their own computers, which would be a lot safer). We don’t specifically need .onion certs for that, and, as I’ve mentioned elsewhere, we’re not able to directly issue certs for these other TLDs.
About OpenNIC there was already a separate thread: