I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-pkix-caa-10
Reviewer: Richard Barnes
Review Date: 06-July-2012
IETF LC End Date: 17-July-2012
IESG Telechat date: TBD
Summary: Nearly ready, but has a couple of major issues, and would benefit from
several clarifications
MAJOR:
General: Why not DANE?
It would help prevent confusion if this document could differentiate itself a
little more clearly from the DANE/TLSA specifications, especially since the RRs
have largely the same information content. It seems to me that there are a few
main reasons:
-- Authorization without exclusion. A domain holder might wish to authorize an
issuer to issue a certificate without invalidating any other certificates that
it has deployed.
-- Avoiding confusion: Having a different RRtype helps avoid these
authorizations being confused with DANE records by relying parties.
-- Incident reporting via the "iodef" type.
General: Tree walking
The tree walking algorithm specified in Section 3 seems like a really bad idea.
It saves the domain holder from having to deploy separate CAA records for
every subdomain, but has some tricky consequences. For example, because the
algorithm stops at the first CAA it finds, authorizations don't flow all the
way down the tree, just to the first CAA point, where they get replaced.
Likewise, if a domain holder doesn't agree with a parent domain's CAAs for his
domain, he's forced to deploy a null CAA defensively. Recommend removing the
tree walking / Extended Issuer Authorization Set.
General: Public Delegation Points
The concept of a Public Delegation Point seems unhelpful here, because it is
not well-defined.
Section 5.4. "... civil or criminal sanctions."
This is complete speculation, and highly contingent on legal matters that don't
belong in a technical specification. Suggested cutting this sentence off:
"It is thus unlikely that the attack would succeed."
MINOR:
Section 2. "CAA records MAY be used by Certificate Evaluators..."
This recommendation seems to contradict the sentence immediately preceding.
From the perspective of deciding whether a certificate is valid, a Certificate
Evaluator is the same as a Relying Party, so if RPs shouldn't use CAA, then
neither should Certificate Evaluators. (In general, the concept of a
Certificate Evaluator seems unhelpful and confusing; I would suggest just using
RP, if anything.)
Section 2.1. "express written authority"
Requiring "written" authority seems like it goes beyond the scope of a
technical specification.
Section 4.1.1. "ASCII letter and numbers in lower case."
Is there any particular reason that this has to be lower case? It might be
helpful to specify ABNF for it, e.g.:
tag = 1*(ALPHA/DIGIT)
Section 4.2. ABNF
This section should specify that IDNs MUST be represented in A-label form, with
a reference to RFC 5890.
Section 4.2. "This form of issue restriction..."
It would be helpful to explain this a little more fully. The major point of a
"null CAA" record seems to (1) stop the tree-climbing in the CA processing, and
(2) let CAs know that the domain owner understands CAA. If the tree-climbing
is removed (as suggested above), then is there really value in this beyond
having no CAA at all? (If not, then just make the "[domain]" above into
"domain".)
Section 5.1.
It would be helpful to have a pointer to DANE here.
EDITORIAL:
Section 2. "issueance" -> "issuance"
Section 2. "Certificate Policy Statement"
Seems like "Certification Practices Statement" would be more appropriate here.
Section 2.1. "a Web service"
It would be helpful to have a reference to RFC 6546 at this point, instead of
all the way at the end.
Section 3. Bullets
It would be helpful to describe the process for assembling the Extended Issuer
Authorization Set. Namely, something like the following:
1. Check for CAA records under the target domain name.
2. If they exist, then they are the EIAS.
3. Otherwise, remove a label from the name
4. If the name is now empty (the root), then the EIAS is empty
5. Otherwise go to step (1) with the new domain name
Section 5. "Observance of CAA records by issuers is subject to accountability
controls."
This is obviously not true as written;even after this RFC is published, not
every CA will have controls enforced on it. Suggested text:
"An issuer's practices with regard to CAA records can be made subject to
accountability controls."
In a similar vein, further down, "Since CA could have avoided ... is
increased." It doesn't seem useful to speculate on probability, but the
possibility is good to point out. Suggested text for this and the following
sentence:
"Since CAs can have avoided the mis-issue by performing CAA processing, if a
particular CA does not use CAA, it could cause other entities to regard it as
less trustworthy. For example, failure to observe CAA issue restrictions might
be used as an objective criterion for excluding issuers from embedded trust
anchor lists."
Section 5. "negligent CAs will likely increase" -> "negligent CAs may increase"