From weiler@watson.org Mon Jun 7 08:21:52 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F773A67E7 for ; Mon, 7 Jun 2010 08:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 L2IzwrC0UXuI for ; Mon, 7 Jun 2010 08:21:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1558028C31F for ; Sun, 6 Jun 2010 21:21:50 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o574LnMe052781 for ; Mon, 7 Jun 2010 00:21:49 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o574Lnp4052777 for ; Mon, 7 Jun 2010 00:21:49 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 7 Jun 2010 00:21:49 -0400 (EDT) From: Samuel Weiler To: sidr@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 07 Jun 2010 00:21:49 -0400 (EDT) Subject: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:21:52 -0000 I just submitted an i-d documenting a much simpler trust anchor format than the one in the current WG draft. Like the format in the WG doc, this one allows for a long-lived trust anchor even though the unlying certificate changes more often, e.g. when new resources are added. This format has the advantage of being noticeably simpler. I encourage the WG to adopt this format in place of the one in the current WG doc. -- Sam ---------- Forwarded message ---------- Date: Sun, 6 Jun 2010 19:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RPKI Trust Anchor Format Author(s) : S. Weiler Filename : draft-weiler-sidr-trust-anchor-format-00.txt Pages : 4 Date : 2010-06-06 This document describes a simple convention for distributing trust anchors for the Resource Public Key Infrastructure (RPKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weiler-sidr-trust-anchor-format-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From sra@hactrn.net Mon Jun 7 10:24:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7D23A6E02 for ; Mon, 7 Jun 2010 10:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-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 cGIFuwKovD5F for ; Mon, 7 Jun 2010 10:24:11 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 8652A3A6A6D for ; Mon, 7 Jun 2010 09:05:59 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 9B01D28431 for ; Mon, 7 Jun 2010 16:05:58 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 39E1A22808 for ; Mon, 7 Jun 2010 12:05:58 -0400 (EDT) Date: Mon, 07 Jun 2010 12:05:58 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100607160558.39E1A22808@thrintun.hactrn.net> Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:24:11 -0000 At Mon, 7 Jun 2010 00:21:49 -0400 (EDT), Sam Weiler wrote: > > I just submitted an i-d documenting a much simpler trust anchor format > than the one in the current WG draft. Like the format in the WG doc, > this one allows for a long-lived trust anchor even though the unlying > certificate changes more often, e.g. when new resources are added. > This format has the advantage of being noticeably simpler. > > I encourage the WG to adopt this format in place of the one in the > current WG doc. I support this proposal. My validator software supports this trust anchor format, via the "indirect-trust-anchor" configuration directive. The semantics are identical to the "trust-anchor-uri-with-key" format I implemented at ARIN's request several years ago. The only change from the older directive is syntax: Sam pointed out (correctly) that moving the URI out of the validator's configuration file and into the file with the public key would make this mechanism easier to use. From randy@psg.com Mon Jun 7 16:48:19 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80713A6879 for ; Mon, 7 Jun 2010 16:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 otWiwMPn8A6J for ; Mon, 7 Jun 2010 16:48:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id ACD423A6843 for ; Mon, 7 Jun 2010 16:48:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLm3C-0008e4-6T; Mon, 07 Jun 2010 23:48:14 +0000 Date: Tue, 08 Jun 2010 08:48:13 +0900 Message-ID: From: Randy Bush To: Samuel Weiler In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 23:48:19 -0000 > Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt i support this becoming a sidr wg document i also like the format randy From terry.manderson@icann.org Mon Jun 7 17:35:25 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5383A68B1 for ; Mon, 7 Jun 2010 17:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 hjA1ax27kPX8 for ; Mon, 7 Jun 2010 17:35:24 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 4AA3B3A68BD for ; Mon, 7 Jun 2010 17:35:24 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 7 Jun 2010 17:35:25 -0700 From: Terry Manderson To: Samuel Weiler , "sidr@ietf.org" Date: Mon, 7 Jun 2010 17:35:23 -0700 Thread-Topic: [sidr] Simpler trust anchor format Thread-Index: AcsGVTfxXBwMBTtERjSxuPYH1hz01QATUMp+ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 00:35:25 -0000 Before I lend my support to either the simpler format or the current compound TA format I'd like to see a pros/cons list comparing the two approaches. While I find myself liking simple approaches but I also wonder if it has an= y downfalls in use. Cheers Terry On 7/06/10 2:21 PM, "Samuel Weiler" wrote: > I just submitted an i-d documenting a much simpler trust anchor format > than the one in the current WG draft. Like the format in the WG doc, > this one allows for a long-lived trust anchor even though the unlying > certificate changes more often, e.g. when new resources are added. > This format has the advantage of being noticeably simpler. >=20 > I encourage the WG to adopt this format in place of the one in the > current WG doc. >=20 > -- Sam >=20 > ---------- Forwarded message ---------- > Date: Sun, 6 Jun 2010 19:30:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : RPKI Trust Anchor Format > Author(s) : S. Weiler > Filename : draft-weiler-sidr-trust-anchor-format-00.txt > Pages : 4 > Date : 2010-06-06 >=20 > This document describes a simple convention for distributing trust > anchors for the Resource Public Key Infrastructure (RPKI). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-weiler-sidr-trust-anchor-format= -00.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Tue Jun 8 06:00:57 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D861028C1A7 for ; Tue, 8 Jun 2010 06:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 XpgD1sFG3HNg for ; Tue, 8 Jun 2010 06:00:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E1AEB28C199 for ; Tue, 8 Jun 2010 06:00:56 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o58D0vJj015315 for ; Tue, 8 Jun 2010 08:00:57 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o58D0sgN009996 for ; Tue, 8 Jun 2010 08:00:55 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 09:00:54 -0400 Date: Tue, 8 Jun 2010 09:00:52 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Jun 2010 13:00:54.0294 (UTC) FILETIME=[A1086360:01CB070A] Subject: Re: [sidr] WG adoption on draft-ymbk-rpki-rtr-protocol-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:00:57 -0000 The adoption call has ended. There were four responses to this call (by non-authors), all supporting adoption. I am satisfied that there is consensus in the wg for adoption of the work. The authors are requested to submit the draft as a wg draft. --Sandy, speaking as wg chair On Wed, 12 May 2010, Sandra Murphy wrote: > Randy Bush has requested that the working group adopt the draft > draft-ymbk-rpki-rtr-protocol-05.txt as a work item. > > It is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-05 > > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work on > the draft. > > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item as well as your intention to work > on the draft if adopted. The call for adoption will end in two weeks on May > 26. > > --Sandy, speaking as wg chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Tue Jun 8 06:01:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0508328C1AD for ; Tue, 8 Jun 2010 06:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] 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 nh5FBp00z6Qr for ; Tue, 8 Jun 2010 06:01:09 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0924F28C1AA for ; Tue, 8 Jun 2010 06:01:08 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o58D19jq015329 for ; Tue, 8 Jun 2010 08:01:09 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o58D16G0010014 for ; Tue, 8 Jun 2010 08:01:09 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 09:01:05 -0400 Date: Tue, 8 Jun 2010 09:01:03 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Jun 2010 13:01:05.0981 (UTC) FILETIME=[A7FFAED0:01CB070A] Subject: Re: [sidr] WG adoption for draft-pmohapat-sidr-pfx-validate-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:01:10 -0000 The adoption call has ended. There were three responses to this call (by non-authors), all supporting adoption, and an energetic discussion of the draft terminology. I am satisfied that there is consensus in the wg for adoption of the work and interest in participating. The authors are requested to submit the draft as a wg draft. --Sandy, speaking as wg chair On Wed, 12 May 2010, Sandra Murphy wrote: > Pradosh Mohapatra has requested that the working group adopt the draft > draft-pmohapat-sidr-pfx-validate-07.txt as a work item. > > This work has been presented at IETF 73, IETF 75, and IETF 77. > > It is available at > http://tools.ietf.org/html/draft-pmohapat-sidr-pfx-validate-07 > > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work on > the draft. > > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item as well as your intention to work > on the draft if adopted. The call for adoption will end in two weeks on May > 26. > > --Sandy, speaking as wg chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Tue Jun 8 06:01:43 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6AC28C1A9 for ; Tue, 8 Jun 2010 06:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=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 pDPndJDZpRmI for ; Tue, 8 Jun 2010 06:01:39 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1D24728C199 for ; Tue, 8 Jun 2010 06:01:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o58D1d6J015345 for ; Tue, 8 Jun 2010 08:01:39 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o58D1dsv010056 for ; Tue, 8 Jun 2010 08:01:39 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 09:01:39 -0400 Date: Tue, 8 Jun 2010 09:01:37 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Jun 2010 13:01:39.0419 (UTC) FILETIME=[BBEDEAB0:01CB070A] Subject: Re: [sidr] WG LC for draft-ietf-sidr-roa-validation-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:01:44 -0000 The WG LC has ended. There were no responses to this LC. None. Zip. Zero. This draft has gone through many changes through the years as it has been discussed in IETF meetings. So the silence must be regarded as proof that the wg had no further comments to make. I do note that the discussion of terminology (valid/unknown/invalid) in the draft-pmohapat-sidr-pfx-validate-07 draft apply equally to this draft and that an author of this draft had alternative terms to suggest in that discussion. I believe that that energetic discussion is indication that the wg would prefer different terminology be used in this draft as well. I invite the authors to continue that discussion to come to consensus of what terms best capture the desired semantics. Any final last call on this draft would be very short indeed. --Sandy, speaking as wg chair On Tue, 18 May 2010, Sandra Murphy wrote: > The presentation "ROA Validation Update" > (http://www.ietf.org/proceedings/77/slides/sidr-8.pdf) at IETF 77 requested a > WG LC for draft "Validation of Route Origination using the Resource > Certificate PKI and ROAs". > > The document (and the draft version history) is at available at > http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-06. > > The Last Call will end on Wednesday 2 June 2010. > > As usual, please address all comments to the WG mailing list, and please be > clear in your comments to this last call if you are supporting the document's > submission to the IESG or if you are opposed. If you are opposed, please > indicate why. > > --Sandy > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Tue Jun 8 06:02:00 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B328928C1AC for ; Tue, 8 Jun 2010 06:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=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 BqxW2K4Hh-31 for ; Tue, 8 Jun 2010 06:02:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id CD18828C199 for ; Tue, 8 Jun 2010 06:01:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o58D20Jt015353 for ; Tue, 8 Jun 2010 08:02:00 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o58D20qF010080 for ; Tue, 8 Jun 2010 08:02:00 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 09:01:59 -0400 Date: Tue, 8 Jun 2010 09:01:58 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Jun 2010 13:02:00.0059 (UTC) FILETIME=[C83B54B0:01CB070A] Subject: Re: [sidr] more repository structure comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:02:00 -0000 On Sat, 29 May 2010, Geoff Huston wrote: > Steve, > >> When I began work on the algorithm migration I-D, I realized that we first needed to document the key rollover process (with no algorithm change). There are hints about this in a few places in this document, but not a complete discussion of this important topic. Unless the WG chairs object, I will include the key rollover discussion as part of the I-D that is also going to discuss algorithm migration. (Maybe I'll call it key and algorithm rollover :-).) When you say "as part of the I-D that is also going to discuss algorithm migration.", do you mean that you are working on a draft that would address that topic? I had asked for volunteers to work on the "transition" draft that was requested by the security ADs, and the volunteers have begun work. If there are alternative approaches, we will have an opportuntity to discuss them at the next IETF meeting (and before). --Sandy > > It is my impression that key rollover and algorithm migration are somewhat different in the demands they place on the PKI, and sufficiently so that attempting to describe the two processes in a single document may not be the most appropriate action. Some thoughts on the algorithm migration issue are to be found in draft-ietf-sidr-rpki-algs-01.txt. > > Geoff > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From warren@kumari.net Tue Jun 8 12:04:16 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0333A67AC for ; Tue, 8 Jun 2010 12:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 jq5ArMvdhw5n for ; Tue, 8 Jun 2010 12:04:15 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 3D1EB3A635F for ; Tue, 8 Jun 2010 12:04:15 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 9ED9322847A8; Tue, 8 Jun 2010 15:00:41 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id C6738228477D; Tue, 8 Jun 2010 15:00:39 -0400 (EDT) Message-Id: From: Warren Kumari To: Randy Bush In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Jun 2010 15:04:13 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:04:16 -0000 On Jun 7, 2010, at 7:48 PM, Randy Bush wrote: >> Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt > > i support this becoming a sidr wg document Yup, as do I. > > i also like the format Yes. So much less pain.... W > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade) From sra@hactrn.net Tue Jun 8 12:42:01 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DEA3A6823 for ; Tue, 8 Jun 2010 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-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 noyiF+n9DOHL for ; Tue, 8 Jun 2010 12:42:00 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 716B93A6806 for ; Tue, 8 Jun 2010 12:42:00 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 89D0D28431 for ; Tue, 8 Jun 2010 19:41:59 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 456BE22808 for ; Tue, 8 Jun 2010 15:41:59 -0400 (EDT) Date: Tue, 08 Jun 2010 15:41:59 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100608194159.456BE22808@thrintun.hactrn.net> Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:42:01 -0000 At Mon, 7 Jun 2010 17:35:23 -0700, Terry Manderson wrote: > > Before I lend my support to either the simpler format or the current > compound TA format I'd like to see a pros/cons list comparing the two > approaches. > > While I find myself liking simple approaches but I also wonder if it > has any downfalls in use. Terry, As far as I know the simple approach has no downside. We've been using something semantically identical to this in our testbed since last July, and the new syntax was a trivial drop-in replacement. The self-signed RPKI certificates change weekly as we get new data, validator keeps humming along. Other than simplicity for its own sake, the main advantage I see with the simple approach is that in some respects it is technically more robust, precisely because there are fewer moving parts, therefore fewer things to go wrong. This is not meant as a slam at the other mechanism, it's just that X.509 and CMS have a lot of options, each with multiple settings. The set of allowed options is much smaller than the set of possible options. Unchecked options can potentially trigger weird behavior in the underlying X.509 and CMS implementations, so all of the options must be checked. All this work makes no progress towards the real goal (verifying RPKI certificates), it's essentially busywork that one is stuck with doing because of the choice of trust anchor wrapper format. The simpler approach eschews most of this, and has very little to check beyond the checks that one has to do anyway for the self-signed RPKI certificate itself. So, to me, the simple approach adds exactly what we need beyond the base RPKI mechanism, and no more, while the other mechanism adds a lot of stuff that accomplishes the same purpose but takes more effort to get right. I freely grant that there are many other parts of this system which are also complicated and easy to get wrong, but that, in and of itself, seems insufficient reason to add another one. So, to me, at least in this case, simplicity is not just an esthetic virtue, it's a form of engineering robustness. YMMV. --Rob From gih@apnic.net Tue Jun 8 15:16:35 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A7C3A683F for ; Tue, 8 Jun 2010 15:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RELAY_IS_203=0.994] 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 OIpByjmO8Jcy for ; Tue, 8 Jun 2010 15:16:34 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 0690D3A680E for ; Tue, 8 Jun 2010 15:16:33 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 6648AD58A9 for ; Wed, 9 Jun 2010 08:16:32 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Geoff Huston In-Reply-To: <20100608194159.456BE22808@thrintun.hactrn.net> Date: Wed, 9 Jun 2010 08:16:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> References: <20100608194159.456BE22808@thrintun.hactrn.net> To: sidr wg X-Mailer: Apple Mail (2.1078) Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 22:16:35 -0000 On 09/06/2010, at 5:41 AM, Rob Austein wrote: > At Mon, 7 Jun 2010 17:35:23 -0700, Terry Manderson wrote: >>=20 >> Before I lend my support to either the simpler format or the current >> compound TA format I'd like to see a pros/cons list comparing the two >> approaches. >>=20 >> While I find myself liking simple approaches but I also wonder if it >> has any downfalls in use. >=20 > Terry, >=20 > As far as I know the simple approach has no downside. We've been > using something semantically identical to this in our testbed since > last July, and the new syntax was a trivial drop-in replacement. The > self-signed RPKI certificates change weekly as we get new data, > validator keeps humming along. >=20 > Other than simplicity for its own sake, the main advantage I see with > the simple approach is that in some respects it is technically more > robust, precisely because there are fewer moving parts, therefore > fewer things to go wrong. This is not meant as a slam at the other > mechanism, it's just that X.509 and CMS have a lot of options, each > with multiple settings. The set of allowed options is much smaller > than the set of possible options. Unchecked options can potentially > trigger weird behavior in the underlying X.509 and CMS > implementations, so all of the options must be checked. All this work > makes no progress towards the real goal (verifying RPKI certificates), > it's essentially busywork that one is stuck with doing because of the > choice of trust anchor wrapper format. The simpler approach eschews > most of this, and has very little to check beyond the checks that one > has to do anyway for the self-signed RPKI certificate itself. >=20 > So, to me, the simple approach adds exactly what we need beyond the > base RPKI mechanism, and no more, while the other mechanism adds a lot > of stuff that accomplishes the same purpose but takes more effort to > get right. I freely grant that there are many other parts of this > system which are also complicated and easy to get wrong, but that, in > and of itself, seems insufficient reason to add another one. >=20 > So, to me, at least in this case, simplicity is not just an esthetic > virtue, it's a form of engineering robustness. >=20 > YMMV. Firstly, I'd like to point out that the approach described in this = draft, namely that of public key plus URL and a self signed RPKI = certificate) is the approach described in = draft-ietf-sidr-res-certs-06.txt through to = draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly = across that sequence of drafts in response to inputs from Steve Kent, = but the concept of using a very simple approach of using the public key = plus URL was what was originally envisaged for the RPKI back in = 2007-2008 when those versions of the draft were submitted to the drafts = repository. The changes made in version 12 of that draft were made in response to = messages from Steve Kent and Russ Housley, which pointed out what they = believed to be specific weaknesses in this key plus URL approach to the = TA that implied that in their opinion this was not a viable approach to = the TA. If they are still of the opinion that this approach is not = viable then I guess that they should say so once more and present their = arguments in support of that view, this time to the WG. Geoff From kent@bbn.com Wed Jun 9 12:38:27 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582A13A676A for ; Wed, 9 Jun 2010 12:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 8bX1-kqGGjwl for ; Wed, 9 Jun 2010 12:38:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9E7573A659A for ; Wed, 9 Jun 2010 12:38:25 -0700 (PDT) Received: from dhcp89-089-149.bbn.com ([128.89.89.149]:49159) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMR6Y-000ABZ-L1; Wed, 09 Jun 2010 15:38:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> Date: Wed, 9 Jun 2010 15:38:24 -0400 To: Geoff Huston From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-936010190==_ma============" Cc: sidr wg Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:38:27 -0000 --============_-936010190==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >... > >Firstly, I'd like to point out that the approach described in this >draft, namely that of public key plus URL and a self signed RPKI >certificate) is the approach described in >draft-ietf-sidr-res-certs-06.txt through to >draft-ietf-sidr-res-certs-11.txt. The terminology was altered >slightly across that sequence of drafts in response to inputs from >Steve Kent, but the concept of using a very simple approach of using >the public key plus URL was what was originally envisaged for the >RPKI back in 2007-2008 when those versions of the draft were >submitted to the drafts repository. > >The changes made in version 12 of that draft were made in response >to messages from Steve Kent and Russ Housley, which pointed out what >they believed to be specific weaknesses in this key plus URL >approach to the TA that implied that in their opinion this was not a >viable approach to the TA. If they are still of the opinion that >this approach is not viable then I guess that they should say so >once more and present their arguments in support of that view, this >time to the WG. > > Geoff Geoff, I read the Sam's TA draft and sent comment directly to him yesterday. But, since you requested feedback from Russ and from me on the list, I'll recap my comments here. The new TA proposal has a few problems. From a terminology perspective it has a problem of the sort that Russ and I noted 2 years ago in the proposal you cited. Specifically, the self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The public key and URI are external mechanisms used to acquire and verify the TA. They are not the TA. Such mechanisms are outside the scope of PKIX and X.509 standards, so the proposal here is not violating any of those standards. It just defines the wrong data as being a TA. There also is a technical error in the paragraph at the end of Section 4, where the new I-D describes how one could operate the CA for the self-signed cert in an offline fashion. The text calls for the TA to not contain a 3779 extension. That is not compliant with 3779. RFC 3779 requires that the TA at which a path terminates contain a 3779 extension that encompasses all subordinate certs. However, if one put the 3779 extensions in the TA (self-signed cert), and set the inherit bit in the (immediate) subordinate CA cert, one could achieve the desired offline operation goal that the I-D describes. This would then comply with RFC 3779. So, the I-D could be rewritten to fix the terminology problem and the technical problem cited above. I think the notion of an offline TA and an online CA below it are important from a secruity perspective. Both the compound TA model and this proposal can achieve that functionality if the new proposal is modified as noted above, and if the use of the subordinate CA (with the inherit bit) is mandated, not an option. I also think it important to have an explicit, mandatory mechanism for revocation of an online CA (TA). This is motivated by the observation that the primary motivation for having matching online and an offline cert issuers is because one believes that online instance is more vulnerable than the offline one. Well, if that belief is true, one needs to be prepared to revoke the online CA's cert, using the offline CA. The compound TA mechanism does that by having the ETA revoke the EE cert that is used to validate the CMS blob that holds the RTA. I don't recall the current proposal making a mention of a comparable function. That can be fixed by having the new proposal say that the TA will maintain a CRL and that it will revoke its subordinate CA, if needed. If all of these changes were made to the new proposal, both approaches would seem equivalent in functionality and security. The new proposal would be somewhat simpler, as it would not make use of the CMS structure that is employed in the compound TA model. However, code already exists for the compound TA model, processing of signed CMS objects is pretty well understood (based on S/MIME implementations), and the differences are relatively minor, in my opinion. Also, once we correct the terminology and label the self-signed cert with the 3779 extensions as a TA, we have the slightly odd situation that the TA is not static, i.e., that cert will change with every new resource allocation. That does not conflict with any PKIX RFC, to the best of my knowledge, but it may confuse some folks who are accustomed to the notion of a TA being a self-signed cert that does not change for a long time. Does this analysis satisfy your request? Steve --============_-936010190==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] Simpler trust anchor format
...

Firstly, I'd like to point out that the approach described in this draft, namely that of public key plus URL and a self signed RPKI certificate) is the approach described in draft-ietf-sidr-res-certs-06.txt through to draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly across that sequence of drafts in response to inputs from Steve Kent, but the concept of using a very simple approach of using the public key plus URL was what was originally envisaged for the RPKI back in 2007-2008 when those versions of the draft were submitted to the drafts repository.

The changes made in version 12 of that draft were made in response to messages from Steve Kent and Russ Housley, which pointed out what they believed to be specific weaknesses in this key plus URL approach to the TA that implied that in their opinion this was not a viable approach to the TA. If they are still of the opinion that this approach is not viable then I guess that they should say so once more and present their arguments in support of that view, this time to the WG.
 Geoff

Geoff,

I read the Sam's TA draft and sent comment directly to him yesterday.  But, since you requested feedback from Russ and from me on the list, I'll recap my comments here.

The new TA proposal has a few problems.

From a terminology perspective it has a problem of the sort that Russ and I noted 2 years ago in the proposal you cited.  Specifically, the self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The public key and URI are external mechanisms used to acquire and verify the TA.  They are not the TA. Such mechanisms are outside the scope of PKIX and X.509 standards, so the proposal here is not violating any of those standards.  It just defines the wrong data as being a TA.

There also is a technical error in the paragraph at the end of Section 4, where the new I-D describes how one could operate the CA for the self-signed cert in an offline fashion. The text calls for the TA to not contain a 3779 extension. That is not compliant with 3779. RFC 3779 requires that the TA at which a path terminates contain a 3779 extension that encompasses all subordinate certs.

However, if one put the 3779 extensions in the TA (self-signed cert), and set the inherit bit in the (immediate) subordinate CA cert, one could achieve the desired offline operation goal that the I-D describes. This would then comply with RFC 3779.

So, the I-D could be rewritten to fix the terminology problem and the technical problem cited above.

I think the notion of an offline TA and an online CA below it are important from a secruity perspective. Both the compound TA model and this proposal can achieve that functionality if the new proposal is modified as noted above, and if the use of the subordinate CA (with the inherit bit) is mandated, not an option.

I also think it important to have an explicit, mandatory mechanism for revocation of an online CA (TA). This is motivated by the observation that the primary motivation for having matching online and an offline cert issuers is because one believes that online instance is more vulnerable than the offline one.  Well, if that belief is true, one needs to be prepared to revoke the online CA's cert, using the offline CA. The compound TA mechanism does that by having the ETA revoke the EE cert that is used to validate the CMS blob that holds the RTA.  I don't recall the current proposal making a mention of a comparable function. That can be fixed by having the new proposal say that the TA will maintain a CRL and that it will revoke its subordinate CA, if needed.

