Let's Encrypt for Handshake domains

[falci]

Hi there, would it be possible to have let's encrypt onboarded on Handshake?
In a nutshell, Handshake is an alternative DNS root zone, powered by blockchain technology.
If that is possible, we could issue ssl certs via cert-bot for HNS domain, which would be amazing!

[JamesLE]

A prerequisite for Let's Encrypt (or any other publicly trusted CA) to do this would be to amend the CA/Browser Forum's Baseline Requirements to permit using alternative DNS hierarchies. For example, take a look at section 3.2.2.4 and Appendix B for how Tor .onion domains are accommodated.

[Osiris]

@JamesLE I've looked for it, but do the BR define which DNS is to be used? Of course it seems logical which DNS has to be used, but is it also explicitly defined?

[petercooperjr]

The closest that I can find is that the definition of "Fully‐Qualified Domain Name" in 1.6.1 Definitions says that it's for the "Internet Domain Name System", and if you're referencing DNS root servers other than the ones IANA defines, then you're not looking at the Internet Domain Name System but something else. And of course, the "Fully‐Qualified Domain Name" is what all the validation methods say is being validated.

Also, at some point when writing documents like that, you have to just assume "words have their natural meaning unless stated otherwise" or it quickly doesn't have any meaningful statements at all. It's not like saying "We decided to run our own root servers with our own entries and point our validator to it" would actually hold much sway over the root programs, even if one could successfully point to some ambiguity in the spec.

[Osiris]

@petercooperjr

The closest that I can find is that the definition of "Fully‐Qualified Domain Name" in 1.6.1 Definitions says that it's for the "Internet Domain Name System", and if you're referencing DNS root servers other than the ones IANA defines, then you're not looking at the Internet Domain Name System but something else.

Sounds reasonable.

@petercooperjr

Also, at some point when writing documents like that, you have to just assume "words have their natural meaning unless stated otherwise" or it quickly doesn't have any meaningful statements at all.

Why would explicitly define stuff suddenly become a lack of meaningful statements? I believe everything becomes more meaningful if everything neatly ties to official definitions and references. For example, it's common to reference RFCs for certain things when writing a RFC. Scientific literature needs to have sources to be meaningful at all. I don't see why the BR is any different to be honest.

IMO a simple reference to the IANA would suffice

[petercooperjr]

Oh, sure. I'm not really objecting to making anything in the standards more clear. But of course, once you reference the IANA, you then need to worry about somebody else making their own IANA (or perhaps, a major split in governance making it unclear which organization is really "the Internet"), and then somebody else moves on to trying to find some other ambiguity they can try to wedge in there.

And all I was trying to say is that in practice, while there's plenty of automation of many things, policy documents tend to be written by and for humans to interpret, which is probably for the best (most of the time).

[Osiris]

@petercooperjr

But of course, once you reference the IANA, you then need to worry about somebody else making their own IANA (…)

Then don't use the abbreviation or perhaps use a footnote with URL to the website I'm not saying you need to go all the way, but some things are relatively easy to mitigate

@petercooperjr

or perhaps, a major split in governance making it unclear which organization is really "the Internet"

That's also a serious issue with the current definition of "Internet Domain Name System"

@petercooperjr

And all I was trying to say is that in practice, while there's plenty of automation of many things, policy documents tend to be written by and for humans to interpret, which is probably for the best (most of the time).

And my counter-point is that if possible, feasible and practical it's always better to make it explicit so you don't run into nonsensical discussions and/or lawsuits which could have prevented.

[petercooperjr]

@Osiris

footnote with URL to the website

Website as resolved by which root DNS servers?

@Osiris

if possible, feasible and practical it's always better to make it explicit so you don't run into nonsensical discussions and/or lawsuits which could have prevented.

Of course. I'm not really disagreeing with you.

[pinheadmz]

I am also a contributor to the Handshake project and I want to thank you @JamesLE petercooperjr and @Osiris for your feedback so far. Handshake also has around 80,000 domain names reserved for the "legacy" DNS owners, that can be claimed with DNSSEC proofs within the first four years of the blockchain's life (3 years remain!). The list includes the ICANN root zone as well as names in the Alexa top 100k but also a few selected domains that the project founders deserved extra rewards as a tribute for their contribution to the internet infrastructure.

These names are reserved and I would be happy to help you claim them:
letsencrypt.org (503 HNS reward)
eff.com( 710,951 HNS reward)
The current price of HNS is around $0.30 and in addition to the coin reward you also of course get your top-level domain name (.letsencrypt and .eff) on the blockchain.

I have a video explaining the name claim process using our GUI wallet: Handshake reserved name claims using Bob Wallet - YouTube

If you are at all interested in joining Handshake or claiming your reserved name, don't hesitate to reach out to us in the HNS Developer forum on telegram: Telegram: Contact @hns_tech or #handshake on Libera IRC.