Skip to main content

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 revision No specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-04-20
Requested 2010-03-24
Authors Sean Turner
I-D last updated 2010-04-25
Completed reviews Secdir Last Call review of -?? by Scott G. Kelly
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-turner-asymmetrickeyformat-algs by Security Area Directorate Assigned
Completed 2010-04-25
review-turner-asymmetrickeyformat-algs-secdir-lc-kelly-2010-04-25-00
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