[secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 (fwd)
Chris Lonvick <clonvick@cisco.com> Sun, 11 April 2010 01:34 UTC
Return-Path: <clonvick@cisco.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 1BEB93A683F; Sat, 10 Apr 2010 18:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 gxZTzyAfy2WK; Sat, 10 Apr 2010 18:34:50 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 11EB63A67D7; Sat, 10 Apr 2010 18:34:50 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As8FAGPEwEurR7Hu/2dsb2JhbACPcwGLVHGefpg/hQwEgyU
X-IronPort-AV: E=Sophos;i="4.52,183,1270425600"; d="scan'208";a="512736014"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2010 01:34:45 +0000
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3B1YjVR013949; Sun, 11 Apr 2010 01:34:45 GMT
Date: Sat, 10 Apr 2010 18:34:45 -0700
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, cwallace@cygnacom.com, turners@ieca.com, housley@vigilsec.com, cwallace@cygnacom.com
Message-ID: <Pine.GSO.4.63.1004101827580.26156@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 (fwd)
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: Sun, 11 Apr 2010 01:34:53 -0000
So, this didn't make it to draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org so I'm sending it again to all of the proper recipients. Please respond to this message. Apologies. Regards, Chris ---------- Forwarded message ---------- Date: Sat, 10 Apr 2010 18:24:10 -0700 (PDT) From: Chris Lonvick <clonvick@cisco.com> To: iesg@ietf.org, secdir@ietf.org, draft-turner-encryptedkeypackagecontenttype-01.all@tools.ietf.org Cc: cwallace@cygnacom.com Subject: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01 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.) 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. 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. Regards, Chris _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
- [secdir] SECDIR review of draft-turner-encryptedk… Chris Lonvick
- [secdir] SECDIR review of draft-turner-encryptedk… Chris Lonvick
- Re: [secdir] SECDIR review of draft-turner-encryp… Sean Turner
- Re: [secdir] SECDIR review of draft-turner-encryp… Chris Lonvick
- Re: [secdir] SECDIR review of draft-turner-encryp… Sean Turner