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

Sean Turner <turners@ieca.com> Mon, 12 April 2010 18:16 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 66C913A6ABD for <secdir@core3.amsl.com>; Mon, 12 Apr 2010 11:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.503, 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 JDHzKiPRCH94 for <secdir@core3.amsl.com>; Mon, 12 Apr 2010 11:16:42 -0700 (PDT)
Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 760B43A6A95 for <secdir@ietf.org>; Mon, 12 Apr 2010 11:16:42 -0700 (PDT)
Received: (qmail 3280 invoked from network); 12 Apr 2010 18:16:37 -0000
Received: from thunderfish.local (turners@96.231.117.128 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 12 Apr 2010 11:16:37 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: h0DSU1AVM1nBMXCBxHdNCjiwGkdZU18qK2bFN.2u6g88o_KezUwS_nrqoID4dkyXtkw_XK9ivUJPYVNYgFzDvxU_bATpwisf4cW1Y4sYbZ0xLylsJF7cb5XwPucbEYI9wcWazDeQojMrqUk6ArA7e8WrmGFZvgSDB3dhQasqGH50WSPM2vReMAR.pMElSof0py5.74TTKSK6nCAIv.t97rZcBjuSPznwPcjyvORWlMwVWyEqm9mCZ5hiLvl2e_bVp_JLZIFZlc6u6jtXQWD6KmaXyWvUH.1prxbX1A6iOKntjTACXzIAXZk2D6TxdroR_EUDiCoxQqxmf.yi9H8069SvQJGVlPNUy4OJQN.PCBtOF9nu5cYIwnCUl7qskPIdcdNKEsQPCrbYWercZGHrMGiPjo6aS8jMF5LTedza7pztvCtY734v
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BC36385.4060506@ieca.com>
Date: Mon, 12 Apr 2010 14:16:37 -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> <4BC35666.60300@ieca.com> <Pine.GSO.4.63.1004121035250.21469@sjc-cde-011.cisco.com>
In-Reply-To: <Pine.GSO.4.63.1004121035250.21469@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 18:16:43 -0000

Chris Lonvick wrote:
> 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!" :-)

I'll add this to the beginning of the considerations.

spt