Skip to main content

Last Call Review of draft-turner-encryptedkeypackagecontenttype-
review-turner-encryptedkeypackagecontenttype-secdir-lc-lonvick-2010-04-15-00

Request Review of draft-turner-encryptedkeypackagecontenttype
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-04-16
Requested 2010-04-01
Authors Russ Housley , Sean Turner
I-D last updated 2010-04-15
Completed reviews Secdir Last Call review of -?? by Chris M. Lonvick
Assignment Reviewer Chris M. Lonvick
State Completed
Request Last Call review on draft-turner-encryptedkeypackagecontenttype by Security Area Directorate Assigned
Completed 2010-04-15
review-turner-encryptedkeypackagecontenttype-secdir-lc-lonvick-2010-04-15-00
Hi,



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.






Overall, I do not see any particular security concerns.  The document 


appears to be in good shape and ready for publication.






Not finding anything of particular importance to note about the concepts, 


I started looking at the nits.




Section 1 - The following is an awkward sentence:
   The Cryptographic Message Syntax (CMS) specification [RFC5652]
   defines means to...
Perhaps:
   The Cryptographic Message Syntax (CMS) specification [RFC5652]
   defines mechanisms to...
(Means means so many different things.)

Section 1 also says:
   This document also defines an unprotected attribute for use with one
   of the key management options supported by the encrypted key package
   content type.


Not being a crypto geek, I'm left guessing which this is.  It's not 


specifically called out in the document, and the implications of using it 


are not called out in the Security Considerations section.






Why are you asking the RFC Editor to remove the IANA Considerstions 


section?  Maybe I missed it, but I havn't seen any discussion about not 


having an IANA Considerations section if you don't have anything for the 


IANA to do.  I can see Informational and Experimental RFCs not having 


anything, but IMHO a Standards Track document should have an IANA 


Considerations ection even if it is just to say that nothing needs to be 


done.




Regards,
Chris