Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Brian Dickson <brian.peter.dickson@gmail.com> Tue, 08 November 2011 12:48 UTC
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6999721F8B29 for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 04:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level:
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g51nVYOFqMKG for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 04:48:21 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E662521F8B39 for <sidr@ietf.org>; Tue, 8 Nov 2011 04:48:18 -0800 (PST)
Received: by faas12 with SMTP id s12so579190faa.31 for <sidr@ietf.org>; Tue, 08 Nov 2011 04:48:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vcqSfABbNjB2HFkhnCKsCDcDLJPvnkOsKj8V7HrztAY=; b=lRfPH8+DaBTnQ9a/VCtC/gKjDxNX8A7jc+H39gqIgaDO8bYfJ9q2+GA935gbK52fj0 HchQNXmKKLYRNXG7Fwlk2GOrRuEIFfruAcj0pQGVPzaWCV+a0JUzDBmsgV2i7xFmqmXS fzjLpzmJiNALHdgKmkmDZyWRuMYV+TUtVdJ50=
MIME-Version: 1.0
Received: by 10.223.58.8 with SMTP id e8mr16150742fah.27.1320756498025; Tue, 08 Nov 2011 04:48:18 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Tue, 8 Nov 2011 04:48:17 -0800 (PST)
In-Reply-To: <BC53A8AD-CABC-4AAC-8B08-EBD0CB825350@cisco.com>
References: <Pine.WNT.4.64.1110201037470.4820@SMURPHY-LT.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> <CAH1iCipuaB=niUZY2WQdMX8REDVTWGjhosxTyq1AekkUiLZ=FQ@mail.gmail.com> <BC53A8AD-CABC-4AAC-8B08-EBD0CB825350@cisco.com>
Date: Tue, 08 Nov 2011 07:48:17 -0500
Message-ID: <CAH1iCip1Eb7X2PMjiHJ0K9zhTJJLS0HWhzeBGS080m54bZE1jQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Roque Gagliano <rogaglia@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Murphy, Sandra" <Sandra.Murphy@cobham.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2011 12:48:22 -0000
On Tue, Nov 8, 2011 at 5:40 AM, Roque Gagliano <rogaglia@cisco.com> wrote: > Hi Brian, > Thanks for your comments. > Please see inline. > Roque > > (snif) > > So the analogous high-level design for agility SHOULD be as follows: > - new CP documents may be published, with new OIDs > > > The CP document in section 6.1.5 refers the definition of the Algorithm > Suite to the draft-ietf-sidr-rpki-algs document. There are not OID defined > in the CP document. That is why in our document we refer to an update of > this document instead. I was actually referring to the OID _of_ the CP document itself, draft-ietf-sidr-cp-17, in section 1.2. And in draft-ietf-sidr-res-certs-22, section 9, use of that OID is referenced, including how the change of OID gets handled. The change-of-OID process identified there would be necessary, even if the res-certs format did not change, so long as there was some other reason for the OID change. And in draft-ietf-sidr-cp-17, section 9.12.3 describes when the OID must change. Clearly, changing the algorithm RFC used by the CP, would require a new CP with a new OID, since it directly affects acceptability of RPKI certificates. > - ONLY when a CA with a given CPS decides to change CP does that CA > need to execute a locally-significant key+alg roll > - The CA would issue new certs with the new CP which itself lists > additional algorithms > - The same procedure would be executed in multiple phases - issue new > child certs published under the old main cert; move them to the new > cert, rewriting/overwriting in the same location > > > In section 4.1 we defined: > > CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST > be ready to process a request from a child CA to issue a > certificate under the Algorithm B suite What I am saying is, there is no reason to require a change to a child's CPS, and thus its CP, and thus its algorithm suite, simply because the parent CA is making this change. The whole 'all (non-leaf)' stuff is un-necessary. Each CA may operate its CPS independently. Algorithms are explicitly included via OIDs in every cert. A child CA may need to sign with algorithms accepted by the parent CA, but they can issue certs with a different CP, signed according to the algorithms _of_that_CP_ (their own CP, independent of the choice of CP used by the parent CA). The choice of algorithm acceptability for a given cert, comes from the CP. It needs internal consistency. There is no further requirement on algorithm choice. > If I summarize your comment, you are stating that the definition of "ready" > for a CA should also include an update on its CPS to refer to the new suite. > This was understood but as what each CA will need to do to be ready to > process requests from a child CA is local to that CA, we did not got into > the details. Okay, yes, that was the bit I said was technically correct... > The process that you have described is indeed the proposed algorithm in the > document for the CAs, where we adopted a "top-down" process and we maintain > the two suites independent. The document also includes the transition to the > new suite on the RPs that are distributed globally. That's the part I disagree with entirely - there is no "top-down" required at all. There is no "globally". There is only the requirement operationally that any newly published CP with new OID be supported by RPs. The publishing the new CP with new OIDs with sufficient time for RPs to implement those changes is the only timeline issue. It is a "sunrise" issue - a minimum time after publication before ANY CA begins to issue certs using the new OID. After that date, any CA may choose to use the new CP, without requiring any change to either the CA's parent, or the CA's children, except as relates to the algorithms used on new certs, which the child needs to discover. This has no bearing on the CP _used_ by the child CA in issuing certs to grand-child CAs - that is under the local policy of the child CA. Every CA is free to choose the CP it uses from among the published CPs, modulo the issue date plus delay required (6 months in the initial CP document). Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to change algorithm suite. Perhaps a separate BCP can recommend, or even require, use of some subset of CP documents, or at some point an old CP could be moved to historic or depracated status. However, that should _not_ be part of the alg-agility document. Agility should limit itself to the mechanism by which a _single_ CA changes algorithm suite, including the possibility that the new suite still include all the algorithm(s) from the previous suite, the possibility that multiple algorithms are part of the new suite, as well as case of (but not a requirement that) _an_ older algorithm is dropped from the suite. > Regards, > Roque Sincerely, Brian
- [sidr] WGLC for draft-ietf-sidr-algorithm-agility… Sandra Murphy
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Arturo Servin
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Paul Hoffman
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Samuel Weiler
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Randy Bush
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Sean Turner
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil