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

Felipe Gasper <felipe@felipegasper.com> Mon, 20 January 2020 15:48 UTC

Return-Path: <felipe@felipegasper.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA8212008A for <acme@ietfa.amsl.com>; Mon, 20 Jan 2020 07:48:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=felipegasper.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2vvVrry1bYd for <acme@ietfa.amsl.com>; Mon, 20 Jan 2020 07:48:33 -0800 (PST)
Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5DA12007A for <acme@ietf.org>; Mon, 20 Jan 2020 07:48:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; 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=DKAW7XRUmXIiuEvLDaeyLYvZHrFf8SjEwzI/xvIVAHk=; b=jQF1qLLZqfOw8xJoD6OoJ/P2Q onjJLh3x0B8UjIAIYPD5forZ+ewsJ3TBOCHLB4F7emztrkEJ+oef4GjwGuV/a02LlyRtkQIZM3F6z nOKFDyOrrzDm86I8OtMP7DgD2XY8PdUie1W6LwE0AU/3P3nsjpwPooM67zQhQsMHNQtlmSQYWbX7w lvJKMLoeiW1QCx930jpcNVLd//vp1CQsW2bK1K12spIGW0LPcUX7McXA0UL2u5WL48bDLrKFVjhG2 bXSLcjm/MGCxp7Dp3pZEI4UqR0vpbJRlOlTzg6QqdJvR7zDj7meZO+8tvQBWZS3cR8CiyyQFmTXWW PN5fuzkNg==;
Received: from hou-2.nat.cptxoffice.net ([184.94.197.2]:41610 helo=[10.3.5.86]) by web1.siteocity.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <felipe@felipegasper.com>) id 1itZHy-00AWIg-LT; Mon, 20 Jan 2020 09:48:32 -0600
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Felipe Gasper <felipe@felipegasper.com>
In-Reply-To: <CAKnbcLh3o4aNiVZ6z1Bu5O9MBOfv8ufCV1R=0XRpV4YuN1GHLg@mail.gmail.com>
Date: Mon, 20 Jan 2020 10:48:28 -0500
Cc: IETF ACME <acme@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB873B83-C35A-4ADC-89C7-DC02B8F88254@felipegasper.com>
References: <MN2PR11MB3901512A25A395E684808FFBDB5F0@MN2PR11MB3901.namprd11.prod.outlook.com> <MN2PR11MB3901D33CB72236ECF7BA437ADB320@MN2PR11MB3901.namprd11.prod.outlook.com> <B5F428E5-D08E-4EE6-9807-B51395F58643@felipegasper.com> <CAKnbcLh3o4aNiVZ6z1Bu5O9MBOfv8ufCV1R=0XRpV4YuN1GHLg@mail.gmail.com>
To: Daniel McCarney <cpu@letsencrypt.org>
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 - web1.siteocity.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - felipegasper.com
X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h
X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/5h_VZKwxEIXvCeIN-tXLAW6XltA>
Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2020 15:48:39 -0000


> On Jan 20, 2020, at 10:44 AM, Daniel McCarney <cpu@letsencrypt.org> wrote:
> 
>  I thought that was the reason why ACME limits wildcard authz to DNS.
> 
> I don't think RFC 8555 imposes any restrictions on what challenge types can be used for wildcard identifiers. Limiting wildcard DNS identifiers to the DNS-01 challenge is a policy decision by Let's Encrypt.

You’re right; I was misreading it. Sorry for the confusion.

-F


> 
> On Mon, Jan 20, 2020 at 7:32 AM Felipe Gasper <felipe@felipegasper.com> wrote:
> Will this document eventually also describe subdomain authz via the standard ACME workflow?
> 
> Examples:
> 
> 1) Client wants a certificate for example.com & www.example.com. Ideally, if the client authzs example.com, then authz for www.example.com shouldn’t be necessary.
> 
> 2) Now client also wants a separate certificate for sub.example.com and www.sub.example.com. Since example.com 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
>    ownership.
> 
> 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.
> 
> 
> cheers,
> -Felipe Gasper
> 
> 
> > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> > 
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents the proposed new authorization object field "basedomain"
> > 
> > 
> >> -----Original Message-----
> >> From: Acme <acme-bounces@ietf.org> On Behalf Of Owen Friel (ofriel)
> >> Sent: 06 December 2019 15:41
> >> To: Salz, Rich <rsalz@akamai.com>om>; acme@ietf.org
> >> 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 <acme-bounces@ietf.org> On Behalf Of Owen Friel (ofriel)
> >>> Sent: 26 November 2019 22:51
> >>> To: Salz, Rich <rsalz@akamai.com>om>; acme@ietf.org
> >>> 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. https://tools.ietf.org/html/rfc8555#section-7.1.3 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. https://tools.ietf.org/html/rfc8555#section-7.1.4 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. https://tools.ietf.org/html/rfc8555#section-7.4.1 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
> >>> https://tools.ietf.org/html/draft-friel-
> >>> 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 <acme-bounces@ietf.org> On Behalf Of Salz, Rich
> >>>> Sent: 26 November 2019 21:53
> >>>> To: acme@ietf.org
> >>>> 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 <mailto:rsalz@akamai.com>
> >>>> Date: Tuesday, November 26, 2019 at 4:51 PM
> >>>> To: "mailto:acme@ietf.org" <mailto:acme@ietf.org>
> >>>> 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@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/acme
> >> _______________________________________________
> >> Acme mailing list
> >> Acme@ietf.org
> >> https://www.ietf.org/mailman/listinfo/acme
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme