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

[Sean Turner <[e-mail]>]

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 
draft-ietf-sidr-res-certs.

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.

spt

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.