If all of these changes were made to the new proposal, both approaches would seem equivalent in functionality and security. The new proposal would be somewhat simpler, as it would not make use of the CMS structure that is employed in the compound TA model. However, code already exists for the compound TA model, processing of signed CMS objects is pretty well understood (based on S/MIME implementations), and the differences are relatively minor, in my opinion. Also, once we correct the terminology and label the self-signed cert with the 3779 extensions as a TA, we have the slightly odd situation that the TA is not static, i.e., that cert will change with every new resource allocation. That does not conflict with any PKIX RFC, to the best of my knowledge, but it may confuse some folks who are accustomed to the notion of a TA being a self-signed cert that does not change for a long time.

Does this analysis satisfy your request?

Steve
--============_-936010190==_ma============-- From gih@apnic.net Wed Jun 9 13:31:34 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74AB3A67B3 for ; Wed, 9 Jun 2010 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RELAY_IS_203=0.994] 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 wCsopn9JtFJi for ; Wed, 9 Jun 2010 13:31:30 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8BB0F3A67B5 for ; Wed, 9 Jun 2010 13:31:28 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0D8C6D58BB; Thu, 10 Jun 2010 06:31:27 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 10 Jun 2010 06:31:23 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> To: Stephen Kent X-Mailer: Apple Mail (2.1078) Cc: sidr wg Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 20:31:34 -0000 On 10/06/2010, at 5:38 AM, Stephen Kent wrote: >> ... >>=20 >> Firstly, I'd like to point out that the approach described in this = draft, namely that of public key plus URL and a self signed RPKI = certificate) is the approach described in = draft-ietf-sidr-res-certs-06.txt through to = draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly = across that sequence of drafts in response to inputs from Steve Kent, = but the concept of using a very simple approach of using the public key = plus URL was what was originally envisaged for the RPKI back in = 2007-2008 when those versions of the draft were submitted to the drafts = repository. >>=20 >> The changes made in version 12 of that draft were made in response to = messages from Steve Kent and Russ Housley, which pointed out what they = believed to be specific weaknesses in this key plus URL approach to the = TA that implied that in their opinion this was not a viable approach to = the TA. If they are still of the opinion that this approach is not = viable then I guess that they should say so once more and present their = arguments in support of that view, this time to the WG. >> Geoff >=20 > Geoff, >=20 > I read the Sam's TA draft and sent comment directly to him yesterday. = But, since you requested feedback from Russ and from me on the list, = I'll recap my comments here. >=20 > The new TA proposal has a few problems. >=20 > =46rom a terminology perspective it has a problem of the sort that = Russ and I noted 2 years ago in the proposal you cited. Specifically, = the self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The = public key and URI are external mechanisms used to acquire and verify = the TA. They are not the TA. Such mechanisms are outside the scope of = PKIX and X.509 standards, so the proposal here is not violating any of = those standards. It just defines the wrong data as being a TA. >=20 > There also is a technical error in the paragraph at the end of Section = 4, where the new I-D describes how one could operate the CA for the = self-signed cert in an offline fashion. The text calls for the TA to not = contain a 3779 extension. That is not compliant with 3779. RFC 3779 = requires that the TA at which a path terminates contain a 3779 extension = that encompasses all subordinate certs. >=20 > However, if one put the 3779 extensions in the TA (self-signed cert), = and set the inherit bit in the (immediate) subordinate CA cert, one = could achieve the desired offline operation goal that the I-D describes. = This would then comply with RFC 3779. >=20 > So, the I-D could be rewritten to fix the terminology problem and the = technical problem cited above. >=20 > I think the notion of an offline TA and an online CA below it are = important from a secruity perspective. Both the compound TA model and = this proposal can achieve that functionality if the new proposal is = modified as noted above, and if the use of the subordinate CA (with the = inherit bit) is mandated, not an option. >=20 > I also think it important to have an explicit, mandatory mechanism for = revocation of an online CA (TA). This is motivated by the observation = that the primary motivation for having matching online and an offline = cert issuers is because one believes that online instance is more = vulnerable than the offline one. Well, if that belief is true, one = needs to be prepared to revoke the online CA's cert, using the offline = CA. The compound TA mechanism does that by having the ETA revoke the EE = cert that is used to validate the CMS blob that holds the RTA. I don't = recall the current proposal making a mention of a comparable function. = That can be fixed by having the new proposal say that the TA will = maintain a CRL and that it will revoke its subordinate CA, if needed. >=20 > If all of these changes were made to the new proposal, both approaches = would seem equivalent in functionality and security. The new proposal = would be somewhat simpler, as it would not make use of the CMS structure = that is employed in the compound TA model. However, code already exists = for the compound TA model, processing of signed CMS objects is pretty = well understood (based on S/MIME implementations), and the differences = are relatively minor, in my opinion. Also, once we correct the = terminology and label the self-signed cert with the 3779 extensions as a = TA, we have the slightly odd situation that the TA is not static, i.e., = that cert will change with every new resource allocation. That does not = conflict with any PKIX RFC, to the best of my knowledge, but it may = confuse some folks who are accustomed to the notion of a TA being a = self-signed cert that does not change for a long time. >=20 > Does this analysis satisfy your request? Thank you for this analysis Steve. Geoff= From sra@hactrn.net Wed Jun 9 14:08:12 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0333A67EE for ; Wed, 9 Jun 2010 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-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 hVjG35N8ui6V for ; Wed, 9 Jun 2010 14:08:10 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 6FBE03A67F3 for ; Wed, 9 Jun 2010 14:08:10 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 818E82842B for ; Wed, 9 Jun 2010 21:08:10 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 103EC22808 for ; Wed, 9 Jun 2010 17:08:10 -0400 (EDT) Date: Wed, 09 Jun 2010 17:08:10 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100609210810.103EC22808@thrintun.hactrn.net> Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 21:08:12 -0000 Debating PKI terminology with Steve is a mug's game, and I've already stated my reasons for liking the simple format in a previous posting, so this will just be about the parts of Steve's analysis where I have something new to say or ask. At Wed, 9 Jun 2010 15:38:24 -0400, Steve Kent wrote: ... > There also is a technical error in the paragraph at the end of > Section 4, where the new I-D describes how one could operate the CA > for the self-signed cert in an offline fashion. The text calls for > the TA to not contain a 3779 extension. That is not compliant with > 3779. RFC 3779 requires that the TA at which a path terminates > contain a 3779 extension that encompasses all subordinate certs. Where in that paragraph (or anywhere in Sam's document) does it say that the TA certificate doesn't contain 3779 extensions? At least one of us is confused on this point. That said, if the text is confusing, it should be fixed. I don't think Sam intended to suggest that the certificate should not contain 3997 extensions; indeed, constraint (1) in that section says that the certificate must contain RFC 3779 resources, albeit by reference (it says that the certificate must comply with the res-cert profile). > However, if one put the 3779 extensions in the TA (self-signed cert), > and set the inherit bit in the (immediate) subordinate CA cert, one > could achieve the desired offline operation goal that the I-D > describes. This would then comply with RFC 3779. Other than the inherit bit, this is what I think the draft already says, or at least is trying to say. More on the inherit bit below. > So, the I-D could be rewritten to fix the terminology problem and the > technical problem cited above. Agreed. > I think the notion of an offline TA and an online CA below it are > important from a secruity perspective. Both the compound TA model and > this proposal can achieve that functionality if the new proposal is > modified as noted above, and if the use of the subordinate CA (with > the inherit bit) is mandated, not an option. Using the inherit bit here is clever. I'm not sure I believe that it needs to be mandatory, that seems like a choice the operator should be allowed to make. It's straight RFC 3779 in either case, no magic, so relying parties have to cope with either option in any case. I'd have no problem with a SHOULD regarding use of the inherit bit, just don't see the need for a MUST. > I also think it important to have an explicit, mandatory mechanism > for revocation of an online CA (TA). This is motivated by the > observation that the primary motivation for having matching online > and an offline cert issuers is because one believes that online > instance is more vulnerable than the offline one. Well, if that > belief is true, one needs to be prepared to revoke the online CA's > cert, using the offline CA. The compound TA mechanism does that by > having the ETA revoke the EE cert that is used to validate the CMS > blob that holds the RTA. I don't recall the current proposal making > a mention of a comparable function. That can be fixed by having the > new proposal say that the TA will maintain a CRL and that it will > revoke its subordinate CA, if needed. The current proposal says that the certificate conforms to the profile, which in turn mandates the CRL. No harm in saying so explicitly if you're more comfortable with that, but it's already part of the specification by reference as far as I can tell. From kent@bbn.com Wed Jun 9 14:34:55 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85FF3A680D for ; Wed, 9 Jun 2010 14:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=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 QATTtMikAgFn for ; Wed, 9 Jun 2010 14:34:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 901F13A67EF for ; Wed, 9 Jun 2010 14:34:54 -0700 (PDT) Received: from dhcp89-089-149.bbn.com ([128.89.89.149]:49163) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMSvH-000Bs2-6r; Wed, 09 Jun 2010 17:34:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100609210810.103EC22808@thrintun.hactrn.net> References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> <20100609210810.103EC22808@thrintun.hactrn.net> Date: Wed, 9 Jun 2010 17:30:45 -0400 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 21:34:56 -0000 >... > >At Wed, 9 Jun 2010 15:38:24 -0400, Steve Kent wrote: >... >> There also is a technical error in the paragraph at the end of >> Section 4, where the new I-D describes how one could operate the CA >> for the self-signed cert in an offline fashion. The text calls for >> the TA to not contain a 3779 extension. That is not compliant with >> 3779. RFC 3779 requires that the TA at which a path terminates >> contain a 3779 extension that encompasses all subordinate certs. > >Where in that paragraph (or anywhere in Sam's document) does it say >that the TA certificate doesn't contain 3779 extensions? At least one >of us is confused on this point. Sam's text in the last paragraph of section 4 said "... delegating all of the resources in the certificate to a single child ..." I misread this text to mean that the TA could have its 3779 extensions moved to the CA cert under it. A less ambiguous description of what I think Sam meant is the wording that I used in my description. >... >Other than the inherit bit, this is what I think the draft already >says, or at least is trying to say. More on the inherit bit below. in retrospect I agree. >... > >Using the inherit bit here is clever. I'm not sure I believe that it >needs to be mandatory, that seems like a choice the operator should be >allowed to make. It's straight RFC 3779 in either case, no magic, so >relying parties have to cope with either option in any case. ... >I'd have no problem with a SHOULD regarding use of the inherit bit, >just don't see the need for a MUST. agreed. > >> I also think it important to have an explicit, mandatory mechanism >> for revocation of an online CA (TA). This is motivated by the >> observation that the primary motivation for having matching online >> and an offline cert issuers is because one believes that online >> instance is more vulnerable than the offline one. Well, if that >> belief is true, one needs to be prepared to revoke the online CA's >> cert, using the offline CA. The compound TA mechanism does that by >> having the ETA revoke the EE cert that is used to validate the CMS >> blob that holds the RTA. I don't recall the current proposal making >> a mention of a comparable function. That can be fixed by having the >> new proposal say that the TA will maintain a CRL and that it will >> revoke its subordinate CA, if needed. > >The current proposal says that the certificate conforms to the >profile, which in turn mandates the CRL. No harm in saying so >explicitly if you're more comfortable with that, but it's already part >of the specification by reference as far as I can tell. yes, I think this needs to be stated explicitly. TAs are special, are self-signed certs. See 5280 for the various cases where they are called out as exceptions. So, for example there is not CRL issued for the TA here, because it is self-signed. But, in all other respects it is a resource cert :-). Steve From randy@psg.com Wed Jun 9 16:06:59 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8453A67B1 for ; Wed, 9 Jun 2010 16:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9QDhSQO0nv0I for ; Wed, 9 Jun 2010 16:06:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5A6403A6893 for ; Wed, 9 Jun 2010 16:06:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMUMM-000Gtl-1w; Wed, 09 Jun 2010 23:06:58 +0000 Date: Wed, 09 Jun 2010 16:06:58 -0700 Message-ID: From: Randy Bush To: Samuel Weiler In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 23:06:59 -0000 > I just submitted an i-d documenting a much simpler trust anchor format > than the one in the current WG draft. i support this draft as a sidr draft randy From randy@psg.com Wed Jun 9 16:09:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314663A68FA for ; Wed, 9 Jun 2010 16:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vyE679BOqvJF for ; Wed, 9 Jun 2010 16:09:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 709AE3A67B1 for ; Wed, 9 Jun 2010 16:09:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMUOV-000GuW-6l for sidr@ietf.org; Wed, 09 Jun 2010 23:09:11 +0000 Date: Wed, 09 Jun 2010 16:09:11 -0700 Message-ID: From: Randy Bush To: sidr wg User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] draft-reynolds-rpki-ltamgmt-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 23:09:11 -0000 oops. wrong draft, though i support sam's too. but i also support draft-reynolds-rpki-ltamgmt-00.txt becoming a sidr draft randy From rogaglia@cisco.com Thu Jun 10 01:26:08 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86AE93A6923 for ; Thu, 10 Jun 2010 01:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 efDnOuNZCJOV for ; Thu, 10 Jun 2010 01:26:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 283933A6902 for ; Thu, 10 Jun 2010 01:26:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAo+EExAZnwM/2dsb2JhbACeYnGjKJojhRgE X-IronPort-AV: E=Sophos;i="4.53,397,1272844800"; d="p7s'?scan'208,217";a="120068885" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2010 08:26:07 +0000 Received: from dhcp-144-254-20-199.cisco.com (dhcp-144-254-20-199.cisco.com [144.254.20.199]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5A8Q0uY002585; Thu, 10 Jun 2010 08:26:00 GMT Received: from [127.0.0.1] by dhcp-144-254-20-199.cisco.com (PGP Universal service); Thu, 10 Jun 2010 10:26:06 +0200 X-PGP-Universal: processed; by dhcp-144-254-20-199.cisco.com on Thu, 10 Jun 2010 10:26:06 +0200 Mime-Version: 1.0 (Apple Message framework v1078) From: Roque Gagliano In-Reply-To: Date: Thu, 10 Jun 2010 10:25:55 +0200 Message-Id: References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> To: Stephen Kent X-Mailer: Apple Mail (2.1078) Content-Type: multipart/signed; boundary=Apple-Mail-45--649071756; protocol="application/pkcs7-signature"; micalg=sha1 Cc: sidr wg Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 08:26:08 -0000 --Apple-Mail-45--649071756 Content-Type: multipart/alternative; boundary=Apple-Mail-44--649071847 --Apple-Mail-44--649071847 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Steve, Thanks for your report. To summarize a little bit, we could call the mechanism in this draft = "Simple Relaying Party Trust Anchor configuration", but not the TA = material itself. Particularly in SEND (RFC 3971 Section 6.5) that also deals with RFC3779 = extensions, the RP configuration is done with a similar mechanism. The = only difference is that it adds the key algorithm too....which could be = also good for this document. Roque. On Jun 9, 2010, at 9:38 PM, Stephen Kent wrote: >> ... >>=20 >> Firstly, I'd like to point out that the approach described in this = draft, namely that of public key plus URL and a self signed RPKI = certificate) is the approach described in = draft-ietf-sidr-res-certs-06.txt through to = draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly = across that sequence of drafts in response to inputs from Steve Kent, = but the concept of using a very simple approach of using the public key = plus URL was what was originally envisaged for the RPKI back in = 2007-2008 when those versions of the draft were submitted to the drafts = repository. >>=20 >> The changes made in version 12 of that draft were made in response to = messages from Steve Kent and Russ Housley, which pointed out what they = believed to be specific weaknesses in this key plus URL approach to the = TA that implied that in their opinion this was not a viable approach to = the TA. If they are still of the opinion that this approach is not = viable then I guess that they should say so once more and present their = arguments in support of that view, this time to the WG. >> Geoff >=20 > Geoff, >=20 > I read the Sam's TA draft and sent comment directly to him yesterday. = But, since you requested feedback from Russ and from me on the list, = I'll recap my comments here. >=20 > The new TA proposal has a few problems. >=20 > =46rom a terminology perspective it has a problem of the sort that = Russ and I noted 2 years ago in the proposal you cited. Specifically, = the self-signed cert is really the TA, as per RFC 5280 and RFC 5914. The = public key and URI are external mechanisms used to acquire and verify = the TA. They are not the TA. Such mechanisms are outside the scope of = PKIX and X.509 standards, so the proposal here is not violating any of = those standards. It just defines the wrong data as being a TA. >=20 > There also is a technical error in the paragraph at the end of Section = 4, where the new I-D describes how one could operate the CA for the = self-signed cert in an offline fashion. The text calls for the TA to not = contain a 3779 extension. That is not compliant with 3779. RFC 3779 = requires that the TA at which a path terminates contain a 3779 extension = that encompasses all subordinate certs. >=20 > However, if one put the 3779 extensions in the TA (self-signed cert), = and set the inherit bit in the (immediate) subordinate CA cert, one = could achieve the desired offline operation goal that the I-D describes. = This would then comply with RFC 3779. >=20 > So, the I-D could be rewritten to fix the terminology problem and the = technical problem cited above. >=20 > I think the notion of an offline TA and an online CA below it are = important from a secruity perspective. Both the compound TA model and = this proposal can achieve that functionality if the new proposal is = modified as noted above, and if the use of the subordinate CA (with the = inherit bit) is mandated, not an option. >=20 > I also think it important to have an explicit, mandatory mechanism for = revocation of an online CA (TA). This is motivated by the observation = that the primary motivation for having matching online and an offline = cert issuers is because one believes that online instance is more = vulnerable than the offline one. Well, if that belief is true, one = needs to be prepared to revoke the online CA's cert, using the offline = CA. The compound TA mechanism does that by having the ETA revoke the EE = cert that is used to validate the CMS blob that holds the RTA. I don't = recall the current proposal making a mention of a comparable function. = That can be fixed by having the new proposal say that the TA will = maintain a CRL and that it will revoke its subordinate CA, if needed. >=20 > If all of these changes were made to the new proposal, both approaches = would seem equivalent in functionality and security. The new proposal = would be somewhat simpler, as it would not make use of the CMS structure = that is employed in the compound TA model. However, code already exists = for the compound TA model, processing of signed CMS objects is pretty = well understood (based on S/MIME implementations), and the differences = are relatively minor, in my opinion. Also, once we correct the = terminology and label the self-signed cert with the 3779 extensions as a = TA, we have the slightly odd situation that the TA is not static, i.e., = that cert will change with every new resource allocation. That does not = conflict with any PKIX RFC, to the best of my knowledge, but it may = confuse some folks who are accustomed to the notion of a TA being a = self-signed cert that does not change for a long time. >=20 > Does this analysis satisfy your request? >=20 > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-44--649071847 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Steve,

Thanks for your = report.

To summarize a little bit, we could = call the mechanism in this draft "Simple Relaying Party Trust Anchor = configuration", but not the TA material = itself.

Particularly in SEND (RFC 3971 Section = 6.5) that also deals with RFC3779 extensions, the RP configuration is = done with a similar mechanism. The only difference is that it adds the = key algorithm too....which could be also good for this = document.


Roque.


On Jun 9, 2010, at 9:38 PM, Stephen Kent = wrote:


Firstly, I'd like = to point out that the approach described in this draft, namely that of = public key plus URL and a self signed RPKI certificate) is the approach = described in draft-ietf-sidr-res-certs-06.txt through to = draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly = across that sequence of drafts in response to inputs from Steve Kent, = but the concept of using a very simple approach of using the public key = plus URL was what was originally envisaged for the RPKI back in = 2007-2008 when those versions of the draft were submitted to the drafts = repository.

The changes made in version 12 of that draft were = made in response to messages from Steve Kent and Russ Housley, which = pointed out what they believed to be specific weaknesses in this key = plus URL approach to the TA that implied that in their opinion this was = not a viable approach to the TA. If they are still of the opinion that = this approach is not viable then I guess that they should say so once = more and present their arguments in support of that view, this time to = the WG.
 acquire and verify the = TA.  They are not the TA. Such mechanisms are outside the scope = of PKIX and X.509 standards, so the proposal here is not violating any = of those standards.  It just defines the wrong data as being a = TA.

There also is a technical error in the = paragraph at the end of Section 4, where the new I-D describes how one = could operate the CA for the self-signed cert in an offline fashion. The = text calls for the TA to not contain a 3779 extension. That is not = compliant with 3779. RFC 3779 requires that the TA at which a path = terminates contain a 3779 extension that encompasses all subordinate = certs.

However, if one put the 3779 extensions = in the TA (self-signed cert), and set the inherit bit in the (immediate) = subordinate CA cert, one could achieve the desired offline operation = goal that the I-D describes. This would then comply with RFC = 3779.

So, the I-D could be rewritten to fix the = terminology problem and the technical problem cited = above.

I think the notion of an offline TA and = an online CA below it are important from a secruity perspective. Both = the compound TA model and this proposal can achieve that functionality = if the new proposal is modified as noted above, and if the use of the = subordinate CA (with the inherit bit) is mandated, not an = option.

I also think it important to have an = explicit, mandatory mechanism for revocation of an online CA (TA). This = is motivated by the observation that the primary motivation for having = matching online and an offline cert issuers is because one believes that = online instance is more vulnerable than the offline one.  Well, if = that belief is true, one needs to be prepared to revoke the online CA's = cert, using the offline CA. The compound TA mechanism does that by = having the ETA revoke the EE cert that is used to validate the CMS blob = that holds the RTA.  I don't recall the current proposal making a = mention of a comparable function. That can be fixed by having the new = proposal say that the TA will maintain a CRL and that it will revoke its = subordinate CA, if needed.

If all of these = changes were made to the new proposal, both approaches would seem = equivalent in functionality and security. The new proposal would be = somewhat simpler, as it would not make use of the CMS structure that is = employed in the compound TA model. However, code already exists for the = compound TA model, processing of signed CMS objects is pretty well = understood (based on S/MIME implementations), and the differences are = relatively minor, in my opinion. Also, once we correct the terminology = and label the self-signed cert with the 3779 extensions as a TA, we have = the slightly odd situation that the TA is not static, i.e., that cert = will change with every new resource allocation. That does not conflict = with any PKIX RFC, to the best of my knowledge, but it may confuse some = folks who are accustomed to the notion of a TA being a self-signed cert = that does not change for a long time.

Does this = analysis satisfy your = request?

