problems with VO certificate authorities

[Roy Williams]

This note refers to:
Single-Sign-On Authentication for the IVO: introduction and description 
of principles
http://www.ivoa.net/Documents/Notes/SSO/SSO-introduction-20051002.html

Guy and Ray

As you know, we are building a system (Nesssi) to allow VO clients to 
run secure batch jobs on major computing resources. The intention is to 
support a multiple usage models, where the client can be authenticated 
weakly or strongly, and can use a web page or a commandline to drive the 
system. We have been following the model outlined in your paper above, 
but I think it is time to revise the document.

We have built two prototypes, one is complicated and based on your 
proposed VO model, and the other is much simpler and is what the HEP 
community has adopted. Each aims to connect a Client to a Resource 
securely. We are not considering workflows or delegation in our model.

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.

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"

If these can be eliminated, I would be happy with using VO-sanctioned 
cert authorities.

Thank you
Roy