for now I'd say this rfc draft is not LE specific, so some things LE won't do like http-01 and tls-alpn challenge are included in it
not set on concrete part on docs:
should we set how to craft onion challange CSR in it, or we should delegate its construction to CA/B BR?
do you think placeholder identifier type onion-v3 and onion-v3-csr challenge type? can we have better naming for it?
currently token is constructed in same way (as string) and just pasted in CAnonce attribute (which is octetstream byte array type) with ASCII encoding, should we order client to decode token as base64url and put it that way instead of being ASCII?
we can't use different name for old challenges : as allowed method itself is looking at that challenges
currently doc has warning about normal rate-limit won't work on it, but should we recommend some way for rate limit? (like onion addr/account or cert need non-onion name etc)
I probably ask this into more place/ like moz secpolicy and IETF acme task group
@TheEnbyperor I noticed HARICA offers an ACME endpoint without EAB at https://acme.harica.gr/directory and as they're able to validate .onion addresses, do you know if they're also able to validate .onion addresses using their ACME API? For regular addresses it fails with a message that the hostname does not match a regex containing harica.gr and some IDN stuff, but that regex doesn't seem to check for .onion addresses.
I've never managed to get HARICA to issue certificates to .onion over ACME. I'd like to talk to them about my draft but can't get a contact there to talk.
Once RFC is published, what are the next steps for LE to be able to issue these? Does it need a blessing from CA/B Forum? Obviously it has to be implemented in Boulder. Anything else?
CA/B forum blessing is already done few years ago, before @TheEnbyperor 's doc is made to implement it in ACME context: not sure LE require client to give CAA info out of band as mentioned before or server will get it from tor network by themselves.
I think Let’s Encrypt is open to supporting .onion domains in theory, but as with everything, it’s a question of where on the priority stack it goes. Not this year for sure, and I can’t speak to further out.
Q’s work on standardizing this in ACME is definitely a big help in that direction, though, so thank you!
Wow! This is all excellent news. It would be good news for my product if this becomes real. I make BrowserBox a web-page embeddable remote browser which can both access the Tor network (using socks proxy on the server) or be served as an onion site (using the Tor control port API). The ability to get recognized issuer TLS certs would be great because:
TLS is necessary for off relay encryption. http://bla.onion will be unencrypted on final hop, breaking the security model of Tor.
The Tor Browser will not recongize mkcert certificates: Currently BrowserBox uses mkcert to create a cert for the .onion v3 address HOWEVER the Tor browser will not even accept the mkcert's CA root file even if installed in the system trust store/ keychain. This lead's to the moderately annoying "Unknown Issuer" SECURITY RISK AHEAD gate before loading the page - which slows down the already slower than normal Tor connection with this additional step.
These "one time exceptions" to accept mkcert TLS certs, also complicate code for creating WebSockets, embedding iframes or using audio (all of which we overcame).
Having legitimate HTTPS I think would be great for the legit users of the TOR network (journalists, activists, cyber researchers, IC/defense/security industry), and for people who use TOR + RBI.