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

Stephen Kent <kent@bbn.com> Thu, 17 November 2011 05:28 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 37AB121F9683 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 21:28:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.538
X-Spam-Level:
X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EOyr7SEsxdS9 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 21:28:12 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E655221F967E for <sidr@ietf.org>; Wed, 16 Nov 2011 21:28:11 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:57390 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RQuW7-000OfF-K4; Thu, 17 Nov 2011 00:28:09 -0500
Mime-Version: 1.0
Message-Id: <p06240801cae63c0d5322@[172.20.1.65]>
In-Reply-To: <CAH1iCiotmm47yZ_S_JyY8a0cODPFcnLe-CUSbzjYm7fdPcZDkA@mail.gmail.com>
References: <CAD6DA02.1C611%terry.manderson@icann.org> <p06240803cad6af1b0ce7@193.0.26.186> <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <p06240803cad951813fd9@193.0.26.186> <CB6FE413-BEC2-4910-AEEF-98D6EAFD4E83@verisign.com> <p06240802cadde494171b@128.89.89.6> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> <p06240811cade1873e723@128.89.89.6> <BDA75A7E-2B2D-44A5-A18F-2D7DA01DF3A2@verisign.com> <p06240808cadf618efaa8@128.89.89.6> <E9BAE21C-A8EF-4D07-90C1-E8A5FD7F00E7@verisign.com> <p06240803cae62a2b13af@128.89.89.129> <CAH1iCiotmm47yZ_S_JyY8a0cODPFcnLe-CUSbzjYm7fdPcZDkA@mail.gmail.com>
Date: Thu, 17 Nov 2011 00:13:56 -0500
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-890614808==_ma============"
Cc: "sidr@ietf.org list" <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: Thu, 17 Nov 2011 05:28:13 -0000

At 10:25 PM -0500 11/13/11, Brian Dickson wrote:
>On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <kent@bbn.com> wrote:
>>  You suggested that we codify how the community should deal with problems
>>  that motivate delaying a phase transition. We're not writing the timeline
>>  document now, but the text at the beginning of this message is an effort to
>>  make sure such considerations are addressed in that document.
>
>When you say "timeline document", do you mean "timeline for specific
>implementation of the phases in this document"?
>
>I ask because the algorithm-agility sure looks like a timeline document.

I mean a document that associates dates with the phases described in the
alg agility doc. I've reworded the agility doc to say "timetable" 
instead of "timeline" to try to avoid confusion.

>...
>
>This statement is entirely predicated on having Phase 2, as it is currently
>defined, after Phase 1 (CAs ready for receiving B) and before Phase 3
>(when RPs are able to validate using B). I don't see what this step
>in this order, buys us, or even that it is necessary at all.

Phase 1 allows early adopter CAs to get certs under the new alg 
suite, but does not require them to do a lot of work, because they 
don't have to issue new certs except for the children who ask for 
them.

Phase 2 requires CAs to do this work, which enables RPs to test their 
RP software with the new alg, if they wish, i.e., another early 
adopter capability.

Phase 3 says RP have to be able to do this.

I think the order makes sense.

>Let's take a look at what happens after Phase 3:
>- RPs speak "B".
>- CAs can process "B".

This characterization strikes me as backwards. RPs process Suite B 
products. CAs generate Suite B products. CAs "process" requests for 
certs under Suite B. But, let's not quibble.

The rest of your message argues that Phase 2 is unnecessary. But, you 
acknowledge the need for CAs and RPs to experiment with software that 
supports Suite B, and processes that support transition from A to B. 
Thart is precisely what Phase 2 enables. It gives RPs time to work on 
processing Suite B product sets, but it does not require that they do 
so. Also, if some CAs didn't get the Suite B product set generation 
right there is an opportunity to provide feedback, but Suite A 
products sets are still there, so things don't break.  Trying to move 
from Phase 1 to Phase 3, as you suggest seems very likely to cause 
things to break, especially when coupled with the notion that a CA 
can decide to make use of only Suite B if it wishes.

Steve