Re: [secdir] secdir review of draft-turner-asymmetrickeyformat-algs-01

Sean Turner <turners@ieca.com> Thu, 22 April 2010 13:57 UTC

Message-ID: <4BD0559D.2030609@ieca.com>
Date: Thu, 22 Apr 2010 09:56:45 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: scott@hyperthought.com
References: <1271786580.275918665@192.168.2.231>
In-Reply-To: <1271786580.275918665@192.168.2.231>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-turner-asymmetrickeyformat-algs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-turner-asymmetrickeyformat-algs-01
Precedence: list

scott@hyperthought.com wrote:
> 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.

I revisited section 2 and agree.  It's not clear what the actual must
algorithms.  It's waxing poetic about PBES1.  I double checked RFC 2898
and it recommends PBES2 be used in new applications, which I think this
is one.  Further someone notes that the sip-certs ID
(http://tools.ietf.org/html/draft-ietf-sip-certs-12) wants to use a
PBES2 algorithm.  I'll work on the wording to make it clear what the
requirement is (follow what sip-certs wanted), delete the tutorial about
PBES1, and follow the recommendation from RFC 2898.

Tim's worked up an RFC editor's note to incorporate this change.

> 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.

That is exactly why I included the reference to RFC 5649.

> --Scott
> 
> 
>

[secdir] secdir review of draft-turner-asymmetric… scott
Re: [secdir] secdir review of draft-turner-asymme… Sean Turner