Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt

Sean Turner <> Thu, 04 August 2011 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 402EE21F8B36 for <>; Thu, 4 Aug 2011 06:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.234
X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kFYU3cGh6ljq for <>; Thu, 4 Aug 2011 06:10:52 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 957E021F8B2C for <>; Thu, 4 Aug 2011 06:10:52 -0700 (PDT)
Received: from [] by with NNFMP; 04 Aug 2011 13:11:04 -0000
Received: from [] by with NNFMP; 04 Aug 2011 13:11:04 -0000
Received: from [] by with NNFMP; 04 Aug 2011 13:11:04 -0000
Received: (qmail 2910 invoked from network); 4 Aug 2011 13:11:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1312463463; bh=p/t2Yq2EPdcP2fjW0kZiaCQVTsjx1JhGVdISNQkXp0I=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oBiBBTGIDjwMwswZQmf9KyViW7fTnrZx0lm/OLDupPs+QKiUGCodlPWr2tIgLXnt3Ry2Dvy33sNc3K9DJiS83dQpl6v5AgbJQyG7iaoU5Hh9SFUqYuMaXgTScxmGSU1Z4yuRW1fzuXyP4aVlNt/qKvE1gE4Pbp6+zI1yqJek2uc=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: EJo8tJUVM1m4xfNRrHnArdem0Ng1AX7j3ezIX1EGrf7SAE9 XAkWmOM8ggMImkoTrq5k0FE_PMDxac7IfHwBsjzS62T7CTZZ8rMbK5LYp61L 2iBQ32.sP_noOYXQXHlYRgL4J4qGTIt6p5k0jQlNb60MAsz9GW5EgvOH_C57 nejThRxF3M5XOpHlgRysF13Gz9drM2t4JMwlk4JZzypoGMKnPSKrUtc0w3zz CGTiVN1_KfjK0b66BKoYjNbyV82CZW1ea1wO6WzyHglDOhhI8CsuHcnIbKwQ 9YMg8NTT30cOn3CPqxGl_6T9WDXNm_T4QJqfT5hxG4ama90nhWKmh4B0J3pn xuc3Kea5Xn.IgBidp1m_lqtglo2LBGro62gXLzAvAItxrUnWdLZ.VplYM4Dd CruhuuD7MOJzec3hwX3cxeqZkldtJTSFcxCoCT4ln
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from (turners@ with plain) by with SMTP; 04 Aug 2011 06:11:03 -0700 PDT
Message-ID: <>
Date: Thu, 04 Aug 2011 09:11:01 -0400
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Randy Bush <>
References: <> <> <p06240807ca5e0bcbcee5@[]> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Aug 2011 13:10:53 -0000

On 8/3/11 8:43 PM, Randy Bush wrote:
>> The intention was to focus on the use case for the proposed changes
>> (BGPSEC certs).
> what is a "BGPSEC cert?"

What Mark and I are currently proposing in 
draft-turner-sidr-bgpsec-pki-profiles is that a BGPSEC certificate is a 
special purpose Resource Certificate (and hence issued by an RPKI CA) 
that always contains:
  - A non-critical "BGPSEC" Extended Key Usage (defined in the draft)
  - An Autonomous System (AS) Identifier Delegation extension (from 3779)
and never contains:
  - the Subject Information Access (SIA) extension
  - the IP Address Delegation extension

With the BGPSEC EKU, RPs will easily be able to distinguish a BGPSEC 
certificate from the Resource Certificates defined with 
draft-ietf-sidr-res-certs and even from those defined in 
draft-ietf-csi-send-cert.  The EKU is pretty much the big clue to RPs 
for two things 1) this certificate is only used by BGPSEC speakers and 
2) that the validation procedures defined in draft-ietf-sidr-res-certs 
won't work on BGPSEC certificates.  The procedures in 
draft-turner-sidr-bgpsec-pki-profiles need to be used.*  Note that 
including EKUs in "routers or other devices" is allowed by 

The AS Identifier Delegation extension is always included because BGPSEC 
is only about AS-Paths.  The IP Address Delegation extension just isn't 
needed so it's left out.

The SIA is omitted because it isn't needed.  The objects signed by the 
BGPSEC speaker (i.e., the BGPSEC update message defined in 
draft-ietf-sidr-bgpsec-protocol) are not included in a repository - the 
objects are exchanged as part of the BGPSEC protocol.

* The difference in path processing is about checking for the presence 
of the EKU and AS Identifier Delegation extensions and the absence of 
the SIA and IP Address Delegation extensions.


PS Technically, the EKU is defined in draft-turner-bpgsec-pki-profiles. 
  It's just an object identifier (OID) that Mark and I would get out of 
the PKIX Arc, which is where all the IETF EKU OIDs come from.  We 
obviously haven't requested the OID yet so it's still "TBD".  If the WG 
decides to adopt this approach, then we'll go through the appropriate 
procedures to request an OID and include it in the draft.