Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Jeffrey Hutzelman <jhutz@cmu.edu> Fri, 11 March 2011 03:34 UTC
Return-Path: <jhutz@cmu.edu>
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 516593A686E; Thu, 10 Mar 2011 19:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 2F3103A67EC; Thu, 10 Mar 2011 19:34:55 -0800 (PST)
Received: from [128.2.184.182] (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.184.182]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (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 <jhutz@cmu.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <18075_1299785510_p2AJVnAa005345_4D79271E.6080707@vpnc.org>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu> <18075_1299785510_p2AJVnAa005345_4D79271E.6080707@vpnc.org>
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 128.2.217.198
Cc: secdir@ietf.org, draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, ietf@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: 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 restriction. --Jeff
- 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