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:06 UTC

Return-Path: <sandy@tislabs.com>
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 0656B12D75D; Wed, 11 May 2016 12:06:51 -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 CxnDIJ4DyXsM; Wed, 11 May 2016 12:06:49 -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 A09A812D593; Wed, 11 May 2016 12:06:21 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 039EF28B003D; Wed, 11 May 2016 15:06:21 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id F02B61F8055; Wed, 11 May 2016 15:06:20 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A1F2D816-639B-4372-B7EC-0E3884CA00A6"; 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:04:58 -0400
Message-Id: <6CD64C8F-F0AA-4042-B974-056F06CE5E0A@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/sidr/V9wRRobPoY4f1j5GqXVcBh8UMtQ>
Cc: sidr <sidr@ietf.org>, sidr chairs <sidr-chairs@ietf.org>, draft-ietf-sidr-rpsl-sig@ietf.org, Sandra Murphy <sandy@tislabs.com>
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: Wed, 11 May 2016 19:06:51 -0000

Speaking as regular ol’ wg member

(I took the ietf off the cc list  - I intended this as a sidr discussion, not an ietf discussion.)

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


wrt Tom’s comment:

It is certainly the case that currently existing EE certificates in the RPKI appear in RPKI Signed Objects (i.e. instances of RFC6488) - manifests, ghostbuster records, ROAs.  But these aren’t the only possible use of EE certificates - the architecture RFC6480 mentions that there might be other uses of EE certificates.

And it is certainly the case that there’s been no intent in this work to put signed RPSL objects into the RPKI repositories.

wrt Brian’s suggestion:

A similar example:  The router certificates draft also omits the SIA field for router EE certificates - probably for similar reasons.

On May 11, 2016, at 12:56 PM, Brian Haberman <brian@innovationslab.net> wrote:

> Hi Randy,
> 
> On 5/11/16 12:42 PM, Randy Bush wrote:
>>> 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.
>> 
>> perhaps you might also include your reasoning for this seemingly odd
>> choice.
> 
> The SIA in 6487 mandates an rsync URI that points to the object that is
> signed with the certificate. I am not aware of any RPSL servers that
> support referencing an RPSL object via rsync.



“A small matter of programming” - an RPSL database operator could find a way to format an rsync URL so that it could be translated on receipt to a database object retrieval. ( :-)  ?  )

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.  I am not an implementer nor operator.

—Sandy, speaking as regular ol’ working group member