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

Paul Hoffman <> Thu, 10 March 2011 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAAE23A6942; Thu, 10 Mar 2011 10:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.946
X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OKXicEs++Mfq; Thu, 10 Mar 2011 10:39:22 -0800 (PST)
Received: from (unknown [IPv6:2001:4870:a30c:41::81]) by (Postfix) with ESMTP id 7B53B3A67EE; Thu, 10 Mar 2011 10:39:22 -0800 (PST)
Received: from MacBook-08.local ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id p2AIecGQ079872 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 11:40:39 -0700 (MST) (envelope-from
Message-ID: <>
Date: Thu, 10 Mar 2011 10:40:38 -0800
From: Paul Hoffman <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Sam Hartman <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
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: Thu, 10 Mar 2011 18:39:23 -0000

On 3/10/11 9:37 AM, Sam Hartman wrote:
> The document also requires that relying parties reject certificates that
> include unknown extensions. The rationale explained in section 8 is that
> it is undesirable to have a situation where if an RP implemented more
> extensions it would reject certificates that a more minimal RP would
> accept.
> In other words the profile picks security and minimalism over
> extensibility.

This statement is too narrow, and it causes your analysis to come to a 
too narrow conclusion. The profile picks security and minimalism over 
extensibility *of this profile only*. If a flaw is later found that 
requires an extension, that extension will be written up in a 
standards-track document that will obsolete this profile. An 
implementation that conforms to that new profile will use the extension. 
Thus, errors can be corrected with new profiles, and the RPKI will have 
multiple profiles running on it, just as the Internet has multiple 
versions of some protocols running on it.

--Paul Hoffman