DNS Certification Authority Authorization (CAA) Resource Record
draft-ietf-pkix-caa-15

Note: This ballot was opened for revision 10 and is now closed.

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

Comment (2012-07-18 for -11)
No email
send info
I agree with the points raised by Barry and Russ.  

Building on one of Stephen's comments: are the requirements
for archiving DNS transactions regarding CAA based on
actual audit requirements or are they speculative?  Why would
this document include those specific requirements instead of
a more general statement about "meeting audit requirements"
from whatever audit process is employed?

Minor editorial suggestion: in section 3, I think you should cite
more than just RFC 1035 as references for CNAME and DNAME
processing.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-07-19 for -11)
No email
send info
I have no objection to the publication of this document and only a 
couple of (well, four) trivial obeservations.

---

Would be nice to add just a couple of words to what is otherwise a good
Abstract to say what this document actually does.

---

The RFC editor will probably want to work with you to move the 
Introduction to be the first section in the document.

---

I don't think Section 6.3 should be a subsection of Section 6!

---

Are you sure that you dn't want an IANA registry for the Flags field
defined in Section 4.1?

(Stephen Farrell) No Objection

Comment (2012-07-16 for -10)
No email
send info
- I agree with Russ' discuss - the "tree-walking vs. not"
disussion needs to be worked through before this is ready.  Is
the wildcard cert part of the gen-art review part of Russ'
discuss? I think the authors also said they'd fix that.

- Overall comment: I think this is a fine function to offer, but
this draft is IMO over complicated and could be a lot simpler.
Nonetheless, I think it can be used as-is, so going forward is
better than holding it up, modulo Russ' discuss.

- A suggested addition for the abstract: "CAA Resource Records
are intended for consumption by CAs and not by other entities
involved in public key infrastrucures." I think it'd help the
reader to get that from the abstract.  I don't care how that's
worded but the above might work.

- Section 1.2: (This was nearly a discuss but I expect it'll be
sorted as part of Russ' discuss.) The definition of Public
Delegation Point is imprecise.  I realise any precise definition
is controversial but you include it in the tree-walking
algorithm here and different interpretations could lead to
unexpected non-issuance without any attack. I think that at
least needs to be noted.

- Section 2: While you do define the term "Certificate
Evaluator" properly, I don't personally like the term, as I
think its too easily confused with RP. However, that's just me,
so this isn't discuss-worthy, but I nonetheless think it'd be
worth the following change in the last para before 2.1: s/CAA
Records MAY be used by Certificate Evaluators/CAA Records MAY be
used by Certificate Evaluators (who are, by definition, not
Relying Parties)/ 

- You probably should say that "1" means "set" for Issuer
Critical and "0" means unset.

- Using "MUST NOT" as part of an example seems wrong since 2119
language would be better avoided there.  I'd suggest s/The
following example informs CAs that certificates MUST NOT/The
following example informs CAs that certificates ought not/

- Be good to provide a reference so people can understand the
zone file syntax used in the examples.

- The first example in 2.1 refers to this being at the public
delegation point, but you've not said anything about that so
far, other than the definition. 

- Section 3, 1st para, might be better to s/the CA/ a compliant
CA/ in the last sentence of this para.

- Last para before 3.1 says "unless the certificate conforms"
but I didn't think you were defining conformance for
certificates, maybe s/certificate/Issuer/ here?

- DNSSEC can demonstrate non-existence of a domain.  If an
Issuer receives a request for foo.bar.example.com and DNSSEC
shows there's no such domain then oughtn't that result in
non-issuance for a compliant CA? Worth a mention here? (I'd say
maybe.)

- I personally doubt that use of DNSSEC gives an issuer a
non-repudiable proof. I'd delete the phrase.

- Is the ABNF for 'parameter' correct? Looks wrong to me. 

- I think this bit of 5.2 is badly stated: " A CA MUST mitigate
this risk by employing DNSSEC verification whenever possible and
rejecting certificate requests in any case where it is not
possible to verify the non-existence or contents of a relevant
CAA record." I think you want to say that "a compliant CA MUST
implement DNSSEC validation" but I'm not sure you can say
anything about rejecting requests really.

- 6.1, 1st para is missing a ")" before "deleted."

- 6.2, I don't get why "auth," "path" and "policy" are reserved
without any further mention.

- 6.2, the public CA business can be competitive. If you could
specify more about when the expert is supposed to say yes or no,
that'd be good, especially if (as is probably likely) the expert
is liable to end up being employed by some CA operator.

(Brian Haberman) (was Discuss) No Objection

Comment (2012-08-28 for -13)
No email
send info
Thanks for addressing my DISCUSS points and comments.

There are a few editorial mistakes (concatenated words) in the RRSet definition that can be fixed with an RFC Editor's note.

(Russ Housley) (was Discuss) No Objection

Comment (2012-11-15)
No email
send info
  One typo in Section 4:
  "X is not a top level domain then R(X) = R(P(X), otherwise"

Barry Leiba (was Discuss) No Objection

Comment (2012-10-20)
No email
send info
[Updated for -15]
One non-blocking comment still remains in this version:
You have to move the Acknowledgments up a level in the sections: it's now Section 7.4, and I think you want it to be a top-level section (8), and not part of the IANA Considerations.  :-)

(Pete Resnick) No Objection

Comment (2012-08-28 for -13)
No email
send info
(Damn. Updating my comment as *I* screwed up the ABNF I gave you the first time. Which is why I'd like to see an external reference to it. But let's try again.)

   label = 1* (ALPHA / DIGIT / "-" )

If you're trying to conform to host syntax, I wish you would reference it from another RFC. In any event, the above is not correct. Try:

   label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

(Robert Sparks) No Objection

Comment (2012-07-18 for -11)
No email
send info
Should automata processing a record with the iodef property do any sort of validation of the URI it finds there before using it? (The examples point into the same domain, but that's not a restriction, right?). 

The draft says "Web Service" a few times, sometimes capitalized that way, when pointing to RFC6546. This could lead to confusion with WSDL/SOAP which RFC6546 does not use.

(Martin Stiemerling) No Objection