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

scott@hyperthought.com Tue, 20 April 2010 18:03 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 393843A6AE0 for <secdir@core3.amsl.com>; Tue, 20 Apr 2010 11:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id B1YKDYyIZ3IN for <secdir@core3.amsl.com>; Tue, 20 Apr 2010 11:03:16 -0700 (PDT)
Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com []) by core3.amsl.com (Postfix) with ESMTP id 990033A6B36 for <secdir@ietf.org>; Tue, 20 Apr 2010 11:03:09 -0700 (PDT)
Received: from relay32.relay.iad.mlsrvr.com (localhost []) by relay32.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 5FFD11B4130; Tue, 20 Apr 2010 14:03:00 -0400 (EDT)
Received: from dynamic12.wm-web.iad.mlsrvr.com (dynamic12.wm-web.iad.mlsrvr.com []) by relay32.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 53BC11B4119; Tue, 20 Apr 2010 14:03:00 -0400 (EDT)
Received: from hyperthought.com (localhost []) by dynamic12.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 43B43216807E; Tue, 20 Apr 2010 14:03:00 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 20 Apr 2010 11:03:00 -0700 (PDT)
Date: Tue, 20 Apr 2010 11:03:00 -0700 (PDT)
From: scott@hyperthought.com
To: secdir@ietf.org, "iesg@ietf.org" <iesg@ietf.org>, draft-turner-asymmetrickeyformat-algs@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1271786580.275918665@>
X-Mailer: webmail7.0
Subject: [secdir] secdir review of draft-turner-asymmetrickeyformat-algs-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 18:03:16 -0000

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.