:
> 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, Steven M. Bellovin