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

Roque Gagliano <rogaglia@cisco.com> Tue, 08 November 2011 14:17 UTC

Return-Path: <rogaglia@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3442521F8CB4 for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 06:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.894
X-Spam-Level:
X-Spam-Status: No, score=-8.894 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 NoR8h7pBfwvw for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 06:17:01 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DCBE421F899F for <sidr@ietf.org>; Tue, 8 Nov 2011 06:17:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8817; q=dns/txt; s=iport; t=1320761821; x=1321971421; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=yoqS5NPjZqjf5SXwgXQ1cCvjQDdxkoyM1tJ6xPH7HM4=; b=Yf7C5elIswfCN0UpOFLLcZJJlfsOP8J5bU+jV5FeuXhgkdD86Tesl9qJ vWqAzwwYMJRvg+giZkC9FLB9/n5igG4WhbSLrfuX0m/M7mlJ9Pubp//8H MxnZ+34AZPpHV0/gxcDObgTJM4Ar9wF26b6aQ1EtjY6S1AhET15menHfW g=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANg4uU6Q/khN/2dsb2JhbAA6CaoHgQWBcgEBAQMBEgFgBgULC0YCVQY1h2CYcQGfJYV9gk1jBJQhkW8
X-IronPort-AV: E=Sophos; i="4.69,477,1315180800"; d="p7s'?scan'208"; a="59424259"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Nov 2011 14:16:59 +0000
Received: from dhcp-vlan250-10-147-19-222.cisco.com (dhcp-vlan250-10-147-19-222.cisco.com [10.147.19.222]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA8EGwo1022771; Tue, 8 Nov 2011 14:16:58 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-236-1004717977; protocol="application/pkcs7-signature"; micalg=sha1
From: Roque Gagliano <rogaglia@cisco.com>
In-Reply-To: <CAH1iCip1Eb7X2PMjiHJ0K9zhTJJLS0HWhzeBGS080m54bZE1jQ@mail.gmail.com>
Date: Tue, 8 Nov 2011 15:16:55 +0100
Message-Id: <083152D5-D693-4BD4-A1D9-325C78192E8A@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> <CAH1iCip1Eb7X2PMjiHJ0K9zhTJJLS0HWhzeBGS080m54bZE1jQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: "sidr@ietf.org wg" <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 14:17:02 -0000

Hi Brian,

Lets focus on this part:

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

This is fine in a model where every CA lives in its own island (think on the identity case) but not in our case. A CA needs to issue a certificate-signing-request to its parent CA.

The WG decided to not allow "mixed" CA certificates. Consequently, you need your parent to be "ready" before been able to issue the CSR. This is the reason for the "top-down" requirement. So for "any" CA to issue certs using the new OID it needs that it parent has migrated first.

The rest of your reasoning seams to go around the same concept.

Roque.



> 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