Thank you for the review, Francis. Once this version is published, change control and copyright is transferred to the IETF. The next version of this document will work to improve known issues.
I will make the change from public/private to private/public as noted, that makes sense. I would imagine it was only written that way as the key pairs are typically referred to in that order as opposed to the original author thinking through the sentence as you had done. I have a few other edits to include and will have this ready before the end of the week. Thank you, Kathleen -----Original Message----- From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Sent: Monday, January 13, 2014 8:56 AM To: gen-art@ietf.org Cc: draft-moriarty-pkcs12v1-1....@tools.ietf.org Subject: review of draft-moriarty-pkcs12v1-1-03.txt 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
