[secdir] Secdir review of draft-ietf-sidr-repos-struct-07

Joe Salowey <jsalowey@cisco.com> Thu, 19 May 2011 04:42 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87A0E06C8; Wed, 18 May 2011 21:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxyrXZ4F2WqB; Wed, 18 May 2011 21:42:35 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD2E06C3; Wed, 18 May 2011 21:42:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1448; q=dns/txt; s=iport; t=1305780155; x=1306989755; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=0eB0d7HsWkwGzNFCCTJY9NhZxxEYlwz226F4XEwbFNw=; b=gdkQtoUMDJQ+hmKQ/MFbuB4UEIDWhiYhfZDFp33cO7DJGq9tYFAnrbqc Zpkk1vQO9lAuZOefPBbM5b4L8Ed1NNfA6nXMlhnTj43cz21BS4owi4DFa G21vIkFhWWuwsVIUfhoYPEqSnBxvyM1uMKL82ccQNLZbDN7/+82+Grr30 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMCe1E2rRDoJ/2dsb2JhbACmHHeqDp1+hhkEhlCJQYQvimY
X-IronPort-AV: E=Sophos;i="4.65,235,1304294400"; d="scan'208";a="450511012"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 19 May 2011 04:42:35 +0000
Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4J4gXsP013018; Thu, 19 May 2011 04:42:34 GMT
From: Joe Salowey <jsalowey@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 May 2011 21:42:44 -0700
Message-Id: <427D4174-E04F-4C2B-BBFA-D445A4682601@cisco.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-sidr-repos-struct.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] Secdir review of draft-ietf-sidr-repos-struct-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 19 May 2011 04:42:43 -0000

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.

In general the draft looks useful, but I think there are a few things that need to be addressed before publication.  

1.   The document asks for a registration for the extension  .roa for Route Origination Authorization, but the discussion of this type is absent from the rest of the document.  
2.   In section 2.2 under certificates it would probably be good to specify the encoding of the certificate since there are different encodings in use (DER, Base64,etc).  
3.   The document is not very specific on what signed objects may consist of.   The security considerations section points out that the repository itself does not provide integrity protection.  The security considerations section should probably also mention that confidentiality is also not provided by the repository or by the signed objects (unless there is some mechanism used to ensure the confidentiality of the data which would need to be specified)  and that data that requires controlled access should not be included in signed objects in the repository.

Thanks,

Joe