Subject: [Acme] draft-ietf-acme-subdomains and public suffixes

From: Peter Thomassen <[email-masked]>
Date: Thu, 7 Apr 2022 16:36:16 +0200

Hi,

Perhaps the following has been discussed before (although I wasn't able to find it, then); in that case, please let me know, and we can close the thread.

I read the draft and think it is a good idea and well done.

However, I was wondering: What if there is a public suffix between the subdomain for which a certificate is requested, and the parent domain used for validation?

Let's work through an example. You may be familiar with the (non-official) eu.org registry, which runs several public suffixes under which one can register domain names. These public suffixes appear on the public suffix list (e.g. de.eu.org).

Now, should it be possible for the DNS admin of eu.org to request a certificate for example.de.eu.org (or subdomains thereof) through the mechanism described in the draft, although there is a public suffix in between? (I don't think so.)

If this should be prevented, the corresponding public suffix check needs to be mandatory. (However, I'm not sure if it needs to be in this draft, or in the CA/B guidelines.)

What do you think?

Thanks,
Peter

-- 
https://desec.io/

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 7 Apr 2022 14:26:05 -0400

On Thu, Apr 7, 2022 at 10:36 AM Peter Thomassen <[email-masked]> wrote:

> Now, should it be possible for the DNS admin of eu.org to request a
> certificate for example.de.eu.org (or subdomains thereof) through the
> mechanism described in the draft, although there is a public suffix in
> between? (I don't think so.)
>
> If this should be prevented, the corresponding public suffix check needs
> to be mandatory. (However, I'm not sure if it needs to be in this draft, or
> in the CA/B guidelines.)

Given that public suffices are an unfortunate fiction invented by browsers,
it'd be doubly unfortunate to codify it in an IETF doc.

That said, it is already an existing requirement of the CA/Browser Forum
Baseline Requirements (for TLS; no comments made re: S/MIME), such that the
authorization domain name (aka the prefix) used to verify a domain requires
termination of tree climbing upon encountering the first public suffix.

So, in practice, a CA using this spec and conforming to the CA/Browser
Forum BRs will refuse to issue such a certificate.

However, this is a convenient fiction in separation: the DNS admin of eu.org
can, at any time, remove de.eu.org from the public suffix list, as they are
the parent authority. In that sense, they have the full technical
capability to cause issuance.

The requirement of public suffix separation is _primarily_ a holdover from
when every validation method was treated equally by CAs (e.g. the use of
HTTP to approve a wildcard domain, without demonstrating DNS-based
control). With the new separations that restrict such broadening, it is
conceivable to imagine that the requirement to "stop" at the public suffix
is removed from the Baseline Requirements, in recognition that the parent
domain fundamentally has more power than the child labels.