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

George Michaelson ggm at apnic.net
Thu Nov 24 02:35:36 UTC 2005


On Wed, 23 Nov 2005 16:03:35 -1000
Randy Bush <randy at psg.com> 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 

cheers
	-George

> 
> 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.

cheers
	-George





More information about the NANOG mailing list