Re: [Acme] Barry Leiba's Discuss on draft-ietf-acme-caa-07: (with DISCUSS and COMMENT)

[Hugo Landau <[e-mail]>]

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> — Section 4 —
> 
>    If appropriate non-ACME identifiers are not present in the
>    ACME Validation Methods IANA registry, the CA MUST use identifiers
>    beginning with the string "ca-", which are defined to have CA-
>    specific meaning.
> 
> Was the working group aware of BCP 178 (RFC 6648), and did they consider the
> “ca-“ prefix in that context?  If so, how does the working group propose to
> avoid the problems outlined by BCP 178?
Yes.

All of these identifiers are already scoped to a specific CA via a
domain name, due to the nature of the CAA specification. The CAA
specification also provides that parameters in general are a CA-specific
namespace.

The core complaint of RFC 6648 is that nonstandard values tend to
graduate to being standard values, and at that point need to be renamed.

Because "ca-" methods are CA-specific and unrelated to ACME, it is
essentially necessary that they be configured in relation to, and in
knowledge of, a specific CA and its issuance and validation practices.
In this regard it is not the same concept as an X- prefix, which defines
nonstandard parameters in the vague hope that such parameters will be
adopted by numerous implementations and entities across the net. This is
a permanent reservation for CA-specific meaning and there is no
expectation that one CA's "ca-foo" method is the same as another CA's
"ca-foo" method.

This reservation is necessary because a CA may engage in both ACME and
non-ACME issuance, so there is an unavoidable need to be able to
communicate about both. However, there are likely to be as many non-ACME
validation methods as there are CAs (more, actually), and seeking to
register all of these in the ACME Validation Methods registry would be
both impractical and out of scope for the ACME WG.

> 
> — Section 5.4 —
> 
>    CAs MUST satisfy this requirement by using URIs which include an
>    authority:
>    "https://a.example.com/account/1234"
> 
> First (this is not the DISCUSS part), readers who are not extremely familiar
> with how URIs are constructed — and given that “authority” is a normal English
> word with a meaning outside the URI world — might not really understand what
> you mean here.  A reference will help, and I suggest it” “…include an authority
> (see Section 3.2 of [RFC3986])”.
Done.

> 
> Second (this is the DISCUSS part), does this mean that all CAs MUST use URIs
> that include an authority?  Or does it only apply to those with the sort of
> situation you describe in this section?  If the latter, it seems odd that
> you’re prescribing, at MUST level, a particular solution, where there are
> certainly others (such as ensuring that the account numbers are unique in the
> first place).

  Thus, CAs MUST ensure that the URIs they recognise as pertaining to a specific
  account of that CA are unique within the scope of all domain names which they
  recognise as identifying that CA for the purpose of CAA record validation.

  CAs MUST satisfy this requirement by using URIs which include an authority (see
  Section 3.2 of {{RFC3986}}):

I agree that the second MUST should be changed to SHOULD here.

> 
> — Section 6 —
> I have no idea what you’re trying to say here.  This is a Proposed Standard,
> right?  It defines two new parameters.  Are you now trying to say that we have
> not really defined anything?  I don’t understand.
The CAA specification allows parameters to be attached to CAA
properties, but this is a CA-specific namespace. Per CAA, there is no
IANA registry for CAA parameters, and a CA is not required to give the
meaning given in this I-D to "accounturi" or "validationmethods"
parameters, unless it chooses to implement this RFC. See "Restrictions
Ineffective without CA Recognition".

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (General: I hope the RFC Editor will be changing most “which” in this document
> to “that”, according to the Chicago Manual of Style, but I’ll let the RFC
> Editor address those.)
> 
> (Also general: For a very short document, this was quite a difficult read. 
> There are quite a few very long, heavy, hard-to-parse sentences, with lots of
> things run together.  While the sentences are grammatically correct, they’re
> harder on the reader than they ought to be.  Picking one of many as an example:
> 
>    Because CAA records are located during validation by walking up the
>    DNS hierarchy until one or more records are found, the use of the
>    "accounturi" and "validationmethods" parameters, or any CAA policy,
>    is not an effective way to restrict or control issuance for
>    subdomains of a domain, where control over those subdomains is
>    delegated to another party (such as via DNS delegation or by
>    providing limited access to manage subdomain DNS records).
> 
> That’s one sentence.  The document in general would benefit from breaking up
> those sorts of sentences to make it easier to get the sense of what it’s trying
> to say.  For example, the above might go something like this:
> 
>    CAA records are located during validation by walking up the
>    DNS hierarchy until one or more records are found. Sometimes,
>    control over subdomains of a domain is delegated to another
>    party — via DNS delegation, or by providing limited access to
>    manage subdomain DNS records.  In those cases CAA policy,
>    including the use of the "accounturi" and "validationmethods"
>    parameters, is not an effective way to restrict or control
>    issuance for subdomains.
> )

