[secdir] secdir review of draft-ietf-sidr-signed-object

Tom Yu <tlyu@MIT.EDU> Thu, 24 March 2011 00:49 UTC

Return-Path: <tlyu@mit.edu>
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 0D1D93A6452; Wed, 23 Mar 2011 17:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.539
X-Spam-Level:
X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 zBUaxvn2fiZg; Wed, 23 Mar 2011 17:49:28 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 26B793A63CB; Wed, 23 Mar 2011 17:49:27 -0700 (PDT)
X-AuditID: 1209190c-b7b06ae000000ad9-70-4d8a9578fe10
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DC.FD.02777.8759A8D4; Wed, 23 Mar 2011 20:51:04 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p2O0p1NG008860; Wed, 23 Mar 2011 20:51:01 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p2O0owZM021564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Mar 2011 20:50:59 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p2O0ov2u011173; Wed, 23 Mar 2011 20:50:57 -0400 (EDT)
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-sidr-signed-object.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 23 Mar 2011 20:50:57 -0400
Message-ID: <ldv7hbp2vf2.fsf@cathode-dark-space.mit.edu>
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nrlsxtcvX4OQHA4vzF/ktZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoErY3/jM9aCsywVr7ZcZG9gfM3cxcjB ISFgIrFzUUoXIyeQKSZx4d56ti5GLg4hgX2MEmtmNjJDOBsYJR4sO84KUiUkcIVJoqmVFyLR xSjx5PIqRpCEiECsxJvDu9hBpgoLmEt8/+kNYrIJSEscXVwGUsEioCrx5NpDsL28AhYSE3Z5 gIR5BDgldk/ayg5i8woISpyc+YQFxGYW0JK48e8l0wRGvllIUrOQpBYwMq1ilE3JrdLNTczM KU5N1i1OTszLSy3SNdTLzSzRS00p3cQICjFOSZ4djG8OKh1iFOBgVOLh9eHt8hViTSwrrsw9 xCjJwaQkyus7ESjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhLfXCCjHm5JYWZValA+TkuZgURLn nSGp7iskkJ5YkpqdmlqQWgSTleHgUJLgvTUFqFGwKDU9tSItM6cEIc3EwQkynAdouP0kkOHF BYm5xZnpEPlTjIpS4rxvQZoFQBIZpXlwvbAU8IpRHOgVYd5zIFU8wPQB1/0KaDAT0GA3DbDB JYkIKakGRt4c5d0/Q+8vVIhoVs9KUthjs+zxnRlmnPlcLRe2TU37yn40YOMW/dz1W9dnTS5M Uw6/vL5K938Jd7R0740Lisphd5MvzJP8NOf6koKvhwv0uvqPGmp1NWu6rDWuvWscGcRm0B7t mbDu4vtTTM1fNvG5hipazCgIjbj+9+GNC9emC64UWvb+jxJLcUaioRZzUXEiACgAMo7cAgAA
Subject: [secdir] secdir review of draft-ietf-sidr-signed-object
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: Thu, 24 Mar 2011 00:49:29 -0000

This document defines a profile of the Cryptographic Message Syntax
(CMS) signed-data object for use with the Resource Public Key
Infrastructure (RPKI).

I find Security Considerations section to be reasonable; it describes
the expected security properties of RPKI signed objects (including a
lack of confidentiality), and rightfully defers to the CMS
specification for additional security considerations.

Someone more familiar with CMS than I am should check whether the
structure version numbers correspond to those specified in RFC 5652;
they appear correct to me, though.