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

Stephen Kent <kent@bbn.com> Mon, 14 March 2011 15:40 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 B35813A6D0F; Mon, 14 Mar 2011 08:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.496
X-Spam-Level:
X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, 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 PcIyDx9tO04k; Mon, 14 Mar 2011 08:40:03 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8FC0C3A6D1C; Mon, 14 Mar 2011 08:40:03 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49160) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Pz9td-000MNL-AW; Mon, 14 Mar 2011 11:41:25 -0400
Mime-Version: 1.0
Message-Id: <p06240801c99ff331d49e@[10.84.130.113]>
In-Reply-To: <1299814571.28172.111.camel@destiny>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu> <18075_1299785510_p2AJVnAa005345_4D79271E.6080707@vpnc.org> <1299814571.28172.111.camel@destiny>
Date: Mon, 14 Mar 2011 11:41:19 -0400
To: Jeffrey Hutzelman <jhutz@cmu.edu>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ietf@ietf.org, draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, Paul Hoffman <paul.hoffman@vpnc.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
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, 14 Mar 2011 15:40:06 -0000

Jeff
>
>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
>restriction.

My comments also noted that part of the strategy to limit the utility of
resource certs in other contexts is to restrict their content. In principle,
establishing constraints on what RPKI C As issue would do this, but 
experience suggests otherwise :-).  Thus, in order to provide 
immediate feedback to a CA that the certs it is issuing are 
non-compliant, we would like to have RPs reject the certs (when used 
in the intended context). Thus having RPs be very strict in what they 
accept is important as well.


Steve

P.S.

Sam noted that there are potentially lots of RPs.  In principle, 
there are just as many CAs, since every ISP is a CA as well as an RP. 
In reality we anticipate that many small ISPs will take advantage of 
managed CA services (the RIRs are already offering such services), so 
there should be many fewer distinct CAs vs. RPs.  Balancing that is 
the possibility that a number of ISPs, ones that rely on default 
routes, will also not be RPs. So, it's not clear whether we have more 
(distinct) CA or RPs.  I am hopeful that the RIRs will do a good job 
of generating compliant certs in their primary and managed service CA 
roles.