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

Sean Turner <> Mon, 12 April 2010 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C52C93A6AB6 for <>; Mon, 12 Apr 2010 10:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.273
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k5ZSw19chxUN for <>; Mon, 12 Apr 2010 10:22:14 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D5E7C3A6A99 for <>; 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@ with plain) by 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: <>
Date: Mon, 12 Apr 2010 13:20:38 -0400
From: Sean Turner <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Chris Lonvick <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Apr 2010 17:22:17 -0000


Thanks for your review.  Responses inline.


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 

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