Certificate for onion v3 address

at April 26 CA/B published TLS baseline requirement 1.8.4, which cleared up about handling onion addresses, and removed wired applicantnonce.
RFC-ish acme onion handling draft : GitHub - orangepizza/acme-onion-doc: docs about standardize handling onion address in acme context
client based on acme-tiny : GitHub - orangepizza/acme-tiny at onion
(shoud update readme.md there though), it use -tor-dir cmdline option to read onion config folder
server based on pebble GitHub - orangepizza/pebble at onion

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

P.S. I'm writing this just before sleep :{

3 Likes