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

Paul Hoffman <> Thu, 10 March 2011 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70E9D3A6828; Thu, 10 Mar 2011 11:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.952
X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UWfmMDCE7cRg; Thu, 10 Mar 2011 11:30:27 -0800 (PST)
Received: from (unknown [IPv6:2001:4870:a30c:41::81]) by (Postfix) with ESMTP id 14CC73A6826; Thu, 10 Mar 2011 11:30:26 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id p2AJVhi7082352 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 12:31:43 -0700 (MST) (envelope-from
Message-ID: <>
Date: Thu, 10 Mar 2011 11:31:42 -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 19:30:28 -0000

On 3/10/11 11:07 AM, Sam Hartman wrote:
>>>>>> "Paul" == Paul Hoffman<>  writes:
>      Paul>  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.
>      Paul>  This statement is too narrow, and it causes your analysis to
>      Paul>  come to a too narrow conclusion. The profile picks security
>      Paul>  and minimalism over extensibility *of this profile only*. If a
>      Paul>  flaw is later found that requires an extension, that extension
>      Paul>  will be written up in a standards-track document that will
>      Paul>  obsolete this profile. An implementation that conforms to that
>      Paul>  new profile will use the extension. Thus, errors can be
>      Paul>  corrected with new profiles, and the RPKI will have multiple
>      Paul>  profiles running on it, just as the Internet has multiple
>      Paul>  versions of some protocols running on it.
> Paul, that's a great argument for why it's OK to prohibit issuing
> certificates with new extensions in this profile.
> We absolutely can change CA behavior with a new profile.
> However, I don't think your argument makes sense for RP behavior.
> Under this profile, if an RP is presented with a certificate issued
> under a new RPKI profile, it will reject that certificate.
> So, it sounds a lot like you'd need to upgrade all the RPs that might
> need to rely on a particular resource certificate before  you could
> issue that certificate under a new profile.
> Given that resource certificates can be used by a lot of RPs--for
> example anyone who needs to verify origins of a route presumably--that's
> a long wait.
> I think that's unjustified.
> One of us is clearly missing something. I would be happy if it's me.

I don't think either of us is missing something, we just disagree about 
what needs to happen if a fix that changes the semantics of the certs 
needs to be made to the system as a whole. For changes that don't change 
the semantics, you change an existing extension or other part of the 
certificate; for changes that need to change the system's semantics, you 
change the certificates in a way that relying parties that don't 
understand the change won't accept the certificate.

Maybe you and I are envisioning different choices being made about those 
changes. I trust the IETF not to make a change that will cause a lot of 
relying parties to fail unless the IETF really thinks that is necessary; 
you may have less faith than I do. (You were on the IESG, so you get to 
be in the sausage-making more than I have...)