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

[Amir Omidi]

There are two CAs (Let's Encrypt and Google Trust Services) with
DNS-ACCOUNT-01 (
https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/)
mostly ready to go. This draft is designed to solve the CNAME delegation
problem.

Maybe if there's interest for this, we can get more folks to look at this
draft so we can finalize this? For what it's worth, I'm planning on
removing the DNS-02 idea from that draft entirely.

Note that of course the timelines of this draft being "ready" is at least a
year away.

Cheers

On Wed, Sep 18, 2024 at 11:44 AM Andrew Ayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240918/d123bc8d/attachment-0001.html>