Sorry, I somehow missed this one.
> ----------------------------------------------------------------------
> 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.
I agree. How's this?
Revelation of Account URIs
--------------------------
Because CAA records are publically accessible, use of the
"accounturi" parameter enables third parties to observe the
authorized account URIs for a domain. This may allow third parties
to identify a correlation between domains if those domains use the
same account URIs.
CAs MUST select and process account URIs under the assumption that
untrusted third parties may learn of them.
> ----------------------------------------------------------------------
> 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".
I don't believe this was considered, but it seems like an improvement.
How's this?
The value of the "validationmethods" parameter MUST comply with the
following ABNF {{RFC5234}}:
value = [*(label ",") label]
label = 1*(ALPHA / DIGIT / "-")
> 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.
I agree we should change this to rfc6844bis, done.
I'm neutral on reintroducing hyphens. I don't think it's worth doing,
since there is now an implementation out there:
<https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125>
> 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?
Changed to:
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 in the value portion of that parameter as
identifying the account making that request.
>
> 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.
s/challenge/validation/ -- consistency.
s/name/label/ -- consistency with the ACME Validation Methods IANA
registry.
Revised this a little to make things more watertight.
The text of this section is now:
A CAA parameter "validationmethods" is also defined for the "issue"
and "issuewild" properties. The value of this parameter, if
specified, MUST be a comma-separated string of validation method
labels.
A validation method label identifies a validation method. A
validation method is a particular way in which a CA can validate
control over a domain.
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
validation method being used is identified by one of the validation
method labels listed in the comma-separated list.
Each validation method label MUST be either the label of a method
defined in the ACME Validation Methods IANA registry, or a
CA-specific non-ACME validation method label as defined below.
Where a CA supports both the "validationmethods" parameter and one
or more non-ACME validation methods, it MUST assign labels to those
methods. If appropriate non-ACME labels are not present in the ACME
Validation Methods IANA registry, the CA MUST use labels beginning
with the string "ca-", which are defined to have CA-specific
meaning.
The value of the "validationmethods" parameter MUST comply with the
following ABNF {{RFC5234}}:
value = [*(label ",") label]
label = 1*(ALPHA / DIGIT / "-")
>
> 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).
I agree with your interpretation, and this interpretation is in fact
explicitly stated in the IANA considerations section — but I don't think
how this is worded currently is a problem.
I mean, it's the security considerations section — it's not just there
to add more normative requirements, but to point out ways you could
shoot yourself in the foot. We need to spell it out for people.
> 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...
I've changed to rfc6844bis, but I don't think it's worth removing this.
It was added on request, and applying more security properties to CAA is
a good opportunity to remind people of this subtlety.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
