[sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt

Roque Gagliano <rogaglia@cisco.com> Tue, 02 August 2011 09:32 UTC

Return-Path: <rogaglia@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D8321F8EFA for <sidr@ietfa.amsl.com>; Tue, 2 Aug 2011 02:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 dMPm1gpi3w7n for <sidr@ietfa.amsl.com>; Tue, 2 Aug 2011 02:31:59 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E14E521F8EF4 for <sidr@ietf.org>; Tue, 2 Aug 2011 02:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=12438; q=dns/txt; s=iport; t=1312277528; x=1313487128; h=from:subject:date:references:to:message-id:mime-version; bh=GDqlmNAK+CvIrQveeHu4xCw9HPqN5rSQdsX6HUViZJg=; b=Pa9gVCAzGfqMi9/kVVFo+eOomkIj5ePgifnIp/JuZ89A5bljm8Tkm8Cy vb97eBHDnzZniTSZSxYA1kIey1ClA74l3H81j2sde6DLtQKnJQ7qoedc5 AE/xJBv41Qqkoq3MoHN+M71wg6DWXbomP6sgZd4rJ2Ef/v7HWxI4KvY1m Q=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAI7DN06Q/khL/2dsb2JhbABCp2B3gUABAQEBAgESAWQHCxwDAQIvAksCCAYTIodKoiYBnwyFY18EknuQZg
X-IronPort-AV: E=Sophos; i="4.67,305,1309737600"; d="p7s'?scan'208,217"; a="106139675"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2011 09:32:06 +0000
Received: from dhcp-144-254-20-178.cisco.com (dhcp-144-254-20-178.cisco.com [144.254.20.178]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p729VwmU006135 for <sidr@ietf.org>; Tue, 2 Aug 2011 09:31:58 GMT
From: Roque Gagliano <rogaglia@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail-113--1037130997"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Tue, 02 Aug 2011 11:31:56 +0200
References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com>
To: sidr wg list <sidr@ietf.org>
Message-Id: <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 09:32:00 -0000

Dear WG,

I uploaded a new version of the draft preparing it for WGLC.

The only change is a requirement from the BGPSEC team to include a paragraph in section 4.2 that clarifies that "mixed" certs are not allowed only for CA certs but may be possible for EE certs that do not validate repository objects (i.e. BGPSEC certs).


Regards,
Roque


Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: August 2, 2011 11:20:22 AM GMT+02:00
> To: rogaglia@cisco.com
> Cc: turners@ieca.com, rogaglia@cisco.com, kent@bbn.com
> Subject: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt
> 
> A new version of I-D, draft-ietf-sidr-algorithm-agility-03.txt has been successfully submitted by Roque Gagliano and posted to the IETF repository.
> 
> Filename:	 draft-ietf-sidr-algorithm-agility
> Revision:	 03
> Title:		 Algorithm Agility Procedure for RPKI.
> Creation date:	 2011-08-02
> WG ID:		 sidr
> Number of pages: 25
> 
> Abstract:
>   This document specifies the process that Certification Authorities
>   (CAs) and Relying Parties (RP) participating in the Resource Public
>   Key Infrastructure (RPKI) will need to follow to transition to a new
>   (and probably cryptographically stronger) algorithm set.  The process
>   is expected to be completed in a time scale of months or years.
>   Consequently, no emergency transition is specified.  The transition
>   procedure defined in this document supports only a top-down migration
>   (parent migrates before children).
> 
> 
> 
> 
> The IETF Secretariat