IETF Logo Mail Archive

Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

Rob Austein <sra@hactrn.net> Thu, 12 May 2016 12:11 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2512D993; Thu, 12 May 2016 05:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXGJHxxXK8Ub; Thu, 12 May 2016 05:11:49 -0700 (PDT)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F97612D9BA; Thu, 12 May 2016 05:11:20 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by cyteen.hactrn.net (Postfix) with ESMTPS id B03EB7C02; Thu, 12 May 2016 12:11:18 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 14C1A3F6370D; Thu, 12 May 2016 08:11:30 -0400 (EDT)
Date: Thu, 12 May 2016 08:11:29 -0400
From: Rob Austein <sra@hactrn.net>
To: sidr@ietf.org
In-Reply-To: <6CD64C8F-F0AA-4042-B974-056F06CE5E0A@tislabs.com>
References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net> <6CD64C8F-F0AA-4042-B974-056F06CE5E0A@tislabs.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160512121130.14C1A3F6370D@minas-ithil.hactrn.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/5zN8U2zh9mi3nYCDK7K4U9vxKWM>
Cc: sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2016 12:11:56 -0000

At Wed, 11 May 2016 15:04:58 -0400, Sandra Murphy wrote:
...
> A new type of EE cert does sound cleaner.  It puts the burden on the
RPKI implementer rather than the RPSL database operators, of course.

We already have precedent and mechanism for adding
application-specific EE certificates: assign a new EKU OID, write a
profile, make sure that the profile requires the new EKU and specifies
all deviations from the base certificate profile.  This is what we did
with router certificates.

As with router certificates, this means that RP code that doesn't know
about the new flavor of EE certificates won't allow them.  This is by
design: we don't accept RPKI objects with unknown semantics.

v2.23.0 | Report a Bug | By Email