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

Stephen Kent <kent@bbn.com> Mon, 31 October 2011 10:57 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 078EB21F8D84 for <sidr@ietfa.amsl.com>; Mon, 31 Oct 2011 03:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.358
X-Spam-Level:
X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 Bo6QTZQ+sYS7 for <sidr@ietfa.amsl.com>; Mon, 31 Oct 2011 03:57:06 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9221F8D82 for <sidr@ietf.org>; Mon, 31 Oct 2011 03:57:06 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:47077 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RKpY6-000Czw-Ta; Mon, 31 Oct 2011 06:57:03 -0400
Mime-Version: 1.0
Message-Id: <p06240800cad408dcc770@[192.168.49.238]>
In-Reply-To: <CAD442A6.1C32B%terry.manderson@icann.org>
References: <CAD442A6.1C32B%terry.manderson@icann.org>
Date: Mon, 31 Oct 2011 06:57:00 -0400
To: Terry Manderson <terry.manderson@icann.org>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" <draft-ietf-sidr-algorithm-agility@tools.ietf.org>, "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: Mon, 31 Oct 2011 10:57:07 -0000

At 7:18 PM -0700 10/30/11, Terry Manderson wrote:
>Some comments.
>
>Section 4.3. Phase 0
>
>I'm still struggling to see the necessity to put in the operational dates
>for a Alg shift in [I-D.ietf-sidr-rpki-algs]. I concur that the future Alg
>suite and to be EOL's suite should be identified once suitable candidates
>have been selected in rpki-algs. But the dates in which the ALGs come into
>effect[1], and are twiglighted/EOL'd seems like a operational CA/RP concern,
>in a hierarchical manner, and would probably end up in the CA's CPS. As such
>I question the viability, and validity, of fixing dates in the IETF.

We have included dates for alg start an EOL because they affect all 
RPs, and we want to make life predictable for RPs. Also, because the 
WG agreed that alg transition will be top-down (to avoid geometric 
growth in the repository system), it is necessary to set alg 
transition dates, for the benefit of
CAs as well.

>[1] I would think that as soon at the document is updated and published they
>are able to be used.

The top tier CAs have to be ready to issue certs under the new alg before
any lower tier CAs can do so, so we need a set date, agreed upon, in 
the future,
to start the transition.

>Phase 3
>
>This section confuses me, the draft says that the RF MUST be able to do both
>algorithms, but its recommended to only use Suite B.
>
>The first sentence seems superfluous to me. Why not just:
>" Phase 3 starts at the RP Ready Algorithm B Date.  During this phase,
>    all signed product sets are available using both algorithm suites.
>    It is RECOMMENDED that RPs utilize only
>    Suite B for validation throughout this phase, in preparation for
>    Phase 4. RPs MAY use Suite A if operationally necessary" ? (ie similar
>wording as used in the Phase 4 Suite A/C observation.)
>
>If that first sentence part " RPs MUST be able to .." is a necessity, it
>makes me start thinking about a matrix decision process of using Suite A
>(and|or) Suite B - which isn't described here.
>
>or perhaps not even mention the RP's responsibility to Suite A in Phase 3??
>...

We want to encourage RPs to verify their ability to use the new Suite, but
we also realize that, during transition, there may be problems. So, 
we RECOMMEND use of Suite B, but require that if either Suite works, 
the RP MUST accept the data as valid. That provides a fall back 
position in case a CA doesn't get it right.

>Phase 4.
>
>The ordering of the sentences could be shuffled I think.
>
>The important statement is that the "CAs MUST neither issue nor publish
>signed products using Algorithm Suite C" ... therefore any erroneous
>issuance of suite C products MUST be considered invalid.

we can revisit this text to try to make it clearer, if others agree with
your observation.

>  Section 5.
>
>I think some discussion of the dates, and for communicating twilight and EOL
>dates between the parent and the child should be here. I don't quite hold
>the belief that it's a unidirectional downward assertion from parent to
>child. In may well be in PKI - there there is a raft of operational
>interaction  that surrounds that.

The dates for alg transition are published and accessible to 
everyone, so there is no need for pairwise communication of the 
dates. Because the alg transition affects ALL RPs, not just the 
children of a given CA, it is important to mandate the transitions on 
a global basis.

>Section 6.
>
>Can you spell out what you technically mean by "keep any relationship
>between " in para 1?

We will revise this sentence. The text is intended to note that the 
data extracted from the repository, signed under each alg, are 
treated separately. Thus one gets a compete, valid chain of data via 
Suite A or Suite B, but not a mix of data under A and B. The next 
paragraph explains this.

>Section 7.
>
>Can you expand the recommendation in keeping the parallel certificate
>hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4)

In phase 4, Suite C products MAY be present, which means that they 
also may be absent. So, we cannot say that the hierarchies are 
parallel any more.

>Twilight doesn't necessarily mean "dead wood is o.k".. since products MAY
>still be constructed.

Not sure what you mean by the above sentence.

Steve