Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

Stephen Kent <kent@bbn.com> Tue, 03 May 2011 09:45 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA551E06F2; Tue, 3 May 2011 02:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.305
X-Spam-Level:
X-Spam-Status: No, score=-104.305 tagged_above=-999 required=5 tests=[AWL=2.294, 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 HZNTGdx8hQC1; Tue, 3 May 2011 02:45:58 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E6E06AA; Tue, 3 May 2011 02:45:58 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:58447 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QHCB3-000K0y-7J; Tue, 03 May 2011 05:45:57 -0400
Mime-Version: 1.0
Message-Id: <p06240808c9e45144c8f9@[10.242.22.94]>
In-Reply-To: <tsl62q2tj33.fsf@mit.edu>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu> <4D79271E.6080707@vpnc.org> <tslzkp2elyf.fsf@mit.edu> <p06240801c9ce424e70b1@[128.89.89.62]> <tsl62q2tj33.fsf@mit.edu>
Date: Tue, 03 May 2011 05:05:01 -0400
To: Sam Hartman <hartmans-ietf@mit.edu>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2011 09:45:58 -0000

At 12:02 PM -0400 4/25/11, Sam Hartman wrote:
>...
>
>
>However, when I look at section 2.1.4 in the signed-object document ,
>the signer can only include one certificate.
>How does that work during phase 2 when some of the RPs support the new
>format and some only support the old format?
>Your text above suggests that RPs grab the certificates from the RPKI
>repository, but it seems at least for end entity certificates they are
>included in the signed object.
>What happens for end entity certificates during this form of upgrade?

Sam,

Yes, only one cert is associated with an RPKI signed object, and yes, 
this cert is embedded in the signed object format. So, when a new 
cert is issued, using a new format, the object itself is changed. 
Thus, the text describing Phase 2 is saying that there will be 
parallel instances of certs, CRLs, and signed objects in the RPKI 
repository system, associated with the old and new cert/CRL formats.
I could add a sentence or two making this explicit, and referring the 
reader to the  phased transition strategy used for algorithm 
transition in the RPKI, and described in 
draft-sidr-algorithm-agility. The reference would be informative, as 
this I-D is still in development and I don't want to hold up the 
progress of the rest of the SIDR docs.

Let me know if this addresses your question.

Steve