Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt

Sandra Murphy <sandy@tislabs.com> Wed, 13 August 2014 16:42 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15B1A00C6 for <sidr@ietfa.amsl.com>; Wed, 13 Aug 2014 09:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 VtUxHtYIqArY for <sidr@ietfa.amsl.com>; Wed, 13 Aug 2014 09:42:31 -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 455BD1A091E for <sidr@ietf.org>; Wed, 13 Aug 2014 09:42:31 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 827B228B005B; Wed, 13 Aug 2014 12:42:30 -0400 (EDT)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 63EC31F8032; Wed, 13 Aug 2014 12:42:30 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_2509FEDE-7750-4679-833B-34E703B74157"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <B97A6E28-4EDB-4EC5-B8DA-9803C7B21900@ieca.com>
Date: Wed, 13 Aug 2014 12:42:29 -0400
Message-Id: <4556FA63-A6FD-471B-93FD-51D748C94EE8@tislabs.com>
References: <20140813004442.10560.45299.idtracker@ietfa.amsl.com> <B97A6E28-4EDB-4EC5-B8DA-9803C7B21900@ieca.com>
To: Sean Turner <TurnerS@ieca.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/OC-TdCtZskP0YtDXLt8yAsSh9pw
Cc: sidr wg list <sidr@ietf.org>, Sandra Murphy <sandy@tislabs.com>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Aug 2014 16:42:38 -0000

speaking as regular ol' member

A question about wording.

I understand the wording change in 3.1.1 (used to be 3.1.1.1) that results from the change from multiple ASs in a cert to a single AS in a cert.

But there is also a wording change having to do with multiple routers sharing the same key pair.

The wording went from:

                                   If the same certificate is issued to more
   than one router (hence the private key is shared among these
   routers), the choice of the router ID used in this name is at the
   discretion of the Issuer.

to:

                                                      If more than one certificate
   for an AS is issued (i.e., more than one router gets a certificate
   for the AS and hence the private key is shared among more than one
   router), the choice of the router ID used in Subject name is at the
   discretion of the Issuer.

I don't understand the new wording.  If all routers in an AS have different keys, then there would be multiple certificates issued for the AS, but no sharing of keys and no confusion over the router ID to be used in each router's cert.  Right?

Apologies if I'm just not parsing the new sentence correctly.  The previous wording was fine with me.

[The certificate request format does not include the subject name anyway, so it looks to me like the subject name is ALWAYS at the discretion of the issuer.  No?)

--Sandy, speaking as regular ol' member


On Aug 12, 2014, at 8:47 PM, Sean Turner <TurnerS@ieca.com> wrote:

> This version incorporates the change discussed at IETF 90 - namely include one and only one AS in the certificate.
> 
> The working version is also available at:
>   https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles
> 
> spt
> 
> On Aug 12, 2014, at 20:44, internet-drafts@ietf.org wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
>> 
>>       Title           : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests
>>       Authors         : Mark Reynolds
>>                         Sean Turner
>>                         Steve Kent
>> 	Filename        : draft-ietf-sidr-bgpsec-pki-profiles-08.txt
>> 	Pages           : 13
>> 	Date            : 2014-08-12
>> 
>> Abstract:
>>  This document defines a standard profile for X.509 certificates for
>>  the purposes of supporting validation of Autonomous System (AS) paths
>>  in the Border Gateway Protocol (BGP), as part of an extension to that
>>  protocol known as BGPSEC.  BGP is a critical component for the proper
>>  operation of the Internet as a whole.  The BGPSEC protocol is under
>>  development as a component to address the requirement to provide
>>  security for the BGP protocol.  The goal of BGPSEC is to design a
>>  protocol for full AS path validation based on the use of strong
>>  cryptographic primitives.  The End-Entity (EE) certificates specified
>>  by this profile are issued under Resource Public Key Infrastructure
>>  (RPKI) Certification Authority (CA) certificates, containing the AS
>>  Identifier Delegation extension, to routers within the Autonomous
>>  System (AS).  The certificate asserts that the router(s) holding the
>>  private key are authorized to send out secure route advertisements on
>>  behalf of the specified AS.  This document also profiles the
>>  Certificate Revocation List (CRL), profiles the format of
>>  certification requests, and specifies Relying Party certificate path
>>  validation procedures.  The document extends the RPKI; therefore,
>>  this documents updates the RPKI Resource Certificates Profile (RFC
>>  6487).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-08
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-08
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr