[sidr] addendum

Stephen Kent <kent@bbn.com> Mon, 14 November 2011 05:24 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 5C1941F0C6D for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 21:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Level:
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 hxW7oDdDAUuR for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 21:24:40 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 994C81F0C4F for <sidr@ietf.org>; Sun, 13 Nov 2011 21:24:40 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:54142 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RPp26-0005K1-8c; Mon, 14 Nov 2011 00:24:38 -0500
Mime-Version: 1.0
Message-Id: <p06240802cae65275fc1b@[130.129.18.170]>
Date: Mon, 14 Nov 2011 00:21:06 -0500
To: eosterweil@verisign.com
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: sidr@ietf.org
Subject: [sidr] addendum
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, 14 Nov 2011 05:24:41 -0000

Eric,

I forgot to address an issue that you mentioned in a previous message,
and that relates to the alg agility doc.

The alg spec for the RPKI is separate from the CP, precisely so that 
we could change the algs without changing the CP. So, when the alg 
spec is replaced to introduce the next set of algs, we do not plan to 
re-issue the CP. As a result, the cert policy OID will not change as 
a side effect of the alg transition.

I discussed this assumption re OID stability with several PKI experts 
today, and they agreed that there is no need to change the policy OID.

i mention this because I recall that a previous message touched on 
this question, and I realize that the alg agility doc failed to 
mention this.  The next rev will make this explicit.

Steve