Changed to

  CAA records are located during validation by walking up the DNS
  hierarchy until one or more records are found. CAA records are
  therefore not an effective way of restricting or controlling issuance
  for subdomains of a domain, where control over those subdomains is
  delegated to another party (such as via DNS delegation or by providing
  limited access to manage subdomain DNS records).


> — Section 3 —
> 
>    "CA account" means an object maintained by a specific CA representing
>    a specific entity, or group of related entities, which may request
>    the issuance of certificates.
> 
> I’m not clear on what the “which” clause goes with:
> 
> 1. Do you mean that the “specific CA” may request the issuance?
> 2. Do you mean that the entity or group of entities may request it?
> 3. Do you mean that the object may be used to request the issuance?
> 
> Some of this confusion might come from the that/which issue, but I think it’s
> really the structure of the sentence.  I suggest that you re-word the sentence
> to make it clearer.  Maybe (assuming (2) above is correct):
> 
> NEW
>    A “CA account” is an object maintained by a specific CA, representing
>    a specific entity or group of entities.  Those entities may request the
>    issuance of certificates from that CA.
> END
The third meaning was intended. Changed to:

  "CA account" means an object, maintained by a specific CA and which may request
  the issuance of certificates, which represents a specific entity or group of
  related entities.

> 
>    A property with multiple "accounturi" parameters is
>    unsatisfiable.
> 
> OK, but why not say, then, that there MUST NOT be multiple “accounturi”
> parameters in a given property?
This specifies how properties are to be processed, not generated. Even
if a normative prohibition were to be added here, this sentence would
remain necessary.

> 
> — Section 3.2 —
> 
>    The use of specific kinds of URI may be specified in future RFCs, and
>    CAs not implementing ACME MAY assign and recognise their own URIs
>    arbitrarily.
> 
> Isn’t this true of CAs that do implement ACME also?  The “MAY” in Section 3.1
> implies that, surely.
The MAY in section 3.1 confers an option for identifying an ACME account
object.

The MAY in section 3.2 confers an option for identifying entities which
may or may not be ACME account objects.

> -- Section 5.3 —
> 
>    A CA which is unable to ensure consistent processing of the
>    "accounturi" or "validationmethods" parameters for a given CA domain
>    name as specifiable in CAA "issue" or "issuewild" properties MUST NOT
>    implement support for these parameters.  Failure to do so will result
>    in an implementation of these parameters which does not provide
>    effective security.
> 
> “Failure to do so” seems odd after “MUST NOT”.  It also makes it sound as
> though failure to comply with a MUST NOT is an option.  I suggest, “Otherwise,
> the CA would have an implementation…”
s/will/would/

> — Section 5.8 —
> 
>    Because they express a restrictive security policy, misconfiguration
>    of the "accounturi" or "validationmethods" parameters may result in
>    legitimate issuance requests being refused.
> 
> As written, “they” goes with “misconfiguration”, which is clearly not what you
> meant (I think you mean it to refer to “the … parameters”).
> 
> NEW
>    Because the "accounturi" or "validationmethods" parameters express
>    a restrictive security policy, misconfiguration of them may result
>    in legitimate issuance requests being refused.
> END

Changed to:
  Because the "accounturi" and "validationmethods" parameters express restrictive
  security policies, misconfiguration of said parameters may result in legitimate
  issuance requests being refused.