Steve
_____________________________= __________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail-44--649071847-- --Apple-Mail-45--649071756 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYxMDA4 MjU1NVowIwYJKoZIhvcNAQkEMRYEFJFX8VUZ2UqXRigpAlGKg7uotNBJMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBALLcJh5dkJY1veoUSdGdA2Rq54FGMCNN1wlT6Hu/5LWQ65UuVhAQ cCfEIg1Avkbrn86GEMNsFlCIDG7aKuc3khtPvIr9bWVS7S7+zXeyBhB2n5ywXWmfLUNEyH0MfQwx +ejg8aVmC/AoMCVWBrBXcrfgh5U4icpPJ8sLwqAD+Dj85EiuXliGe17/OEK55ZclG26PrudJIkUK EC9Kj434+T5srsrjA1kvTNRutSeJSXieve9vITWea79JkQLyEk5lDHuN5Rw3B08nmr9EPKVZbIMC 07uQBBAHbpePqfIuhl0jpTGB742Xrx0b5ZCLwGVMM15l9Td2/eW1TVBQG7+jh3kAAAAAAAA= --Apple-Mail-45--649071756-- From Sandra.Murphy@cobham.com Thu Jun 10 03:10:54 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABF43A6943 for ; Thu, 10 Jun 2010 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_50=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 Smbue+5VfR-N for ; Thu, 10 Jun 2010 03:10:53 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0DA1F3A6920 for ; Thu, 10 Jun 2010 03:10:52 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5AAAsxR011288 for ; Thu, 10 Jun 2010 05:10:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5AAAp9h002745 for ; Thu, 10 Jun 2010 05:10:51 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 06:10:50 -0400 Date: Thu, 10 Jun 2010 06:10:47 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Jun 2010 10:10:50.0811 (UTC) FILETIME=[341BF0B0:01CB0885] Subject: [sidr] Important dates for the Maastrict meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 10:10:54 -0000 A reminder of the important dates for the upcoming IETF meeting in Maastrict. Please note the cut-off dates for internet-draft submissions. Also note that initial versions of wg drafts (those whose names start draft-ietf-sidr-) must be pre-approved by the wg chairs. --Sandy, speaking as wg chair ----------------------------------------------------------------- 78th IETF Maastricht, Netherlands Meeting Dates: July 25-30, 2010 Host: SIDN ----------------------------------------------------------------- IETF meetings start Monday morning and run through Friday mid-afternoon (15:15). # 2010-06-23 (Wednesday): Preliminary agenda published for comment. # 2010-06-28 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PDT (24:00 UTC). # 2010-06-28 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PDT (24:00 UTC). # 2010-07-02 (Friday): Final agenda to be published. # 2010-07-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC), upload using IETF ID Submission Tool. # 2010-07-12 (Monday): Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC), upload using IETF ID Submission Tool. # 2010-07-14 (Wednesday): Draft Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. # 2010-07-16 (Friday): Early Bird registration and payment cut-off at 17:00 PDT (24:00 UTC). # 2010-07-19 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. # 2010-07-19 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). # 2010-07-23 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local Maastricht time (08:00 PDT, 15:00 UTC). From sra@hactrn.net Thu Jun 10 08:37:40 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE513A696E for ; Thu, 10 Jun 2010 08:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-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 vRzPHK535B2X for ; Thu, 10 Jun 2010 08:37:39 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 0919E3A69E8 for ; Thu, 10 Jun 2010 08:37:39 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3DD722842B for ; Thu, 10 Jun 2010 15:37:39 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E9B6F22808 for ; Thu, 10 Jun 2010 11:37:38 -0400 (EDT) Date: Thu, 10 Jun 2010 11:37:38 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100610153738.E9B6F22808@thrintun.hactrn.net> Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 15:37:40 -0000 At Thu, 10 Jun 2010 10:25:55 +0200, Roque Gagliano wrote: > > Particularly in SEND (RFC 3971 Section 6.5) that also deals with > RFC3779 extensions, the RP configuration is done with a similar > mechanism. The only difference is that it adds the key algorithm > too....which could be also good for this document. The Base64-encoded key portion described in the second sentence of section 2 of Sam's draft is an X.509 SubjectPublicKeyInfo, which includes a key algorithm identifier. See RFC 5280. I don't think we'd gain anything from adding a second key algorithm identifier, and would prefer not to add an unnecessary error condition (if we were to duplicate the key algorithm identifier, we'd have to check that the two copies identify the same algorithm, and handle the failure case -- none of which makes any progress towards our real goal). From robert@ripe.net Thu Jun 10 10:48:08 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4780228C10D for ; Thu, 10 Jun 2010 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9PeUHc+9VOj1 for ; Thu, 10 Jun 2010 10:48:07 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id D9FD03A6917 for ; Thu, 10 Jun 2010 10:48:06 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OMlrF-00051X-Ru for sidr@ietf.org; Thu, 10 Jun 2010 19:48:07 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=Kistel-Mac.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OMlrF-0002uF-Ji for sidr@ietf.org; Thu, 10 Jun 2010 19:48:01 +0200 Message-ID: <4C112550.3030806@ripe.net> Date: Thu, 10 Jun 2010 10:48:00 -0700 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2746d55eb9d9dd7a68500cd3c03f28ec352 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2746d55eb9d9dd7a68500cd3c03f28ec352 Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:48:08 -0000 On 2010.06.06. 21:21, Samuel Weiler wrote: > I just submitted an i-d documenting a much simpler trust anchor format > than the one in the current WG draft. Like the format in the WG doc, > this one allows for a long-lived trust anchor even though the unlying > certificate changes more often, e.g. when new resources are added. This > format has the advantage of being noticeably simpler. > > I encourage the WG to adopt this format in place of the one in the > current WG doc. > > -- Sam > My friend grep tells me I should support the adoption of this document. Robert From kent@bbn.com Thu Jun 10 14:08:36 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411753A659A for ; Thu, 10 Jun 2010 14:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 P8PmDbFnTUIM for ; Thu, 10 Jun 2010 14:08:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 876783A6359 for ; Thu, 10 Jun 2010 14:08:35 -0700 (PDT) Received: from dhcp89-089-149.bbn.com ([128.89.89.149]:49179) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMozK-000PAW-CV; Thu, 10 Jun 2010 17:08:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100608194159.456BE22808@thrintun.hactrn.net> <5BC1C38D-BBAC-422E-8F3D-89FCA80185C3@apnic.net> Date: Thu, 10 Jun 2010 16:56:39 -0400 To: Roque Gagliano From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg Subject: Re: [sidr] Simpler trust anchor format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 21:08:36 -0000 At 10:25 AM +0200 6/10/10, Roque Gagliano wrote: >Steve, > >Thanks for your report. > >To summarize a little bit, we could call the mechanism in this draft >"Simple Relaying Party Trust Anchor configuration", but not the TA >material itself. "relying" vs. "relaying" > >Particularly in SEND (RFC 3971 Section 6.5) that also deals with >RFC3779 extensions, the RP configuration is done with a similar >mechanism. The only difference is that it adds the key algorithm >too....which could be also good for this document. The subject public key info format that this I-D calls for contains the alg ID, so I thik we're good on that count. Steve From kent@bbn.com Fri Jun 11 15:10:32 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61FC128C0ED for ; Fri, 11 Jun 2010 15:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 6rc-UXHJpvF7 for ; Fri, 11 Jun 2010 15:10:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 399893A67EE for ; Fri, 11 Jun 2010 15:10:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54309 helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONCQp-000ChZ-FN for sidr@ietf.org; Fri, 11 Jun 2010 18:10:31 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 18:08:23 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-935828265==_ma============" Subject: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 22:10:32 -0000 --============_-935828265==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, The design team (Roque, Sean, and I) has been working on an I-D to deal with algorithm migration (as directed by our cognizant AD, Tim). In the course of exploring ways to do this, we (at least I) became convinced that we first needed to document how to perform (non-emergency) key rollover when the algorithm suite stays constant. I view this as a very similar transition problem, and one that needs to be addressed first, to provide guidance to the algorithm migration problem. Anyway, in the course of exploring solutions we have encountered some problems with some aspects of the current RPKI design details. So, before we proceed too far, we wanted to share our perceptions of the requirements for key rollover (and algorithm migration), to make sure that there is WG agreement on the basis for this work. Also, this provides a context and rationale for some of the changes that we believe may be needed for two, current SIDR I-Ds (resource certificate profile and repository structure). The RPKI must accommodate transitions between the public keys used by CAs. Transitions of this sort are usually termed "key rollover". Planned key rollover will occur at regular intervals throughout the life of the RPKI, as each CA changes its public keys, in a non-coordinated fashion. (By non-coordinated we mean that the time at which each CA elects to change its keys is locally determined, not coordinated across the RPKI.) Moreover, because a key change might be necessitated by suspected private key compromise, one can never assume coordination of these events among all of the CAs in the RPKI. In an emergency key rollover, the old certificate is revoked and a new certificate with a new key is issued. (We do not plan to provided a detailed discussion regarding emergency key rollover in this document unless the WG requires such.) In discussing key rollover we make a few assumptions (goals?): 1. We assume that each relying party (RP) accesses the repository system in a locally-controlled fashion. The RP may employ a top-down tree walk, as suggested in the repository structure I-D, but that tree walk may be interrupted by communication problems, publication point lockout (to enable a publisher to add or remove objects in an "atomic" fashion, local processing problems, etc. As a result, an RP may skip over one or more publication points and return to them later. Moreover, an RP may suffer a partial of total loss of data from the local cache that the repository structure documents suggests each RP maintain. Thus we cannot assume that an RP visits every publication point in order, in a continuous, top-down fashion. We also cannot be certain how long it may take an RP to complete its traversal of the repository tree. Thus we must be prepared to accommodate situations in which an RP elects to process the data it has collected, even if that data is a mix of old and new retrievals. We are pursuing a strategy for key rollover (and algorithm suite migration) that minimizes the likelihood that an RP will be unable to verify data that it has retrieved from the repository, under the processing and communication assumptions noted above. 2. It is necessary for a CA to be able to rollover a key without affecting subordinate CAs, e.g., these CAs MUST NOT be required to reissue any certificates or signed objects that they manage in their directory (repository publication point). This assumption implies that only CAs are involved in key rollover: the CA requesting the rekey, and its parent. 3. In the case of algorithm migration, we expect that it will take some time for ALL CAs and ALL RPs to be prepared to generate and consume signed objects produced using a new algorithm suite. To simplify the migration, we assume that the upper tiers of the RPKI, e.g., IANA and the RIRs, will be the first to support a new algorithm suite. This assumption means that a lower tier CA will not be able to issue certificates, CRLs, and signed objects under a new algorithm suite until all of its parents have begun to do so. We want to know if this is a reasonable assumption. Because we also assume that migration will take a while (a year or more?), it will be essential a CA that has begun to use the new suite publish certificates, CRLs, and signed objects under both the old and new suites during the migration period. Given these assumptions, we have adopted an initial design in which both key rollover and algorithm suite migration entail an interval during which old and new CA certificates, CRLs, and signed objects are maintained in parallel in the repository system. For key rollover, we anticipate that this interval will be relatively brief, say 3-7 days. For algorithm suite migration we anticipate that it will be much longer, as noted above in assumption #3. One implication of this initial design is that the definition of the AIA pointer in each (non-self-signed) certificate needs to be changed. The certificate profile calls for this extension to point to the file containing the parent (CA) certificate. The problem with this definition is that it conflicts with assumption/goal #2. When a CA rekeys it is issued a new certificate, by definition. That CA will then have to reissue certificates to its subordinate CAs, under the rekeyed CA's new key. This can be done without coordinating with the subordinate CAs. However, each certificate issued by one these subordinate CAs contains an AIA extension that points back to the OLD subordinate CA certificate. That means that these subordinate CAs would have to reissue their EE and subordinate CA certificates, to incorporate a new AIA extension, and this would have to propagate down the whole RPKI hierarchy! There is a simple fix to this, i.e., make the AIA extension point to the directory in which the parent CA certificate is stored. That way, when a CA rekeys and reissues subordinate CA certificates, IF those certificates are stored in the same directory as the old certificates, the rekey event does not affect subordinate CAs, as per #2 above. Note that this approach to using the AIA extension is consistent with what PKIX mandates for other, directory environments, i.e., X.500 and LDAP. The SKI/AKI extensions, which are mandated in the RPKI, are designed to enable an RP to select the "right" CA certificate from a directory that may contain more than one certificate associated with the same CA, but containing different keys. So, the RPKI certificate profile already includes the needed extensions to enable an RP to determine which CA certificate is appropriate for a given child certificate (CA or EE). An implication of assumptions #1 and #3 is that, during a transition interval, old and new CA certificates, CRLs, and signed objects associated with a rekeying CA will co-exist. This means that there must be a way to generate file names for these entities that do not conflict. The current file name generation approach described in the repository structure I-D does not accommodate this for subordinate CA certificates. There is no problem for CRL or manifest files, because their file names are generated form the rekeying CA's public key, and that has changed, by definition. However, the files that contain subordinate CA certificates need a slightly modified naming procedure, since the public key for each of these certificates has not changed. It should be easy to modify the naming generation algorithm to call for appending a delimiter (maybe a dash?) and one digit, to allow old and new to coexist. A single digit qualifier should suffice as we don't seem to need to maintain more than that two instances of these CA certificate files. (We might make the value be a mod 2 counter?) We would like to receive feedback from the WG before we go to far with this design. Please consider the assumptions/goals described above and let us know if you agree with them, if you think they should be modified, or if you want to suggest others. Also, please consider the impact of the two changes noted above, relative to the resource certificate profile and repository structure I-D's. We have tried to explain why we believe that these changes are required, but we recognize that a number of folks have been writing code based on these I-Ds, and thus there are impacts when changes of this sort are proposed. Finally, as I noted in my comments on the repository structure I-D on 5/26, and in my review and suggested edits of that document posted a few days before, I am still wondering why we need to change the name of CA when we rekey it. This is not normally mandated in a PKI, although we are free to impose such a requirement for the RPKI if appropriate. I even generated text for the resource certificate profile to specify how to do this, using a combination of the common name and serial number attributes. (This was proposed as a way to accommodate the need to change the CA name, while retaining some part of it that might be a locally significant ID, e.g., a database key.) While I don't see a problem with performing key rollover and algorithm migration if we have to retain this requirement, I do believe that we ought to document the rationale for it. Thanks, Steve --============_-935828265==_ma============ Content-Type: text/html; charset="us-ascii" key rollover and algorithm migration
Folks,

The design team (Roque, Sean, and I) has been working on an I-D to deal with algorithm migration (as directed by our cognizant AD, Tim).  In the course of exploring ways to do this, we (at least I) became convinced that we first needed to document how to perform (non-emergency) key rollover when the algorithm suite stays constant.  I view this as a very similar transition problem, and one that needs to be addressed first, to provide guidance to the algorithm migration problem.

Anyway, in the course of exploring solutions we have encountered some problems with some aspects of the current RPKI design details. So, before we proceed too far, we wanted to share our perceptions of the requirements for key rollover (and algorithm migration), to make sure that there is WG agreement on the basis for this work.  Also, this provides a context and rationale for some of the changes that we believe may be needed for two, current SIDR I-Ds (resource certificate profile and repository structure).

The RPKI must accommodate transitions between the public keys used by CAs. Transitions of this sort are usually termed "key rollover".  Planned key rollover will occur at regular intervals throughout the life of the RPKI, as each CA changes its public keys, in a non-coordinated fashion. (By non-coordinated we mean that the time at which each CA elects to change its keys is locally determined, not coordinated across the RPKI.) Moreover, because a key change might be necessitated by suspected private key compromise, one can never assume coordination of these events among all of the CAs in the RPKI.  In an emergency key rollover, the old certificate is revoked and a new certificate with a new key is issued. (We do not plan to provided a detailed discussion regarding emergency key rollover in this document unless the WG requires such.)

In discussing key rollover we make a few assumptions (goals?):

