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

Sandra Murphy <sandy@tislabs.com> Wed, 11 May 2016 19:09 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0112D581; Wed, 11 May 2016 12:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 js4bgUFkrwU8; Wed, 11 May 2016 12:09:51 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF9312D595; Wed, 11 May 2016 12:09:51 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8203628B003D; Wed, 11 May 2016 15:09:50 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 77DCE1F8055; Wed, 11 May 2016 15:09:50 -0400 (EDT)
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_265FCDC6-D8E9-4BC8-80DE-959713344E6D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.2
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <57332EDB.9090609@innovationslab.net>
Date: Wed, 11 May 2016 15:09:50 -0400
Message-Id: <3BF5F229-FC96-403E-826E-EA0E48E2DDBE@tislabs.com>
References: <20160425184508.30206.46648.idtracker@ietfa.amsl.com> <20160428225451.GE123284@main> <57332EDB.9090609@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/yL7qNW2jReJ1Lc-nJzr5faQ_bg8>
Cc: sidr@ietf.org, sidr-chairs@ietf.org, ietf@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2016 19:09:54 -0000

speaking as one of the wg co-chairs

On May 11, 2016, at 9:08 AM, Brian Haberman <brian@innovationslab.net> wrote:

> Hi Tom,
>     Thanks for the in-depth review and your efforts in creating another
> implementation of this draft. Responses to your comments are below...
> 
> On 4/28/16 6:54 PM, Tom Harrison wrote:
>> Section 5 requires that an EE certificate be used for the signing of
>> the RPSL object.  An EE certificate must contain an SIA extension that
>> points to an RPKI signed object (RFC 6487 [4.8.8.2]).  The draft does
>> not define a profile for a new type of object, or specify an existing
>> one that may be used instead.  There are a number of ways to deal with
>> this: for example, by defining a new profile and changing the
>> signature URL to suit, or by amending RFC 6487 such that object
>> pointers in EE certificates are optional.
> 
> I would propose adding some text to this draft (probably as a
> sub-section in section 2) that says that the SIA defined in RFC 6487 is
> omitted when a certificate is used to sign RPSL objects. Given the
> single-use nature of the key-pair (section 3.2, point #1), omitting the
> SIA is straightforward.
> 

Speaking as one of the wg co chairs:

You are suggesting much the same as draft-ietf-sidr-bgpsec-pki-profiles - defining a new EE cert profile.

This draft would have to say that it is updating RFC6485(bis).

Which means making clear what the additions/modification/deletions are.

So that implementations know how to interpret these new certs when they find them in some repository, it must be possible to distinguish these new EE certs from other EE certs.

Etc.

And the wg would have to agree on the changes.

—Sandy, speaking as  one of the wg co-chairs