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>
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)
Precedence: list



> On Jan 20, 2020, at 10:44 AM, Daniel McCarney <cpu@letsencrypt.org> =
wrote:
>=20
>  I thought that was the reason why ACME limits wildcard authz to DNS.
>=20
> 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=E2=80=99re right; I was misreading it. Sorry for the confusion.

-F


>=20
> 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?
>=20
> Examples:
>=20
> 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=E2=80=99t be necessary.
>=20
> 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.
>=20
> It seems like the above workflow should =E2=80=9Cjust work=E2=80=9D, =
but since it=E2=80=99s closely related to what your document describes I =
wonder if there=E2=80=99s benefit to mentioning it?
>=20
> Also, the linked document states:
>=20
>    The call flow illustrates the DNS-based proof of ownership =
mechanism,
>    but the subdomain workflow is equally valid for HTTP based proof of
>    ownership.
>=20
> Can=E2=80=99t I have HTTP access to a base domain=E2=80=99s website =
without having access to a subdomain=E2=80=99s, though? I thought that =
was the reason why ACME limits wildcard authz to DNS.
>=20
>=20
> cheers,
> -Felipe Gasper
>=20
>=20
> > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <ofriel@cisco.com> =
wrote:
> >=20
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 =
documents the proposed new authorization object field "basedomain"
> >=20
> >=20
> >> -----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)
> >>=20
> >> Any comments on this email on how to explicitly distinguish between =
wildcard
> >> and subdomain authorizations, which hopefully addresses ekr's mic =
comments.
> >>=20
> >>=20
> >>> -----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
> >>>=20
> >>> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition =
to
> >>> the IANA Considerations section):
> >>>=20
> >>> 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order =
Objects:
> >>>=20
> >>>   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.
> >>>=20
> >>> 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization =
Objects:
> >>>=20
> >>>   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.
> >>>=20
> >>> 3. https://tools.ietf.org/html/rfc8555#section-7.4.1 =
Pre-authorization
> >>>=20
> >>>   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.
> >>>=20
> >>> 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.
> >>>=20
> >>> 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.
> >>>=20
> >>> 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.
> >>>=20
> >>>> -----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
> >>>>=20
> >>>> WRONG.  My mistake.
> >>>>=20
> >>>> Please discuss this, especially the subdomains/wildcard issues.
> >>>> This is *NOT* a call for adoption.  We will take this up in =
Vancouver, IETF
> >> 107.
> >>>>=20
> >>>> 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
> >>>>=20
> >>>> 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.
> >>>>=20
> >>>> Thank you.
> >>>>=20
> >>> _______________________________________________
> >>> 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
>=20
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme