problems with VO certificate authorities

[Paul Harrison]

A key point here is that both these two approaches are using the same  
technologies - each approach has different advantages and  
disadvantages, and crucially different trust relationships. At ESO we  
are planning to produce services and clients that can work with  
*both* approaches.

The VO CAs as proposed cannot issue certificates that would be  
accepted by "big-iron" grids that exist today - the strong trust in  
those PKIs comes about from two key conditions

1. you have to identify yourself in person before the certifciate is  
issued
2. you must take personal responsibility for protecting your private  
key.

However these conditions have been seen as too burdensome to some  
people, and the mechanism proposed for the VO certificate handling  
produces 'good-enough' security for most astronomical purposes and  
lowers the barriers to entry, by making certificate management easier  
for the travelling astronomer - they need only remember a username/ 
password. This approach is gaining some momentum in the "big-iron"  
world as well, and may even become the norm.

Personally I would always get a national CA level of certificate  
rather than rely on the VO CA, because 1. I am in direct control of  
my private key, 2. it gives me access to more resources, but there  
will be people who would prefer the VO approach.

Another point in favour of getting a national CA level certificate is  
that proxy certificates are not yet commodity items, in the sense  
that although you can load them into browsers etc. they have  
different rules for checking the certificate chain, so the server end  
needs to be modified properly  to check the certificate. A standard  
apache httpd distribution would reject a proxy certificate.

> Specifically:
> (1) The NVO model keeps all certificates (aka "warrants") in a
> certificate store, and only issues proxies. This forces one of two  
> architectures:
> (a) There is an intermediate Proxy between Client and Resource that
> connects to the cert store, gets a proxy, and sends it to the  
> Resource on behalf of the Client. Note that there are now four  
> systems interacting securely. This is quite a complex and delicate  
> arrangement.
> (b) The user runs a program that connects to the cert store to  
> obtain a
> proxy, then sends that to the Resource. It works well for  
> commandline access, but is awkward if the client uses web access --  
> because the proxy must be loaded into the browser again *every day*.
>
> (2) The HEP model assumes that the Client has the certificate locally.
> For commandline, a proxy can be created with a program like  
> globus_proxy_init. For web application, the cert is loaded *once*  
> into the browser, and a Javascript application used to connect to  
> the Resource. The advantages are:
> -- No need for a Proxy machine between Client and Resource, and no  
> need for the cert store (except once to fetch the cert). -- Easily  
> extensible to "normal" certificate authorites, where you get the  
> cert itself instead of all this messing about with cert stores and  
> proxies.
So the distinction is that the programmer has to do more work for the  
VO proposal, but it is more convenient for the casual end user.

> THEREFORE I would like to use VO certificate authorities for VO  
> work. BUT it is awkward to do so because of the artificial  
> restrictions that are embedded in the model, specifically two of  
> your Recommendations in section 9: "Don't issue long-term warrants  
> to users" and "Issue warrants to user agents, not to users"
I think that at least the first one of these is a very good  
recommendation to VO CAs - we do not have the resources (it is a long  
term commitment)  to run proper CAs that would be trusted by anyone  
outside the immediate VO.

> If these can be eliminated, I would be happy with using VO- 
> sanctioned cert authorities.
well I think that you probably could not use them anyway for NESSI to  
connect to HEP grids.
> Thank you
> Roy

I think that the real issue here is making sure that the VO proxying  
mechanisms will easily allow you to use a national CA or the VO CA as  
the ultimate trust anchor, but with services seeing always a "VO  
Identity" when decoding the trust chain.


Paul Harrison
ESO Garching
www.eso.org