With the recent passage of SC27 at the CA/Browser Forum there are now acceptable mechanisms for validating v3 Onion addresses for inclusion in DV certificates. As such it would be good to extend ACME to be able to make use of these methods. I've written a short draft that covers what is likely to be the most interesting validation mechanism to CAs (i.e. the one that doesn't require actually using Tor directly) and would be interested in thoughts from the WG.
The defined ACME challenge is basically just an adapted version of the method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think in general the usage of a CSR as the transport mechanism for the nonces and key signature are a bit burdensome, and likely to cause some confusion for implementers (since it introduces yet another place a CSR is transferred between the client and server, with another non-standard use). That said I think the first priority in this document is to get out something that works with current CABF rules. There could be value though in defining our own validation mechanism that is a bit more straightforward alongside the existing CABF method and if/when this document is standardized we could lobby for it's inclusion as a blessed CABF validation method. Thoughts? https://www.ietf.org/id/draft-shoemaker-acme-onion-02.html
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
