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

Stephen Kent <kent@bbn.com> Mon, 28 March 2011 16:18 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A443A680D; Mon, 28 Mar 2011 09:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level:
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJVAPC4aKi31; Mon, 28 Mar 2011 09:18:27 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 94D993A67E5; Mon, 28 Mar 2011 09:18:27 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:44744 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Q4FAi-0005qt-LZ; Mon, 28 Mar 2011 12:20:05 -0400
Mime-Version: 1.0
Message-Id: <p0624080bc9b617cf5725@[130.129.71.125]>
In-Reply-To: <18783D32-D6AD-48AF-853D-3A6B67B9F9FE@cisco.com>
References: <BC4FD686-8AE2-472C-9677-B7DA1FA10060@cisco.com> <p06240804c9b5ec3f841b@[130.129.71.125]> <18783D32-D6AD-48AF-853D-3A6B67B9F9FE@cisco.com>
Date: Mon, 28 Mar 2011 12:19:55 -0400
To: Brian Weis <bew@cisco.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-910793292==_ma============"
Cc: sidr-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-sidr-rpki-algs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-rpki-algs-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 28 Mar 2011 16:18:28 -0000

At 1:38 AM -0700 3/28/11, Brian Weis wrote:
>....
>  >
>  > 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 had looked through the algorithm-agility document before 
>commenting but didn't see that it declared that a new profile would 
>be generated. Your description of ("two sets of algs, current and 
>next") seems to match the intent of Section 5, such that it would be 
>an update to this same profile. Here's the text in question:
>
>   "It is anticipated that the RPKI will require the adoption of updated
>    key sizes and a different set of signature and hash algorithms over
>    time, in order to maintain an acceptable level of cryptographic
>    security to protect the integrity of signed products in the RPKI.
>    This profile should be updated to specify such future requirements,
>    as and when appropriate."
>
>When I read 'updated' I assume it means it adds to the same profile, 
>and the subsequent 'update' will be published under the same name as 
>the original. Is that your intent?

yes, although "update" is the wrong RFC term. It should say 
"replace."  we shoud make that change, to the text.

>  > 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.
>
>Understood, and I didn't mean to imply a normative reference was 
>needed -- just an informational explanation of why a different 
>profile might be needed rather than an update to this one. But if 
>that isn't actually expected, then I was questioning why the title 
>implied there would in fact be independent profiles.

OK.  And I agree that we probably should change the name to be "The 
Profile for Algorithms and Key Sizes ..." since we anticipate a 
replacement for this doc when we adopt new algs.

Steve