Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-01.txt

Brian Weis <bew@cisco.com> Fri, 08 July 2011 19:08 UTC

Return-Path: <bew@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 3BD6621F8ACB for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 12:08:50 -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=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNJWbCuaL4jA for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 12:08:49 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 60C4221F8AC5 for <sidr@ietf.org>; Fri, 8 Jul 2011 12:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3161; q=dns/txt; s=iport; t=1310152129; x=1311361729; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ojVvsrQyatTm5wosnXtkCfDTDsRgYm4Yy6+WGywBVv0=; b=mPVAoaDa1hmn2h8n48dkRFytTcJk71m1RTy3c+oj9K/mejKotUDRC8Q7 cLY16NZGMX/0K4iUTjaE6PJEv2Xe8ZW3ivdSizCJsWRg5sb6mIZ/iI9P8 TGwTt1Whc+38pm9oi9ZnFgqB6S6huxlSBPdyJlUKNYGJh6Qj2DxVaZrhW o=;
X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="1157503"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jul 2011 19:08:49 +0000
Received: from dhcp-128-107-147-1.cisco.com (dhcp-128-107-147-1.cisco.com [128.107.147.1]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p68J8mxa024779; Fri, 8 Jul 2011 19:08:48 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Brian Weis <bew@cisco.com>
In-Reply-To: <42FAFCD2-C5F0-471C-8E90-A6AF0EC17DE6@cisco.com>
Date: Fri, 08 Jul 2011 12:08:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com>
References: <20110708161252.27961.972.idtracker@ietfa.amsl.com> <42FAFCD2-C5F0-471C-8E90-A6AF0EC17DE6@cisco.com>
To: Roque Gagliano <rogaglia@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: "sidr@ietf.org wg" <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-01.txt
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: Fri, 08 Jul 2011 19:08:50 -0000

Hi Roque,

This draft seems very complete. I have just a few questions and comments:

1. Section 2. "A failure to comply with this process during an algorithm transition MUST be considered as non-compliance with ...
I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply with this process would be result in non-compliance. It would be hopeful to more specific here.

2. Section 3. The definition of a "Non-Leaf CA" is "A CA that issues certificates to entities not under its administrative control." I believe this effectively  means "CAs that have children", and if that's the intended meaning perhaps that's a better statement. The present definition could apply to a CA cross-certifying another CA and other non-child certificate signing. Even if those situations don't expect to be possible within the RPKI, it would be helpful to clarify the definition. Also, it's not clear to me that a child CA is "under its administrative control" in the sense that the child CA (e.g., ISP) might not be administered by the parent (e.g., RIR).

3. Section 4.2. "The only milestone that affects both CAs and RPs, at the same moment is the EOL date.". But the "Process for RPKI CAs" figure shows that two milestones are aligned: (5) and (6). How do these reconcile?

4. Section 4.3. The alignment errors that Arturo mentioned don't seem to be fixed in -01. Did you mean to adjust them? Also, it might be worth stating explicitly in the Note following this first example that the indentation mean "signed by".

5. Section 4.5. "During this phase all signed product sets MUST be available using both Algorithm Suite A and Algorithm Suite B." It isn't clear to me what "During this phase" means in Phase 2. Does it mean "By the end of this phase"? Or does it mean "Before the start of Phase 3", which is not the same moment in time according to the figures in Section 4.2. I'm inclined to think it means "Before the start of Phase 3", because by Phase 3 "all product sets are available". Although again, Section 4.6 uses the phrase "During this phrase" so that also isn't clear and I would recommend being more precise here too.

6. Section 4.5. "An RP that validates all signed product sets using both Algorithm Suite A or Algorithm Suite B, SHOULD expect the same results." The text added to this paragraph in -01 clarifies how to resolve certificate validation results that differ, but I think it would be helpful to include references to both Sections 6 and 7 here which cover issues when on there are differences in validation more thoroughly.

7. (nit) The references for I-D.ietf-sidr-cp didn't get updated to -17. I didn't check other references.

Thanks,
Brian

On Jul 8, 2011, at 9:14 AM, Roque Gagliano wrote:

> In this new version we included the changes from the review by Arturo and several editorial nits.
> 
> Please take a look at the document and send your comments.
> 
> Roque.

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com