Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
> On Jan 20, 2020, at 10:44 AM, Daniel McCarney 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 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) wrote:
> >
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 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 ; 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 On Behalf Of Owen Friel (ofriel)
> >>> Sent: 26 November 2019 22:51
> >>> To: Salz, Rich ; 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
Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
>
> 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
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)
> wrote:
> >
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01
> 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 ; 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 On Behalf Of Owen Friel (ofriel)
> >>> Sent: 26 November 2019 22:51
> >>> To: Salz, Rich ; 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] I-D Action: draft-ietf-acme-integrations-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment WG of the IETF. Title : ACME Integrations Authors : Owen Friel Richard Barnes Rifaat Shekh-Yusef Michael Richardson Filename: draft-ietf-acme-integrations-00.txt Pages : 18 Date: 2020-01-20 Abstract: This document outlines multiple advanced use cases and integrations that ACME facilitates without any modifications or enhancements required to the base ACME specification. The use cases include ACME integration with EST, BRSKI and TEAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-integrations-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
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) wrote:
>
> FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 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 ; 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 On Behalf Of Owen Friel (ofriel)
>>> Sent: 26 November 2019 22:51
>>> To: Salz, Rich ; 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 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
Date: Tuesday, November 26, 2019 at 4:51 PM
To: "mailto:acme@ietf.org;
Subject:
Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)
FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 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 ; 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 On Behalf Of Owen Friel (ofriel)
> > Sent: 26 November 2019 22:51
> > To: Salz, Rich ; 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 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
> > > Date: Tuesday, November 26, 2019 at 4:51 PM
> > > To: "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
