Re: [Acme] Review of draft-friel-acme-subdomains-02

Felipe Gasper <> Thu, 03 September 2020 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCF2E3A0BD5 for <>; Thu, 3 Sep 2020 06:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SHAFIfgjhs54 for <>; Thu, 3 Sep 2020 06:14:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 223F33A0BC8 for <>; Thu, 3 Sep 2020 06:14:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DC3Dk+zt0tqguHgIOQLM/uybTfJQgC+AbhqHVHoG10U=; b=j2/GVBpiwutEfVOq3FTz/o9LP 2oGnZlg343Zf81UmlBg5SXtUAiJhaEGnRoQ8xik6leGYC5igdrdnyAipRY+RVZB8zJA44BWbJm5Wl m7hhukY9BZod0zUopcNklZy0QWSjO4Sv2vm7PHccyHsfmle9XuTc3dcjkAdgTBty5tthiW+E0B9aK HKzhoWXYNVMDmd0rqrka8RWMNSyeuw3olK/PF1mP+RYCv9ZLbO/Eqix0iE7O8uqlnKGVfIIYOmtLp 87G8nEAcixmY7fjJrVr2hpZcgXZ/4PGHGXxnug7IAQSnGLZB2WTI3Zzntg7Ii55fK/TnMDmPkD7Sc gw9y64AqQ==;
Received: from [] (port=54259 helo=felipes-mbp.lan) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1kDp3w-007Mzm-Uh; Thu, 03 Sep 2020 08:14:01 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: Felipe Gasper <>
In-Reply-To: <>
Date: Thu, 03 Sep 2020 09:14:25 -0400
Cc: Russ Housley <>, IETF ACME <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Owen Friel (ofriel)" <>
X-Mailer: Apple Mail (2.3445.104.15)
X-OutGoing-Spam-Status: No, score=0.3
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: fgasper/from_h
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Acme] Review of draft-friel-acme-subdomains-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Sep 2020 13:14:06 -0000

Hi all,

	What if … there’s no need for a standard for this? Or at least, the standard would require no significant changes to the protocol?

	The application that I help manage integrates alternately with Sectigo and with Let’s Encrypt. Sectigo, when they verify domain control, always checks parent domains along with the domain(s) given in the certificate order. If any of those checks succeeds, the authz is valid. Perhaps the standard could be defined merely in those terms, such that CAs who so choose could simply indicate in the authz objects that parent/ancestor domains suffice for the verification?

	This would also allow CAs to mandate that such liberty apply only to DNS-based authz, while still requiring HTTP-based authz to be against the literal identifier.

	A bit of context: our application runs on shared-hosting servers that we don’t administer, subject to firewall rules that neither we nor the admin may control. The admins run the gamut of competence, from highly-skilled on down. The domains are end-user-controlled, not necessarily registered with the same organization that administers the server. We’ve seen all kinds of crazy setups that complicate SSL issuance, as a result of which our certificate-provision logic attempts to accommodate potential misconfigurations. Sectigo’s acceptance of ancestor domains for authz helps toward that end since all we have to do to capitalize on it is to create the relevant HTTP docroot files or DNS records all at once, then send the order. Some oddity might frustrate direct authz against “”, but as long as “” works, we can still secure the subdomain.

	An alternate implementation might be for authz objects to include challenges against whatever ancestor domains and methods the server allows; thus, if I do newAuthz against “”, I might get back:

- http-01,
- tls-alpn-01,
- dns-01,
- dns-01,
- dns-01,

	The disadvantage to that, for us, would be that we’d have to recreate the authz for every failure. I assume that that’s also disadvantageous for the ACME server--more so than simply doing “fallback” authz checks against parent domains.

	That aside, as to Owen’s proposal document:

- How is the client to indicate that they want to authz the parent domain ( rather than the literal identifier ( And for, how shall the client indicate which parent domain is to be used for authz?

Thank you!

-Felipe Gasper

> On Sep 2, 2020, at 5:41 AM, Owen Friel (ofriel) <> wrote:
> Thanks Russ. I've addressed all these in github at: I have not pushed out draft-03 yet, lets see what Jacob and Felipe have to say on the related thread about challenge options, and I will incorporate then.
> -----Original Message-----
> From: Acme <> On Behalf Of Russ Housley
> Sent: 05 August 2020 06:44
> To: IETF ACME <>
> Subject: [Acme] Review of draft-friel-acme-subdomains-02
> Document: draft-friel-acme-subdomains-02
> Reviewer: Russ Housley
> Date: 2020-08-04
> Major Concern:
> The TODO markers regarding wildcard domain names, the 200 response code, and the security considerations should be filled in with strawman text before this I-D is adopted by the ACME WG.
> Minor Concerns:
> General: s/certificate authority/certification authority/ (many)
> Abstract: s/certificate authority policy/certificate policy/
> Introduction: s/X.509 (PKIX)/X.509v3 (PKIX) [RFC5280]/
> Terminology: Correct CA, please.  See above.
> Terminology: Please add a definition of subdomain.
> Nits:
> Section 3: says:
>   3.  client sends POST-as-GET requests to retrieve the
>       "authorizations", with the downloaded "authorization" object(s)
>       containing the "identifier" that the client must prove control of
> s/client must prove control of/client must prove that they control/
> There is something wrong with the table formatting in Section 6.2.
> _______________________________________________
> Acme mailing list
> _______________________________________________
> Acme mailing list