1. We assume that each relying party (RP) accesses the repository system in a locally-controlled fashion. The RP may employ a top-down tree walk, as suggested in the repository structure I-D, but that tree walk may be interrupted by communication problems, publication point lockout (to enable a publisher to add or remove objects in an "atomic" fashion, local processing problems, etc. As a result, an RP may skip over one or more publication points and return to them later. Moreover, an RP may suffer a partial of total loss of data from the local cache that the repository structure documents suggests each RP maintain. Thus we cannot assume that an RP visits every publication point in order, in a continuous, top-down fashion. We also cannot be certain how long it may take an RP to complete its traversal of the repository tree. Thus we must be prepared to accommodate situations in which an RP elects to process the data it has collected, even if that data is a mix of old and new retrievals. We are pursuing a strategy for key rollover (and algorithm suite migration) that minimizes the likelihood that an RP will be unable to verify data that it has retrieved from the repository, under the processing and communication assumptions noted above.

2. It is necessary for a CA to be able to rollover a key without affecting subordinate CAs, e.g., these CAs MUST NOT be required to reissue any certificates or signed objects that they manage in their directory (repository publication point). This assumption implies that only CAs are involved in key rollover: the CA requesting the rekey, and its parent.

3. In the case of algorithm migration, we expect that it will take some time for ALL CAs and ALL RPs to be prepared to generate and consume signed objects produced using a new algorithm suite. To simplify the migration, we assume that the upper tiers of the RPKI, e.g., IANA and the RIRs, will be the first to support a new algorithm suite. This assumption means that a lower tier CA will not be able to issue certificates, CRLs, and signed objects under a new algorithm suite until all of its parents have begun to do so.  We want to know if this is a reasonable assumption. Because we also assume that migration will take a while (a year or more?), it will be essential a CA that has begun to use the new suite publish certificates, CRLs, and signed objects under both the old and new suites during the migration period.

Given these assumptions, we have adopted an initial design in which both key rollover and algorithm suite migration entail an interval during which old and new CA certificates, CRLs, and signed objects are maintained in parallel in the repository system.  For key rollover, we anticipate that this interval will be relatively brief, say 3-7 days. For algorithm suite migration we anticipate that it will be much longer, as noted above in assumption #3.

One implication of this initial design is that the definition of the AIA pointer in each (non-self-signed) certificate needs to be changed. The certificate profile calls for this extension to point to the file containing the parent (CA) certificate. The problem with this definition is that it conflicts with assumption/goal #2. When a CA rekeys it is issued a new certificate, by definition. That CA will then have to reissue certificates to its subordinate CAs, under the rekeyed CA's new key. This can be done without coordinating with the subordinate CAs. However, each certificate issued by one these subordinate CAs contains an AIA extension that points back to the OLD subordinate CA certificate. That means that these subordinate CAs would have to reissue their EE and subordinate CA certificates, to incorporate a new AIA extension, and this would have to propagate down the whole RPKI hierarchy! There is a simple fix to this, i.e., make the AIA extension point to the directory in which the parent CA certificate is stored. That way, when a CA rekeys and reissues subordinate CA certificates, IF those certificates are stored in the same directory as the old certificates, the rekey event does not affect subordinate CAs, as per #2 above. Note that this approach to using the AIA extension is consistent with what PKIX mandates for other, directory environments, i.e., X.500 and LDAP. The SKI/AKI extensions, which are mandated in the RPKI, are designed to enable an RP to select the "right" CA certificate from a directory that may contain more than one certificate associated with the same CA, but containing different keys. So, the RPKI certificate profile already includes the needed extensions to enable an RP to determine which CA certificate is appropriate for a given child certificate (CA or EE).

An implication of assumptions #1 and #3 is that, during a transition interval, old and new CA certificates, CRLs, and signed objects associated with a rekeying CA will co-exist. This means that there must be a way to generate file names for these entities that do not conflict.  The current file name generation approach described in the repository structure I-D does not accommodate this for subordinate CA certificates. There is no problem for CRL or manifest files, because their file names are generated form the rekeying CA's public key, and that has changed, by definition. However, the files that contain subordinate CA certificates need a slightly modified naming procedure, since the public key for each of these certificates has not changed. It should be easy to modify the naming generation algorithm to call for appending a delimiter (maybe a dash?) and one digit, to allow old and new to coexist. A single digit qualifier should suffice as we don't seem to need to maintain more than that two instances of these CA certificate files. (We might make the value be a mod 2 counter?)

We would like to receive feedback from the WG before we go to far with this design.  Please consider the assumptions/goals described above and let us know if you agree with them, if you think they should be modified, or if you want to suggest others. 

Also, please consider the impact of the two changes noted above, relative to the resource certificate profile and repository structure I-D's. We have tried to explain why we believe that these changes are required, but we recognize that a number of folks have been writing code based on these I-Ds, and thus there are impacts when changes of this sort are proposed.

Finally, as I noted in my comments on the repository structure I-D on 5/26, and in my review and suggested edits of that document posted a few days before, I am still wondering why we need to change the name of CA when we rekey it. This is not normally mandated in a PKI, although we are free to impose such a requirement for the RPKI if appropriate.  I even generated text for the resource certificate profile to specify how to do this, using a combination of the common name and serial number attributes.  (This was proposed as a way to accommodate the need to change the CA name, while retaining some part of it that might be a locally significant ID, e.g., a database key.) While I don't see a problem with performing key rollover and algorithm migration if we have to retain this requirement, I do believe that we ought to document the rationale for it.

Thanks,
Steve
--============_-935828265==_ma============-- From gih@apnic.net Fri Jun 11 16:09:37 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFF628C121 for ; Fri, 11 Jun 2010 16:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RELAY_IS_203=0.994] 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 sWJaHG7v44iy for ; Fri, 11 Jun 2010 16:09:36 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 1298428C115 for ; Fri, 11 Jun 2010 16:09:34 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DC600D58A9; Sat, 12 Jun 2010 09:09:32 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 12 Jun 2010 09:09:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1078) Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 23:09:38 -0000 On 12/06/2010, at 8:08 AM, Stephen Kent wrote: >=20 > Finally, as I noted in my comments on the repository structure I-D on = 5/26, and in my review and suggested edits of that document posted a few = days before, I am still wondering why we need to change the name of CA = when we rekey it. This is not normally mandated in a PKI, although we = are free to impose such a requirement for the RPKI if appropriate. I = even generated text for the resource certificate profile to specify how = to do this, using a combination of the common name and serial number = attributes. (This was proposed as a way to accommodate the need to = change the CA name, while retaining some part of it that might be a = locally significant ID, e.g., a database key.) While I don't see a = problem with performing key rollover and algorithm migration if we have = to retain this requirement, I do believe that we ought to document the = rationale for it. The requirement was introduced into the res-cert draft in response to a = review comment from David Cooper: 3) Section 3.9.5 states: In this profile, the scope of the CRL is specified to be all certificates issued by this CA issuer using a given key pair. The scope of a CRL MUST be all certificates issued by the issuing CA unless the CRL includes an issuingDistributionPoint extension. So, if the scope of CRLs is to be limited to certificates signed with a given key pair, then the profile must either require inclusion of the issuingDistributionPoint extension in CRLs or forbid CAs from = performing key rollover. The latter option may be implemented by having issuers change names whenever changing the key pair used to sign certificates. http://www.ietf.org/mail-archive/web/sidr/current/msg00476.html (and the = ensuing brief thread). Geoff From gih@apnic.net Fri Jun 11 16:20:43 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1CC28C156 for ; Fri, 11 Jun 2010 16:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RELAY_IS_203=0.994] 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 VQnVxnmgiOcI for ; Fri, 11 Jun 2010 16:20:43 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4D3EE28C145 for ; Fri, 11 Jun 2010 16:20:42 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C9D2BD58A9; Sat, 12 Jun 2010 09:20:43 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 12 Jun 2010 09:20:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1078) Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 23:20:43 -0000 On 12/06/2010, at 8:08 AM, Stephen Kent wrote: >=20 > Given these assumptions, we have adopted an initial design in which = both key rollover and algorithm suite migration entail an interval = during which old and new CA certificates, CRLs, and signed objects are = maintained in parallel in the repository system. For key rollover, we = anticipate that this interval will be relatively brief, say 3-7 days. = For algorithm suite migration we anticipate that it will be much longer, = as noted above in assumption #3. >=20 For algorithm suite migration this extended period of parallel operation = with an imposition of top down migration is certainly an interesting = approach. The comments in section 3 of draft-ietf-sidr-rpki-algs-01.txt = address this form of algorithm migration and cast some doubt as to the = feasibility of such an approach within the scope of conventional = operational practices when looking at the behaviour of widely = distributed data structures. If the operational impost of maintenance of = parallel structures over an extended period was considered to be too = risky in terms of ensuring a requirement for precise coherence between = the multiple structures and ensuring identical outcomes for every = relying party , are there alternative approaches that mitigate some of = these risks? >=20 > We would like to receive feedback from the WG before we go to far with = this design. Please consider the assumptions/goals described above and = let us know if you agree with them, if you think they should be = modified, or if you want to suggest others.=20 At this point, I do not agree with the approach you describe here, given = the considerations summarized above. It appears to describe a path of = high complexity and high risk of chaotic outcomes. Geoff From kent@bbn.com Sun Jun 13 07:15:39 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0B33A657C for ; Sun, 13 Jun 2010 07:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=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 axneUSfwNOxX for ; Sun, 13 Jun 2010 07:15:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C6A0B3A6977 for ; Sun, 13 Jun 2010 07:15:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41379 helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONnyP-00029v-DS; Sun, 13 Jun 2010 10:15:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 13 Jun 2010 10:14:53 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 14:15:39 -0000 At 9:09 AM +1000 6/12/10, Geoff Huston wrote: >O... > >The requirement was introduced into the res-cert draft in response >to a review comment from David Cooper: > >3) Section 3.9.5 states: > > In this profile, the scope of the CRL is specified to be all > certificates issued by this CA issuer using a given key pair. > > The scope of a CRL MUST be all certificates issued by the issuing CA > unless the CRL includes an issuingDistributionPoint extension. So, if > the scope of CRLs is to be limited to certificates signed with a given > key pair, then the profile must either require inclusion of the > issuingDistributionPoint extension in CRLs or forbid CAs from performing > key rollover. The latter option may be implemented by having issuers > change names whenever changing the key pair used to sign certificates. > >http://www.ietf.org/mail-archive/web/sidr/current/msg00476.html (and >the ensuing brief thread). > >Geoff Geoff, Thanks for the explanation. David suggested two solutions to the problem, and you chose to mandate changing the CA name rather than adding the IDP extension into the CRL. The ensuring brief thread, that I just (quickly) reviewed, entailed message exchanges between only you and David, and involved clarifying discussion about how one could use the iDP extension to qualify the scope of a CRL when rekeying. (It also included a confusing excursion into revocation reason codes, and a discussion of appropriate key lengths to match hash algs. That latter discussion may have been unduly biased by some NIST guidance that focuses on long term sigs vs. certs, but ...) I'd just like to make sure that, that the WG still agrees that this is the preferred solution. If so, we can accommodate that in the key/alg rollover document, and note the rationale. I do think the rationale also should appear in the repository structure document as well, maybe the resource cert profile too. It would take only a short paragraph to do so. Steve From kent@bbn.com Sun Jun 13 07:15:40 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088303A657C for ; Sun, 13 Jun 2010 07:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=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 Xz-rhin6tDcu for ; Sun, 13 Jun 2010 07:15:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 31F633A69A1 for ; Sun, 13 Jun 2010 07:15:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41379 helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONnyQ-00029v-3C; Sun, 13 Jun 2010 10:15:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 13 Jun 2010 10:15:37 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 14:15:40 -0000 At 9:20 AM +1000 6/12/10, Geoff Huston wrote: >On 12/06/2010, at 8:08 AM, Stephen Kent wrote: > >> >> Given these assumptions, we have adopted an initial design in >>which both key rollover and algorithm suite migration entail an >>interval during which old and new CA certificates, CRLs, and signed >>objects are maintained in parallel in the repository system. For >>key rollover, we anticipate that this interval will be relatively >>brief, say 3-7 days. For algorithm suite migration we anticipate >>that it will be much longer, as noted above in assumption #3. >> > >For algorithm suite migration this extended period of parallel >operation with an imposition of top down migration is certainly an >interesting approach. The comments in section 3 of >draft-ietf-sidr-rpki-algs-01.txt address this form of algorithm >migration and cast some doubt as to the feasibility of such an >approach within the scope of conventional operational practices when >looking at the behaviour of widely distributed data structures. Can you elaborate on this concern? >If the operational impost of maintenance of parallel structures over >an extended period was considered to be too risky in terms of >ensuring a requirement for precise coherence between the multiple >structures and ensuring identical outcomes for every relying party , >are there alternative approaches that mitigate some of these risks? I initially investigated an approach that allows a CA at any point in the hierarchy to begin using the next alg suite, subject only to the constraint that the CA's parent is prepared to effect PoP with the new alg suite when issuing a cert to that CA. However, this approach seems to result in much greater complexity than a top-down approach. Steve From kent@bbn.com Mon Jun 14 08:19:13 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AF53A69AC for ; Mon, 14 Jun 2010 08:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=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 EwwMVl5dvPKw for ; Mon, 14 Jun 2010 08:19:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9593928C0EB for ; Mon, 14 Jun 2010 08:19:12 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49160) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOBRT-0006Iq-Kd; Mon, 14 Jun 2010 11:19:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Jun 2010 11:19:10 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 15:19:13 -0000 Geoff, Thnaks for the speedy reply. As I noted, if the WG is still comfortable with the name-change approach to key rollover, I am not opposed, and I don't see it causing problems for key rollover (or alg migration) approaches that we're developing. I'm not sure that the issuing CDP is a bad option. Each resource cert already contains a CRLDP extension, pointing to the CRL on which the cert will appear if it is revoked. If one put the same URI into the CRL, in the Issuing distribution point extension, that would seem to allow an easy check to ensure that the CRL being checked it the right one for the cert in question. (That's the reason the CRL IDP extension exists.) I'll ask David Cooper, Tim, and Russ for their perspectives on this. My view is that not having to change the CA name each time the CA rekeys is simpler, and if we can remove the serial number attribute feature that we added to compensate for the name change, I think that would be preferable as well. Upon further reflection I agree with you that the res cert profile is probably the best place to document the decision, if we elect to keep the name change procedure. We also would need to document the use of the CRL IDP extension, and explain the rationale for its use here, if we elect to go that way. Steve From sra@hactrn.net Mon Jun 14 08:22:03 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF6C3A69C1 for ; Mon, 14 Jun 2010 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, NO_RELAYS=-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 mBXdAu6aLeMC for ; Mon, 14 Jun 2010 08:22:02 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 666AD3A69DA for ; Mon, 14 Jun 2010 08:22:02 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id AC0432845E for ; Mon, 14 Jun 2010 15:22:02 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 621B922808 for ; Mon, 14 Jun 2010 11:22:02 -0400 (EDT) Date: Mon, 14 Jun 2010 11:22:02 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100614152202.621B922808@thrintun.hactrn.net> Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 15:22:04 -0000 I need to read this thread a couple more times before I'll be sure I really understand all the questions Steve is asking, but one particular paragraph leapt out at me: At Fri, 11 Jun 2010 18:08:23 -0400, Steve Kent wrote: > ... > One implication of this initial design is that the definition of the > AIA pointer in each (non-self-signed) certificate needs to be > changed. The certificate profile calls for this extension to point to > the file containing the parent (CA) certificate. The problem with > this definition is that it conflicts with assumption/goal #2. When a > CA rekeys it is issued a new certificate, by definition. That CA will > then have to reissue certificates to its subordinate CAs, under the > rekeyed CA's new key. This can be done without coordinating with the > subordinate CAs. However, each certificate issued by one these > subordinate CAs contains an AIA extension that points back to the OLD > subordinate CA certificate. That means that these subordinate CAs > would have to reissue their EE and subordinate CA certificates, to > incorporate a new AIA extension, and this would have to propagate > down the whole RPKI hierarchy! There is a simple fix to this, i.e., > make the AIA extension point to the directory in which the parent CA > certificate is stored. That way, when a CA rekeys and reissues > subordinate CA certificates, IF those certificates are stored in the > same directory as the old certificates, the rekey event does not > affect subordinate CAs, as per #2 above. Note that this approach to > using the AIA extension is consistent with what PKIX mandates for > other, directory environments, i.e., X.500 and LDAP. The SKI/AKI > extensions, which are mandated in the RPKI, are designed to enable an > RP to select the "right" CA certificate from a directory that may > contain more than one certificate associated with the same CA, but > containing different keys. So, the RPKI certificate profile already > includes the needed extensions to enable an RP to determine which CA > certificate is appropriate for a given child certificate (CA or EE). I see some issues lurking here: 1) Our use of the AIA pointer has always been a little weak. At least in my validation code, which always runs top-down, the AIA pointer serves largely as a sanity check or source of gratuitous errors, depending on one's point of view. That is: I check whether the AIA pointer matches up with the parent, per the res-certs profile; if it doesn't, the child fails validation, which might be good or might be bad depending on why the AIA pointer doesn't match. Our use of the AIA pointer has always been problematic for things like Steve's local trust anchor proposal. 2) I don't think that just redefining the AIA pointer to point to the directory will work, due to approximately the same problem that caused us to add manifests to the SIA extension. The situation is different here, though, because pretty much by definition the child doesn't know the set of parents signing it would be (forgive the imprecise language, Steve) so it couldn't generate a manifest if it wanted to do so. So I think that this approach would leave us potentially vulnerable to drop-out and replay problems. More generally, I'm not sure I believe the model you're using here. We've been doing rekey operations with my software for years now, and it seems to work, without needing to change the AIA definition. We handle it by reissuing one level down, to fix the AIA pointers. One doesn't have to reissue further down, unless there are other changes. Essentially what happens is that one ends up in a transient state with two (or more) paths down to the same certificate, one of which validates and one of which doesn't, depending on exactly which updated objects the RP has managed to retrieve at any given moment. So one does the usual cycle of publishing new stuff, waiting a while for it to propagate, then cleaning up the old stuff. We ended up making the "wait for it to propagate" a manual control, ie, publishing the new stuff and cleaning up the old stuff are two separate operations and the time between them is controlled by the operator, not the software, because we didn't think there's a one-size-fits-all answer to how long to wait. So (a) I'm not sure I agree with the problem as stated, but (b) we might just want to get rid of the AIA pointer anyway, or at least make it purely advisory (not a res-certs profile conformance violation if the AIA pointer is whacked). Not sure yet. Maybe both :). But maybe I'm missing something, I'm only on my second cup of tea. From Sandra.Murphy@cobham.com Mon Jun 14 10:27:03 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7B13A6977 for ; Mon, 14 Jun 2010 10:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_50=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 evi1lQ+LX25u for ; Mon, 14 Jun 2010 10:27:02 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B7C873A68CC for ; Mon, 14 Jun 2010 10:27:02 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5EHR5mw029745 for ; Mon, 14 Jun 2010 12:27:05 -0500 Received: from ELECTRONVILLE.boston.ads.sparta.com ([157.185.20.250]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5EHR4Vv010130 for ; Mon, 14 Jun 2010 12:27:05 -0500 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by ELECTRONVILLE.boston.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 13:27:04 -0400 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 13:25:24 -0400 Date: Mon, 14 Jun 2010 13:25:22 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Jun 2010 17:25:24.0447 (UTC) FILETIME=[92DC0EF0:01CB0BE6] Subject: Re: [sidr] Consensus calls X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:27:04 -0000 There has been too little discussion of this to say that there is any consensus of the wg. So Matt's choice of direction stands. --Sandy, speaking as wg chair On Wed, 12 May 2010, Sandra Murphy wrote: > > Matt Lepinski requested that the wg chairs judge consensus on the following > topics. Both topics were discussed in the sidr IETF 77 meeting, but > consensus was not clear at the time. > > Please send your thoughts on the following to the list so that the wg chairs > can give guidance on the drafts to the author. > > --Sandy, speaking as wg chair > > > ---------- Forwarded message ---------- > From: Matt Lepinski > To: Sandra Murphy , Chris Morrow > Subject: Request to Chairs for Concensus Calls > > There are two issues which I brought up at the meeting, for which I would > like to determine if the working group has achieved concensus. > > First [arch]: Scope of the architecture document. Following two choices: > > A) The architecture document covers only the RPKI with no discussion of > applications. It describes behaivor for entities that want to be a part of > the RPKI, but is silent on how relying parties use this data > (this requires only minor revisions to the current document) > > B) The architecture document expands to include some discussion of origin > validation in a partial deployment setting > (this requires more significant changes to the current document, and will > create a normative dependency on roa-validation) > > At the meeting we heard views on both sides. I believe that Sam was the only > vocal proponent of (B). I believe that Rob A, Geoff, Danny and Ruediger were > proponents of (A). > > > Second [roa-format]: Cautionary text in the document > > A) I put some "make-before-break" cautionary text in the security > considerations of the ROA Format document. (Similar text will remain in the > architecture documnet ... and could potentially be put in other places as > well.) > > B) The ROA Format document is the wrong place for such text, since ROA format > only talks about things within the ROA wrapper ... and the > "make-before-break" issue is actually larger since it applies not just to > ROAs but also to resource certificates higher up the chain. > > Note: The cautionary text will stay in architecture regardless (and indeed I > think I can even improve that text in light of the discussions at the > meeting). It's possible that such warning text could [additionally] be > reasonably put in the security considerations of ROA-Validation and/or > Rescert profile. > > I heard a lot of opinions during the meeting. However, I'm not convinced that > anyone feels strongly enough about this issue to justify holding up this > document for prolonged discussion. > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From turners@ieca.com Mon Jun 14 12:08:38 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522363A68D3 for ; Mon, 14 Jun 2010 12:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 lXf7t5C8OL2B for ; Mon, 14 Jun 2010 12:08:37 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id 624FA3A68CC for ; Mon, 14 Jun 2010 12:08:37 -0700 (PDT) Received: (qmail 22586 invoked from network); 14 Jun 2010 19:08:39 -0000 Received: from thunderfish.local (turners@96.231.121.108 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 14 Jun 2010 12:08:39 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: VZeKc5YVM1lv_Aab_btUl34mpJD0AJ0lC_8GWiwLbLxQRGI_2QVvLoJIT5UqEa8fwPBh04wUT05_26QskB2f520nn0LcMfC.Jy0aTfxUezf0FruWA7jPDTiOfGH9Kv6UwgAPd_cSTKrZiBN05KNoQ8XNP.EqRJvxkfY2x5D.GEsMuxMmlbKPB77VVYZnJn28kKuYrZOpGE3nUaGaC_si5i4yBnKoV50HpNGhA._pJueIL12ZJr3Xl7SovWJUHfa7Mu3RD2jcCZ3haMoX0EhQ5bAghD7OhNLW8UeBx7gnUmOqRApkP8SxtbY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C167E36.2040305@ieca.com> Date: Mon, 14 Jun 2010 15:08:38 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: gih@apnic.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: [sidr] Question about draft-ietf-sidr-rpki-algs migration text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 19:08:38 -0000 Geoff, In the rpki-algs document there's a note in section 3 that talks about algorithm agility. Part of it copied below: The alternate approach, of allowing multiple signature algorithms in the RPKI certificate profile, and in the specification of CMS signatures as used in manifests, ROAS, other signed objects, and in the provisioning protocol, allows for algorithm transition to occur within a single RPKI framework, and allows for individual CAs to commence use of multiple algorithms in a piecemeal fashion without reliance on the algorithm transition of the immediate superior CA and without a forced synchronisation of algorithm transition with subordinate CAs. In the light of this consideration, this document recommends the comprehensive revision of the existing RPKI specification and architecture documents to include provision for multiple signatures with multiple algorithms in order to support an orderly transition to longer key sizes and to other signature algorithms in the RPKI. Question: Is the first sentence suggesting that the certificates should have two signatures applied? I.e., do you consider a certificate to be an "other signed object." spt From kent@bbn.com Mon Jun 14 14:16:28 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E4C3A6933 for ; Mon, 14 Jun 2010 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, HTML_MESSAGE=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 Tx+jfI4nu1Ja for ; Mon, 14 Jun 2010 14:16:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2E0523A691D for ; Mon, 14 Jun 2010 14:16:27 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49190) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOH1C-000CF2-Fy; Mon, 14 Jun 2010 17:16:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Jun 2010 16:07:10 -0400 To: "George, Wes E IV [NTK]" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-935572306==_ma============" Cc: "sidr@ietf.org" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 21:16:28 -0000 --============_-935572306==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:45 AM -0500 6/14/10, George, Wes E IV [NTK] wrote: > >... (We do not plan to provided a detailed discussion regarding >emergency key rollover in this document unless the WG requires such.) >[[WEG]] I think that depends on your definition of "detailed" as to >whether I'm ok with that. Is that one sentence the sum total of your >planned discussion, or are you going to expand it somewhat? I envision saying only that an emergency key rollover requires immediate revocation of the old CA cert and issuance of a new one, and thus there is may be no overlap period (unless the emergency rekey takes place during a planned rollover). > Depending on the order of the final document, you may need to >explain the difference in general terms - the idea of immediate >revocation as a difference won't be obvious if you haven't yet >discussed old and new key existing in parallel for some period of >time as in a scheduled roll. good point. >Also, either way I think you need to discuss what immediate >revocation means in terms of the behavior of the system. You imply >that it's virtually a requirement to have an overlap period since >there is no coordinated change, so I think you need to discuss at >least in general terms what happens if you forego the overlap period >with an immediate revocation, and how to mitigate any issues that >arise from that, even if it's to recommend that emergency rolls >require some means of coordination to minimize their impact. another good point. I can see that we probably will need a few paragraphs to address your comments. > And yes, I realize that coordination, especially on an emergency >timeline may be impossible, so it may be up to the community to look >at the potential impact and say, "go back to the drawing board" or >accept it as-is and hope that there is never an emergency. OK. Steve --============_-935572306==_ma============ Content-Type: text/html; charset="us-ascii" RE: [sidr] key rollover and algorithm migration
At 8:45 AM -0500 6/14/10, George, Wes E IV [NTK] wrote:
 
... (We do not plan to provided a detailed discussion regarding emergency key rollover in this document unless the WG requires such.)
[[WEG]] I think that depends on your definition of "detailed" as to whether I'm ok with that. Is that one sentence the sum total of your planned discussion, or are you going to expand it somewhat?

I envision saying only that an emergency key rollover requires immediate revocation of the old CA cert and issuance of a new one, and thus there is may be no overlap period (unless the emergency rekey takes place during a planned rollover).

 Depending on the order of the final document, you may need to explain the difference in general terms - the idea of immediate revocation as a difference won't be obvious if you haven't yet discussed old and new key existing in parallel for some period of time as in a scheduled roll.

good point.
Also, either way I think you need to discuss what immediate revocation means in terms of the behavior of the system. You imply that it's virtually a requirement to have an overlap period since there is no coordinated change, so I think you need to discuss at least in general terms what happens if you forego the overlap period with an immediate revocation, and how to mitigate any issues that arise from that, even if it's to recommend that emergency rolls require some means of coordination to minimize their impact.

another good point. I can see that we probably will need a few paragraphs to address your comments.

 And yes, I realize that coordination, especially on an emergency timeline may be impossible, so it may be up to the community to look at the potential impact and say, "go back to the drawing board" or accept it as-is and hope that there is never an emergency.

OK.

