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

Stephen Kent <kent@bbn.com> Mon, 11 July 2011 17:27 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 E170321F8DAF for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 10:27:14 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 iwFlLHnTDlkl for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 10:27:14 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD50611E8086 for <sidr@ietf.org>; Mon, 11 Jul 2011 10:27:10 -0700 (PDT)
Received: from dhcp89-089-024.bbn.com ([128.89.89.24]:49196) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QgKGD-0003WK-BI; Mon, 11 Jul 2011 13:27:10 -0400
Mime-Version: 1.0
Message-Id: <p06240800ca40dd314fe7@[192.168.1.10]>
In-Reply-To: <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com>
References: <20110708161252.27961.972.idtracker@ietfa.amsl.com> <42FAFCD2-C5F0-471C-8E90-A6AF0EC17DE6@cisco.com> <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com>
Date: Mon, 11 Jul 2011 13:17:22 -0400
To: Brian Weis <bew@cisco.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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: Mon, 11 Jul 2011 17:27:15 -0000

At 12:08 PM -0700 7/8/11, Brian Weis wrote:
>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.

Agreed. The CP cites the alg spec (draft-ietf-sidr-rpki-algs). 
However, this doc say that the alg specs doc will be updated to 
reflect the new alg suite, and to include the timeline for the alg 
transition. Once that happens, a failure to comply with the alg 
transition procedure described here will imply noncompliance with the 
CP.


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

There is no cross-certification (in the common, but incorrect, use of 
the term) in the RPKI, because of the constraints imposed by the 3779 
extensions. Still, I agree that the definition could be improved. How 
about:

Non-leaf CA: A CA that issues certs to other CAs in a non-leaf CA. In 
contrast, a leaf CA is a CA that issues only EE certs.

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

Yes, it would be more accurate to say "at the start of Phase 2, all 
signed products ..."