North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

  • From: Steven M. Bellovin
  • Date: Wed Nov 23 22:20:43 2005

In message <[email protected]>, George Michaelson writes
>On Wed, 23 Nov 2005 17:54:44 -0800 (PST)
>"william(at)" <[email protected]> wrote:
>> On Thu, 24 Nov 2005, George Michaelson wrote:
>> > According to what I understand, there have to be two certificates
>> > per entity:
>> >
>> > 	one is the CA-bit enabled certificate, used to sign
>> > subsidiary certificates about resources being given to other people
>> > to use.
>> >
>> > 	the other is a self-signed NON-CA certificate, used to sign
>> > 	route assertions you are attesting to yourself: you make
>> > this cert using the CA cert you get from your logical parent.
>> So how is the 2nd one different from the first?  
>the important distinction is that the certificate used to sign resource
>assertions doesn't have the CA bit set.

More generally....  To a 0th and even a 1st approximation, a 
certificate is just a binding of a public key to an identity.  But 
there's far more complexity, much of it actually necessary, to real
X.509 certificates, or the PKIX working group wouldn't have churned
out 32 RFCs...

One thing important here is the usage fields.  For example, I just went
to and looked at its cert.  Under "Certificate 
Key Usage", it says "Signing" and "Key Encipherment".  There's another 
field, "Extended Key Usage", that Firefox can't decode.  There are 
other certificates, issued by Microsoft, that are identified as 
code-signing certificates.

Here, we need several forms.  One is just for communicating with the 
RIR(s); that's a pretty ordinary identity cert.  We need an AS cert (at 
least for some proposals); that coudl be an identity cert, but with a name
of a special form.  We need prefix ownership certs; these need a special 
field identifying the prefix owned.  (See RFC 3779, which also 
describes AS certificates).  We need the latter in CA form, for 
delegation.  There are probably a few more, depending on just how we 
decide to secure BGP.

The purpose of all of these distinctions is to permit control over how 
certificates are used, without relying on special-format names.  

		--Steven M. Bellovin,