Steve
--============_-935572306==_ma============-- From turners@ieca.com Mon Jun 14 14:41:16 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD1B3A6946 for ; Mon, 14 Jun 2010 14:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_50=0.001, 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 I5K9Ume8aio4 for ; Mon, 14 Jun 2010 14:41:12 -0700 (PDT) Received: from smtp113.biz.mail.mud.yahoo.com (smtp113.biz.mail.mud.yahoo.com [209.191.68.78]) by core3.amsl.com (Postfix) with SMTP id 3C3993A69A4 for ; Mon, 14 Jun 2010 14:41:09 -0700 (PDT) Received: (qmail 54441 invoked from network); 14 Jun 2010 21:41:01 -0000 Received: from thunderfish.local (turners@96.231.121.108 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 14 Jun 2010 14:41:01 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: wCcZz48VM1k9phtIsleecDbrzVRUttgcjE6w6UOQGhXfCkJtQL4t1HIpsCaLGAd3Z9A8Zi.gQo..t_ncvLQ81LH8K3IInsXEJeKreOo9AbhMf0Mc_xuFGr68gR7m4s0hujRQTNW.fgfyjWkTKSJOj8n92FwQuY9B0LFZnR6aRE6tStoLfkYFLsnc1_3swYdrEn3V3rOqUZ83g8p8ilQkHN2bKVSDayFMQTOwir1oqRteH4ug8TSs6NR9.3DN7Ha.rlPvdSrHmXx2giaapCQI48bvax7cbdEUmLKORkFikiQQNURtVYAdKhQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C16A1EC.407@ieca.com> Date: Mon, 14 Jun 2010 17:41:00 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Geoff Huston References: <4C167E36.2040305@ieca.com> <40A6C79E-A125-470A-AF81-AD49ED109218@apnic.net> In-Reply-To: <40A6C79E-A125-470A-AF81-AD49ED109218@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Question about draft-ietf-sidr-rpki-algs migration text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 21:41:16 -0000 Geoff Huston wrote: > On 15/06/2010, at 5:08 AM, Sean Turner wrote: > >> Geoff, >> >> In the rpki-algs document there's a note in section 3 that talks about algorithm agility. Part of it copied below: >> >> The alternate approach, of allowing >> multiple signature algorithms in the RPKI certificate profile, and in >> the specification of CMS signatures as used in manifests, ROAS, other >> signed objects, and in the provisioning protocol, allows for >> algorithm transition to occur within a single RPKI framework, and >> allows for individual CAs to commence use of multiple algorithms in a >> piecemeal fashion without reliance on the algorithm transition of the >> immediate superior CA and without a forced synchronisation of >> algorithm transition with subordinate CAs. In the light of this >> consideration, this document recommends the comprehensive revision of >> the existing RPKI specification and architecture documents to include >> provision for multiple signatures with multiple algorithms in order >> to support an orderly transition to longer key sizes and to other >> signature algorithms in the RPKI. >> >> Question: Is the first sentence suggesting that the certificates should have two signatures applied? I.e., do you consider a certificate to be an "other signed object." > > nope! (although its an interesting idea, I was assuming that RFC5280 was more or less cast in concrete rather than plasticine.) This is good news ;) There's one place to put a signature value and it's a single valued field. spt > I was referring in that text to signed objects and the use of CMS and the option in CMS for multiple signatures, and I was advocating consideration of an approach that used a single collection of such signed objects. I'm sorry if the words are less than clear. Perhaps they should be removed in the next iteration of this draft in any case. > > Geoff > > > > > > From Sandra.Murphy@cobham.com Mon Jun 14 15:08:05 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05563A69A4 for ; Mon, 14 Jun 2010 15:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_20=-0.74] 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 uaeBPjFw0vGb for ; Mon, 14 Jun 2010 15:08:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A3FF33A68DF for ; Mon, 14 Jun 2010 15:08:04 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5EM8490002605; Mon, 14 Jun 2010 17:08:04 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5EM843w003117; Mon, 14 Jun 2010 17:08:04 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 18:07:05 -0400 Date: Mon, 14 Jun 2010 18:07:04 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Jun 2010 22:07:05.0384 (UTC) FILETIME=[EC9A6280:01CB0C0D] Cc: sidr@ietf.org Subject: Re: [sidr] Consensus calls X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 22:08:05 -0000 Sorry not to be clear. In the absence of consensus in the wg, Matt gets to make the choice. Clearer? --Sandy, speaking as wg chair On Tue, 15 Jun 2010, Geoff Huston wrote: > Wg Chair: > > That would be fine if the note you quoted included a choice of direction. I see no such choice, and instead I see the careful use of a neutral stance on the part of the note's author. So what exactly is the guidance being given here? > > Geoff > > > On 15/06/2010, at 3:25 AM, Sandra Murphy wrote: > >> There has been too little discussion of this to say that there is any consensus of the wg. >> >> So Matt's choice of direction stands. >> >> --Sandy, speaking as wg chair >> >> On Wed, 12 May 2010, Sandra Murphy wrote: >> >>> >>> Matt Lepinski requested that the wg chairs judge consensus on the following topics. Both topics were discussed in the sidr IETF 77 meeting, but consensus was not clear at the time. >>> >>> Please send your thoughts on the following to the list so that the wg chairs can give guidance on the drafts to the author. >>> >>> --Sandy, speaking as wg chair >>> >>> >>> ---------- Forwarded message ---------- >>> From: Matt Lepinski >>> To: Sandra Murphy , Chris Morrow >>> Subject: Request to Chairs for Concensus Calls >>> >>> There are two issues which I brought up at the meeting, for which I would like to determine if the working group has achieved concensus. >>> >>> First [arch]: Scope of the architecture document. Following two choices: >>> >>> A) The architecture document covers only the RPKI with no discussion of applications. It describes behaivor for entities that want to be a part of the RPKI, but is silent on how relying parties use this data >>> (this requires only minor revisions to the current document) >>> >>> B) The architecture document expands to include some discussion of origin validation in a partial deployment setting >>> (this requires more significant changes to the current document, and will create a normative dependency on roa-validation) >>> >>> At the meeting we heard views on both sides. I believe that Sam was the only vocal proponent of (B). I believe that Rob A, Geoff, Danny and Ruediger were proponents of (A). >>> >>> >>> Second [roa-format]: Cautionary text in the document >>> >>> A) I put some "make-before-break" cautionary text in the security considerations of the ROA Format document. (Similar text will remain in the architecture documnet ... and could potentially be put in other places as well.) >>> >>> B) The ROA Format document is the wrong place for such text, since ROA format only talks about things within the ROA wrapper ... and the "make-before-break" issue is actually larger since it applies not just to ROAs but also to resource certificates higher up the chain. >>> >>> Note: The cautionary text will stay in architecture regardless (and indeed I think I can even improve that text in light of the discussions at the meeting). It's possible that such warning text could [additionally] be reasonably put in the security considerations of ROA-Validation and/or Rescert profile. >>> >>> I heard a lot of opinions during the meeting. However, I'm not convinced that anyone feels strongly enough about this issue to justify holding up this document for prolonged discussion. >>> >>> >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > From gihsidr@gmail.com Mon Jun 14 23:16:20 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9623A686A for ; Mon, 14 Jun 2010 23:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Rt4-HV078e2X for ; Mon, 14 Jun 2010 23:16:19 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6B5113A684A for ; Mon, 14 Jun 2010 23:16:19 -0700 (PDT) Received: by pwi8 with SMTP id 8so3559710pwi.31 for ; Mon, 14 Jun 2010 23:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=F/nv819+j0V3houefk3ZXu7CKPvMqQeTtloPbpgVrzk=; b=IxXsQeFVTt37vNaZZiIlum5jkBotibQp/aXGTRk+EFee6VI9yxeszDKkO/evSYPiQ6 f9yBppx1RTq2qNnqd3/kxA4BdNsHoWY/LrV31VQaVT2mOuhrHxVzPpPs9zFb8Zxnv3Xw jVHGDNWVXsErKt1oq4/yn1ZErDjmk6PHRBJbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=G4Pt+WOljwCOTjyd1Uv93OnHQhNwUIMJX9dmBfP7XJO21RN9Gb0Z6g6E7ddXILTqxx PvcRoS9NKZ8l4jkT9sbuEHzCs1JSKiQWPHzJynFjFTCE4i7EODtAY7mtQN7hYtTYRlId zldnwluVUCqWVRJwh4Li9Ids6aCXUYntRiXRY= Received: by 10.140.57.5 with SMTP id f5mr5366493rva.173.1276582580803; Mon, 14 Jun 2010 23:16:20 -0700 (PDT) Received: from dhcp205.potaroo.net (220-253-186-110.NSW.netspace.net.au [220.253.186.110]) by mx.google.com with ESMTPS id o38sm5488186rvp.2.2010.06.14.23.16.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 23:16:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Geoff Huston - SIDR In-Reply-To: Date: Tue, 15 Jun 2010 16:16:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2C59EB86-3607-4E81-A702-50766D17EAE0@gmail.com> References: To: sidr wg X-Mailer: Apple Mail (2.1078) Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 08:31:30 -0000 My second response to Steve Kent, also sent to the sidr WG 24 hours ago, = does not appear to be in the WG mailing list archive either. Let met try once more to send this to the sidr wg. Geoff -------------------------- On 14/06/2010, at 12:15 AM, Stephen Kent wrote: > At 9:20 AM +1000 6/12/10, Geoff Huston wrote: >> On 12/06/2010, at 8:08 AM, Stephen Kent wrote: >>=20 >>>=20 >>> Given these assumptions, we have adopted an initial design in which = both key rollover and algorithm suite migration entail an interval = during which old and new CA certificates, CRLs, and signed objects are = maintained in parallel in the repository system. For key rollover, we = anticipate that this interval will be relatively brief, say 3-7 days. = For algorithm suite migration we anticipate that it will be much longer, = as noted above in assumption #3. >>>=20 >>=20 >> For algorithm suite migration this extended period of parallel = operation with an imposition of top down migration is certainly an = interesting approach. The comments in section 3 of = draft-ietf-sidr-rpki-algs-01.txt address this form of algorithm = migration and cast some doubt as to the feasibility of such an approach = within the scope of conventional operational practices when looking at = the behaviour of widely distributed data structures. >=20 > Can you elaborate on this concern? >=20 >> If the operational impost of maintenance of parallel structures over = an extended period was considered to be too risky in terms of ensuring a = requirement for precise coherence between the multiple structures and = ensuring identical outcomes for every relying party , are there = alternative approaches that mitigate some of these risks? >=20 > I initially investigated an approach that allows a CA at any point in = the hierarchy to begin using the next alg suite, subject only to the = constraint that the CA's parent is prepared to effect PoP with the new = alg suite when issuing a cert to that CA. However, this approach seems = to result in much greater complexity than a top-down approach. As a general comment, I have doubts about any high degree of isomorphism = between key rollover and algorithm migration, and consequently I wonder = if the proposed approach of attempting to use a single document is = creating a artificial incentive to define a single approach when in fact = they are operationally quite distinct functions and may justifiably be = efficiently addressed by distinct algorithms. If that is indeed the case = that the most operationally effective and efficient procedures are quite = distinct then the rationale to describe these procedures in a single = document would appear to me to pretty much entirely unconvincing. With respect to a CA performing a key rollover, as I understand it, a = key rollover is intended to be a local operation performed by a CA. = While there is a forced impact on the CA's immediate parent in terms of = issuing a new certificate, the intent of the key rollover procedure was, = I thought, to limit the impact on the CA's subordinates. An algorithm = migration is a collective procedure where, as I understand it, there is = the desire to head to an end state where all parties, CAs, EEs, and = Relying Parties have migrated to exclusive use of the "new" algorithm, = and the issue here is to define a procedure for collective action across = the entire RPKI that does not necessarily involve critical or forced = dependencies. At present the key rollover procedure is documented as = part of the "design notes" of the res-cert draft. The choice of a design = note was to delineate the standard specification component of the draft, = namely that of a standard profile of fields for certificates, CRLs and = certificate requests, from the descriptions of procedures and = constraints that were not necessarily an integral part of the standard = specification. With respect to algorithm migration migration, there is an imposed = requirement for some level of coordination of actions over an extended = period, and also a need for duplication of actions, which is not = necessarily the case in key rollover. In one form of the key rollover = algorithm (the one documented in draft-ietf-sidr-res-certs) the entity = performing the key rollover firstly requests a certificate for the new = key, while leaving the old certificate in place. The entity can then = wait for replying parties to "catch up", by giving relying parties some = time to retrieve the new certificate. After this time it is an option = for the entity to reissue the subordinate products using the new key, = and it is possible to have the old set of subordinate products be = overwritten (or replaced) with the new set. The algorithm migration = procedure cannot assume that there is some small "catch up" time after = which all relying parties can be assumed to be able to use the new = algorithm. The consequence, as I understand it, is that the entity has = to in effect operate in a mode where all actions are duplicated, once = for each algorithm. This is, in effect, specifying the construction and = operation of a parallel RPKI structure that is entirely distinct from = the "current" RPKI structure by virtue of its exclusive use of a "new" = algorithm for signature generation. The latter option, that of the = concurrent operation of parallel RPKI structures, poses some complex = issues in terms of synchronisation of actions across the set of RPKI = CAs, as well as issues of consistency and coherency in the operation of = multiple parallel RPKI frameworks, as well as the uncertainties = associated with a global determination of when any such transition can = be considered "complete". This poses some issues which to my mind are = not dissimilar to the difficulties that are being presented with the = current IPv6 transition. The notes in the draft-sidr-algs draft pointed = to the possible direction of maintained a single collection of signed = objects, and use a CMS structure of multiple signatures. while this does = not mitigate the need for multiple certificate hierarchies (one per = algorithm) it does at least address the issue of multiple distinct sets = of signed objects by collapsing these back to a single (distributed) set = of signed objects, regards, Geoff From gihsidr@gmail.com Tue Jun 15 01:35:48 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3F73A67E3 for ; Tue, 15 Jun 2010 01:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 nE7vZB3HIumw for ; Tue, 15 Jun 2010 01:35:45 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 00A3E3A67AC for ; Tue, 15 Jun 2010 01:35:44 -0700 (PDT) Received: by pvh1 with SMTP id 1so1015720pvh.31 for ; Tue, 15 Jun 2010 01:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=9flOkw7MKOGeQ9QyqyuhLTWP5WTnJM32L3dnJN/oDCM=; b=gcb0d99PpkwBlZ/jmSOI4qENdPjcWFQgub6aJVFX3UrobajIINNMmtECdnvW1q4sju vvIimC78O8RCMJhTxuk41oDjVSksV7Ex7+reJw+EVbzdQ85HWJz7iVBDEBe/nI6+WlQL YB61fSJ66Fpc8AmVHgd9jA3CGYAS8hhEcBank= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=BwPB7QWZtcKBOYHgYIR5251eJxqqdjCE1kwYuWiN9N0JnG/LBMUyQ8yBE0GPX8XB/G 77eqUOVp0WXsNw5O3JvGl+Gm05xpBs9R1il6sB7tZe+pFthOX093kblCCFyNQVye/epi hhqa/7fvlZ2MygJvY3UdS0V8zW3eBIyUVP4/8= Received: by 10.141.100.4 with SMTP id c4mr5470223rvm.240.1276590944524; Tue, 15 Jun 2010 01:35:44 -0700 (PDT) Received: from dhcp205.potaroo.net (220-253-186-110.NSW.netspace.net.au [220.253.186.110]) by mx.google.com with ESMTPS id q10sm5601447rvp.20.2010.06.15.01.35.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 01:35:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Geoff Huston - SIDR In-Reply-To: Date: Tue, 15 Jun 2010 18:35:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9C7AA06D-1B49-4B2B-9B73-B29037595A93@gmail.com> References: To: sidr wg X-Mailer: Apple Mail (2.1078) Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 08:35:48 -0000 My response to Steve Kent, sent to the SIDR WG > 24 hours ago, does not = appear to be in the WG mailing list archive. It appears that using IPv6 = to send mail to the sidr mailing list is not a good idea. The mail = appears to to have been sent to the IETF mail servers according to the = local mail log but never makes it to the mailing list on the IETF's = systems. (So much for IPv6 robustness at the IETF, if thats indeed what = has happaned!) Let met try once more to send this to the sidr wg using a different = mechanism.... Geoff Geoff -------------------------- On 14/06/2010, at 12:14 AM, Stephen Kent wrote: > At 9:09 AM +1000 6/12/10, Geoff Huston wrote: >> O... >>=20 >> The requirement was introduced into the res-cert draft in response to = a review comment from David Cooper: >>=20 >> 3) Section 3.9.5 states: >>=20 >> In this profile, the scope of the CRL is specified to be all >> certificates issued by this CA issuer using a given key pair. >>=20 >> The scope of a CRL MUST be all certificates issued by the issuing CA >> unless the CRL includes an issuingDistributionPoint extension. So, = if >> the scope of CRLs is to be limited to certificates signed with a = given >> key pair, then the profile must either require inclusion of the >> issuingDistributionPoint extension in CRLs or forbid CAs from = performing >> key rollover. The latter option may be implemented by having issuers >> change names whenever changing the key pair used to sign = certificates. >>=20 >> http://www.ietf.org/mail-archive/web/sidr/current/msg00476.html (and = the ensuing brief thread). >>=20 >> Geoff >=20 > Geoff, >=20 > Thanks for the explanation. David suggested two solutions to the = problem, and you chose to mandate changing the CA name rather than = adding the IDP extension into the CRL. This is true, although I have a recollection of consulting with some = others at the time. >=20 > The ensuring brief thread, that I just (quickly) reviewed, entailed = message exchanges between only you and David, and involved clarifying = discussion about how one could use the iDP extension to qualify the = scope of a CRL when rekeying. (It also included a confusing excursion = into revocation reason codes, and a discussion of appropriate key = lengths to match hash algs. That latter discussion may have been unduly = biased by some NIST guidance that focuses on long term sigs vs. certs, = but ...) I have not dredged up all the emails from the time, but I recall = (possibly not quite accurately) that at the time the general view was = that the alternatives involved keeping the CA constant and allowing a = CRL signed with the "new" key to revoke objects that were signed with = "older" keys, or using a regime whereby the scope of the CRL which was = limited to objects that were signed with the same private key that was = used to sign the CRL was retained, which appeared to imply the concept = of a key rollover implying a new CA. As I recall there was a marked = preference for the latter course of action as representing the least = impact on the evolving code base and an expectation that this limited = CRL scope could be of benefit in this environment of a widely = distributed PKI. Hence, the response to David's comments was to forbid = CAs from performing a key rollover and implement key rollover via the = use of change of CA. =20 >=20 > I'd just like to make sure that, that the WG still agrees that this is = the preferred solution. I agree that this is a prudent check. > If so, we can accommodate that in the key/alg rollover document, and = note the rationale. I do think the rationale also should appear in the = repository structure document as well, maybe the resource cert profile = too. It would take only a short paragraph to do so. I think it better not to succumb to the temptation to play hide and seek = with a future consumer of these documents and embed critical design = information and rationales in a whole set of documents. Its probably = also unwise to copy this information and rationale and use it in = multiple documents given the possibility of latter revision of one of = the documents but not the others, resulting in the potential for = contradiction. On that basis I would argue in favour of a position that = placed constraints on a CA and the rationale for this constraint in a = single document. It seems to me that the most logical place is the = resource certificate profile document. I do not see a convincing case to = duplicate this same rationale in the repository structure document, nor = in an algorithm migration document, based on these considerations. regards, Geoff= From kent@bbn.com Tue Jun 15 11:25:25 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846503A68B8 for ; Tue, 15 Jun 2010 11:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_50=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 Pat82E6HdVT3 for ; Tue, 15 Jun 2010 11:25:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4B7FC3A68B7 for ; Tue, 15 Jun 2010 11:25:24 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49214) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOapE-000ADX-5M; Tue, 15 Jun 2010 14:25:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100614152202.621B922808@thrintun.hactrn.net> References: <20100614152202.621B922808@thrintun.hactrn.net> Date: Tue, 15 Jun 2010 13:28:22 -0400 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 18:25:25 -0000 At 11:22 AM -0400 6/14/10, Rob Austein wrote: >... > >I see some issues lurking here: > >1) Our use of the AIA pointer has always been a little weak. At least > in my validation code, which always runs top-down, the AIA pointer > serves largely as a sanity check or source of gratuitous errors, > depending on one's point of view. That is: I check whether the AIA > pointer matches up with the parent, per the res-certs profile; if > it doesn't, the child fails validation, which might be good or > might be bad depending on why the AIA pointer doesn't match. Our > use of the AIA pointer has always been problematic for things like > Steve's local trust anchor proposal. If one always were able to do the tree traversal top down, I can see why the AIA pointer might be superfluous. But, I belive that we ought to be prepared to accommodate tree traversal that may (temporarily) skip over some directories in the process. As I suggested in my note, a directory might be inaccessible due to locking for an update, a (hopefully transient) comm error, etc. I'd rather not require RP software grind to a halt waiting for these problems to go away , as that presents a DoS vulnerability. > >2) I don't think that just redefining the AIA pointer to point to the > directory will work, due to approximately the same problem that > caused us to add manifests to the SIA extension. The situation is > different here, though, because pretty much by definition the child > doesn't know the set of parents signing it would be (forgive the > imprecise language, Steve) so it couldn't generate a manifest if it > wanted to do so. So I think that this approach would leave us > potentially vulnerable to drop-out and replay problems. I don't understand this argument. (also note that for a given cert, there is exactly one parent, not a "set" as described above. There may be more than one CA cert that can be used to validate the target cert. Is that what you referring to above?) If the AIA extension points to the directory that contains the parent CA cert(s) then there should be no problem. One can start by acquiring the directory contents. In a normal directory environment (e.g., X.500 or LDAP) one would then look at all of the certs to find the ones with a Subject name that matches the Issuer name in the target cert (the cert being validated). If there is more than one such cert, then match the AKI from the target cert against the SKI in each CA cert (with the right Subject name). The result should be a CA cert than can be used to validate the target cert. Because the RPKI has manifests, we can augment the procedure above to filter out "bad" files early in the process, and we can alert the RP is a file is missing (one the manifest but not in the directory. >More generally, I'm not sure I believe the model you're using here. >We've been doing rekey operations with my software for years now, and >it seems to work, without needing to change the AIA definition. We >handle it by reissuing one level down, to fix the AIA pointers. One >doesn't have to reissue further down, unless there are other changes. >Essentially what happens is that one ends up in a transient state with >two (or more) paths down to the same certificate, one of which >validates and one of which doesn't, depending on exactly which updated >objects the RP has managed to retrieve at any given moment. So one >does the usual cycle of publishing new stuff, waiting a while for it >to propagate, then cleaning up the old stuff. We ended up making the >"wait for it to propagate" a manual control, ie, publishing the new >stuff and cleaning up the old stuff are two separate operations and >the time between them is controlled by the operator, not the software, >because we didn't think there's a one-size-fits-all answer to how long >to wait. I agree that, in general, the model you describe is reasonable, but there are some cases in which I fear it may not work. I'll provide examples in a message I am composing in reply to one of Geoff's recent messages. >So (a) I'm not sure I agree with the problem as stated, but (b) we >might just want to get rid of the AIA pointer anyway, or at least make >it purely advisory (not a res-certs profile conformance violation if >the AIA pointer is whacked). Not sure yet. Maybe both :). I'm not comfortable killing off the AIA extension, in whatever form we agree to use. Steve From turners@ieca.com Tue Jun 15 12:14:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05CB3A6942 for ; Tue, 15 Jun 2010 12:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 kxhM-MRNZbhL for ; Tue, 15 Jun 2010 12:14:17 -0700 (PDT) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id 75E303A69D5 for ; Tue, 15 Jun 2010 12:14:17 -0700 (PDT) Received: (qmail 53891 invoked from network); 15 Jun 2010 19:14:19 -0000 Received: from thunderfish.local (turners@96.231.121.221 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 15 Jun 2010 12:14:18 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: bOtvlrcVM1kQ.YWK3v9rtB8_TznPzqUdyt_iUKTVXcQzsxwiBMAsvbGb X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C17D109.9070705@ieca.com> Date: Tue, 15 Jun 2010 15:14:17 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Rob Austein References: <20100614152202.621B922808@thrintun.hactrn.net> In-Reply-To: <20100614152202.621B922808@thrintun.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 19:14:21 -0000 Rob Austein wrote: > I need to read this thread a couple more times before I'll be sure I > really understand all the questions Steve is asking, but one > particular paragraph leapt out at me: > > At Fri, 11 Jun 2010 18:08:23 -0400, Steve Kent wrote: >> ... >> One implication of this initial design is that the definition of the >> AIA pointer in each (non-self-signed) certificate needs to be >> changed. The certificate profile calls for this extension to point to >> the file containing the parent (CA) certificate. The problem with >> this definition is that it conflicts with assumption/goal #2. When a >> CA rekeys it is issued a new certificate, by definition. That CA will >> then have to reissue certificates to its subordinate CAs, under the >> rekeyed CA's new key. This can be done without coordinating with the >> subordinate CAs. However, each certificate issued by one these >> subordinate CAs contains an AIA extension that points back to the OLD >> subordinate CA certificate. That means that these subordinate CAs >> would have to reissue their EE and subordinate CA certificates, to >> incorporate a new AIA extension, and this would have to propagate >> down the whole RPKI hierarchy! There is a simple fix to this, i.e., >> make the AIA extension point to the directory in which the parent CA >> certificate is stored. That way, when a CA rekeys and reissues >> subordinate CA certificates, IF those certificates are stored in the >> same directory as the old certificates, the rekey event does not >> affect subordinate CAs, as per #2 above. Note that this approach to >> using the AIA extension is consistent with what PKIX mandates for >> other, directory environments, i.e., X.500 and LDAP. The SKI/AKI >> extensions, which are mandated in the RPKI, are designed to enable an >> RP to select the "right" CA certificate from a directory that may >> contain more than one certificate associated with the same CA, but >> containing different keys. So, the RPKI certificate profile already >> includes the needed extensions to enable an RP to determine which CA >> certificate is appropriate for a given child certificate (CA or EE). > > I see some issues lurking here: > > 1) Our use of the AIA pointer has always been a little weak. At least > in my validation code, which always runs top-down, the AIA pointer > serves largely as a sanity check or source of gratuitous errors, > depending on one's point of view. That is: I check whether the AIA > pointer matches up with the parent, per the res-certs profile; if > it doesn't, the child fails validation, which might be good or > might be bad depending on why the AIA pointer doesn't match. Our > use of the AIA pointer has always been problematic for things like > Steve's local trust anchor proposal. Did you see something in Section 6.1 of RFC 5280 that made you think AIA should be used during path validation? If you use the id-caIssuers method in the AIA, then it is useful to locate the certificates needed to build the path, but I don't think you need to use it during path validation. There are a couple of pieces of information in the certificate that are useful for building the path but don't need to be checked during validation. I think AKI, SKI, and AIA fall in to that category. I guess you're free to add any checks you like, but if a check causes the path validation to fail that should have otherwise passed - then that's a bad thing. spt From kent@bbn.com Tue Jun 15 12:31:44 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D113A6983 for ; Tue, 15 Jun 2010 12:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599] 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 cJ6onb1+AviE for ; Tue, 15 Jun 2010 12:31:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2A2643A6986 for ; Tue, 15 Jun 2010 12:31:18 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49216) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OObr0-000Bkt-BR for sidr@ietf.org; Tue, 15 Jun 2010 15:31:22 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Jun 2010 15:30:45 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] responses to Geoff's message of 6/14 (resent on 6/15) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 19:31:45 -0000 Folks, There was a lot to discuss in Geoff's reply to my message, so I have broken my responses into 6 separate replies. Each has a different Subject line, so that we can keep discussions of different topics (key rollover, alg suite migration, and similarities and differences between the two) separate. Hopefully some of these threads will die off before others, and lessen our e-mail burden. Steve From kent@bbn.com Tue Jun 15 12:43:22 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657803A6927 for ; Tue, 15 Jun 2010 12:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_50=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 EGWcl2B9hJ9C for ; Tue, 15 Jun 2010 12:43:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 635343A6974 for ; Tue, 15 Jun 2010 12:43:21 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49231) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOc2f-000By0-DB; Tue, 15 Jun 2010 15:43:25 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Jun 2010 15:43:22 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: [sidr] key rollover and alg transition (similarities) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 19:43:22 -0000 >... > >As a general comment, I have doubts about any high degree of >isomorphism between key rollover and algorithm migration, and >consequently I wonder if the proposed approach of attempting to use >a single document is creating a artificial incentive to define a >single approach when in fact they are operationally quite distinct >functions and may justifiably be efficiently addressed by distinct >algorithms. If that is indeed the case that the most operationally >effective and efficient procedures are quite distinct then the >rationale to describe these procedures in a single document would >appear to me to pretty much entirely unconvincing. My model for key rollover assumes an interval when old and new keys (and certs) are both valid, which is a common notion in PKIs. Your key rollover discussion (Section 8 of the resource cert profile) seems to include a similar notion. You work hard to limit the number of signed products that are simultaneously represented under the old and new certs associated with a CA that is rekeying. I was thinking about a more liberal approach :-). I believe that for alg migration such an interval is absolutely required, but is just longer that for key rollover. Your comments on alg migration (Section 3 of the RPKI alg profile) seem to call for a transition interval with old and new signed products simultaneously available. You advocate a dual-signing (where feasible) approach, to limit the number of directory entries and, presumably, to make it easier for CAs to maintain synch between signed products issued under the old and new algs. So, we both seem to agree on the need for a transition interval for key rollover and alg migration, but we have slightly different notions about the details of how signed products are represented during the transition interval. To me that suggests a lot of similarity between the two processes. Steve From kent@bbn.com Tue Jun 15 12:43:24 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FD93A6972 for ; Tue, 15 Jun 2010 12:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_40=-0.185] 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 RVjcdV3Vr04x for ; Tue, 15 Jun 2010 12:43:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7CE603A6983 for ; Tue, 15 Jun 2010 12:43:23 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49231) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOc2h-000By0-D9; Tue, 15 Jun 2010 15:43:27 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Jun 2010 15:43:22 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: [sidr] key rollover as a standard (vs. a design note) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 19:43:24 -0000 > At present the key rollover procedure is documented as part of the >"design notes" of the res-cert draft. I have to admit that I never read that part of the draft, because the heading labelled it as a set of design notes and says that it is not normative. Sorry 'bout that. I strongly believe that key rollover needs to be specified in a normative fashion, so that CA operation, repository maintenance, and RP behavior is well understood and predictable by all parties. Thus I would suggest that we have a document that specifies key rollover separately, and comprehensively, whether or not it is combined with an alg migration spec. Steve From david.cooper@nist.gov Tue Jun 15 12:45:08 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB52F3A6972 for ; Tue, 15 Jun 2010 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.791 X-Spam-Level: X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[AWL=2.808, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NvOqjWuDZ+H2 for ; Tue, 15 Jun 2010 12:45:06 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id A1ED23A68D3 for ; Tue, 15 Jun 2010 12:45:05 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5FJilYn007575; Tue, 15 Jun 2010 15:44:48 -0400 Message-ID: <4C17D82F.4080105@nist.gov> Date: Tue, 15 Jun 2010 15:44:47 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Mandriva/3.0.4-0.4mdv2010.0 (2010.0) Thunderbird/3.0.4 MIME-Version: 1.0 To: Sean Turner References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> In-Reply-To: <4C17D109.9070705@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 19:45:08 -0000 Sean, The SIDR WG has defined its own certificate validation algorithm in Section 7 of draft-ietf-sidr-res-certs-18. Steps 3 and 4 in Section 7.2 require the client to check that: 3. The certificate contains all fields that MUST be present and contains field values as specified in this profile for all field values that MUST be present. 4. No field value that MUST NOT be present in this profile is present in the certificate. So, for a client to conform to draft-ietf-sidr-res-certs-18 it MUST check (for example) that certificates include a subject key identifier extension, that the extension is marked as non-critical, and that its value is the SHA-1 hash of the subject public key. A couple of years ago I pointed out that these checks were unnecessary, that RFC 5280 discourages including checks during path validation for the sole purpose of verifying that the certificates were issued in conformance with the profile, and that requiring the checks to be performed would preclude the use of off-the-shelf path validation software in the RPKI. While no one explained the reason for mandating these checks, I was told that "the requirements of steps 3 and 4 very definitely are intended to be applied" and the requirements were kept in the document. Dave On 06/15/2010 03:14 PM, Sean Turner wrote: > Did you see something in Section 6.1 of RFC 5280 that made you think > AIA should be used during path validation? If you use the > id-caIssuers method in the AIA, then it is useful to locate the > certificates needed to build the path, but I don't think you need to > use it during path validation. There are a couple of pieces of > information in the certificate that are useful for building the path > but don't need to be checked during validation. I think AKI, SKI, and > AIA fall in to that category. I guess you're free to add any checks > you like, but if a check causes the path validation to fail that > should have otherwise passed - then that's a bad thing. > From kent@bbn.com Tue Jun 15 13:00:39 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471D328B797 for ; Tue, 15 Jun 2010 13:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_50=0.001, HTML_MESSAGE=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 OrrSw+EWl2vf for ; Tue, 15 Jun 2010 13:00:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 862953A6977 for ; Tue, 15 Jun 2010 13:00:37 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49231) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOc2i-000By0-Cv; Tue, 15 Jun 2010 15:43:28 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Jun 2010 15:43:22 -0400 To: Geoff Huston From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-935491488==_ma============" Cc: sidr@ietf.org Subject: [sidr] key rollover details (long) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 20:00:39 -0000 --============_-935491488==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >The choice of a design note was to delineate the standard >specification component of the draft, namely that of a standard >profile of fields for certificates, CRLs and certificate requests, >from the descriptions of procedures and constraints that were not >necessarily an integral part of the standard specification. > >With respect to algorithm migration migration, there is an imposed >requirement for some level of coordination of actions over an >extended period, and also a need for duplication of actions, which >is not necessarily the case in key rollover. In one form of the key >rollover algorithm (the one documented in draft-ietf-sidr-res-certs) >the entity performing the key rollover firstly requests a >certificate for the new key, while leaving the old certificate in >place. The entity can then wait for replying parties to "catch up", >by giving relying parties some time to retrieve the new certificate. So, the old and current certs for the rekeying CA are simultaneously present in the directory of the parent CA at the beginning of the rollover but there are no signed products in the rekeying CA's directory, yet, right? > After this time it is an option for the entity to reissue the >subordinate products using the new key, and it is possible to have >the old set of subordinate products be overwritten (or replaced) >with the new set. The name generation convention described in the repository structure doc causes a new cert file to replace an old cert file whenever the public key in the cert remains constant. So I think the design makes replacement mandatory (vs. "possible"). Step 8 of the design note on key rollover says that the OLD CA signed products are removed at that time. But removal really happens in steps 5 & 6, because new instances of the signed products overwrite old instances (based on the name generation conventions described in the repository structure doc). I also find the text in Step 5 confusing. I agree with the notion that each subordinate CA cert has to be reissued without changing its public key, but this step says that the same rule applies to EE certs (single and multi-use?) issued by the rekeying CA. This implies that a ROA will be replaced by a new ROA that has a new EE cert, but with the same public key. That could be a nice feature in that it does not require a CA to generate a new key-pair for each ROA and re-sign the ROA. But then Step 6 seem to contradict that notion, saying that single-use EE certs and associated data structures must be resigned, using a new key pair. That's confusing to me. The repository publication point discussion introduces the notion of OLD, CURRENT, and FUTURE CAs and keys. I like that sort of state description. But, the subsequent key rollover discussion fails to refer to any CA as FUTURE. I think the text for key rollover needs to better adopt this terminology to be complete. The repository publication point also discussion says that the OLD CA will continue to publish a CRL and a manifest covering the OLD signed products. But, is also says that new signed products will be issued only under the NEW CA. I worry that this might cause problems for RPs. For example, if the rekeying CA generates a new ROA and issues it only under the new CA cert, that might cause problems for RPs that have not yet fetched the new CA cert. The document says that the CA waits a suitable interval before replacing its old signed products with new ones, issued under the new CA. The rationale is to allow enough time for all RPs to acquire the new CA cert. If the CA issues any new signed product during the interval before it replaces the old products, that seems to imply that the CA can't be confident that all RPs will have retrieved the rekeyed CA cert. Similarly, what if a child (subordinate) CA requests a rekey during this interval? The text seems to say that the new child cert would be issued only under the rekeying CA's new cert. That might pose problems for the child, who may have a different notion of how long the overlap interval should be. Then there's the case of an emergency rekey for a child. if the child wants the old cert revoked immediately and a new cert issued in its place, is it OK to issue the new cert only under the new CA key? I think I understand your overall proposal for rekeying, but I am concerned about corner cases of the sort mentioned above. The old and new certs for the rekeyed CA can overlap in the parent's directory, because they have different public keys and thus different file names. The signed products for the rekeyed CA need not overlap because RPs have been given enough time to retrieve the new CA cert before the new signed products are published, wiping out the old signed products. AN RP will not b confused by the presence of the new CA cert, because the AIA extension in each CA or EE cert points to the old CA cert. (Of course the RP is supposed to use AKI/SKI matching to find the right parent CA cert anyway. so even if the AIA extension pointed to the directory of the parent CA, the SKI/AKI matching would avoid any ambiguity.) Steve --============_-935491488==_ma============ Content-Type: text/html; charset="us-ascii" key rollover details (long)
The choice of a design note was to delineate the standard specification component of the draft, namely that of a standard profile of fields for certificates, CRLs and certificate requests, from the descriptions of procedures and constraints that were not necessarily an integral part of the standard specification.

