problems with VO certificate authorities

[Ray Plante]

Hi Roy,

Did you try to use the end-entity cert (i.e. long-lived, non-proxy 
certificate) in your browser?  Did it work?

First, I believe we can issue somewhat long-lived certificate for download 
for loading into client applications, such as a browser.  This has always 
been in our plan.  In general, it should not matter whether this is a 
proxy or an end-entity cert.  The need for an end-entity cert would be 
interfacing non-VO services that don't know how to deal with proxies.  Any 
new VO-compatible service MUST support proxies.

Second, I want to review the reasons why in both the HEP and SC 
communitites users are prompted for a password to create a proxy:
    o  someone that has access to your laptop/workstation does not have
         access to your remote privileges.
    o  creating a limited lifetime proxy limits what (e.g. damage) the
         holder can do on your behalf.

The danger in loading a long-lived, end-entity cert into a browser is that 
anyone who has access to the open browser can access your assets.  Is 
there a mechanism to protect against that?

Also, as a general practice, it also has the disadvantage that it's not a 
great solution for the broadest community.  It's "complicated" for the 
naive user, and you have to deal with the plethora of browsers out there. 
Note that my credit card company and bank do not issue me a certificate 
for loading into my browser; rather they make me login over a secure 
channel.

When it comes to browser-based interfaces to services, I believe 
portal-managed certificate model is the safer approach and easiest for 
users; however, I think the direct approach you want to use is worth 
developing to see what it can do.  In particular, I would like to 
understand under what conditions the latter model is particularly useful. 
(Do you see it as the most common mode of operation?)

Of course, the portal-managed certificate model shifts the complications 
to the portal (as I believe it should); in particular,
   o  the portal must track a session via a store of active proxies
   o  if the service being accessed trusts VO certs, then the portal can
        use the cert directly.
   o  if the service does *not* trust VO certs, the portal must use a
        "community" cert that the service does trust.  This in effect would
        have to be a long-term and well-protected cert that can be used
        by the web server without a password.

Finally, I feel that if we want our VO certs to be trusted both by our own 
service developers and the broader community (e.g. the grid community), 
then we need to take measures to establish secure practices.

> 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

All that said, I would have to admit that it may be unclear in the SSO 
document whether one is to interpret section 9, "Recommendations for the 
VO" as just recommendations or a set of compliance assertions.  While some 
should be advisory ("Support external CAs"), others are more at the crux 
of interoperability ("Use X.509 certificates as warrants...").  I believe 
though that this is a principles document that more specific standards 
will base themselves on; but this could be made clearer.

In other words, I don't think this document says that you can't use 
long-lived credentials in a browser.  However, it advises against this for 
the reasons reiterated above.

hope this helps,
Ray