Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
Daniel McCarney <cpu@letsencrypt.org> Mon, 20 January 2020 15:45 UTC
Return-Path: <dmccarney@letsencrypt.org>
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 5D8681200B7 for <acme@ietfa.amsl.com>; Mon, 20 Jan 2020 07:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 4OTyvgtewNzK for <acme@ietfa.amsl.com>; Mon, 20 Jan 2020 07:45:12 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C08120104 for <acme@ietf.org>; Mon, 20 Jan 2020 07:45:11 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id i16so29903088edr.5 for <acme@ietf.org>; Mon, 20 Jan 2020 07:45:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=dC3udtlOaxOFbfmSvvWYEYrj/X8TjZcrCrApA0TXWjY=; b=IRDRGD72seyrEqG0PtlpSMM6zHwIrVCSb2TL2D2U3mRHA9M9dU474jzNJdTn3CuvF/ OgHuNUhCuoKN77mwx5AeXF4o0tKMHETcu1CmN1wVjosw/qtdgF94hRSocDN1m+EPapId 7WAy+P6D+tTqOZRDSTEzDbgnSXOXNAXY5Y7N4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=dC3udtlOaxOFbfmSvvWYEYrj/X8TjZcrCrApA0TXWjY=; b=lGEGaXLqVi7shUImUtG1mdhzUSBTJects3yedV0KSOftrpe070J7tl1yeH7+p9stGz bfk+zm62jxIfUe5hmP6aEzfXPYfR6lE2kf80U4ezszOmzsoOzwW9gDFAgWs0W6pswV/X HGIHHk0sf8I83+7OuxHpVN6sM7pk1wgQ6V60n2iPTUgSukU8qzUNum9nIZJw1JuGSSqQ lBzwu1/hq0tGV/BM7rL4z/HOFrKZZEIgkIs8VVc/fHxPgEjEzOUh/69G6nz3dTz9qWID 5bVc2fC93TgozKBhnspqqSMPd+pgHAcCTIHHt9HyNq8DjkI6RqlIUesqdX4eC9F477VU 5eVQ==
X-Gm-Message-State: APjAAAWBnMiXnsvfrRSkxdpJTING/9ZsHgUHVmWbe6C4qWGuozhXzsIT c+oS/Vj5VMhm90OA8C5nuI+aARk88ZTThesrg9WaGHbO2ug=
X-Google-Smtp-Source: APXvYqwSJd2aFxPas5gXKidxQb3D4SIuy/DWlpjPSqiRic71Zh3ewnMiiOdCAu3bylTYSZMFZlz5ZHDABWICntt5ZSo=
X-Received: by 2002:a17:906:114e:: with SMTP id i14mr9265eja.358.1579535110373; Mon, 20 Jan 2020 07:45:10 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB3901512A25A395E684808FFBDB5F0@MN2PR11MB3901.namprd11.prod.outlook.com> <MN2PR11MB3901D33CB72236ECF7BA437ADB320@MN2PR11MB3901.namprd11.prod.outlook.com> <B5F428E5-D08E-4EE6-9807-B51395F58643@felipegasper.com>
In-Reply-To: <B5F428E5-D08E-4EE6-9807-B51395F58643@felipegasper.com>
Reply-To: cpu@letsencrypt.org
From: Daniel McCarney <cpu@letsencrypt.org>
Date: Mon, 20 Jan 2020 10:44:58 -0500
Message-ID: <CAKnbcLh3o4aNiVZ6z1Bu5O9MBOfv8ufCV1R=0XRpV4YuN1GHLg@mail.gmail.com>
To: Felipe Gasper <felipe@felipegasper.com>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002a174a059c942d56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/O7HWMj41tEMnq8AE6AmSI_WRZbY>
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:45:18 -0000
> > 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. 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>; 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>; 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 >
- [Acme] ACME wildcards vs. subdomain authorization… Owen Friel (ofriel)
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Owen Friel (ofriel)
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Felipe Gasper
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Daniel McCarney
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Felipe Gasper
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Owen Friel (ofriel)
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Ryan Sleevi
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Felipe Gasper
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Felipe Gasper
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Alan Doherty
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Owen Friel (ofriel)
- Re: [Acme] ACME wildcards vs. subdomain authoriza… Owen Friel (ofriel)