In message <20051124120010.2c2aed2a@garlic.apnic.net>, George Michaelson writes :
On Wed, 23 Nov 2005 17:54:44 -0800 (PST) "william(at)elan.net" <william@elan.net> 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 https://www.microsoft.com 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, http://www.cs.columbia.edu/~smb