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

Sandra Murphy <Sandra.Murphy@sparta.com> Mon, 11 July 2011 17:44 UTC

Return-Path: <Sandra.Murphy@cobham.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 9056A21F8784 for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 10:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.549
X-Spam-Level:
X-Spam-Status: No, score=-100.549 tagged_above=-999 required=5 tests=[AWL=2.050, 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 NJ+s6mv1ALyv for <sidr@ietfa.amsl.com>; Mon, 11 Jul 2011 10:44:09 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A33C921F85CE for <sidr@ietf.org>; Mon, 11 Jul 2011 10:44:09 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p6BHi2AP005653; Mon, 11 Jul 2011 12:44:03 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p6BHi219003959; Mon, 11 Jul 2011 12:44:03 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.116]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 13:44:02 -0400
Date: Mon, 11 Jul 2011 13:44:01 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <p06240800ca40dd314fe7@[192.168.1.10]>
Message-ID: <Pine.WNT.4.64.1107111340180.3744@SMURPHY-LT.columbia.ads.sparta.com>
References: <20110708161252.27961.972.idtracker@ietfa.amsl.com> <42FAFCD2-C5F0-471C-8E90-A6AF0EC17DE6@cisco.com> <AAA28269-7DC5-4E19-A05B-6FAA4DF01388@cisco.com> <p06240800ca40dd314fe7@[192.168.1.10]>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 11 Jul 2011 17:44:02.0068 (UTC) FILETIME=[1EF17D40:01CC3FF2]
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:44:10 -0000

On Mon, 11 Jul 2011, Stephen Kent wrote:

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

S---T---R---E---T---C---H???

If the non-compliance with this draft was to fail to update the algs 
document, then the failure to comply with the procedure would not imply 
non-compliance with the CP.

--Sandy, speaking as wg chair



>
>
>> 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 ..."
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>