With respect to algorithm migration migration, there is an imposed requirement for some level of coordination of actions over an extended period, and also a need for duplication of actions, which is not necessarily the case in key rollover. In one form of the key rollover algorithm (the one documented in draft-ietf-sidr-res-certs) the entity performing the key rollover firstly requests a certificate for the new key, while leaving the old certificate in place. The entity can then wait for replying parties to "catch up", by giving relying parties some time to retrieve the new certificate.

So, the old and current certs for the rekeying CA are simultaneously present in the directory of the parent CA at the beginning of the rollover but there are no signed products in the rekeying CA's directory, yet, right?

 After this time it is an option for the entity to reissue the subordinate products using the new key, and it is possible to have the old set of subordinate products be overwritten (or replaced) with the new set.

The name generation convention described in the repository structure doc causes a new cert file to replace an old cert file whenever the public key in the cert remains constant. So I think the design makes replacement mandatory (vs. "possible"). 

Step 8 of the design note on key rollover says that the OLD CA signed products are removed at that time. But removal really happens in steps 5 & 6, because new instances of the signed products overwrite old instances (based on the name generation conventions described in the repository structure doc).

I also find the text in Step 5 confusing. I agree with the notion that each subordinate CA cert has to be reissued without changing its public key, but this step says that the same rule applies to EE certs (single and multi-use?) issued by the rekeying CA. This implies that a ROA will be replaced by a new ROA that has a new EE cert, but with the same public key. That could be a nice feature in that it does not require a CA to generate a new key-pair for each ROA and re-sign the ROA. But then Step 6 seem to contradict that notion, saying that single-use EE certs and associated data structures must be resigned, using a new key pair.  That's confusing to me.

The repository publication point discussion introduces the notion of OLD, CURRENT, and FUTURE CAs and keys. I like that sort of state description. But, the subsequent key rollover discussion fails to refer to any CA as FUTURE. I think the text for key rollover needs to better adopt this terminology to be complete.

The repository publication point also discussion says that the OLD CA will continue to publish a CRL and a manifest covering the OLD signed products. But, is also says that new signed products will be issued only under the NEW CA. I worry that this might cause problems for RPs.  For example, if the rekeying CA generates a new ROA and issues it only under the new CA cert, that might cause problems for RPs that have not yet fetched the new CA cert. The document says that the CA waits a suitable interval before replacing its old signed products with new ones, issued under the new CA.  The rationale is to allow enough time for all RPs to acquire the new CA cert.  If the CA issues any new signed product during the interval before it replaces the old products, that seems to imply that the CA can't be confident that all RPs will have retrieved the rekeyed CA cert. Similarly, what if a child (subordinate) CA requests a rekey during this interval? The text seems to say that the new child cert would be issued only under the rekeying CA's new cert.  That might pose problems for the child, who may have a different notion of how long the overlap interval should be. Then there's the case of an emergency rekey for a child. if the child wants the old cert revoked immediately and a new cert issued in its place, is it OK to issue the new cert only under the new CA key?

I think I understand your overall proposal for rekeying, but I am concerned about corner cases of the sort mentioned above. The old and new certs for the rekeyed CA can overlap in the parent's directory, because they have different public keys and thus different file names.  The signed products for the rekeyed CA need not overlap because RPs have been given enough time to retrieve the new CA cert before the new signed products are published, wiping out the old signed products. AN RP will not b confused by the presence of the new CA cert, because the AIA extension in each CA or EE cert points to the old CA cert. (Of course the RP is supposed to use AKI/SKI matching to find the right parent CA cert anyway. so even if the AIA extension pointed to the directory of the parent CA, the SKI/AKI matching would avoid any ambiguity.)

