problems with VO certificate authorities
rplante at poplar.ncsa.uiuc.edu
Wed Oct 25 15:50:18 PDT 2006
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
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
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,
More information about the grid