Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Stephen Kent <kent@bbn.com> Wed, 09 November 2011 21:51 UTC

Return-Path: <kent@bbn.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 782DA11E8085 for <sidr@ietfa.amsl.com>; Wed, 9 Nov 2011 13:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.46
X-Spam-Level:
X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 pSIkTUW184Fj for <sidr@ietfa.amsl.com>; Wed, 9 Nov 2011 13:51:22 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE15A11E809A for <sidr@ietf.org>; Wed, 9 Nov 2011 13:51:22 -0800 (PST)
Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49163) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ROG2d-0006io-8t; Wed, 09 Nov 2011 16:50:43 -0500
Mime-Version: 1.0
Message-Id: <p0624080ccae07aaa8047@[128.89.89.6]>
In-Reply-To: <CAH1iCip1Eb7X2PMjiHJ0K9zhTJJLS0HWhzeBGS080m54bZE1jQ@mail.gmail.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> <CAH1iCip1Eb7X2PMjiHJ0K9zhTJJLS0HWhzeBGS080m54bZE1jQ@mail.gmail.com>
Date: Wed, 09 Nov 2011 16:50:24 -0500
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "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: Wed, 09 Nov 2011 21:51:23 -0000

At 7:48 AM -0500 11/8/11, Brian Dickson wrote:
>...
>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.

this text makes it sound as though there is a per CA CP. The CP for 
the RPKI is global. One possibility is that the CP is updated to 
refer to two alg suites, and two policy OIDs, supplanting the old CP. 
Since the changes would be limited to a vert small part of the CP, it 
is not clear that one would want to have multiple CPs in place for 
the RPKI at the same time. Also, removing the alg description from 
the CP was intended to make the change to a new alg suite more 
modular. Still, the difference between two CPs or one is not so 
critical to this discussion.

>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).

Every CA nominally has a CPS, so part of the statement above is 
confusing. There are limitations to what a CA can do vs. what algs 
its parent supports, e.g., because of PoP.

>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.

not entirely true.  each CA MUST perform PoP (3.2.1 of the CP) when 
issuing a cert to a subordinate CA. To perform PoP, the issuer must 
be prepared to deal with the alg in the subordinate CA's public key 
info.

>  > 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.

Top down is strongly motivated because of the PoP issue, and because of the
repository growth issue. the WG agreed to mandate top down alg 
transition last year (July, 2010), after a briefing at IETF 78. See 
the proceedings for details.

>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.

The very brief description provided above does not contain sufficient 
detail to enable it to be compared to the current proposal. it also 
fails to address issues such as PoP, repository growth, and the 
burden imposed on CAs and RPs to support algs forever, if some small 
set of CAs or RPs choose to not transition.

>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.

We do not believe that alg suite changes are unilateral decisions by 
CAs, for the various reasons cited above.

Steve