[db-wg] Re: [ncc-services-wg] X.509 authentication in the RIPE Database

I have spent some time _talking_ with people about this project, so now 
I am not guessing anymore.

What was told me makes perfect sense, but doesn't really match the 
message sent out.

First of all, my fear when reading the message was that one thought 
S/MIME was perfect, working, etc etc and this in turn would make X.509 
possible to use both in email and for http/ssl.

What I now heard was that the ssl connections will be strengthened by 
adding client side certificates which can be used for authentication. 
This might of course rise questions about the use of third-party-CA for 
the certificates, but this is (as clarified in this mail below) 
resolved by having the RIR being an CA by itself.

This gives authenticated and secure connections between the RIR and the 
customer/member, as long as the certificate format issues are resolved 
(which should not be hard).

Now, give we have this certificate which creates the trust relationship 
between the RIR (which also is the CA) and the client, we _MIGHT_ be 
able to also use it for other things. For example, if one is lucky, we 
can use it for signing email if the email client can use the same 
client certificate.

Note that this last paragraph is the part of X.509 where my experience 
says there is a big difference between the map and the reality, *NOT* 
the main reason why this project is running -- strengthened 
authentication/security when using "the web" for access to the 
databases.

      paf

On måndag, jul 14, 2003, at 11:15 Europe/Stockholm, George Michaelson 
wrote:

> On Mon, 14 Jul 2003 07:47:11 +0200 Patrik Fältström <paf at cisco.com> 
> wrote:
>
>> On måndag, jul 14, 2003, at 02:53 Europe/Stockholm, Sanjaya wrote:
>>
>>> Yes we run our own root-CA, and the first step is for the client
>>> to install APNIC root CA in its trusted root store.
>>
>> Good.
>>
>>> We're using the OpenCA software (www.openca.org) and modify
>>> it to suit our purpose. When we issue a certificate, an e-mail
>>> containing download url + instruction is sent to the requestor.
>>
>> ...which imply each customer/user of yours have to get a certificate
>> from you which they are to use in the communication with you?
>>
>>     paf
>>
>
> Yes.
>
> There are open questions here, about capabilities in the wider 
> community to
> understand PKI, and also about the nature of certification: right now 
> we are
> only doing identity certificates for people, but we are using them to
> gateway access into I.T. Systems, which makes them agents for 
> authorization as
> well as authentication.  They are being presented to SSL enabled 
> webservers,
> which then use the identity knowledge to decide to enable/permit a 
> privileged
> operation like a whois object update. Right now, the APNIC model has 
> stored
> tokens in the web database backend, but we'd expect that we could 
> bypass those,
> if we took the PKI model all the way to the whois.
>
> When we discuss PKIX, and things like S-BGP or SO-BGP, it introduces 
> questions
> about how we will tie certificates to resources, what are the 
> properties of the
> certificate we need to play with to represent the resource, how 
> 'unitary' are
> these assertions or can they authenticate a range, and bless instances 
> of the
> sub-range as well.. This is an area we are going to need to discuss 
> widely.
>
> The Lynn/Kent/Seo draft on X.509 Address and AS identifiers in 
> certificates is
> the first document I've seen coming from the IETF which treads into 
> this area
> and I think the RIR community needs to review and participate in this
> discussion.
>
> draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
>
> cheers
> 	-George
>
> -- 
> George Michaelson       |  APNIC
> Email: ggm at apnic.net    |  PO Box 2131 Milton QLD 4064
> Phone: +61 7 3367 0490  |  Australia
>   Fax: +61 7 3367 0482  |  http://www.apnic.net
>