[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
- [sidr] addendum Stephen Kent
- Re: [sidr] addendum Eric Osterweil