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-moriarty-pkcs12v1-1-03.txt Reviewer: Francis Dupont Review Date: 20130104 IETF LC End Date: 20130110 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: (not really technical) PKCS#12 was subject to concerns from teh cryptography community, in particular from Peter Gutmann, based on: - its (too) high complexity (BTW IMHO it is a legitimate concern: complexity is not wellcome for a security device) - (related to the previous item) its possible misuse with private key, summarized by this famous warning in OpenSSL FAQ: "Occasionally someone suggests using a command such as: openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem DO NOT DO THIS! This command will give away your CAs private key and reduces its security to zero: allowing anyone to forge certificates in whatever name they choose." Unfortunately I can't see how we can address these concerns in the document. Perhaps with a stronger security considerations section? Nits/editorial comments: - TOC page 3 and F page 29: Acknowledgements -> Acknowledgments - 1 page 4 in: The most secure of the privacy and integrity modes require the source and destination platforms to have trusted public/private key pairs usable for digital signatures and encryption, respectively. respectively suggests the same order but the private key is used to sign and the public key to encrypt. I propose to swap keys, i.e., to use "private/public" key pairs. - 5.1 5 B page 16: i.e. -> i.e., - a full example should have been wellcome but IMHO it is far too late (and there are a lot of tools able to produce examples if needed :-). Regards francis.dup...@fdupont.fr _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
