Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01

Sean Turner <turners@ieca.com> Mon, 12 April 2010 17:22 UTC

Return-Path: <turners@ieca.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52C93A6AB6 for <secdir@core3.amsl.com>; Mon, 12 Apr 2010 10:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level:
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5ZSw19chxUN for <secdir@core3.amsl.com>; Mon, 12 Apr 2010 10:22:14 -0700 (PDT)
Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id D5E7C3A6A99 for <secdir@ietf.org>; Mon, 12 Apr 2010 10:20:47 -0700 (PDT)
Received: (qmail 32525 invoked from network); 12 Apr 2010 17:20:40 -0000
Received: from thunderfish.local (turners@96.231.117.128 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 10:20:39 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: CWZzMC4VM1k3EV_CjP0S4miFCOb_f3qMf6MKVwzqBSeoS25_Q0sac51IuodChK3lALsmj5vIHIs9MBcV8pBQtnSqXrnBaEf9kwWuQuuBLiyxA6DOQFJbbTPJPRdA8b.BZ_KcamU68NqjGkHfJzzRv8zE_6z.tbR_DX3lNyPA8kaIPfL_euA34EB95i7B_J1ap397TuPpK0VMq8UULevQScseI1Atn8KrmBOhWyUJwNl44Z6ZvHN3PIijjiSbpoezzXhk4jf7j.qCJOPJxwRfMQ9IZwa6r2MZGYLCV8y8QXQGb1IxQ_AC6dES2oDSBUbfZBSWx258b4Io9HURrg_EjqXfu_qn1RVd1N92Zm9SDorByf.lQTgn1DQuh6cZp7tofP6SP9WfpB0MIUiriVV4CSazzpdlI0b5aMu1WxtqTY0RnM7na1LP
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BC35666.60300@ieca.com>
Date: Mon, 12 Apr 2010 13:20:38 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Chris Lonvick <clonvick@cisco.com>
References: <Pine.GSO.4.63.1004101623250.26156@sjc-cde-011.cisco.com>
In-Reply-To: <Pine.GSO.4.63.1004101623250.26156@sjc-cde-011.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: cwallace@cygnacom.com, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-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: Mon, 12 Apr 2010 17:22:17 -0000

Chris,

Thanks for your review.  Responses inline.

spt

Chris Lonvick wrote:
> Hi,
> 
> 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.
> 
> Overall, I do not see any particular security concerns.  The document 
> appears to be in good shape and ready for publication.
> 
> Not finding anything of particular importance to note about the 
> concepts, I started looking at the nits.
> 
> Section 1 - The following is an awkward sentence:
>    The Cryptographic Message Syntax (CMS) specification [RFC5652]
>    defines means to...
> Perhaps:
>    The Cryptographic Message Syntax (CMS) specification [RFC5652]
>    defines mechanisms to...
> (Means means so many different things.)

I'll r/means/mechanisms

> Section 1 also says:
>    This document also defines an unprotected attribute for use with one
>    of the key management options supported by the encrypted key package
>    content type.
> Not being a crypto geek, I'm left guessing which this is.  It's not 
> specifically called out in the document, and the implications of using 
> it are not called out in the Security Considerations section.

How about I replace that sentence with:

This document also defines an unprotected attribute, Content Decryption
Key Identifier, for use with EncryptedData.

WRT the use of the unprotected attribute: The attribute is used to
identify a key that was previously distributed.  This kind of mechanism 
is used in EcnryptedData as well as in certificates (e.g., subject key 
and authority key identifiers).  I looked for some wording from other 
RFCs that used this kind of mechanism that I could use in a security 
consideration.  But, I couldn't find any.  I'm thinking there's isn't 
any text because as long as people don't do something utterly stupid 
like use the actual key as the identifier there is no security 
consideration.

> Why are you asking the RFC Editor to remove the IANA Considerstions 
> section?  Maybe I missed it, but I havn't seen any discussion about not 
> having an IANA Considerations section if you don't have anything for the 
> IANA to do.  I can see Informational and Experimental RFCs not having 
> anything, but IMHO a Standards Track document should have an IANA 
> Considerations ection even if it is just to say that nothing needs to be 
> done.

I'll delete the second sentence.