<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The issue with DNS right now through ACME is that you effectively have to give the ability for every certificate issuing system to change a single DNS zone. This is possible in small organizations but very prohibitive in large organizations.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2024 at 12:38 PM Tobias S. Josefowitz via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Andrew,<br>
<br>
On Wed, 18 Sep 2024, Andrew Ayer wrote:<br>
<br>
> On Wed, 18 Sep 2024 14:51:52 +0000<br>
> "Tobias S. Josefowitz via Servercert-wg" <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
> wrote:<br>
><br>
>> While it may be possible to securely implement automation based on<br>
>> this that does so securely, checking the CSR and correlates it to the<br>
>> CSR automatically handed in... it sounds unlikely that the majority<br>
>> of such implementations do this properly. It would be reasonably<br>
>> involved to arrive at an actually secure automated process, and it<br>
>> would so easily lend itself to an insecure implementation.<br>
><br>
> You can see in Amazon's documentation<br>
> (<a href="https://docs.aws.amazon.com/acm/latest/userguide/email-automation.html" rel="noreferrer" target="_blank">https://docs.aws.amazon.com/acm/latest/userguide/email-automation.html</a>)<br>
> that the email clearly specifies the account ID of the certificate<br>
> requester and a certificate identifier.  It is critical to validate the<br>
> account ID.  I don't think this is as hard as you're suggesting.<br>
<br>
Indeed, thank you for sharing this. I can easily see how one could do <br>
something useful with this. I am not convinced that's where the majority <br>
of users of this method necessarily arrive, but I certainly do not want to <br>
criticize anyone who did.<br>
<br>
> Unfortunately, I don't think this is universally true.  ALPN and<br>
> HTTP challenges don't work for wildcards or hostnames that are not<br>
> publicly-accessible on port 80 or 443.  Large organizations usually lock<br>
> down the ability to create DNS records, or are using DNS providers<br>
> without sensible APIs, making it a significant challenge to manage DNS<br>
> challenges at scale.  Being able to delegate certificate validation for<br>
> all domains to a central point is extremely useful.<br>
<br>
I still maintain that ACME with automated DNS changes is ultimately the <br>
better option, DNS hosting options enabling that are readily available as <br>
well. But I would not like to be forced to transition from one that <br>
doesn't allow it to one that does for an organization, and specifically <br>
not in a short timeframe. Point taken.<br>
<br>
> In the long term this should not be a reason to keep around WHOIS<br>
> validation, and I support immediately sunsetting WHOIS validation for<br>
> ccTLDs due to the demonstrated problem there.  I just wanted to provide<br>
> an explanation for why sunsetting WHOIS would be disruptive to<br>
> currently-deployed automation solutions.<br>
<br>
Thank you for that!<br>
<br>
Tobi<br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>