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

Terry Manderson <terry.manderson@icann.org> Mon, 31 October 2011 02:18 UTC

Return-Path: <terry.manderson@icann.org>
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 2E27111E80A2 for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 19:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 5pvsintgsrXu for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 19:18:52 -0700 (PDT)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9606A11E809F for <sidr@ietf.org>; Sun, 30 Oct 2011 19:18:52 -0700 (PDT)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 30 Oct 2011 19:18:48 -0700
From: Terry Manderson <terry.manderson@icann.org>
To: "sidr@ietf.org" <sidr@ietf.org>
Date: Sun, 30 Oct 2011 19:18:46 -0700
Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Thread-Index: AcyPN6DKanq91Yz1QWmcfdgUHGAbjAIO8pB8
Message-ID: <CAD442A6.1C32B%terry.manderson@icann.org>
In-Reply-To: <Pine.WNT.4.64.1110201037470.4820@SMURPHY-LT.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" <draft-ietf-sidr-algorithm-agility@tools.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 02:18:53 -0000

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.

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

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


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

Section 6.

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

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)

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


.. If these concerns can be addressed, then I think the document is ready to
move on.

Cheers
Terry




On 21/10/11 12:50 AM, "Sandra Murphy" <Sandra.Murphy@sparta.com> wrote:

> The authors have requested a WG LC for draft "Algorithm Agility Procedure
> for RPKI."
> 
> The document and the draft version history are available at
> http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03
> 
> The last call will end Thu, 3 Nov 2011 (AOE).
> 
> As usual, please address all comments to the WG mailing list, and
> please be clear in your comments to this last call if you are
> supporting the document's submission to the IESG or if you are
> opposed. If you are opposed, please indicate why.
> 
> --Sandy, speaking as wg chair with appropriate ceremonial garb donned
>           (and covered with ashes for having neglected this)
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr