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.
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Jeffrey Hutzelman
- [secdir] Secdir review of draft-ietf-sidr-res-cer… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Paul Hoffman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Paul Hoffman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Rob Austein
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Martin Rex
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… John C Klensin
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman