[Servercert-wg] Discussion Period Begins - Ballot SC-080 V1: "Sunsetting use of WHOIS to identify Domain Contacts"

[Andrew Ayer]

Hi Tobias,

On Wed, 18 Sep 2024 14:51:52 +0000
"Tobias S. Josefowitz via Servercert-wg" <servercert-wg at cabforum.org>
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