Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

Felipe Gasper <> Mon, 20 January 2020 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C053F1200E5 for <>; Mon, 20 Jan 2020 04:31:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vWYe1c0awsUO for <>; Mon, 20 Jan 2020 04:31:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81EDC120059 for <>; Mon, 20 Jan 2020 04:31:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From:Sender: Reply-To:Cc: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=N6Yqr69ws2iiALjSncAeObpP75+Vsm+E7ozSSqtV1Y0=; b=Fot4lyUtCQK0WiJdfHhdz92AeT w8oIjms1T2GaRAUjAlnkyG9qC1pOqR7qMXYvNANF+o7wcA5Ey3iLyH+vpdGxQWcK+6msu5bEdMP7/ oDnWTYIpHzMqMnM2LvO34bJ+x4FZ0CRTL23vfQO0YeK7zHfSGG736vvAHFviJTBKSkhrshC3zQVQZ Ng/QlgmmmJ3u8zi+QA5XZ/UHIm2N2cKS2im6CpOpsHO1L0f/fXCtHn1s6u24L0JGt/oC5WYWr03hl clKhe+kfhiCFMG9JPCvCjfyffAdgDrYVIczEBdKNQ00uaMbuaA0NKGtCqc07e3+T4h6Re7hiCw3uA V9g63/zg==;
Received: from [] (port=59931 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1itWDg-009zVH-A4 for; Mon, 20 Jan 2020 06:31:53 -0600
From: Felipe Gasper <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 20 Jan 2020 07:31:50 -0500
References: <> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
X-OutGoing-Spam-Status: No, score=-0.2
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] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
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: Mon, 20 Jan 2020 12:31:59 -0000

Will this document eventually also describe subdomain authz via the standard ACME workflow?


1) Client wants a certificate for & Ideally, if the client authzs, then authz for shouldn’t be necessary.

2) Now client also wants a separate certificate for and Since was already authorized, this certificate order should not require any additional authz.

It seems like the above workflow should “just work”, but since it’s closely related to what your document describes I wonder if there’s benefit to mentioning it?

Also, the linked document states:

   The call flow illustrates the DNS-based proof of ownership mechanism,
   but the subdomain workflow is equally valid for HTTP based proof of

Can’t I have HTTP access to a base domain’s website without having access to a subdomain’s, though? I thought that was the reason why ACME limits wildcard authz to DNS.

-Felipe Gasper

> On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <> wrote:
> FYI, documents the proposed new authorization object field "basedomain"
>> -----Original Message-----
>> From: Acme <> On Behalf Of Owen Friel (ofriel)
>> Sent: 06 December 2019 15:41
>> To: Salz, Rich <>om>;
>> Subject: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for
>> adoption draft-frield-acme-subdomains)
>> Any comments on this email on how to explicitly distinguish between wildcard
>> and subdomain authorizations, which hopefully addresses ekr's mic comments.
>>> -----Original Message-----
>>> From: Acme <> On Behalf Of Owen Friel (ofriel)
>>> Sent: 26 November 2019 22:51
>>> To: Salz, Rich <>om>;
>>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
>>> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to
>>> the IANA Considerations section):
>>> 1. Order Objects:
>>>   Any identifier of type "dns" in a newOrder request MAY have a
>>>   wildcard domain name as its value.  A wildcard domain name consists
>>>   of a single asterisk character followed by a single full stop
>>>   character ("*.") followed by a domain name as defined for use in the
>>>   Subject Alternate Name Extension by [RFC5280].  An authorization
>>>   returned by the server for a wildcard domain name identifier MUST NOT
>>>   include the asterisk and full stop ("*.") prefix in the authorization
>>>   identifier value.  The returned authorization MUST include the
>>>   optional "wildcard" field, with a value of true.
>>> 2. Authorization Objects:
>>>   If an
>>>   authorization object conveys authorization for the base domain of a
>>>   newOrder DNS identifier containing a wildcard domain name, then the
>>>   optional authorizations "wildcard" field MUST be present with a value
>>>   of true.
>>> 3. Pre-authorization
>>>   Note that because the identifier in a pre-authorization request is
>>>   the exact identifier to be included in the authorization object, pre-
>>>   authorization cannot be used to authorize issuance of certificates
>>>   containing wildcard domain names.
>>> For the subdomains use case, it looks as if it makes sense to define a
>>> "parentdomain" boolean flag (or "basedomainname" or similar) to be
>>> included in the authorization object for a domain that authorizes
>>> subdomain certs. The relevant CAB guidelines are quoted in
>>> acme-subdomains-00#appendix-A.
>>> The authorization object would then explicitly indicate that this is a
>>> base domain authorization and thus subdomain certs may be issued off
>>> this. This is conceptually similar to the current "wildcard" flag
>>> which indicates that a wildcard cert may be issued off the identifier
>>> in the object, and would definitively differentiate wildcard vs. base
>>> domain vs. explicit domain authorizations.
>>> Item #3 from section 7.4.1 Pre-authorization is already called out as
>>> a substantive change from RFC8555: i.e. the identifier in the
>>> authorization object may be different from the identifier in the newAuthz
>> object.
>>>> -----Original Message-----
>>>> From: Acme <> On Behalf Of Salz, Rich
>>>> Sent: 26 November 2019 21:53
>>>> To:
>>>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
>>>> WRONG.  My mistake.
>>>> Please discuss this, especially the subdomains/wildcard issues.
>>>> This is *NOT* a call for adoption.  We will take this up in Vancouver, IETF
>> 107.
>>>> From: Rich Salz <>
>>>> Date: Tuesday, November 26, 2019 at 4:51 PM
>>>> To: "" <>
>>>> Subject: [Acme] Call for adoption draft-frield-acme-subdomains
>>>> This email starts a ten-day call for adoption. There was consensus
>>>> in the room at IETF 106 to adopt this as a working group document.
>>>> If you disagree with that, or have any other strong feelings, please
>>>> post to the list before the end of next week.
>>>> Also discussed was the need for some additional clarity around
>>>> subdomains and the existing wildcard challenges.
>>>> Thank you.
>>> _______________________________________________
>>> Acme mailing list
>> _______________________________________________
>> Acme mailing list
> _______________________________________________
> Acme mailing list