Subject: [Acme] Consensus -- CAA draft to WGLC?

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Jun 2017 15:27:56 +0000

>>                Hugo's CAA draft (already adopted, short, might be

>> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01

This has moved to WGLC.  If you know of any reason why it should not advance to the IESG, please post by end of next week.

If you are willing to be the document shepherd for this document (see https://www.ietf.org/iesg/template/doc-writeup.html; an essay style writeup is fine), please let the chairs know soon.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Jun 2017 15:36:17 -0400

> On Jun 8, 2017, at 11:27 AM, Salz, Rich <[email-masked]> wrote:
> 
> >> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 <https://tools.ietf.org/html/draft-ietf-acme-caa-01>
>  

Section 2 includes this text:

   . . .  A CA MUST only consider a property with an "account-uri"
   parameter to authorize issuance where the URI specified is an URI
   that the CA recognises as identifying the account making a
   certificate issuance request.

This is not a crust MUST statement.  I think it is trying to say two things when the "account-uri” is present: 

(1)  the CA MUST NOT issue a certificate containing the domain name that contains the CAA Resource Record if it does not recognize the account referenced by the URI.

(2)  the CA MUST use the account referenced by the URI in the authorization process for a certificate request for the domain containing the CAA Resource Record.

If this is correct, please separate these two requirements.  If it is not correct, please explain the text.

Russ

---

From: Hugo Landau <[email-masked]>
Date: Tue, 13 Jun 2017 12:03:51 +0100

>    This is not a crust MUST statement.  I think it is trying to say two
>    things when the "account-uri” is present: 
>    (1)  the CA MUST NOT issue a certificate containing the domain name that
>    contains the CAA Resource Record if it does not recognize the account
>    referenced by the URI.
>    (2)  the CA MUST use the account referenced by the URI in the
>    authorization process for a certificate request for the domain containing
>    the CAA Resource Record.

What does "crust MUST" mean?

I don't understand your interpretation. A CA does not "use" (select) an
account as part of the issuance process; the account has already been
determined from the context of the issuance request.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Jun 2017 09:23:01 -0400

Couple of minor comments:

- It might be useful to specify validation methods even without ACME.  The
CAB Forum is working on whittling down the space of available mechanisms to
an enumerated list, and while these might not completely overlap with ACME
methods, it will be a small enough list to enumerate in a registry.  I
think the only impacts to this spec would be (1) to change from
"acme-methods" to "validation-methods" and (2) to remove the "non-acme"
value.

- With regard to Section 5.1, it might be useful to note that as of Sept
2017, all Web PKI CAs will be required to check CAA; see 3.2.2.8 in

https://github.com/cabforum/documents/blob/master/docs/BR.md

- Using "CA A" as an example is kind of confusing :)  Maybe "CA X" and "CA
Y"?

On Thu, Jun 8, 2017 at 11:27 AM, Salz, Rich <[email-masked]> wrote:

> This has moved to WGLC.  If you know of any reason why it should not
> advance to the IESG, please post by end of next week.
>
>
>
> If you are willing to be the document shepherd for this document (see
> https://www.ietf.org/iesg/template/doc-writeup.html; an essay style
> writeup is fine), please let the chairs know soon.
>
>
>
> --
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jun 2017 15:14:46 +0000

> Couple of minor comments:

These seem like all strictly editorial to me.  Anyone disagree?

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Jun 2017 20:31:05 +0300

> These seem like all strictly editorial to me.  Anyone disagree?

The two last ones are editorial, but the first about enumerating
all BR methods isn't (since it needs new validation method
identifiers).

One list of all BR methods is:

"contact-applicant" (method 1 validation)
"contact-email" (method 2 validation)
"contact-fax" (method 2 validation)
"contact-sms" (method 2 validation) <-- Anyone scared yet?
"contact-postal" (method 2 validation)
"contact-phone" (method 3 validation)
"domain-email" (method 4 validation)
"authz-doc" (method 5 validation)
"http" (method 6 validation) <-- ACME HTTP-xx.
"dns" (method 7 validation) <-- ACME DNS-xx
"ip" (method 8 validation)
"test-cert" (method 9 validation)
"random-cert" (method 10 validation) <-- Possbibly TLS-SNI-xx?

(The method 2 has email, fax, SMS and postal mail as options,
those four have rather different security properties).

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jun 2017 17:33:48 +0000

> The two last ones are editorial, but the first about enumerating all BR
> methods isn't (since it needs new validation method identifiers).

Thinking about it a bit more, I don't think it is appropriate for ACME to list CABF things.  That's a strong view as an individual, and a moderate view as a WG chair.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Jun 2017 20:43:53 +0300

On Tue, Jun 13, 2017 at 05:33:48PM +0000, Salz, Rich wrote:
> Thinking about it a bit more, I don't think it is appropriate for
> ACME to list CABF things.  That's a strong view as an individual,
> and a moderate view as a WG chair.

Yeah, the major problem includes keeping the list up to date if a new
method comes about. Or if some method is modified in major way.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 30 Jun 2017 14:30:39 +0000

Based on feedback here, Hugo just posted an updated draft, https://tools.ietf.org/html/draft-ietf-acme-caa-02

I would like to advance this to the IESG in a week.  Please speak up if you disagree.

 Also, still looking for a  document shepherd (see https://www.ietf.org/iesg/template/doc-writeup.html; an essay style writeup is fine).

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Jun 2017 12:51:14 -0400

I do not see how the comments from Richard Barnes were handled.

Russ

> On Jun 30, 2017, at 10:30 AM, Salz, Rich <[email-masked]> wrote:
>