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: George Michaelson
  • Date: Wed Nov 23 21:36:46 2005

On Wed, 23 Nov 2005 16:03:35 -1000
Randy Bush <[email protected]> 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.
> probably more.  smb has convinced me that the (possibly ca[0]) cert
> i get from the rir, with which i do business with the rir (dns,
> ip requests, billing), should be different than that which i use
> for routing info.

At APNIC the cert we expect you to identify yourself with to transact
with the registry is not the same as the cert which identifies resource
utilization. But we (APNIC) also expect to use a different root CA for
these 'identity' certs anyway.

the test APNIC resource certificates are using an interim self-signed
CA, and will be moving to a hardware-token secured CA shortly. The
hardware is the same as our identity certificates used in MyAPNIC, but
a different trust anchor and CA identity will be used for resource
certificate processes.

We probably need to make this explict in our policies in this area.
We've always 


> randy 
> ---
> [0] - i'll want the business cert to have the ca bit if i am
>       large enough to have internal authorization process, and
>       thus want to create and manage different certs for dns,
>       billing, ...

We are discussing how we can do subsidiary certificate services like
this in APNIC but I think this goes outside of routing policy and into
registry business practices which are unlikely to be common for all RIR
and NIR in the ways that resource certificates *have* to be.