Last Call Review of draft-moriarty-pkcs12v1-1-03
review-moriarty-pkcs12v1-1-03-genart-lc-dupont-2014-01-13-00

Request Review of draft-moriarty-pkcs12v1-1
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-01-10
Requested 2013-12-19
Draft last updated 2014-01-13
Completed reviews Genart Last Call review of -03 by Francis Dupont (diff)
Secdir Last Call review of -03 by Tina Tsou (diff)
Opsdir Last Call review of -03 by Bert Wijnen (diff)
Assignment Reviewer Francis Dupont
State Completed
Review review-moriarty-pkcs12v1-1-03-genart-lc-dupont-2014-01-13
Reviewed rev. 03 (document currently at 05)
Review result Ready
Review completed: 2014-01-13

Review
review-moriarty-pkcs12v1-1-03-genart-lc-dupont-2014-01-13

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.Dupont at fdupont.fr