Hi all, I support the draft for adoption. Specifically, I think it's a good thing to standardize the onion-csr-01 challenge type. I have two classes of comments that I look forward to discussing in-depth after adoption: 1) Obviously it's valuable for this draft to standardize a method that is already accepted by the CA/BF. But in the long term there's no need to use a CSR as the transport mechanism for a random token, a public key, and a signature -- moving away from x509 for this would be nice in the long term. Probably out-of-scope for this document, but worth discussing. 2) The primary benefit of the onion-csr-01 method is that it allows the CA to perform domain control validation without operating a Tor client. However, this benefit is obviated entirely by the need to operate a Tor client to check for CAA in the hidden service descriptor. It seems likely that there are CAs which have avoided implementing HTTP-01 and TLS-ALPN-01 for .onion due to the need to operate a Tor client; these same CAs may have been willing to implement ONION-CSR-01, but now will not due to the CAA mechanism.
Thanks, Aaron On Sun, Jun 4, 2023 at 4:07 AM Deb Cooley <debcool...@gmail.com> wrote: > This will be a two week call for adoption ending on 16 June. Please > speak up either for or against adopting this draft. > > Thanks, > Deb > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme