Last Call Review of draft-turner-asymmetrickeyformat-algs-
review-turner-asymmetrickeyformat-algs-secdir-lc-kelly-2010-04-25-00

Request Review of draft-turner-asymmetrickeyformat-algs
Requested rev. no specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-04-20
Requested 2010-03-24
Other Reviews
Review State Completed
Reviewer Scott Kelly
Review review-turner-asymmetrickeyformat-algs-secdir-lc-kelly-2010-04-25
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg01615.html
Draft last updated 2010-04-25
Review completed: 2010-04-25

Review
review-turner-asymmetrickeyformat-algs-secdir-lc-kelly-2010-04-25

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.

This document describes conventions for crypto algorithms for use with a companion document (

http://tools.ietf.org/html/draft-turner-asymmetrickeyformat-03

) which is intended to replace rfc5208. 

I couldn't give this review the amount of time I would have liked to, but I hope my comments are useful nonetheless.

In section 2, it says that the de facto standard for PrivateKeyInfo encryption is Password Based Encryption using either PKCS5 or PKCS12, and that the major difference between these is the password encoding. I was surprised that no mention was made of the more robust crypto algorithms supported by PKCS12, which seems like an important consideration for this application.

Also, I was confused as to whether the draft is mixing the documentation of current practices with some recommendations, or whether it intends to specify a required usage profile. If the latter, it seems reasonable to ask why deprecated algorithms are included. If the former, maybe the document could do a better job of making this intention clear, and of demarcating which is which.

The only other nit I had was that no mention is made of the implications of wrapping various asymmetric key sizes with potentially weaker symmetric keys/algorithms, but the security considerations section references a mighty list of related RFCs, at least one of which discusses this (RFC5649), so maybe that is good enough.

--Scott