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

Stephen Kent <> Wed, 04 May 2011 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C3E8E0735; Wed, 4 May 2011 10:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.15
X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1bpiOpv0OX5t; Wed, 4 May 2011 10:20:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8E769E06DE; Wed, 4 May 2011 10:20:48 -0700 (PDT)
Received: from ([]:49357 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1QHfkg-000Dso-Bg; Wed, 04 May 2011 13:20:42 -0400
Mime-Version: 1.0
Message-Id: <p06240802c9e73842b579@[]>
In-Reply-To: <>
References: <> <> <> <> <> <p06240801c9ce424e70b1@[]> <> <p06240808c9e45144c8f9@[]> <> <p06240800c9e604898d1c@[]> <> <p06240803c9e6ae6a7fe9@[]> <> <p06240803c9e6f3747d1c@[]> <>
Date: Wed, 04 May 2011 13:20:38 -0400
To: Sam Hartman <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc:, Sam Hartman <>,,
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 May 2011 17:20:49 -0000

At 10:32 AM -0400 5/4/11, Sam Hartman wrote:
>  >...
>Let me see if I can summarize where we are:
>You've describe an upgrade strategey for the origin validation in the
>current set of docs. It depends on the ability to store multiple certs,
>ROAs and other objects in the repository.

requirements that already exist to accommodate key rollover and alg 
transition for the RPKI. We have a SIDR doc describing both key 

>You agree that when SIDR looks at using RPKI objects in the newly
>adopted work it will need some upgrade strategy for format, keys and
>algorithms.  There are probably a number of options for how to
>accomplish this. Even if the working group did decide to update
>processing of RPKI objects at that point, requiring new behavior from
>parties implementing a new protocol would be possible.

I find your last sentence above confusing.  I would say that the 
BGPSEC protocol will have to define how it deals with alg changes for 
the signed objects it defines, with key changes for RPKI certs, with 
alg changes for all RPKI objects, and with format changes for RPKI 
objects and for its own objects.