Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04

Stephen Kent <> Mon, 28 March 2011 07:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7910B3A68D2; Mon, 28 Mar 2011 00:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P1AIJoHji3Dm; Mon, 28 Mar 2011 00:46:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A40D03A6886; Mon, 28 Mar 2011 00:46:08 -0700 (PDT)
Received: from ([]:51200 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1Q47Av-000Ou4-NS; Mon, 28 Mar 2011 03:47:45 -0400
Mime-Version: 1.0
Message-Id: <p06240804c9b5ec3f841b@[]>
In-Reply-To: <>
References: <>
Date: Mon, 28 Mar 2011 03:47:29 -0400
To: Brian Weis <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Mar 2011 07:46:09 -0000

At 1:37 PM -0700 3/27/11, Brian Weis wrote:
>I have reviewed this document as part of the security directorate's 
>ongoing effort to review all IETF documents being processed by the 
>IESG. These comments were written primarily for the benefit of the 
>security area directors. Document editors and WG chairs should treat 
>these comments just like any other last call comments.
>This document describes the algorithm suite used as part of the 
>RPKI. The suite specifies a single signature algorithm (RSA) with a 
>single key size, a single hashing algorithm (SHA-256), a single 
>signature format, and formats for describing the public key. Section 
>5 indicates that this profile will be updated when the RPKI needs to 
>adapt different choices. I was glad to see such an algorithm agility 
>plan, but this implies that this will in fact never have a peer 
>document describing another profile. In such a case I would expect 
>the document title to be more inclusive (e.g., drop the first three 
>words of the title). Alternatively, it might be helpful to describe 
>in Section 5 under what circumstance another profile would be 
>published instead of updating this one.
>The Security Considerations document refers the reader to the 
>security considerations described in several other documents. After 
>reading those sections, I agree this is appropriate.


There will be another profile that will define two sets of algs, 
current and next.  See daft-sidr-algorithm-agility-00.txt for the 
description of how alg migration is anticipated to work. I hesitate 
to put a (normative) reference to that doc in here, because it is not 
yet approved and might slow down the
set of SIDR docs that rely, normatively, on the doc that you reviewed.