Last Call Review of draft-ietf-pkix-rfc5280-clarifications-
review-ietf-pkix-rfc5280-clarifications-secdir-lc-melnikov-2012-09-13-00

Request Review of draft-ietf-pkix-rfc5280-clarifications
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-09-05
Requested 2012-08-30
Authors Peter Yee
Draft last updated 2012-09-13
Completed reviews Genart Last Call review of -?? by Vijay Gurbani
Genart Telechat review of -10 by Vijay Gurbani (diff)
Secdir Last Call review of -?? by Alexey Melnikov
Assignment Reviewer Alexey Melnikov 
State Completed
Review review-ietf-pkix-rfc5280-clarifications-secdir-lc-melnikov-2012-09-13
Review result Ready with Nits
Review completed: 2012-09-13

Review
review-ietf-pkix-rfc5280-clarifications-secdir-lc-melnikov-2012-09-13

I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


 These comments were written primarily for the benefit of the security 


area directors.  Document editors and WG chairs should treat these 


comments just like any other last call comments.




This document updates RFC 5280, the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile.  This document changes the set of acceptable encoding
methods for the explicitText field of the user notice policy
qualifier and clarifies the rules for converting internationalized
domain name labels to ASCII.  This document also provides some
clarifications on the use of self-signed certificates, trust anchors,
and some updated security considerations.



The Security Considerations section is basically a patch to the Security 


Considerations in RFC 5280. I think the new text is a good addition and 


the whole section is adequate.






I think the document is basically fine as far as SEC Area is concerned, 


but there are some related Apps issues:




In Section 3

   The explicitText string SHOULD NOT include any control
   characters (e.g., U+0000 to U+001F and U+007F to U+009F)



I think you should really properly define what you are talking about 


here. Are you talking about Unicode Control characters? If yes, please 


say so. Suggested replacement:




   The explicitText string SHOULD NOT include any Unicode Control
   characters (i.e., U+0000 to U+001F and U+007F to U+009F)



You should also consider whether you should reference RFC 5198 here 


(which restricts the set even further).





Section 5 only talks about IDNA 2003. What about IDNA 2008?