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

Jeffrey Hutzelman <> Fri, 11 March 2011 03:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 516593A686E; Thu, 10 Mar 2011 19:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A-fmjO+a4-p1; Thu, 10 Mar 2011 19:34:55 -0800 (PST)
Received: from (SMTP03.SRV.CS.CMU.EDU []) by (Postfix) with ESMTP id 2F3103A67EC; Thu, 10 Mar 2011 19:34:55 -0800 (PST)
Received: from [] (JHUTZ-DYN5.PC.CS.CMU.EDU []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id p2B3aBbN009705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 22:36:12 -0500 (EST)
From: Jeffrey Hutzelman <>
To: Paul Hoffman <>
In-Reply-To: <>
References: <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 10 Mar 2011 22:36:11 -0500
Message-ID: <1299814571.28172.111.camel@destiny>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on
Cc:,, Sam Hartman <>,
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: Fri, 11 Mar 2011 03:34:56 -0000

On Thu, 2011-03-10 at 11:31 -0800, Paul Hoffman wrote:
>  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.

Sure.  The way to do that is to issue a certificate with a critical
extension.  An RP encountering a certificate with a critical extension
it doesn't understand will not accept the certificate.

What the profile does as written is require RP's to treat all extensions
as critical, even if they are not so marked.  That reduces flexibility
without gaining anything in return.  In particular, we don't gain the
ability to make a change that will prevent certificates from being
accpted by RPs that don't understand them, because we already had that.

Steve noted a desire to limit the liability of entities acting as CAs in
the RPKI.  I agree that goal is desirable, and restrictions on what
certificates issued by those CAs can contain help to do that (provided
the CAs actually comply).  However, requiring compliant RPs to treat all
extensions as critical does _not_ help, because an RP which incorrectly
accepts an over-broad RPKI certificate for some other purpose is
probably not an implementation of this profile and thus not bound by the