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

Reply via email to