Subject: Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

From: Yaron Sheffer <[email-masked]>
Date: Thu, 10 Oct 2019 12:22:41 +0300

Hi Ryan,

Apologies for the very late reply. 

I accept your comments below, and we will reword this section as a recommendation or best practice. The flexibility of CAA means that the solution must be tailored to the particular CA(s) trusted by the IdO. This is unfortunate in the sense that we cannot recommend a one-size-fits-all security solution, and admins would need to have deeper understanding of the mechanisms they are using.

I am wondering though about this sentence: A CA can "also offer additional validation methods/issuance flows which also use the "dns-01" method." Doesn't specifying "dns-01" restrict the CA to one particular validation/authorization flow?

Thanks,
	Yaron

On 29/08/2019, 12:38, "Thomas Fossati" <[email-masked]> wrote:

    Hi Ryan,
    
    Thanks very much for the comments.  I'm going to address some of your
    points and let Yaron comment on the rest.
    
[snip]
    
    > 6.1 Restricting CDNs to the Delegation Mechanism There are RFC 2119
    > MUSTs attached here, when it seems these functionally should be
    > SHOULDs. That is, I think it's fair to highlight the consideration of
    > concerns between the IdO and the CDN, but I don't think it's
    > reasonable to normatively specify the policy consideration mechanism.
    > For example, as specified, those requirements would not be sufficient
    > to guarantee that a conforming CA uses this mechanism, as a number of
    > CAs "comply with ACME" (second bullet), but also offer additional
    > validation methods/issuance flows which also use the "dns-01" method.
    >
    > As CAA is intentionally flexible to allow for CA-specific policy
    > identifiers to be expressed between the IdO and the CA, I think it's
    > best to change these to SHOULD, and to recognize that CAs may devise
    > other means of technically expressing this conformance, and that's
    > between the IdO and the CA. CAA provides the necessary component (to
    > allow them to restrict to CAs that respect CAA, to allow CA-specific
    > policy), but I think that's the extent to which policy-specific
    > requirements can be made.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 10 Oct 2019 11:16:15 -0400

On Thu, Oct 10, 2019 at 5:22 AM Yaron Sheffer <[email-masked]> wrote:

> I am wondering though about this sentence: A CA can "also offer additional
> validation methods/issuance flows which also use the "dns-01" method."
> Doesn't specifying "dns-01" restrict the CA to one particular
> validation/authorization flow?
>

No.

There's a gap in the assumption here, which is that the CA MUST support
draft-ietf-acme-caa, which is not specified, and were it specified, runs
into the set of issues covered in
https://tools.ietf.org/html/draft-ietf-acme-caa-10#section-5

However, setting that aside, the dns-01 validation method alone doesn't
restrict the issuance pattern to just being STAR, which is the assertion
"To restrict certificate delegation only to the protocol defined here:"

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 11 Oct 2019 00:24:33 +0300

Agree on both points.

From: Ryan Sleevi <[email-masked]>
Date: Thursday, 10 October 2019 at 18:16
To: Yaron Sheffer <[email-masked]>
Cc: Thomas Fossati <[email-masked]>, Ryan Sleevi <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

No.

There's a gap in the assumption here, which is that the CA MUST support draft-ietf-acme-caa, which is not specified, and were it specified, runs into the set of issues covered in https://tools.ietf.org/html/draft-ietf-acme-caa-10#section-5 

However, setting that aside, the dns-01 validation method alone doesn't restrict the issuance pattern to just being STAR, which is the assertion "To restrict certificate delegation only to the protocol defined here:"