Hi Tobias, On Wed, 18 Sep 2024 14:51:52 +0000 "Tobias S. Josefowitz via Servercert-wg" <[email protected]> wrote:
> Hi Andrew, > > On Tue, 17 Sep 2024, Andrew Ayer via Servercert-wg wrote: > > > Regrettably, parsing emails sent to a Domain Contact is often the > > easiest way to implement automated validation for a large number of > > domains, since it allows delegation to a single central point, using > > configuration that is often already in place (WHOIS record contact > > information). Delegating DNS records using CNAME (e.g. with [3]) is > > The use case you bring up here is however problematic. In this > validation scenario, how would the automation ensure that the > certificate request subject to approval by e.g. the link contained in > the email is indeed the one that was requested? > > While it may be possible to securely implement automation based on > this that does so securely, checking the CSR and correlates it to the > CSR automatically handed in... it sounds unlikely that the majority > of such implementations do this properly. It would be reasonably > involved to arrive at an actually secure automated process, and it > would so easily lend itself to an insecure implementation. You can see in Amazon's documentation (https://docs.aws.amazon.com/acm/latest/userguide/email-automation.html) that the email clearly specifies the account ID of the certificate requester and a certificate identifier. It is critical to validate the account ID. I don't think this is as hard as you're suggesting. > It would be my guess that you could arrive at a secure automation for > the use case you describe with much less effort through the use of > e.g. ACME. Unfortunately, I don't think this is universally true. ALPN and HTTP challenges don't work for wildcards or hostnames that are not publicly-accessible on port 80 or 443. Large organizations usually lock down the ability to create DNS records, or are using DNS providers without sensible APIs, making it a significant challenge to manage DNS challenges at scale. Being able to delegate certificate validation for all domains to a central point is extremely useful. > Accordingly, as I currently see it, this use case is not necessarily > one that seems valuable to keep around in the face of fundamental > challenges with the underlying WHOIS based Domain Validation method, > or at all. In the long term this should not be a reason to keep around WHOIS validation, and I support immediately sunsetting WHOIS validation for ccTLDs due to the demonstrated problem there. I just wanted to provide an explanation for why sunsetting WHOIS would be disruptive to currently-deployed automation solutions. Regards, Andrew _______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
