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

Chris Lonvick <> Mon, 12 April 2010 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C48B3A6A48; Mon, 12 Apr 2010 10:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.289
X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ItRJk+WPB9w3; Mon, 12 Apr 2010 10:42:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3C6383A6990; Mon, 12 Apr 2010 10:42:48 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAv4wkurRN+J/2dsb2JhbACbOnGjT5h4gleCNQSDJQ
X-IronPort-AV: E=Sophos;i="4.52,191,1270425600"; d="scan'208";a="181822603"
Received: from ([]) by with ESMTP; 12 Apr 2010 17:42:43 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id o3CHgh8p012268; Mon, 12 Apr 2010 17:42:43 GMT
Date: Mon, 12 Apr 2010 10:42:42 -0700
From: Chris Lonvick <>
To: Sean Turner <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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:42:50 -0000

Hi Sean,

All looks good.  One comment in-line.

On Mon, 12 Apr 2010, Sean Turner wrote:
> 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.

You're on the same track as I was thinking, but I was thinking of 
something VERY much more generic.  From RFCs 2797 and 5273,

    Implementers of this protocol are strongly encouraged to consider
    generally accepted principles of secure key management when
    integrating this capability within an overall security architecture.

(Which is a nice way of saying, "Don't be utterly stoopid!" :-)