Subject: Gen-ART review of draft-ietf-pkix-caa-10

From: Richard L. Barnes <[email-masked]>
Date: Fri, 6 Jul 2012 17:44:06 -0400

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"