Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4464
IMPORTANT
S 4.
> Where a CA supports both the "validationmethods" parameter and one or
> more non-ACME challenge methods, it MUST assign identifiers to those
> methods. These identifiers MUST be chosen to minimise the likelihood
> of conflict with any ACME challenge method name; it is RECOMMENDED
> that, at the very least, CAs avoid assigning identifiers ending in a
> hyphen and two digits ("-00").
This doesn't seem sufficient to prevent conflicts. You need to either
(a) ensure they don't conflict or (b) remove this feature.
S 5.4.
> CAA record validation.
>
> It is RECOMMENDED that CAs satisfy this requirement by using URIs
> which include an authority:
>
> "https://a.example.com/account/1234";
What is the reason for ever not including URIs with an authority? This
just seems like a recipe for fail.
S 5.6.
> 1. Use the "accounturi" parameter to ensure that only accounts which
> it controls are authorized to obtain certificates, or
>
> 2. Exclusively use validation methods which rely solely on
> information obtained via DNSSEC, and use the "validationmethods"
> parameter to ensure that only such methods are used.
I don't think this is right unless *also* all CAs do DNSSEC
validation, because one CA might not do DNSSEC and *then* the CAA
record could be attacked.
S 5.7.
> parameter to ensure that only such methods are used.
>
> 5.7. Use without DNSSEC
>
> Where a domain does not secure its nameservers using DNSSEC, or one
> or more of the CAs it authorizes do not perform CAA validation
As above, it's not the CAs it authorizes, because only the CAA record
restricts that.
COMMENTS
> Abstract
>
> The CAA DNS record allows a domain to communicate issuance policy to
> CAs, but only allows a domain to define policy with CA-level
> granularity. However, the CAA specification also provides facilities
> for extension to admit more granular, CA-specific policy. This
extensions.
S 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 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.
This is very awkward writing. Can you rephrase in a positive way.
I.e.,
"The CA MUST only issue if..."
S 3.
> 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.
>
> If a certificate issuance request is made to a CA such that no
> account URI is available, because the request is made in the absence
IMPORTANT What does "available" mean in this context.
S 3.
>
> If a certificate issuance request is made to a CA such that no
> account URI is available, because the request is made in the absence
> of any account or the account has no URI assigned to it, a CA MUST
> NOT consider any property having an "accounturi" parameter as
> authorizing issuance.
Again, rephrase postiively
S 3.
> account URI is available, because the request is made in the absence
> of any account or the account has no URI assigned to it, a CA MUST
> NOT consider any property having an "accounturi" parameter as
> authorizing issuance.
>
> If a CA finds multiple CAA records pertaining to it (i.e., having
pertaining to what? the CA?
S 3.
> If a CA finds multiple CAA records pertaining to it (i.e., having
> property "issue" or "issuewild" as applicable and a domain that the
> CA recognises as its own) with different "accounturi" parameters, the
> CA MUST NOT consider the CAA record set to authorize issuance unless
> at least one of the specified account URIs identifies the account of
> the CA by which issuance is requested. A property without an
The account of the CA? CAs don't have accounts.
Does this say anything other than "at least one of the records must
match according to the conditions above"
S 3.
> CA MUST NOT consider the CAA record set to authorize issuance unless
> at least one of the specified account URIs identifies the account of
> the CA by which issuance is requested. A property without an
> "accounturi" parameter matches any account. A property with an
> invalid or unrecognised "accounturi" parameter is unsatisfiable. A
> property with multiple "accounturi" parameters is unsatisfiable.
So you have to ignore it?
S 3.
>
> The presence of an "accounturi" parameter does not replace or
> supercede the need to validate the domain name specified in an
> "issue" or "issuewild" record in the manner described in the CAA
> specification. CAs MUST still perform such validation. For example,
> a CAA property which specifies a domain name belonging to CA A and an
Please use the property names here.
S 3.1.
> An ACME [I-D.ietf-acme-acme] account object MAY be identified by
> setting the "accounturi" parameter to the URI of the ACME account
> object.
>
> Implementations of this specification which also implement ACME MUST
> recognise such URIs.
What does this mean as a practical matter? How would you implement
this specification without that?
S 3.2.
>
> The "accounturi" specification provides a general mechanism to
> identify entities which may request certificate issuance via URIs.
> 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.
It seems like you need to say something about the properties of said
URIs.
S 5.
> expressed. This allows the set of entities capable of successfully
> requesting issuance of certificates for a given domain to be
> restricted beyond that which would otherwise be possible, while still
> allowing issuance for specific accounts of a CA. This improves the
> security of issuance for domains which choose to employ it, when
> combined with a CA which implements this specification.
It seems like you also need to acknowledge that it increases the risk
of bricking yourself.
S 5.1.
>
> All of the security considerations of the CAA specification are
> inherited by this document. This specification merely enables a
> domain with an existing relationship with a CA to further constrain
> that CA in its issuance practices, where that CA implements this
> specification. In particular, it provides no additional security
This isn't correct. I could use validationmethods to restrict some CA
I've never spoken to.
S 5.5.
> a certificate issuance request. The CAA policy expressed by a domain
> may have changed in the meantime, creating the risk that a CA will
> issue certificates in a manner inconsistent with the presently
> published CAA policy.
>
> CAs SHOULD consider adopting practices to reduce the risk of such
https://tools.ietf.org/rfcmarkup?doc=6919#section-2
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