Steve
--============_-935491488==_ma============-- From kent@bbn.com Tue Jun 15 13:00:39 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629CD3A6977 for ; Tue, 15 Jun 2010 13:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_50=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 xHsh3w8cW26t for ; Tue, 15 Jun 2010 13:00:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 547CC28B23E for ; Tue, 15 Jun 2010 13:00:38 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49231) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOc2j-000By0-4X; Tue, 15 Jun 2010 15:43:29 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Jun 2010 15:43:22 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: [sidr] alg migration (long) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 20:00:39 -0000 > The algorithm migration procedure cannot assume that there is some >small "catch up" time after which all relying parties can be assumed >to be able to use the new algorithm. The consequence, as I >understand it, is that the entity has to in effect operate in a mode >where all actions are duplicated, once for each algorithm. This is, >in effect, specifying the construction and operation of a parallel >RPKI structure that is entirely distinct from the "current" RPKI >structure by virtue of its exclusive use of a "new" algorithm for >signature generation. I think that is a fair characterization. >The latter option, that of the concurrent operation of parallel RPKI >structures, poses some complex issues in terms of synchronisation of >actions across the set of RPKI CAs, as well as issues of consistency >and coherency in the operation of multiple parallel RPKI frameworks, >as well as the uncertainties associated with a global determination >of when any such transition can be considered "complete". If we have an ability to lock a directory, and if we put the current and next algorithm signed products in the same directory, then I believe that the problem of consistency is manageable, on a local, per-CA basis. It certainly is manageable for RPs, under the locked directoty assumption. > This poses some issues which to my mind are not dissimilar to the >difficulties that are being presented with the current IPv6 >transition. The notes in the draft-sidr-algs draft pointed to the >possible direction of maintained a single collection of signed >objects, and use a CMS structure of multiple signatures. while this >does not mitigate the need for multiple certificate hierarchies (one >per algorithm) it does at least address the issue of multiple >distinct sets of signed objects by collapsing these back to a single >(distributed) set of signed objects, If we have dual signature ROAs and manifests, that does seem to make life easier for repository maintainers, i.e., they need not generate two versions of the same data structures and sign them separately. They do, however, have to generate two sets of keys and certs, one for each alg suite, and populate the ROAs and manifests with pairs of these EE certs. RP's incur some added complexity dealing with dual signatures and dual EE certs (single use), but I find it hard to quantify that. Also, we still need to have one CRL per alg suite, because a CRL cannot have more than one signature. So, we would have two CRLs in the same directory, both covered by the same manifest. It's not clear to me when (and for how long) a subordinate CA cert would have a doppleganger, i.e., a second cert issued under the new alg suite, but containing a key form the old alg suite. Then, when the subordinate CA is capable of issuing signed products under the new suite, would we not have old and new alg suite versions for it's CA cert, as well? I recall that you voiced concern that we might have an exponential growth in the repository tree, depending on how alg suite migration worked. I don't think it is that bad, but I can imagine a doubling or quadrupling of signed products under some scenarios. (I wonder if these scenarios provide examples where the AIA extension should point to the directory, vs. the cert file?) Amnyway, the savings in the number of directory signed products is mostly in terms of the number of ROAs, which are reduced by 1/2 if we use dual signature CMS objects. But, each of these objects is bigger that an single sig object, as it holds two EE certs and two sigs. I have not asked anyone to generate single vs. dual sig instances of a ROA, but I bet the size of one dual sig ROA is not much smaller than two, single-sig ROAs. (The cert and sig elements of the CMS blob are the biggest pieces, I believe.) So in terms of directory space and transmission volume, dual sigs may not be much of a win. Still, we may still want to consider this approach, to simplify repository maintenance. Steve From sra@hactrn.net Tue Jun 15 13:01:41 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBF03A68A7 for ; Tue, 15 Jun 2010 13:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_05=-1.11, NO_RELAYS=-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 jmSaU5QkGy8i for ; Tue, 15 Jun 2010 13:01:40 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 91B173A6977 for ; Tue, 15 Jun 2010 13:01:40 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 186F528464 for ; Tue, 15 Jun 2010 20:01:44 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C6D7B22808 for ; Tue, 15 Jun 2010 16:01:43 -0400 (EDT) Date: Tue, 15 Jun 2010 16:01:43 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4C17D109.9070705@ieca.com> References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100615200143.C6D7B22808@thrintun.hactrn.net> Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 20:01:41 -0000 At Tue, 15 Jun 2010 15:14:17 -0400, Sean P Turner wrote: > > Did you see something in Section 6.1 of RFC 5280 that made you think > AIA should be used during path validation? No. The issue is conformance to draft-ietf-sidr-res-certs, which is a tighter set of constraints than RFC 5280 or RFC 3779. One might disagree with that profile (and on this particular point regarding the AIA pointer I've been thinking that perhaps I do) but I was talking about validation within the context of that profile. From turners@ieca.com Tue Jun 15 14:09:59 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A293A697A for ; Tue, 15 Jun 2010 14:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_50=0.001, 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 lo+9aQNzZV2N for ; Tue, 15 Jun 2010 14:09:58 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id D04A43A696E for ; Tue, 15 Jun 2010 14:09:58 -0700 (PDT) Received: (qmail 22441 invoked from network); 15 Jun 2010 21:09:52 -0000 Received: from thunderfish.local (turners@96.231.121.221 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 15 Jun 2010 14:09:52 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: voR5XJIVM1k8SNMu1ylxIGpkrcbg.65hy43UBO8H56fHRFVhs8QAtfZHFxm48Gd.t2hxlyXCU2MqzmJjOxxo059Ntduvt8_L91zM19WSEJoec.jjpRNk7eOUNOOxyYie4PAY4tleIViBMU7O6SCE5iO5jtzTj_OHAPl7r7Mvj402G4m6AdUAdJ_pAouZIgK59Xyj2VBE53z1.pGHYbhvJvOV7whVbrUnpgCrmDp8Rpqm2Ky.mawnrRpoeQoNcOcePuNkzxmbhfS7i5YM.nalVe18ImqFtOdMbZzLYChqqjBexVSxcWbgspUG X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C17EC1F.7050203@ieca.com> Date: Tue, 15 Jun 2010 17:09:51 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "David A. Cooper" References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> In-Reply-To: <4C17D82F.4080105@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 21:09:59 -0000 David A. Cooper wrote: > Sean, > > The SIDR WG has defined its own certificate validation algorithm in > Section 7 of draft-ietf-sidr-res-certs-18. Steps 3 and 4 in Section 7.2 > require the client to check that: Dave, Thanks for the heads up. I'm still learning all the ins and outs of these specs. > 3. The certificate contains all fields that MUST be present and > contains field values as specified in this profile for all > field values that MUST be present. > > 4. No field value that MUST NOT be present in this profile is > present in the certificate. > > So, for a client to conform to draft-ietf-sidr-res-certs-18 it MUST > check (for example) that certificates include a subject key identifier > extension, that the extension is marked as non-critical, and that its > value is the SHA-1 hash of the subject public key. > A couple of years ago I pointed out that these checks were unnecessary, > that RFC 5280 discourages including checks during path validation for > the sole purpose of verifying that the certificates were issued in > conformance with the profile, and that requiring the checks to be > performed would preclude the use of off-the-shelf path validation > software in the RPKI. While no one explained the reason for mandating > these checks, I was told that "the requirements of steps 3 and 4 very > definitely are intended to be applied" and the requirements were kept in > the document. Are we doing these checks to slow the validation process down? ;) Like I said I don't see the need to check some of the information in the certificate during validation. I agree with you that it is unnecessary to check a few of things during path validation that are required to be in some certificates: AKI, SKI, AIA, SIA, and CRLDP. If these checks can't be explained and it's causing problems for key rollover, then maybe we should drop the checks. spt > Dave > > On 06/15/2010 03:14 PM, Sean Turner wrote: >> Did you see something in Section 6.1 of RFC 5280 that made you think >> AIA should be used during path validation? If you use the >> id-caIssuers method in the AIA, then it is useful to locate the >> certificates needed to build the path, but I don't think you need to >> use it during path validation. There are a couple of pieces of >> information in the certificate that are useful for building the path >> but don't need to be checked during validation. I think AKI, SKI, and >> AIA fall in to that category. I guess you're free to add any checks >> you like, but if a check causes the path validation to fail that >> should have otherwise passed - then that's a bad thing. >> > > From turners@ieca.com Tue Jun 15 14:11:49 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B213A697A for ; Tue, 15 Jun 2010 14:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.780, 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 LH0SyB2dyW6f for ; Tue, 15 Jun 2010 14:11:47 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id BC46A3A696E for ; Tue, 15 Jun 2010 14:11:47 -0700 (PDT) Received: (qmail 88414 invoked from network); 15 Jun 2010 21:11:49 -0000 Received: from thunderfish.local (turners@96.231.121.221 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 15 Jun 2010 14:11:49 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 2KTTexMVM1mu5fXKFmGbZK1J0bJXR3W0mEmL83fMhX1c9D9F1ra4uCDJajmSHfI.cd1rddTsSohs4kKelSR7WwxRZqZF4MebZ0NKUhiT_OtwSjLpELA4X7DyliL1AmD73PZiRLYg.KVXmsaCEC7o3WjKBtYehg7mb9RvfEPIXXdJmQRLHBYtQWdvH1InsMTkH.NZvr1353UFF6ATgTweajOQKSiierixaJjHLMDLgF4b9x2A5pdJexI1ImTgOrVqfUSlZ.RrBEUHeY8x5xzzt.6.i2y5eE.bNSJgJapNa3zv_87L8soWFheOYqXKGhHu4NtMG4H0CPKvr66DIbI6Qi.K.D7O0rK8K3dv47F12JwLW5p7ARiijQkUV3gJPYl02Gx1lJ.BuyDGOIycMRCWYOYSWIh4dkJyGigv0HIE.rZCiw.yDfC5 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C17EC95.5080405@ieca.com> Date: Tue, 15 Jun 2010 17:11:49 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Rob Austein References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <20100615200143.C6D7B22808@thrintun.hactrn.net> In-Reply-To: <20100615200143.C6D7B22808@thrintun.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 21:11:49 -0000 Rob Austein wrote: > At Tue, 15 Jun 2010 15:14:17 -0400, Sean P Turner wrote: >> Did you see something in Section 6.1 of RFC 5280 that made you think >> AIA should be used during path validation? > > No. The issue is conformance to draft-ietf-sidr-res-certs, which is a > tighter set of constraints than RFC 5280 or RFC 3779. > > One might disagree with that profile (and on this particular point > regarding the AIA pointer I've been thinking that perhaps I do) but > I was talking about validation within the context of that profile. Rob thanks for setting me straight. I think I'm starting to disagree ;) spt From Sandra.Murphy@cobham.com Tue Jun 15 14:22:59 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601653A69EA for ; Tue, 15 Jun 2010 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=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 MS-5Y24jLDtN for ; Tue, 15 Jun 2010 14:22:58 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 521723A69D5 for ; Tue, 15 Jun 2010 14:22:58 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5FLMwOa016153; Tue, 15 Jun 2010 16:22:58 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5FLMuUH013383; Tue, 15 Jun 2010 16:22:58 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 17:20:28 -0400 Date: Tue, 15 Jun 2010 17:20:26 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Sean Turner In-Reply-To: <4C16A1EC.407@ieca.com> Message-ID: References: <4C167E36.2040305@ieca.com> <40A6C79E-A125-470A-AF81-AD49ED109218@apnic.net> <4C16A1EC.407@ieca.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Jun 2010 21:20:28.0767 (UTC) FILETIME=[941A3EF0:01CB0CD0] Cc: sidr@ietf.org Subject: Re: [sidr] Question about draft-ietf-sidr-rpki-algs migration text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 21:22:59 -0000 On Mon, 14 Jun 2010, Sean Turner wrote: > Geoff Huston wrote: >> On 15/06/2010, at 5:08 AM, Sean Turner wrote: >> >>> Geoff, >>> >>> In the rpki-algs document there's a note in section 3 that talks about >>> algorithm agility. Part of it copied below: >>> >>> The alternate approach, of allowing >>> multiple signature algorithms in the RPKI certificate profile, and in >>> the specification of CMS signatures as used in manifests, ROAS, other >>> signed objects, and in the provisioning protocol, allows for >>> algorithm transition to occur within a single RPKI framework, and >>> allows for individual CAs to commence use of multiple algorithms in a >>> piecemeal fashion without reliance on the algorithm transition of the >>> immediate superior CA and without a forced synchronisation of >>> algorithm transition with subordinate CAs. In the light of this >>> consideration, this document recommends the comprehensive revision of >>> the existing RPKI specification and architecture documents to include >>> provision for multiple signatures with multiple algorithms in order >>> to support an orderly transition to longer key sizes and to other >>> signature algorithms in the RPKI. >>> >>> Question: Is the first sentence suggesting that the certificates should >>> have two signatures applied? I.e., do you consider a certificate to be an >>> "other signed object." >> >> nope! (although its an interesting idea, I was assuming that RFC5280 was >> more or less cast in concrete rather than plasticine.) Can you say more about what this means for the certificates? Does this mean that there might be mulitple certificates, one per algorithm? If so, how would this avoid the problems of consistency and coherency you note: The latter option, that of the concurrent operation of parallel RPKI structures, poses some complex issues in terms of synchronisation of actions across the set of RPKI CAs, as well as issues of consistency and coherency in the operation of multiple parallel RPKI frameworks, as well as the uncertainties associated with a global determination of when any such transition can be considered "complete". Pretty sure I'm not understanding the draft's recommendation here. --Sandy, speaking as someone who wants to clarify the wg document, so probably as wg member > > This is good news ;) There's one place to put a signature value and it's a > single valued field. > > spt > >> I was referring in that text to signed objects and the use of CMS and the >> option in CMS for multiple signatures, and I was advocating consideration >> of an approach that used a single collection of such signed objects. I'm >> sorry if the words are less than clear. Perhaps they should be removed in >> the next iteration of this draft in any case. >> >> Geoff >> >> >> >> >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From gih@apnic.net Tue Jun 15 15:02:15 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604CF3A68F0 for ; Tue, 15 Jun 2010 15:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.983 X-Spam-Level: X-Spam-Status: No, score=-90.983 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, RELAY_IS_220=2.118, 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 rDcqL7D9mSUM for ; Tue, 15 Jun 2010 15:02:14 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id DF7413A68CC for ; Tue, 15 Jun 2010 15:02:12 -0700 (PDT) Received: from dhcp205.potaroo.net (220-253-186-110.NSW.netspace.net.au [220.253.186.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A5C16D57BB; Wed, 16 Jun 2010 08:02:05 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 16 Jun 2010 08:02:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8F4A8291-41E8-4E52-9CD0-EEED5CD9C383@apnic.net> References: <4C167E36.2040305@ieca.com> <40A6C79E-A125-470A-AF81-AD49ED109218@apnic.net> <4C16A1EC.407@ieca.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1078) Cc: sidr@ietf.org Subject: Re: [sidr] Question about draft-ietf-sidr-rpki-algs migration text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 22:02:15 -0000 On 16/06/2010, at 7:20 AM, Sandra Murphy wrote: >=20 >=20 > On Mon, 14 Jun 2010, Sean Turner wrote: >=20 >> Geoff Huston wrote: >>> On 15/06/2010, at 5:08 AM, Sean Turner wrote: >>>> Geoff, >>>> In the rpki-algs document there's a note in section 3 that talks = about algorithm agility. Part of it copied below: >>>> The alternate approach, of allowing >>>> multiple signature algorithms in the RPKI certificate profile, and = in >>>> the specification of CMS signatures as used in manifests, ROAS, = other >>>> signed objects, and in the provisioning protocol, allows for >>>> algorithm transition to occur within a single RPKI framework, and >>>> allows for individual CAs to commence use of multiple algorithms in = a >>>> piecemeal fashion without reliance on the algorithm transition of = the >>>> immediate superior CA and without a forced synchronisation of >>>> algorithm transition with subordinate CAs. In the light of this >>>> consideration, this document recommends the comprehensive revision = of >>>> the existing RPKI specification and architecture documents to = include >>>> provision for multiple signatures with multiple algorithms in order >>>> to support an orderly transition to longer key sizes and to other >>>> signature algorithms in the RPKI. >>>> Question: Is the first sentence suggesting that the certificates = should have two signatures applied? I.e., do you consider a certificate = to be an "other signed object." >>> nope! (although its an interesting idea, I was assuming that RFC5280 = was more or less cast in concrete rather than plasticine.) >=20 > Can you say more about what this means for the certificates? >=20 > Does this mean that there might be mulitple certificates, one per = algorithm? yes, that is the implication. > If so, how would this avoid the problems of consistency and coherency = you note: >=20 > The latter option, that of the concurrent > operation of parallel RPKI structures, poses some complex issues in > terms of synchronisation of actions across the set of RPKI CAs, as > well as issues of consistency and coherency in the operation of > multiple parallel RPKI frameworks, as well as the uncertainties > associated with a global determination of when any such transition > can be considered "complete". It mitigates, but does not totally avoid these issues.=20 It is easier to explain this if you use a taxonomy of the RPKI as having = two distinct sets of "things" in it, with one set being the collection = of CA and EE certificates and associated CRLs, and the other set being a = a collection of digitally signed objects. The objects in the second set = can be verified using validation paths that are in effect certificate = chains where the certificates are drawn from the first set. One approach to algorithm migration is to create an entirely different = RPKI. That is, the actors need to maintain a new set of certificates = that are identical in every respect save for the key algorithm and key = values (and any names that are derived from the key values), and also = maintain a "new" set of signed objects that are verifiable using = exclusively these "new" certificates.=20 Another approach to algorithm migration is to maintain a single set of = signed objects, but use the multiple signature capability of CMS to = allow an object with multiple attached signatures to be verified using = either of the signatures, and hence either of the certificate sets and = hence either of the algorithms.=20 When an entity is capable of supporting the new algorithm it can add the = additional signature to the entity's collection of objects that are = signed by the entity. When a relying party is capable of using a new = algorithm it may attempt to perform verification using the new algorithm = instead of the "old" algorithm, and use a "either to validate" condition = to ensure that if verification fails in the new algorithm it will try = using the old algorithm before pronouncing that the object cannot be = verified. There is some form of "fail safe" in this latter scenario = becuase even if verification fails in the "new" world becuase of = incomplete validation paths (due to lack of comprehensive use of the = "new" algorithm by all issuers) there is still the onus on the Relying = Party to undertake the same verification task using the "old" algorithm = before pronouncing the object unverifiable. If you contrast this to a = scenario of two distinct RPKI universes, each populated with its own set = of signed objects, then how does a relying party know which signed = objects from one RPKI universe are equivalent to which object in the = other RPKI universe? Are the two RPKI universes mutually exclusive? Are = Relying Parties meant to use one RPKI universe or the other as an = exclusive choice? What happens when the practical outcomes in terms of = route origination filters differ between the two universes? Is the lack = of clear determinism from the perspective of Relying Parties in the = verification outcomes because of the diverse use of two distinct RPKI = universes a desirable outcome? The notes in the algorithm draft advocated the approach to multiple = signatures on signed objects as representing some degree of mitigation = of the issue of maintaining precise synchronisation of parallel and = distinct RPKI universes. In the multi-signature approach there is still = the same single collection of signed objects with the same set of = intended semantics. The remaining task is to ensure that the two = certificate sets offer the same verification outcomes, which looks like = being the unavoidable minimal requirement for precise synchronisation in = this scenario.=20 >=20 > Pretty sure I'm not understanding the draft's recommendation here. >=20 the above explanation may help - or of course it may not! >>> I was referring in that text to signed objects and the use of CMS = and the option in CMS for multiple signatures, and I was advocating = consideration of an approach that used a single collection of such = signed objects. I'm sorry if the words are less than clear. Perhaps they = should be removed in the next iteration of this draft in any case. My earlier apology over lack of clarity and my intent to remove these = comments in the next iteration of the draft in any case still stand. Geoff From robert@ripe.net Tue Jun 15 15:38:01 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F0A3A68DF for ; Tue, 15 Jun 2010 15:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 I+oYLpQIk1WX for ; Tue, 15 Jun 2010 15:38:00 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id D06803A688E for ; Tue, 15 Jun 2010 15:37:59 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OOelZ-0006Q3-CH for sidr@ietf.org; Wed, 16 Jun 2010 00:38:02 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OOelZ-0004is-1w for sidr@ietf.org; Wed, 16 Jun 2010 00:37:57 +0200 Message-ID: <4C1800C4.3090703@ripe.net> Date: Tue, 15 Jun 2010 15:37:56 -0700 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: <20100614152202.621B922808@thrintun.hactrn.net> In-Reply-To: <20100614152202.621B922808@thrintun.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2740e2e941603b3d963a72a5322bf836fff X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2740e2e941603b3d963a72a5322bf836fff Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 22:38:01 -0000 On 2010.06.14. 8:22, Rob Austein wrote: > So (a) I'm not sure I agree with the problem as stated, but (b) we > might just want to get rid of the AIA pointer anyway, or at least make > it purely advisory (not a res-certs profile conformance violation if > the AIA pointer is whacked). Not sure yet. Maybe both :). Please don't kill AIA, it's useful for discovery. I agree that you don't need to use it in verification though. Robert From Sandra.Murphy@cobham.com Tue Jun 15 15:57:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BE93A6991 for ; Tue, 15 Jun 2010 15:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_50=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 x-Mbv7KhAWe1 for ; Tue, 15 Jun 2010 15:57:20 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8BD3A3A68DF for ; Tue, 15 Jun 2010 15:57:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5FMvK42017218; Tue, 15 Jun 2010 17:57:20 -0500 Received: from ELECTRONVILLE.boston.ads.sparta.com ([157.185.20.250]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5FMvJG2016325; Tue, 15 Jun 2010 17:57:20 -0500 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by ELECTRONVILLE.boston.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 18:57:19 -0400 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 18:53:04 -0400 Date: Tue, 15 Jun 2010 18:53:01 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <8F4A8291-41E8-4E52-9CD0-EEED5CD9C383@apnic.net> Message-ID: References: <4C167E36.2040305@ieca.com> <40A6C79E-A125-470A-AF81-AD49ED109218@apnic.net> <4C16A1EC.407@ieca.com> <8F4A8291-41E8-4E52-9CD0-EEED5CD9C383@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="36642911-18963-1276642381=:836" X-OriginalArrivalTime: 15 Jun 2010 22:53:04.0662 (UTC) FILETIME=[83AC8B60:01CB0CDD] Cc: sidr@ietf.org Subject: Re: [sidr] Question about draft-ietf-sidr-rpki-algs migration text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 22:57:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --36642911-18963-1276642381=:836 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Thank you. Yes this helps. If I've got it correctly now, you are suggesting multiple signatures on=20 signed objects as a rendezvous point in the independent parallel=20 structures of the certificate side of the systems, a point at which the=20 parallel structures must synchronize. How strict is this synchronization? The ROA would need to have two EE=20 certs, and the requirement is that the ROA IP address prefix "is contained= =20 within the set of IP addresses specified by the EE certificate's IP=20 address delegation extension". Would you envision that the=20 synchronization would insist that the two EE certs have exactly the same=20 address delegation extension? (Eliminating some degree of=20 freedom/inconsistency between the parallel structures.) --Sandy On Wed, 16 Jun 2010, Geoff Huston wrote: > > On 16/06/2010, at 7:20 AM, Sandra Murphy wrote: > >> >> >> On Mon, 14 Jun 2010, Sean Turner wrote: >> >>> Geoff Huston wrote: >>>> On 15/06/2010, at 5:08 AM, Sean Turner wrote: >>>>> Geoff, >>>>> In the rpki-algs document there's a note in section 3 that talks abou= t algorithm agility. Part of it copied below: >>>>> The alternate approach, of allowing >>>>> multiple signature algorithms in the RPKI certificate profile, and in >>>>> the specification of CMS signatures as used in manifests, ROAS, other >>>>> signed objects, and in the provisioning protocol, allows for >>>>> algorithm transition to occur within a single RPKI framework, and >>>>> allows for individual CAs to commence use of multiple algorithms in a >>>>> piecemeal fashion without reliance on the algorithm transition of the >>>>> immediate superior CA and without a forced synchronisation of >>>>> algorithm transition with subordinate CAs. In the light of this >>>>> consideration, this document recommends the comprehensive revision of >>>>> the existing RPKI specification and architecture documents to include >>>>> provision for multiple signatures with multiple algorithms in order >>>>> to support an orderly transition to longer key sizes and to other >>>>> signature algorithms in the RPKI. >>>>> Question: Is the first sentence suggesting that the certificates shou= ld have two signatures applied? I.e., do you consider a certificate to be = an "other signed object." >>>> nope! (although its an interesting idea, I was assuming that RFC5280 w= as more or less cast in concrete rather than plasticine.) >> >> Can you say more about what this means for the certificates? >> >> Does this mean that there might be mulitple certificates, one per algori= thm? > > yes, that is the implication. > >> If so, how would this avoid the problems of consistency and coherency y= ou note: >> >> The latter option, that of the concurrent >> operation of parallel RPKI structures, poses some complex issues in >> terms of synchronisation of actions across the set of RPKI CAs, as >> well as issues of consistency and coherency in the operation of >> multiple parallel RPKI frameworks, as well as the uncertainties >> associated with a global determination of when any such transition >> can be considered "complete". > > > It mitigates, but does not totally avoid these issues. > > It is easier to explain this if you use a taxonomy of the RPKI as having = two distinct sets of "things" in it, with one set being the collection of C= A and EE certificates and associated CRLs, and the other set being a a coll= ection of digitally signed objects. The objects in the second set can be ve= rified using validation paths that are in effect certificate chains where t= he certificates are drawn from the first set. > > One approach to algorithm migration is to create an entirely different RP= KI. That is, the actors need to maintain a new set of certificates that are= identical in every respect save for the key algorithm and key values (and = any names that are derived from the key values), and also maintain a "new" = set of signed objects that are verifiable using exclusively these "new" cer= tificates. > > Another approach to algorithm migration is to maintain a single set of si= gned objects, but use the multiple signature capability of CMS to allow an = object with multiple attached signatures to be verified using either of the= signatures, and hence either of the certificate sets and hence either of t= he algorithms. > > When an entity is capable of supporting the new algorithm it can add the = additional signature to the entity's collection of objects that are signed = by the entity. When a relying party is capable of using a new algorithm it = may attempt to perform verification using the new algorithm instead of the = "old" algorithm, and use a "either to validate" condition to ensure that if= verification fails in the new algorithm it will try using the old algorith= m before pronouncing that the object cannot be verified. There is some form= of "fail safe" in this latter scenario becuase even if verification fails = in the "new" world becuase of incomplete validation paths (due to lack of c= omprehensive use of the "new" algorithm by all issuers) there is still the = onus on the Relying Party to undertake the same verification task using the= "old" algorithm before pronouncing the object unverifiable. If you contras= t this to a scenario of two distinct RPKI universes, each populated with it= s own set of signed objects, then how does a relying party know which signe= d objects from one RPKI universe are equivalent to which object in the othe= r RPKI universe? Are the two RPKI universes mutually exclusive? Are Relying= Parties meant to use one RPKI universe or the other as an exclusive choic= e? What happens when the practical outcomes in terms of route origination f= ilters differ between the two universes? Is the lack of clear determinism f= rom the perspective of Relying Parties in the verification outcomes because= of the diverse use of two distinct RPKI universes a desirable outcome? > > The notes in the algorithm draft advocated the approach to multiple signa= tures on signed objects as representing some degree of mitigation of the is= sue of maintaining precise synchronisation of parallel and distinct RPKI un= iverses. In the multi-signature approach there is still the same single col= lection of signed objects with the same set of intended semantics. The rema= ining task is to ensure that the two certificate sets offer the same verifi= cation outcomes, which looks like being the unavoidable minimal requirement= for precise synchronisation in this scenario. > > > >> >> Pretty sure I'm not understanding the draft's recommendation here. >> > > the above explanation may help - or of course it may not! > > >>>> I was referring in that text to signed objects and the use of CMS and = the option in CMS for multiple signatures, and I was advocating considerati= on of an approach that used a single collection of such signed objects. I'm= sorry if the words are less than clear. Perhaps they should be removed in = the next iteration of this draft in any case. > > My earlier apology over lack of clarity and my intent to remove these com= ments in the next iteration of the draft in any case still stand. > > Geoff > > --36642911-18963-1276642381=:836-- From kent@bbn.com Wed Jun 16 07:47:15 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68583A6A62 for ; Wed, 16 Jun 2010 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_05=-1.11] 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 winocW0iuI9r for ; Wed, 16 Jun 2010 07:47:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 578E13A6B40 for ; Wed, 16 Jun 2010 07:47:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57303 helo=[10.242.52.205]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOttT-0009u2-Iv; Wed, 16 Jun 2010 10:47:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1800C4.3090703@ripe.net> References: <20100614152202.621B922808@thrintun.hactrn.net> <4C1800C4.3090703@ripe.net> Date: Wed, 16 Jun 2010 10:29:42 -0400 To: Robert Kisteleki From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:47:16 -0000 At 3:37 PM -0700 6/15/10, Robert Kisteleki wrote: >On 2010.06.14. 8:22, Rob Austein wrote: >>So (a) I'm not sure I agree with the problem as stated, but (b) we >>might just want to get rid of the AIA pointer anyway, or at least make >>it purely advisory (not a res-certs profile conformance violation if >>the AIA pointer is whacked). Not sure yet. Maybe both :). > >Please don't kill AIA, it's useful for discovery. I agree that you >don't need to use it in verification though. > >Robert I was just thinking about Robert's plan to use RPKI certs to verify signed RPLS objects. This application needs AIA and the other bottom-up cert path discovery methods that are common for PKI apps. I don't know if we will have other such apps in the future, but if so, this is an example of a situation where we cannot always rely on a top-down cert acquisition methodology. Steve From kent@bbn.com Wed Jun 16 08:30:35 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474913A68F2 for ; Wed, 16 Jun 2010 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74] 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 pXghvI7ZgsYE for ; Wed, 16 Jun 2010 08:30:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id BBC533A6931 for ; Wed, 16 Jun 2010 08:30:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57303 helo=[10.242.52.205]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOttp-0009u2-10 for sidr@ietf.org; Wed, 16 Jun 2010 10:47:29 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 16 Jun 2010 10:47:01 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] another TA observation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 15:30:35 -0000 Folks, In explaining the differences between the new TA proposal and the compound TA proposal to a staff member, I realized that there is another (perhaps minor) difference that I failed to include in my analysis last week. The new (simple) TA proposal requires each RP to fetch the trust anchor (the self-signed cert) to make sure that the RP has the current version re the 3779 resources contained therein. I don't recall that Sam's I-D specified how frequently an RP should (SHOULD?) perform this fetch. The simple, safe answer might be to perform the fetch every time the RP does a tree walk to gather new certs, CRLs, etc. In the compound TA mode the ETA is constant for a very long period (indicated by the validity interval in the self-signed cert). The CMS blob that contains the RTA is fetched (presumably as part of the tree walk), and verified using the (single-use?) EE cert contained in the blob, to obtain the up-to-date TA for RPKI cert validation. Thios is essentially the same sort of operation we have to do for other CMS blobs (e.g., ROAs and manifests), except in terms of what we do with the content. Not sure if anyone cares about this difference, but I thought I would mention it for completeness. Steve P.S. I accidentally sent this to the secdir list first. Whoops. From kent@bbn.com Thu Jun 17 06:30:25 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729863A6837 for ; Thu, 17 Jun 2010 06:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992] 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 wWDxKlIfQ3Lb for ; Thu, 17 Jun 2010 06:30:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 328F73A67EC for ; Thu, 17 Jun 2010 06:30:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34245 helo=[172.28.179.87]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPFAW-000OTi-Dr; Thu, 17 Jun 2010 09:30:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C17D82F.4080105@nist.gov> References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> Date: Wed, 16 Jun 2010 18:04:49 -0400 To: "David A. Cooper" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] key rollover and algorithm migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 13:30:26 -0000 David & Sean, We put checks into the validation spec to try to ensure that CAs issue certs consistent with the profile. This profile is for a large, highly distributed system that needs to work reliably across the public Internet. Note that the RPKI asks Internet registries and ISPs to act as CAs. They are not organizations that set out to act as CAs to make money issuing certs; they allocate address space (either as a primary function, or as a side effect of offering ISP services). We don't want to make life hard for them, either as CAs or as RPs. Recall that the RPKI is unusual (unique?) in that essentially every RP is also a CA, so each of these organizations has a dual role. Over the years we have seen a lot of examples of CAs doing an awful job of issuing certs in compliance with the PKIX profiles, and RP software that behaves equally poorly, condoning (encouraging?) such behavior. My hope (maybe Geoff's ad well) is to try to get RP software to help detect bad CA behavior in this respect, to provide a feedback loop to help address such problems. Steve From kent@bbn.com Wed Jun 23 09:11:18 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566923A6803 for ; Wed, 23 Jun 2010 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_50=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 jInd3F6o524P for ; Wed, 23 Jun 2010 09:11:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1CA1328C131 for ; Wed, 23 Jun 2010 09:11:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34370 helo=[130.129.12.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ORSXs-0009sB-7e for sidr@ietf.org; Wed, 23 Jun 2010 12:11:24 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 23 Jun 2010 12:11:21 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] algorithm suite migration (top level scenario) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:11:18 -0000 I think it might be helpful to explore some aspects of how we envision migrating to a new algorithm suite, without debating all of the details of migration. This way we can determine if there is agreement on general principles re migration before we try to resolve details. My notion is that the process of migration begins with the publication of a new CP version by the IETF. That process will be very visible and take several months to complete, at a minimum. The new CP would specify the next algorithm suite by reference to an existing RFC that defines the signature algorithm and hash algorithm that comprise the suite. That RFC will have been around for a while, because we would not consider migrating to anything other than a well-established, mature algorithm suite. Thus the suite itself will have been defined in an RFC well in advance. I think new CP should specify the following milestones: - CA Ready : By this date all (non-leaf) CAs MUST be ready to process a request from a child CA to issue a certificate containing a key for the new signature algorithm. The certificate that is issued would be signed under the current algorithm suite. The reason we need this date is because a certificate request requires the issuing CA to verify proof of possession (PoP) for the new key by the requesting party. Thus by this date all CAs MUS be able to perform the PoP procedure, even if they are not yet ready to issue certificates under the new algorithm suite. (If we decide that a top-down migration approach is desirable, this date might apply to IANA and the RIRs, rather than to all CAs.) - CA Set : By his date all CAs MUST be prepared to issue a certificate signed under the new algorithm suite to a child CA that requests such. At this stage there is no requirement that any CA issue such certificates, but rather that all (not leaf) CAs be prepared to do so upon request. - CA Go : By this date, all (non-leaf) CAs MUST have re-issued all child CA certificates, under the new algorithm suite, as well as CRLs, manifests, and ROAs. The old suite is still in use and thus CAs are maintaining parallel, synchronized sets of signed objects under old and new algorithm suites. (If we adopt dual-signatures for ROAs and manifests, one set of those objects can satisfy this requirement. However, a certificate or CRL has only one signature, so corresponding copies of these objects are still required.) - RP Ready : By this date all RPs MUST be prepared to process certificates issued under the new algorithm suite. Since all CAs are publishing all sighed products under both suites by now, RPs have plenty of material to process to verify that they get the same results under old and new suites. My recommendation would be that if the results from the new suite don't agree with the results from the current suite, stick with the results from the current suite while you try to figure out the problem. (This may require contacting some of the CAs to see why there is a mismatch, but since you can keep using the products under the current alg suite, there should be time to resolve the problems.) - Twilight : At this date a CA MAY cease issuing signed products under the old algorithm suite, at its discretion. (This affects the children of the CA, so there is a need for coordination. But, since this date is after RP Ready, no RPs should require signed products under the old algorithm suite at this stage.) - EOL : At this date NO signed objects under the old algorithm suite are generated or consumed. More formally, every CA and every RP MUST NOT generate certs, CRLs, or other RPKI signed objects under the old alg suite. The transition is now complete. Note that during the interval when current and new algorithm suites are in use (from CA Set until Twilight ) a CA MUST be prepared to process key rollover requests for children under both current and new suites. There are a lot of details to be worked out for this. I have intentionally not suggested any durations for the intervals defined by the ordered list above. Clearly that is one of the topics we need to address, if we agree to a model that adopts a timetable like this. But, first we need to discuss whether these are the right milestones. Comments and suggestions are solicited. Steve From Sandra.Murphy@cobham.com Wed Jun 23 13:53:29 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECF43A69E1 for ; Wed, 23 Jun 2010 13:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=1.148, BAYES_00=-2.599] 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 8S8M29qqYFAT for ; Wed, 23 Jun 2010 13:53:28 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 12EA83A6966 for ; Wed, 23 Jun 2010 13:53:27 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5NKrZlK022754 for ; Wed, 23 Jun 2010 15:53:35 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5NKrZcQ001579 for ; Wed, 23 Jun 2010 15:53:35 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.121]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 16:53:35 -0400 Date: Wed, 23 Jun 2010 16:53:34 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 23 Jun 2010 20:53:35.0246 (UTC) FILETIME=[25AC7AE0:01CB1316] Subject: [sidr] Nomcom 2010-2011: Second Call for Volunteers (fwd) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 20:53:29 -0000 Here is a request for volunteers for the nomcom. The nomcom is important to the IETF process and broad participation is desirable. If you meet the requirements, please consider volunteering. --Sandy, speaking as wg chair ---------- Forwarded message ---------- Date: Mon, 21 Jun 2010 14:49:08 -0700 From: NomCom Chair To: IETF Announcement list Subject: Nomcom 2010-2011: Second Call for Volunteers Hi all, This is the Second call for Volunteers for the 2010-11 nomcom. We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon. I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF pouplation. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of nomcom may be found in RFC 3777. The process on how to volunteer for nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are: Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From root@core3.amsl.com Thu Jun 24 09:30:14 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B9CD13A67FB; Thu, 24 Jun 2010 09:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100624163011.B9CD13A67FB@core3.amsl.com> Date: Thu, 24 Jun 2010 09:30:03 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-usecases-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 16:30:14 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Use Cases and interpretation of RPKI objects for issuers and relying parties Author(s) : T. Manderson, et al. Filename : draft-ietf-sidr-usecases-00.txt Pages : 23 Date : 2010-06-20 This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI in relation to the Internet routing system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-usecases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-24092025.I-D@ietf.org> --NextPart-- From gih@apnic.net Thu Jun 24 14:23:37 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB6C3A69D0 for ; Thu, 24 Jun 2010 14:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, RELAY_IS_203=0.994, 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 ZgJ1duujMhwX for ; Thu, 24 Jun 2010 14:23:36 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 3F5E63A6A5E for ; Thu, 24 Jun 2010 14:23:34 -0700 (PDT) Received: from dhcp61.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 326D9D5899; Fri, 25 Jun 2010 07:23:36 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 25 Jun 2010 07:23:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] algorithm suite migration (top level scenario) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 21:23:37 -0000 Hi Steve, I'll interleave my comments against each section in your note - I think = it probably makes my queries a little clearer in terms of the additional = context. On 24/06/2010, at 2:11 AM, Stephen Kent wrote: > I think it might be helpful to explore some aspects of how we envision = migrating to a new algorithm suite, without debating all of the details = of migration. This way we can determine if there is agreement on general = principles re migration before we try to resolve details. >=20 > My notion is that the process of migration begins with the publication = of a new CP version by the IETF. That process will be very visible and = take several months to complete, at a minimum. The new CP would specify = the next algorithm suite by reference to an existing RFC that defines = the signature algorithm and hash algorithm that comprise the suite. That = RFC will have been around for a while, because we would not consider = migrating to anything other than a well-established, mature algorithm = suite. Thus the suite itself will have been defined in an RFC well in = advance. >=20 > I think new CP should specify the following milestones: >=20 > - CA Ready : By this date all (non-leaf) CAs = MUST be ready to process a request from a child CA to issue a = certificate containing a key for the new signature algorithm. The = certificate that is issued would be signed under the current algorithm = suite. The reason we need this date is because a certificate request = requires the issuing CA to verify proof of possession (PoP) for the new = key by the requesting party. Thus by this date all CAs MUS be able to = perform the PoP procedure, even if they are not yet ready to issue = certificates under the new algorithm suite. (If we decide that a = top-down migration approach is desirable, this date might apply to IANA = and the RIRs, rather than to all CAs.) I assume that you are defining the distinction between a "non-leaf" CA = and a "leaf" CA as being one where a "leaf" CA only has EE subordinates. = It this a correct assumption. Your final comment about this date = applying to IANA and the RIRs does not quite capture for me the same = goal as the body of this paragraph.=20 I also gather the impression that you see Proof of Possession validation = requiring the CA to have the ability to process the algorithm used by = the subordinate when the subordinate entity generated the key pair. The = RPKI provisioning protocol does not specify any such direct test using = the subordinate's public key value. I am wondering if there is a missing = element in the provisioning protocol, namely the inclusion of such a = direct test of PoP, and what they would imply in any case. Is the nature = of the PoP test one of the issuer assurring itself that the requestor = really is the party they are purporting to be, or whether the PoP test = is one of the issuer assuring itself that the requestor really has = possession of the associated private key? If the former is the case, then the issuer does not necessarily need to = have the ability to process the algorithm identified in the certificate = request. If the latter than the rescert provisioning protocol may well = be missing a needed step in verification of the request. Am I missing something here? >=20 > - CA Set : By his date all CAs MUST be = prepared to issue a certificate signed under the new algorithm suite to = a child CA that requests such. At this stage there is no requirement = that any CA issue such certificates, but rather that all (not leaf) CAs = be prepared to do so upon request. >=20 How does a requestor specify the algorithm to be used by the issuer? = Again my concerns here is that there is something missing in section 6 = of the res-cert draft if it is indeed necessary that the requestor = specify the algorithm that the issuer must use in generating the = certificate the describes the subject. >=20 > - CA Go : By this date, all (non-leaf) CAs = MUST have re-issued all child CA certificates, under the new algorithm = suite, as well as CRLs, manifests, and ROAs. The old suite is still in = use and thus CAs are maintaining parallel, synchronized sets of signed = objects under old and new algorithm suites. (If we adopt dual-signatures = for ROAs and manifests, one set of those objects can satisfy this = requirement. However, a certificate or CRL has only one signature, so = corresponding copies of these objects are still required.) >=20 Now here I'm somewhat confused. Are you talking about a parallel, but = entirely distinct certificate hierarchy? i.e. are you in effect saying = that the condition here is that all certificates issued for a subject = using subject key algorithm X are issued by the issuer with a = certificate signature algorithm also of algorithm X?=20 > - RP Ready : By this date all RPs MUST be = prepared to process certificates issued under the new algorithm suite. = Since all CAs are publishing all sighed products under both suites by = now, RPs have plenty of material to process to verify that they get the = same results under old and new suites. My recommendation would be that = if the results from the new suite don't agree with the results from the = current suite, stick with the results from the current suite while you = try to figure out the problem. (This may require contacting some of the = CAs to see why there is a mismatch, but since you can keep using the = products under the current alg suite, there should be time to resolve = the problems.) I want to conform something here - are the CAs for the new and old suite = distinct? Whats the scope of the CRLs? I assume that it would be an = undesireable situation if a CRL from the "new" suite attempts to revoke = a certificate from the "old" suite, and I'm unsure what mechanism would = be used to prevent such a scenario from occurring. >=20 >=20 > - Twilight : At this date a CA MAY cease = issuing signed products under the old algorithm suite, at its = discretion. (This affects the children of the CA, so there is a need for = coordination. But, since this date is after RP Ready, no RPs should = require signed products under the old algorithm suite at this stage.) What you are in effect saying, as far as I can tell, is that the RP is = to switch over to believe the new "suite" if the results of the "new" = and "old" differ. I wonder how such a switch in collective RP behaviour = could be coordinated so precisely across all RPs. Or are you saying that = the onus is on all CAs to ensure that the two environments are = absolutely and precisely synchronized such that there is no possibility = for such a situation? >=20 > - EOL : At this date NO signed objects under = the old algorithm suite are generated or consumed. More formally, every = CA and every RP MUST NOT generate certs, CRLs, or other RPKI signed = objects under the old alg suite. The transition is now complete. >=20 > Note that during the interval when current and new algorithm suites = are in use (from CA Set until Twilight ) a CA MUST be prepared to process key rollover requests for = children under both current and new suites. There are a lot of details = to be worked out for this. >=20 indeed! > I have intentionally not suggested any durations for the intervals = defined by the ordered list above. Clearly that is one of the topics we = need to address, if we agree to a model that adopts a timetable like = this. But, first we need to discuss whether these are the right = milestones. regards, Geoff From kent@bbn.com Fri Jun 25 02:33:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D782C3A68E7 for ; Fri, 25 Jun 2010 02:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_50=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 0JgdULeY0kDV for ; Fri, 25 Jun 2010 02:33:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1EF5F3A69F4 for ; Fri, 25 Jun 2010 02:32:29 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34110 helo=[130.129.12.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OS5H2-000J24-OH; Fri, 25 Jun 2010 05:32:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 25 Jun 2010 05:32:25 -0400 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] algorithm suite migration (top level scenario) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 09:33:21 -0000 Geoff, Thanks for your comments. response inline. >... > > >I assume that you are defining the distinction between a "non-leaf" >CA and a "leaf" CA as being one where a "leaf" CA only has EE >subordinates. It this a correct assumption. Your final comment about >this date applying to IANA and the RIRs does not quite capture for >me the same goal as the body of this paragraph. Yes, leaf CAs are ones that issue only EE certs. My parenthetical comment was meant to note that this first date might apply only to top tier CAs, IF we choose to adopt a top-down deployment approach. The rest of the text does not make such an assumption, so maybe it was a mistake to make this comment here, sine I failed to carry it through i the rest of the discussion. Let's table the top-down discussion for now. >I also gather the impression that you see Proof of Possession >validation requiring the CA to have the ability to process the >algorithm used by the subordinate when the subordinate entity >generated the key pair. The RPKI provisioning protocol does not >specify any such direct test using the subordinate's public key >value. I am wondering if there is a missing element in the >provisioning protocol, namely the inclusion of such a direct test >of PoP, and what they would imply in any case. Is the nature of the >PoP test one of the issuer assurring itself that the requestor >really is the party they are purporting to be, or whether the PoP >test is one of the issuer assuring itself that the requestor really >has possession of the associated private key? The CP mandates that every CA engage in PoP as part of cert issuance. if the provisioning protocol does not make use of PoP, there is a mismatch. I have not looked at the protocol, so I can't say any more on that topic. >If the former is the case, then the issuer does not necessarily need >to have the ability to process the algorithm identified in the >certificate request. If the latter than the rescert provisioning >protocol may well be missing a needed step in verification of the >request. Agreed. > > - CA Set : By his date all CAs MUST be >prepared to issue a certificate signed under the new algorithm suite >to a child CA that requests such. At this stage there is no >requirement that any CA issue such certificates, but rather that all >(not leaf) CAs be prepared to do so upon request. > > > >How does a requestor specify the algorithm to be used by the issuer? >Again my concerns here is that there is something missing in section >6 of the res-cert draft if it is indeed necessary that the requestor >specify the algorithm that the issuer must use in generating the >certificate the describes the subject. Good question. The parent CA might establish a separate "portal" via which requests are made to the new vs. current alg suite. I have not looked at the cert request formats to see if there is a provision to indicate the alg suite to be used, but your comment suggests that there is not. So, I think it might be easier to say that each CA must advertise (via its CPS) how subjects can indicate the alg suite under which a request is to be fulfilled. >... > >Now here I'm somewhat confused. Are you talking about a parallel, >but entirely distinct certificate hierarchy? i.e. are you in effect >saying that the condition here is that all certificates issued for a >subject using subject key algorithm X are issued by the issuer with >a certificate signature algorithm also of algorithm X? essentially, yes. Parallel CA certs, CRLs, manifests, and ROAs. As noted, if we adopt the suggestion you made about revising the manifest and ROA formats to accommodate dual sigs, we could have just one set of these objects, but the CAs certs and CRLs are distinct. >... > >I want to conform something here - are the CAs for the new and old >suite distinct? Whats the scope of the CRLs? I assume that it would >be an undesireable situation if a CRL from the "new" suite attempts >to revoke a certificate from the "old" suite, and I'm unsure what >mechanism would be used to prevent such a scenario from occurring. The CAs represent the same administrative entity, which may or may not have the same name, depending on the outcome of another discussion. The CA instances use different keys to sign certs and CRLs, so there is no ambiguity re CRL scope. Each CRL lists serial number of certs issued under the corresponding CA key. >... > >What you are in effect saying, as far as I can tell, is that the RP >is to switch over to believe the new "suite" if the results of the >"new" and "old" differ. I wonder how such a switch in collective RP >behaviour could be coordinated so precisely across all RPs. Or are >you saying that the onus is on all CAs to ensure that the two >environments are absolutely and precisely synchronized such that >there is no possibility for such a situation? > This is the date after which CAs are relieved of the burden of issuing signed objects under the old suite. It is not a statement about RP behavior, but we are past the RP Ready date, so RPs MUST be able to process new alg suite signed objects, and not rely on any old alg suite objects. > > - EOL : At this date NO signed objects >under the old algorithm suite are generated or consumed. More >formally, every CA and every RP MUST NOT generate certs, CRLs, or >other RPKI signed objects under the old alg suite. The transition is >now complete. > > >> Note that during the interval when current and new algorithm >>suites are in use (from CA Set until Twilight >suite name>) a CA MUST be prepared to process key rollover requests >>for children under both current and new suites. There are a lot of >>details to be worked out for this. >> >indeed! I have a minor in understatement :-). Steve From kent@bbn.com Fri Jun 25 11:52:28 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32E23A683D for ; Fri, 25 Jun 2010 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599] 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 IUOBROV5G1kW for ; Fri, 25 Jun 2010 11:52:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DE8E13A69A5 for ; Fri, 25 Jun 2010 11:52:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58335 helo=[192.168.51.187]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OSE0v-0000rL-5A for sidr@ietf.org; Fri, 25 Jun 2010 14:52:33 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 25 Jun 2010 14:52:14 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] on vacation now, no e-mail until 7/6 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:52:28 -0000 From rogaglia@cisco.com Wed Jun 30 06:49:20 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1808D3A6A65 for ; Wed, 30 Jun 2010 06:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.446 X-Spam-Level: X-Spam-Status: No, score=-8.446 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_50=0.001, 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 EGVD59On-mgo for ; Wed, 30 Jun 2010 06:49:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 445763A6A40 for ; Wed, 30 Jun 2010 06:49:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGfoKkxAZnwN/2dsb2JhbACfW3GlcZoqhSUEiCM X-IronPort-AV: E=Sophos;i="4.53,513,1272844800"; d="p7s'?scan'208";a="127178910" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Jun 2010 13:49:25 +0000 Received: from Roque-Gaglianos-MacBook-Pro.local ([144.254.21.53]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5UDnIPp005331; Wed, 30 Jun 2010 13:49:19 GMT Received: from [127.0.0.1] by Roque-Gaglianos-MacBook-Pro.local (PGP Universal service); Wed, 30 Jun 2010 15:49:24 +0200 X-PGP-Universal: processed; by Roque-Gaglianos-MacBook-Pro.local on Wed, 30 Jun 2010 15:49:24 +0200 Mime-Version: 1.0 (Apple Message framework v1081) From: Roque Gagliano In-Reply-To: Date: Wed, 30 Jun 2010 15:49:13 +0200 Message-Id: <3B901BA8-9264-4CF5-A4F6-E3DDCCD47AAA@cisco.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1081) Content-Type: multipart/signed; boundary=Apple-Mail-82--1049156881; protocol="application/pkcs7-signature"; micalg=sha1 Cc: sidr wg Subject: Re: [sidr] algorithm suite migration (top level scenario) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:49:20 -0000 --Apple-Mail-82--1049156881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Steve, Just one comment of procedure. We have now the document = draft-ietf-sidr-rpki-algs, so I guess your procedure should be in a = document that obsoletes that document in the future. There is no real = reference to algorithms in the CP now. Roque. On Jun 23, 2010, at 6:11 PM, Stephen Kent wrote: > I think it might be helpful to explore some aspects of how we envision = migrating to a new algorithm suite, without debating all of the details = of migration. This way we can determine if there is agreement on general = principles re migration before we try to resolve details. >=20 > My notion is that the process of migration begins with the publication = of a new CP version by the IETF. That process will be very visible and = take several months to complete, at a minimum. The new CP would specify = the next algorithm suite by reference to an existing RFC that defines = the signature algorithm and hash algorithm that comprise the suite. That = RFC will have been around for a while, because we would not consider = migrating to anything other than a well-established, mature algorithm = suite. Thus the suite itself will have been defined in an RFC well in = advance. >=20 > I think new CP should specify the following milestones: >=20 > - CA Ready : By this date all (non-leaf) CAs = MUST be ready to process a request from a child CA to issue a = certificate containing a key for the new signature algorithm. The = certificate that is issued would be signed under the current algorithm = suite. The reason we need this date is because a certificate request = requires the issuing CA to verify proof of possession (PoP) for the new = key by the requesting party. Thus by this date all CAs MUS be able to = perform the PoP procedure, even if they are not yet ready to issue = certificates under the new algorithm suite. (If we decide that a = top-down migration approach is desirable, this date might apply to IANA = and the RIRs, rather than to all CAs.) >=20 > - CA Set : By his date all CAs MUST be = prepared to issue a certificate signed under the new algorithm suite to = a child CA that requests such. At this stage there is no requirement = that any CA issue such certificates, but rather that all (not leaf) CAs = be prepared to do so upon request. >=20 >=20 > - CA Go : By this date, all (non-leaf) CAs = MUST have re-issued all child CA certificates, under the new algorithm = suite, as well as CRLs, manifests, and ROAs. The old suite is still in = use and thus CAs are maintaining parallel, synchronized sets of signed = objects under old and new algorithm suites. (If we adopt dual-signatures = for ROAs and manifests, one set of those objects can satisfy this = requirement. However, a certificate or CRL has only one signature, so = corresponding copies of these objects are still required.) >=20 > - RP Ready : By this date all RPs MUST be = prepared to process certificates issued under the new algorithm suite. = Since all CAs are publishing all sighed products under both suites by = now, RPs have plenty of material to process to verify that they get the = same results under old and new suites. My recommendation would be that = if the results from the new suite don't agree with the results from the = current suite, stick with the results from the current suite while you = try to figure out the problem. (This may require contacting some of the = CAs to see why there is a mismatch, but since you can keep using the = products under the current alg suite, there should be time to resolve = the problems.) >=20 >=20 > - Twilight : At this date a CA MAY cease = issuing signed products under the old algorithm suite, at its = discretion. (This affects the children of the CA, so there is a need for = coordination. But, since this date is after RP Ready, no RPs should = require signed products under the old algorithm suite at this stage.) >=20 > - EOL : At this date NO signed objects under = the old algorithm suite are generated or consumed. More formally, every = CA and every RP MUST NOT generate certs, CRLs, or other RPKI signed = objects under the old alg suite. The transition is now complete. >=20 > Note that during the interval when current and new algorithm suites = are in use (from CA Set until Twilight ) a CA MUST be prepared to process key rollover requests for = children under both current and new suites. There are a lot of details = to be worked out for this. >=20 > I have intentionally not suggested any durations for the intervals = defined by the ordered list above. Clearly that is one of the topics we = need to address, if we agree to a model that adopts a timetable like = this. But, first we need to discuss whether these are the right = milestones. >=20 > Comments and suggestions are solicited. >=20 > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-82--1049156881 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYzMDEz NDkxNFowIwYJKoZIhvcNAQkEMRYEFO+J6dlc3PK3uLScED6LjPm7LurCMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAJpMvCsRglJwknvDfuN8zyxGRXpM1Q0hj57zxU9Aoa2shl3+ZgZv +u+3Vawrj0RWOse7xAi4uQpb1v9VcnzKXKGRKcZ4ttPl8NXayPlbtVZ9MhJFZBWmH5Apv41IDgnk sgjSkeyHrIHfi5kH1cfu4huXoE5N6yfklZn6nmoxb7cf8x2lhnPr6OonZT6+qBIsDpW9xw/lftnY jQjE44CUzRrugB2dLLTAxYFIpZApB5TPgC/iYQeRpZqyAB1I5fH9GHIGiMZvBQAFHEYlv446V4sa EM0qFbw4/Xp/Yjc2cIXjSeVgWYaDT7sjCuh1OT8WNJ9ptOWU5P+av/aV3FUuRXIAAAAAAAA= --Apple-Mail-82--1049156881-- From gih@apnic.net Wed Jun 30 11:52:06 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C463A67ED for ; Wed, 30 Jun 2010 11:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.492 X-Spam-Level: X-Spam-Status: No, score=-99.492 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_50=0.001, RELAY_IS_203=0.994, 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 cIgnIREmbhmW for ; Wed, 30 Jun 2010 11:52:05 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id BDC7A3A68F3 for ; Wed, 30 Jun 2010 11:52:03 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1B286D58BE; Thu, 1 Jul 2010 04:52:05 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <3B901BA8-9264-4CF5-A4F6-E3DDCCD47AAA@cisco.com> Date: Thu, 1 Jul 2010 04:52:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <52446A71-7366-4D3A-99C5-15BA078C2E88@apnic.net> References: <3B901BA8-9264-4CF5-A4F6-E3DDCCD47AAA@cisco.com> To: Roque Gagliano X-Mailer: Apple Mail (2.1081) Cc: sidr wg Subject: Re: [sidr] algorithm suite migration (top level scenario) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 18:52:06 -0000 I disagree Roque. My understanding was that all the references to = algorithms used in the RPKI were collected into a single document that = itself could be updated without requiring updates to all the other = documents - That central reference point is the rpki-algs document. A = second document was proposed that described how to migrate the RPKI from = one algorithm suite to another. The latter document does not obsolete = the former.=20 An update to the alg document would presumably say something along the = lines of "The standard algorithm used in the RPKI is , and use of = RSASSA-PKCS1-v1_5 is deprecated. The process of migration to use of = algorithm is described in RFC Z." This algorithm document could be = further updated to refer to other algorithms and still reference the = same migration process description. Geoff On 30/06/2010, at 11:49 PM, Roque Gagliano wrote: > Hi Steve, >=20 > Just one comment of procedure. We have now the document = draft-ietf-sidr-rpki-algs, so I guess your procedure should be in a = document that obsoletes that document in the future. There is no real = reference to algorithms in the CP now. >=20 > Roque. >=20 > On Jun 23, 2010, at 6:11 PM, Stephen Kent wrote: >=20 >> I think it might be helpful to explore some aspects of how we = envision migrating to a new algorithm suite, without debating all of the = details of migration. This way we can determine if there is agreement on = general principles re migration before we try to resolve details. >>=20 >> My notion is that the process of migration begins with the = publication of a new CP version by the IETF. That process will be very = visible and take several months to complete, at a minimum. The new CP = would specify the next algorithm suite by reference to an existing RFC = that defines the signature algorithm and hash algorithm that comprise = the suite. That RFC will have been around for a while, because we would = not consider migrating to anything other than a well-established, mature = algorithm suite. Thus the suite itself will have been defined in an RFC = well in advance. >>=20 >> I think new CP should specify the following milestones: >>=20 >> - CA Ready : By this date all (non-leaf) CAs = MUST be ready to process a request from a child CA to issue a = certificate containing a key for the new signature algorithm. The = certificate that is issued would be signed under the current algorithm = suite. The reason we need this date is because a certificate request = requires the issuing CA to verify proof of possession (PoP) for the new = key by the requesting party. Thus by this date all CAs MUS be able to = perform the PoP procedure, even if they are not yet ready to issue = certificates under the new algorithm suite. (If we decide that a = top-down migration approach is desirable, this date might apply to IANA = and the RIRs, rather than to all CAs.) >>=20 >> - CA Set : By his date all CAs MUST be = prepared to issue a certificate signed under the new algorithm suite to = a child CA that requests such. At this stage there is no requirement = that any CA issue such certificates, but rather that all (not leaf) CAs = be prepared to do so upon request. >>=20 >>=20 >> - CA Go : By this date, all (non-leaf) CAs = MUST have re-issued all child CA certificates, under the new algorithm = suite, as well as CRLs, manifests, and ROAs. The old suite is still in = use and thus CAs are maintaining parallel, synchronized sets of signed = objects under old and new algorithm suites. (If we adopt dual-signatures = for ROAs and manifests, one set of those objects can satisfy this = requirement. However, a certificate or CRL has only one signature, so = corresponding copies of these objects are still required.) >>=20 >> - RP Ready : By this date all RPs MUST be = prepared to process certificates issued under the new algorithm suite. = Since all CAs are publishing all sighed products under both suites by = now, RPs have plenty of material to process to verify that they get the = same results under old and new suites. My recommendation would be that = if the results from the new suite don't agree with the results from the = current suite, stick with the results from the current suite while you = try to figure out the problem. (This may require contacting some of the = CAs to see why there is a mismatch, but since you can keep using the = products under the current alg suite, there should be time to resolve = the problems.) >>=20 >>=20 >> - Twilight : At this date a CA MAY cease = issuing signed products under the old algorithm suite, at its = discretion. (This affects the children of the CA, so there is a need for = coordination. But, since this date is after RP Ready, no RPs should = require signed products under the old algorithm suite at this stage.) >>=20 >> - EOL : At this date NO signed objects under = the old algorithm suite are generated or consumed. More formally, every = CA and every RP MUST NOT generate certs, CRLs, or other RPKI signed = objects under the old alg suite. The transition is now complete. >>=20 >> Note that during the interval when current and new algorithm suites = are in use (from CA Set until Twilight ) a CA MUST be prepared to process key rollover requests for = children under both current and new suites. There are a lot of details = to be worked out for this. >>=20 >> I have intentionally not suggested any durations for the intervals = defined by the ordered list above. Clearly that is one of the topics we = need to address, if we agree to a model that adopts a timetable like = this. But, first we need to discuss whether these are the right = milestones. >>=20 >> Comments and suggestions are solicited. >>=20 >> Steve >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Wed Jun 30 13:15:24 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1822728C118 for ; Wed, 30 Jun 2010 13:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_50=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 Wfx9Ad7hHkbx for ; Wed, 30 Jun 2010 13:14:51 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 27CFA28C117 for ; Wed, 30 Jun 2010 13:14:47 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5UKEoJQ013228; Wed, 30 Jun 2010 15:14:50 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5UKEoLH021997; Wed, 30 Jun 2010 15:14:50 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.124]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Jun 2010 16:14:49 -0400 Date: Wed, 30 Jun 2010 16:14:49 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <52446A71-7366-4D3A-99C5-15BA078C2E88@apnic.net> Message-ID: References: <3B901BA8-9264-4CF5-A4F6-E3DDCCD47AAA@cisco.com> <52446A71-7366-4D3A-99C5-15BA078C2E88@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 30 Jun 2010 20:14:49.0953 (UTC) FILETIME=[E4952D10:01CB1890] Cc: sidr wg Subject: Re: [sidr] algorithm suite migration (top level scenario) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 20:15:24 -0000 Speaking as wg chair, I aggree with Geoff's understanding of the current wg document strategy. I can see drawbacks to the suggested process. The sidr-rpki-algs draft was instituted so that changes in algorithm would not require changes in the base specs, as an ease to implementers of the base spec and an ease to process. If we combine the discussion of the transition/migration procedure with the discussion of required algorithms, we complicate the process both now (we have to wait until both issues achieve consensus to progress either work) and also when either the algorithm requirements or the transition procedure changes. I believe there is reason to keep the discussion of algorithms requirements separate from discussion of transition/migration procedures. --Sandy, speaking as wg chair On Thu, 1 Jul 2010, Geoff Huston wrote: > I disagree Roque. My understanding was that all the references to algorithms used in the RPKI were collected into a single document that itself could be updated without requiring updates to all the other documents - That central reference point is the rpki-algs document. A second document was proposed that described how to migrate the RPKI from one algorithm suite to another. The latter document does not obsolete the former. > > An update to the alg document would presumably say something along the lines of "The standard algorithm used in the RPKI is , and use of RSASSA-PKCS1-v1_5 is deprecated. The process of migration to use of algorithm is described in RFC Z." This algorithm document could be further updated to refer to other algorithms and still reference the same migration process description. > > Geoff > > > > > On 30/06/2010, at 11:49 PM, Roque Gagliano wrote: > >> Hi Steve, >> >> Just one comment of procedure. We have now the document draft-ietf-sidr-rpki-algs, so I guess your procedure should be in a document that obsoletes that document in the future. There is no real reference to algorithms in the CP now. >> >> Roque. >> >> On Jun 23, 2010, at 6:11 PM, Stephen Kent wrote: >> >>> I think it might be helpful to explore some aspects of how we envision migrating to a new algorithm suite, without debating all of the details of migration. This way we can determine if there is agreement on general principles re migration before we try to resolve details. >>> >>> My notion is that the process of migration begins with the publication of a new CP version by the IETF. That process will be very visible and take several months to complete, at a minimum. The new CP would specify the next algorithm suite by reference to an existing RFC that defines the signature algorithm and hash algorithm that comprise the suite. That RFC will have been around for a while, because we would not consider migrating to anything other than a well-established, mature algorithm suite. Thus the suite itself will have been defined in an RFC well in advance. >>> >>> I think new CP should specify the following milestones: >>> >>> - CA Ready : By this date all (non-leaf) CAs MUST be ready to process a request from a child CA to issue a certificate containing a key for the new signature algorithm. The certificate that is issued would be signed under the current algorithm suite. The reason we need this date is because a certificate request requires the issuing CA to verify proof of possession (PoP) for the new key by the requesting party. Thus by this date all CAs MUS be able to perform the PoP procedure, even if they are not yet ready to issue certificates under the new algorithm suite. (If we decide that a top-down migration approach is desirable, this date might apply to IANA and the RIRs, rather than to all CAs.) >>> >>> - CA Set : By his date all CAs MUST be prepared to issue a certificate signed under the new algorithm suite to a child CA that requests such. At this stage there is no requirement that any CA issue such certificates, but rather that all (not leaf) CAs be prepared to do so upon request. >>> >>> >>> - CA Go : By this date, all (non-leaf) CAs MUST have re-issued all child CA certificates, under the new algorithm suite, as well as CRLs, manifests, and ROAs. The old suite is still in use and thus CAs are maintaining parallel, synchronized sets of signed objects under old and new algorithm suites. (If we adopt dual-signatures for ROAs and manifests, one set of those objects can satisfy this requirement. However, a certificate or CRL has only one signature, so corresponding copies of these objects are still required.) >>> >>> - RP Ready : By this date all RPs MUST be prepared to process certificates issued under the new algorithm suite. Since all CAs are publishing all sighed products under both suites by now, RPs have plenty of material to process to verify that they get the same results under old and new suites. My recommendation would be that if the results from the new suite don't agree with the results from the current suite, stick with the results from the current suite while you try to figure out the problem. (This may require contacting some of the CAs to see why there is a mismatch, but since you can keep using the products under the current alg suite, there should be time to resolve the problems.) >>> >>> >>> - Twilight : At this date a CA MAY cease issuing signed products under the old algorithm suite, at its discretion. (This affects the children of the CA, so there is a need for coordination. But, since this date is after RP Ready, no RPs should require signed products under the old algorithm suite at this stage.) >>> >>> - EOL : At this date NO signed objects under the old algorithm suite are generated or consumed. More formally, every CA and every RP MUST NOT generate certs, CRLs, or other RPKI signed objects under the old alg suite. The transition is now complete. >>> >>> Note that during the interval when current and new algorithm suites are in use (from CA Set until Twilight ) a CA MUST be prepared to process key rollover requests for children under both current and new suites. There are a lot of details to be worked out for this. >>> >>> I have intentionally not suggested any durations for the intervals defined by the ordered list above. Clearly that is one of the topics we need to address, if we agree to a model that adopts a timetable like this. But, first we need to discuss whether these are the right milestones. >>> >>> Comments and suggestions are solicited. >>> >>> Steve >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >