Subject: [Acme] Before entering WGLC ...

From: "Salz, Rich" <[email-masked]>
Date: Fri, 16 Jun 2017 12:40:05 +0000

Hugo, the CAA document is in WGLC.  Russ raised the following issue on some text in section 2:

   . . .  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 [crisp] 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.

Can you post an update next week?  If not, would it help to add another author to do so?  I would like to move this forward to the IESG soon.  Please respond by early next week.

Thank you.

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

---

From: Hugo Landau <[email-masked]>
Date: Sat, 17 Jun 2017 16:01:22 +0100

> Can you post an update next week?  If not, would it help to add another author to do so?  I would like to move this forward to the IESG soon.  Please respond by early next week.

I don't understand this issue. The wording is clear.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 17 Jun 2017 23:03:32 +0000

> > > (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.
> >
> > Can you post an update next week?  If not, would it help to add another
> author to do so?  I would like to move this forward to the IESG soon.  Please
> respond by early next week.
> 

It's understandable, yes.   Does Russ's proposal have the same meaning?   I'm not sure.  That means, I think that the original wording could stand a bit of clarification.

---

From: Hugo Landau <[email-masked]>
Date: Sun, 18 Jun 2017 10:02:19 +0100

> It's understandable, yes.   Does Russ's proposal have the same meaning?   I'm not sure.  That means, I think that the original wording could stand a bit of clarification.

(2) is weird. It talks about 'using an account', as though a CAA record
can dictate what account is to be used. It almost suggests something
like this:

  - I register account A and issue for example.com and setup ACME-CAA
    for that account
  - An unrelated party creates account B and requests issuance for
    example.com without control over that domain; the CA identifies
    the account specified in ACME-CAA, finds it authorised to issue
    for example.com and issues under it (!!!)

Moreover it talks about how the CA MUST NOT issue a certificate under
certain circumstances. But an individual CAA record never prevents
issuance, per se (although the presence of any CAA records creates the
requirement that at least one pass); at the worst it merely fails to
authorize issuance in a particular case (but other adjacent CAA records
might).

Because of this I think it's necessary to keep the wording in terms of
whether a CAA property authorizes issuance, rather than an enumeration
of cases in which issuance MUST NOT occur. That's simply not possible
when speaking about a single CAA record without regard to the other CAA
records which might be adjacent to it.

I'm open to clearer wording but I can't see any better way to express
this accurately than talking about whether a given CAA property
authorizes issuance.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 18 Jun 2017 14:16:04 +0000

Thank you.  For me, it addresses the issue.  Russ, are you ok?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Jun 2017 09:30:17 +1000

Like Russ, I find the statement very difficult to read.  Would
inverting it be better?

> A CA MUST NOT issue authorize issuance if a CAA record is present unless the "account-uri" parameter identifies the account making a certificate issuance request.

On 19 June 2017 at 00:16, Salz, Rich <[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Hugo Landau <[email-masked]>
Date: Mon, 19 Jun 2017 17:22:31 +0100

> > A CA MUST NOT issue authorize issuance if a CAA record is present unless the "account-uri" parameter identifies the account making a certificate issuance request.
See previous reply. Issuance is not determined by the presence of "a"
CAA record; there may be multiple and issuance is authorized if any are
considered to match the request. Establishing that a specific CAA record
is not matched is not a sufficient condition for refusing issuance,
because another adjacent CAA record might authorise it. I think any
attempt to describe this criterion in terms of specific situational MUST
NOTs with regard to a single CAA record is futile.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Jun 2017 16:31:43 +0000

How about this:

A CA MAY proceed with issuance if a CAA record is present whose value matches the account-uri parameter of the account making the request.
If no CAA records have such a match, then the CA MUST NOT proceed with issuance.

---

From: Hugo Landau <[email-masked]>
Date: Tue, 20 Jun 2017 12:10:43 +0100

> If no CAA records have such a match, then the CA MUST NOT proceed with issuance.
This neglects to include the other criteria for validation of a CAA
record, however; the wording here suggests this is the only aspect of a
CAA record that needs to be validated. If you want to describe a
sufficient condition, rather than a necessary one, it stands to reason
you'd have to copy and paste large amounts of language from the CAA
specification into the specification.

Currently we have
  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.

We could also negate it, which might actually be better - the above is
slightly more susceptible to be confused for a statement of a sufficient
condition:
  A CA MUST NOT consider a property with an "account-uri" parameter to
  authorize issuance unless the URI specified is an URI that the CA
  recognises as identifying the account making a certificate issuance
  request.

This might be easier to read, though is actually slightly longer:
  Where a CAA property has an "account-uri" parameter, a CA MUST NOT
  consider that property to authorize issuance in the context of a given
  certificate issuance request unless the CA recognises the URI
  specified as identifying the account making that request.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Jun 2017 12:08:53 +0000

>   specified as identifying the account making that request.

I like this.  Martin and Russ, your views?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Jun 2017 15:10:31 +1000

> I like this.  Martin and Russ, your views?

It's an improvement, certainly.  For brevity I would say:

"unless the account URI corresponds to the account making that request."

There are many specification pitfalls here regarding how you might
compare URIs, but this neatly avoids those and leaves the authority
for that space (the CA) in the position where it performs the
comparison.