problems with VO certificate authorities

[Giuliano Taffoni]

Dear All
I personally agree with Paul.
I believe that structure of the SSO as design by the document is
driven by the necessity to ease  enough the procedures not to  
discourage Astronomers in the use of
the VO resources, and this is a crucial point.
However, I believe that the standard  way used by the  ""big-iron"  
grids"  (HEP community or EGEE or
TeraGrid) is getting a sufficient level of simplicity to be used also  
by our community. Moreover,
using a national/grid already existing CA to issue certificates,   
minimize the efforts of an Astronomer
to join the "new e-science resources". I mean we have a number of  
Astronomers using the grid that
immediately can access the VO resources and vice versa.


In EGEE/HEP grid community the certificate (long term one - 1 year  
cert) is generated directly in the browser. The procedure is quite  
easy: a user fill up  a form with  his data (name institue etc) the
the form is send to the CA which contacts the institute RA by e mail  
to verify that the user is actually
a trust user and then send an email with a link to the signed  
publickey which is directly uploaded to the
browser. At the end of the procedure the user has a certificate in  
the browser protected by a
certificate passphrase. Then the user extract the certificate from  
the browser and save it in the User Interface. This procedure is  
quite easy and not too much annoying   for the Astronomer. Of course  
it requires a RA (by the way did you not mention also the RA in the  
SSO recommendation?) so of some
extra work for someone. As I told you I am providing such  a server  
for testing for us.
The certificate stored in the browser is the long term one. And it is  
common to store it in the browser. The certificate is protected by  
the pass phase and only the public key is exposed. In EGEE for  
example It is used generally only for identity verification to  
portals using the DN of the certificate.

However, it is a big security issue to use the long term certificate  
to access services via a portal so I agree with Paul that the focus  
should be on the VO proxying/myproxing mechanism.
I do not think that issuing a long term warrant is a big problem as  
soon as we find a way to
simply manage a proxy, better my-proxy for the  users.

If we want to  focus on the portal side and we do not want to use  
myproxy (as done commonly by  portals
for the grid community)  there are also some grid projects that can  
inspire  us as  the Grid Accounting and Management Architecture  
(GAMA) that provides a server which wraps a CA and Myproxy as web  
services that are  used by the GAMA portlets. When deployed GAMA  
offers the ability for
users to request new accounts that can be approved by admins. When an
account has been approved, a certificate is generated for the user and
proxy stored in MyProxy. It is used in Gridsphere project. However,  
it is still not standard
in the framework of the "big-iron" grids.


Sorry Ray have also a question regarding you comment on portal- 
managed certificate:
it is not clear to me the difference between a "community" cert and a  
VO cert.

thanks  a lot


bye
Giuliano


On Oct 27, 2006, at 9:12 AM, Paul Harrison wrote:

>
> 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
>

--------------------------------------------------------------
VO-DCA WP5 coordinator
+39 040 3199273
INAF  SI - Osservatorio Astronomico di Trieste
Via G.B Tiepolo 11, I-34131 Trieste
ITALY




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/grid/attachments/20061027/2edd88dd/attachment-0001.html>