DNS Certification Authority Authorization (CAA) Resource Record
draft-ietf-pkix-caa-15
Yes
(Sean Turner)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 10 and is now closed.
Sean Turner Former IESG member
Yes
Yes
(for -10)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-07-19 for -11)
Unknown
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?
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2012-10-20)
Unknown
[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. :-)
Benoît Claise Former IESG member
No Objection
No Objection
(for -11)
Unknown
Brian Haberman Former IESG member
(was Discuss)
No Objection
No Objection
(2012-08-28 for -13)
Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2012-08-28 for -13)
Unknown
(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))
Ralph Droms Former IESG member
No Objection
No Objection
(2012-07-18 for -11)
Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection
(2012-07-18 for -11)
Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection
(for -10)
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2012-11-15)
Unknown
One typo in Section 4: "X is not a top level domain then R(X) = R(P(X), otherwise"
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-07-16 for -10)
Unknown
- 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.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -11)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -11)
Unknown