Subject: [Acme] 2nd working group call for adoption

From: "Cooley, Dorothy E" <[email-masked]>
Date: Thu, 14 Oct 2021 12:16:23 +0000

This is the second working group call for adoption of:  draft-friel-acme-subdomains-05.
We have had presentations of this work at the most recent interim (clarifications presented) and at many of the past IETF meetings.

Please review the draft and post your comments to the list by Thursday, 28
October 2021.

Thanks,
Deb and Yoav

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Oct 2021 17:03:31 -0400

I have read the document, and I think that ACME should adopt it.

Russ

> On Oct 14, 2021, at 8:16 AM, Cooley, Dorothy E <decoole=[email-masked]> wrote:
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 15 Oct 2021 09:07:59 +1100

Just read it. Reasonable thing to specify.

Not sure why this doesn't talk about delegations of the domain and the effect that might have. That seems relevant. Though control over the parent implies control over delegations, it might be a consideration when setting policy.

Not sure why "domainNamespace" is used as the field when "subdomains" is shorter and easier to understand.

On Thu, Oct 14, 2021, at 23:16, Cooley, Dorothy E wrote:
> We have had presentations of this work at the most recent interim 
> (clarifications presented) and at many of the past IETF meetings.
>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Fri, 15 Oct 2021 07:00:29 +0000

[ofriel] there was early discussion on the mailer about what exactly a 'subdomain' meant. So we quoted the CA/B Browser baseline definitions and used that terminology instead.  Note that the draft is not restricted to web use cases, so basing terminology on CA/B is not by any means mandatory. I have no strong preference on what we call the field at all -  subdomains and namespaces are both used in the draft, so happy to change to whatever is clearest.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 15 Oct 2021 10:46:26 -0400

I have read the document, and support its adoption.

This functionality actually reflects the existing behavior of a lot of CAs
in the Web PKI (allowing issuance for subdomains after validating a
registered domain), so it's good to have clear semantics in ACME for it.

--Richard

---

From: Seo Suchan <[email-masked]>
Date: Fri, 15 Oct 2021 23:56:47 +0900

I think it'd better to not limit challenge type to dns-01, but to any 
challenge type that CA is be allowed to issue wildcard cert from it. 
there may be add another challenge type (like using rfc8823's mail 
challange to CAA iodef or whois mail?) or DNS challenge may needed to 
amend to dns-02 in future.

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Fri, 15 Oct 2021 13:26:02 +0000

+1 for adoption. 
It will benefit various usecases. 

-----Original Message-----
From: Acme <[email-masked]> On Behalf Of Cooley, Dorothy E
Sent: Thursday, October 14, 2021 8:16 AM
To: [email-masked]' <[email-masked]>
Subject: [Acme] 2nd working group call for adoption

Please review the draft and post your comments to the list by Thursday, 28 October 2021.

Thanks,
Deb and Yoav

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 15:41:38 -0400

You don't say if you support adoption or not.
Is this something the WG should on?  Once adopted, the WG can change it.

Seo Suchan <[email-masked]> wrote:
    > challenge type that CA is be allowed to issue wildcard cert from it. there
    > may be add another challenge type (like using rfc8823's mail challange to CAA
    > iodef or whois mail?) or DNS challenge may needed to amend to dns-02 in
    > future.

I think that should new challenge types come along, that those new challenges
will either Update this document, will detail some new consideration, or will
detail why a subdomain challenge can't apply.

Security reviewers do not like it when they inputs to some protocols can be
anything.  Narrow scopes are easy to widen with later documents.  The
opposite is not the case.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 18 Oct 2021 12:45:38 +1100

On Fri, Oct 15, 2021, at 18:00, Owen Friel (ofriel) wrote:
> [ofriel] there was early discussion on the mailer about what exactly a 
> 'subdomain' meant. So we quoted the CA/B Browser baseline definitions 
> and used that terminology instead.  Note that the draft is not 
> restricted to web use cases, so basing terminology on CA/B is not by 
> any means mandatory. I have no strong preference on what we call the 
> field at all -  subdomains and namespaces are both used in the draft, 
> so happy to change to whatever is clearest.

RFC 8499:

   Subdomain:  "A domain is a subdomain of another domain if it is
      contained within that domain.

I found "namespaces" confusing.  I don't think we need to borrow CA/BF obfuscations.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Oct 2021 07:41:09 +0200

I have read the draft and support its adoption.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 25 Oct 2021 06:08:41 +0000

-----Original Message-----
From: Martin Thomson <[email-masked]> 
Sent: 18 October 2021 09:46
To: Owen Friel (ofriel) <[email-masked]>; [email-masked]
Subject: Re: [Acme] 2nd working group call for adoption

RFC 8499:

[ofriel] As section https://datatracker.ietf.org/doc/html/draft-friel-acme-subdomains-05#section-7.1 already explicitly states that this draft is not restricted to Web PKI use cases and CA/B policy, and is equally applicable to e.g. IoT use cases or Private CA use cases, it makes sense to stick to generic IETF RFC 8499 terminology, and use that to define subdomain. 

And even though the appendix explicitly references version 1.7.1 of the CA/B reqs, its probably worth deleting that appendix completely, as its already out of date.