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

[Owen Friel (ofriel)]

> -Original Message-
> From: Felipe Gasper 
> Sent: 21 January 2020 14:15
> To: Ryan Sleevi 
> Cc: Owen Friel (ofriel) ; IETF ACME 
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> 
> > On Jan 21, 2020, at 8:04 AM, Ryan Sleevi  wrote:
> >
> > On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel)  
> > wrote:
> > > 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.
> >
> > [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME
> limitation.
> >
> > Although the CA/Browser Forum / Browser Stores have repeatedly
> > discussed forbidding it. That is, allowing the HTTP and TLS methods of
> > validation to only be scoped for the host in question (and potentially
> > the service in question, if we can work out the safe SRVName
> > transition, due to the interaction of nameConstraints and policy)
> >
> > Would it be simpler to remove the statement from the draft, rather than try 
> > to
> clarify equally valid refers to the technology without commenting on the 
> policy?
> 
> For what my opinion is worth, that seems reasonable--though perhaps the best
> might be to defer explicitly to the CA/B guidelines, e.g., “whatever 
> validation
> methods CA/B allows for subdomains/wildcards, this also allows.”

[ofriel] this suggestion makes sense. I will clarify what RFC8555 allows, and 
then refer to CA/B guidelines too. This could be for a private CA, or an IoT 
root CA (as per the long thread on lamps), so CA/B may not even be applicable 
depending on the use case.

> 
> -F
___
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)

[Owen Friel (ofriel)]

> -Original Message-
> From: Felipe Gasper 
> Sent: 21 January 2020 14:01
> To: Owen Friel (ofriel) 
> Cc: IETF ACME 
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> 
> > On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel)  wrote:
> >
> >>
> >> Will this document eventually also describe subdomain authz via the
> >> standard ACME workflow?
> >>
> >> 
> >
> > [ofriel] That’s the exact workflow that the document is attempting to
> describe, so maybe it needs to be clarified.
> > The example section https://tools.ietf.org/html/draft-friel-acme-subdomains-
> 01#section-4.2 (and I realise now looking at it that I messed up the numbered
> steps - they are all '1') outlines a client authorizing for "example.com" and
> getting certs for "sub0.example.com", "sub1.example.com" and
> "sub2.example.com". If its not clear, I can try reword in an update.
> 
> Your document seems to confine itself to the pre-authorization workflow,
> though (as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability 
> to
> 8555’s default/standard/order-then-authz workflow.

[ofriel] Confining to pre-authorization certainly isn’t the intention, and I 
can clarify this.

https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.1 states:

" If a server has such a policy and a client is not authorized for the
   parent domain then:
...
   o  If the client submits a newOrder request for a subdomain: The
  server MUST return a status 201 (Created) response.  The response
  body is an order object with status set to "pending" and links to
  newly created authorizations objects against the parent domain." 

So some of the text explicitly allows this. I will refactor.

> 
> -FG
___
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)

[Alan Doherty]

At 13:04 21/01/2020  Tuesday, Ryan Sleevi wrote:


>On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) 
><ofr...@cisco.com> wrote:
>> 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? 

err yes you can (easily)
I as a website provider, have access to the http base domains of many customers 
(how we obtain/refresh the SAN certs that keep their websites available) I do 
not (and do not want/need access to create wildcard certs for their other sites 
elsewhere)
and customers do not assume their web host provider needs a lot of trust



I (separate hat) as a dns provider (separate set of customers some overlap) can 
access their basedomain to create wildcards, but as i could also repoint their 
other sites elsewhere (here for long enough to http authenticate them too, or 
to a reverse proxy to mitm them etc) this risk is omnipresent (why you should 
ensure your dns hoster is above reproach and has a small staff, here its 2 ppl 
with access to the dns servers)
and why dns hoster is usually seriously considered as largest risk in terms of 
Internet vulnerability



>I thought that was the reason why ACME limits wildcard
>> authz to DNS.
>
>[ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME 
>limitation.
>
>
>Although the CA/Browser Forum / Browser Stores have repeatedly discussed 
>forbidding it. That is, allowing the HTTP and TLS methods of validation to 
>only be scoped for the host in question (and potentially the service in 
>question, if we can work out the safe SRVName transition, due to the 
>interaction of nameConstraints and policy)
>
>Would it be simpler to remove the statement from the draft, rather than try to 
>clarify equally valid refers to the technology without commenting on the 
>policy?
>
>___
>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

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

[Felipe Gasper]

> On Jan 21, 2020, at 8:04 AM, Ryan Sleevi  wrote:
> 
> On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel)  wrote:
> > 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.
> 
> [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME 
> limitation.
> 
> Although the CA/Browser Forum / Browser Stores have repeatedly discussed 
> forbidding it. That is, allowing the HTTP and TLS methods of validation to 
> only be scoped for the host in question (and potentially the service in 
> question, if we can work out the safe SRVName transition, due to the 
> interaction of nameConstraints and policy)
> 
> Would it be simpler to remove the statement from the draft, rather than try 
> to clarify equally valid refers to the technology without commenting on the 
> policy?

For what my opinion is worth, that seems reasonable--though perhaps the best 
might be to defer explicitly to the CA/B guidelines, e.g., “whatever validation 
methods CA/B allows for subdomains/wildcards, this also allows.”

-F
___
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)

[Felipe Gasper]

> On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>> Will this document eventually also describe subdomain authz via the standard
>> ACME workflow?
>> 
>> 
> 
> [ofriel] That’s the exact workflow that the document is attempting to 
> describe, so maybe it needs to be clarified.
> The example section 
> https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.2 (and I 
> realise now looking at it that I messed up the numbered steps - they are all 
> '1') outlines a client authorizing for "example.com" and getting certs for 
> "sub0.example.com", "sub1.example.com" and "sub2.example.com". If its not 
> clear, I can try reword in an update.

Your document seems to confine itself to the pre-authorization workflow, though 
(as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability to 
8555’s default/standard/order-then-authz workflow.

-FG
___
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)

[Ryan Sleevi]

On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) 
wrote:

> > 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.
>
> [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an
> ACME limitation.


Although the CA/Browser Forum / Browser Stores have repeatedly discussed
forbidding it. That is, allowing the HTTP and TLS methods of validation to
only be scoped for the host in question (and potentially the service in
question, if we can work out the safe SRVName transition, due to the
interaction of nameConstraints and policy)

Would it be simpler to remove the statement from the draft, rather than try
to clarify equally valid refers to the technology without commenting on the
policy?

>
___
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)

[Owen Friel (ofriel)]

> -Original Message-
> From: Acme  On Behalf Of Felipe Gasper
> Sent: 20 January 2020 12:32
> To: IETF ACME 
> Subject: 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?
> 

[ofriel] That’s the exact workflow that the document is attempting to describe, 
so maybe it needs to be clarified.
The example section 
https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.2 (and I 
realise now looking at it that I messed up the numbered steps - they are all 
'1') outlines a client authorizing for "example.com" and getting certs for 
"sub0.example.com", "sub1.example.com" and "sub2.example.com". If its not 
clear, I can try reword in an update.

> 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.

[ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME 
limitation.

> 
> 
> 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 i

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

[Felipe Gasper]

> 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" b

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

[Daniel McCarney]

>
>  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 i

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

[Felipe Gasper]

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
>>> a

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

[Owen Friel (ofriel)]

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 <mailto:rs...@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] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Owen Friel (ofriel)]

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