My other thought here is that we know complexity is bad ;) The specific concern about that command is specific to openssl ad though widely deployed doesn’t really belong in this draft.
spt On Jan 21, 2014, at 16:38, Moriarty, Kathleen <kathleen.moria...@emc.com> wrote: > Hi Jari, > > Since this document is meant to transfer change control to the IETF, RSA > would prefer to leave the document in-tact to match their published version > as much as possible. There is IETF interest in starting a draft as soon as > this is published to correct the well-known issues. We would prefer to take > that approach and I am working to make sure we have at least one resource to > edit the new document who has the background to make the changes and there > may be others. > > Thank you, > Kathleen > > -----Original Message----- > From: Jari Arkko [mailto:jari.ar...@piuha.net] > Sent: Tuesday, January 21, 2014 10:31 AM > To: Moriarty, Kathleen; Sean P. Turner > Cc: francis.dup...@fdupont.fr; gen-art@ietf.org; > draft-moriarty-pkcs12v1-1....@tools.ietf.org > Subject: Re: [Gen-art] review of draft-moriarty-pkcs12v1-1-03.txt > > Thanks for your review, Francis, and for your edits, Kathleen. > > Do you Kathleen or Sean think that Francis' comment on strengthening the > security considerations would be something that you should address? > > jari > > On Jan 13, 2014, at 6:02 PM, "Moriarty, Kathleen" <kathleen.moria...@emc.com> > wrote: > >> Hi Francis, >> >> I went to update your comments in my draft version and in thinking about it >> more, I agree with the current text on the public/private order. As I read >> it, the referenced keys are discussed for the keys that validate and I >> assume you read it as the creation of a signature or to encrypt. I'm going >> to leave that as-is. >> >> Thanks, >> Kathleen >> >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Monday, January 13, 2014 9:42 AM >> To: 'francis.dup...@fdupont.fr'; gen-art@ietf.org >> Cc: draft-moriarty-pkcs12v1-1....@tools.ietf.org >> Subject: RE: review of draft-moriarty-pkcs12v1-1-03.txt >> >> 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
