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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-caa-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-caa/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we need to have some privacy considerations text about how this
mechanism exposes ACME account URLs, which are otherwise intended to be
unguessable, in the public DNS view.  While ACME is generally intended
to remain secure in the face of such information disclosure, it does
have potential to enable some forms of correlation attacks, and could
lead to DoS attempts specific to a given account or accounts.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Barry's Discusses (noting in particular that the "ca-" prefix is
not reserved for local use by RFC 8555).

Did we consider supplying ABNF descriptions of the parameter values?  In
particular, this would unambiguously specify whether optional whitespace
is admitted in the comma-separated list used by "validationmethods".

The shepherd writeup notes that there used to be hyphens in
"account-uri" and "accepted-challenges".  It seems that rfc6844bis has
expanded the grammar to allow such hyphens; do we want to revisit their
removal from this document?  Noting that rfc6844bis is also slated for
approval on this week's telechat, it may be worth updating the
references as well, regardless of the decision on hyphens.

Section 3

   The presence of this parameter constrains the property to which it is
   attached.  Where a CAA property has an "accounturi" parameter, a CA
   MUST only consider that property to authorize issuance in the context
   of a given certificate issuance request if the CA recognises the URI
   specified as identifying the account making that request.

nit: perhaps "URI specified in the value portion of the accounturi
parameter" for maximum clarity?

Section 4

   The presence of this parameter constrains the property to which it is
   attached.  A CA MUST only consider a property with the
   "validationmethods" parameter to authorize issuance where the name of
   the challenge method being used is one of the names listed in the
   comma-separated list.

nit: I'm not sure that we've really defined "challenge method" in the
sense it's used here.  (We do define it in the sense of "names listed in
the comma-separated list", but it seems like this usage is trying to
refer to the actual actions taken by the CA to authorize the issuance
request.

Section 5.2

I think this section may be predicated on an understanding of CAA
"issue"/"issuewild" parameters that does not match my own.  (Note that
this includes the possibility that my understanding is incorrect.)
Specifically, my reading of draft-ietf-lamps-rfc6844bis-06 Section 4.2
indicates that a given paramter is only defined for usage in a CAA
"issue" record at the explicit specification of the Issuer, and that the
Issuer alone determines their semantics.  So when this text says that
parameters are not an effective control absent out-of-band establishment
of support, that's either a non sequitur or a tautology -- nobody has
any business adding parameters to an Issuer's CAA entry unless that
Issuer has told them to do so, full stop.
Granted, we are complicating things by providing a preestablished
specification for a set of parameters that an Issuer may choose to
incorporate by reference, but I don't see that as changing the fact that
the parameters are still specific to the given Issuer (and their CAA
entry).
Similarly, "MUST NOT assume" and "SHOULD also document" are repeating
requirements from rfc6844bis, when starting from my frame of reference
(and thus would not need to use the normative capitalization).

Section 5.7

This seems perhaps more appropriate in the core CAA specification than
in this document.  Conveniently, rfc6844bis is open and in IESG
evaluation...