<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Dear All<DIV>I personally agree with Paul. </DIV><DIV>I believe that structure of the SSO as design by the document is</DIV><DIV>driven by the necessity to ease enough the procedures not to discourage Astronomers in the use of</DIV><DIV>the VO resources, and this is a crucial point. </DIV><DIV>However, I believe that the standard way used by the ""big-iron" grids" (HEP community or EGEE or</DIV><DIV>TeraGrid) is getting a sufficient level of simplicity to be used also by our community. Moreover,</DIV><DIV>using a national/grid already existing CA to issue certificates, minimize the efforts of an Astronomer </DIV><DIV>to join the "new e-science resources". I mean we have a number of Astronomers using the grid that</DIV><DIV>immediately can access the VO resources and vice versa. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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</DIV><DIV>the form is send to the CA which contacts the institute RA by e mail to verify that the user is actually </DIV><DIV>a trust user and then send an email with a link to the signed publickey which is directly uploaded to the </DIV><DIV>browser. At the end of the procedure the user has a certificate in the browser protected by a </DIV><DIV>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 </DIV><DIV>extra work for someone. As I told you I am providing such a server for testing for us. </DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV>I do not think that issuing a long term warrant is a big problem as soon as we find a way to </DIV><DIV>simply manage a proxy, better my-proxy for the users. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If we want to focus on the portal side and we do not want to use myproxy (as done commonly by portals</DIV><DIV>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 </DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">users to request new accounts that can be approved by admins. When an </DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">account has been approved, a certificate is generated for the user and </DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">proxy stored in MyProxy. It is used in Gridsphere project. However, it is still not standard </DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in the framework of the "big-iron" grids. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sorry Ray have also a question regarding you comment on portal-managed certificate:</DIV><DIV>it is not clear to me the difference between a "community" cert and a VO cert.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>thanks a lot</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>bye</DIV><DIV>Giuliano</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><DIV><DIV>On Oct 27, 2006, at 9:12 AM, Paul Harrison wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1. you have to identify yourself in person before the certifciate is issued</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2. you must take personal responsibility for protecting your private key.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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<SPAN class="Apple-converted-space"> </SPAN>to check the certificate. A standard apache httpd distribution would reject a proxy certificate.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Specifically:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(1) The NVO model keeps all certificates (aka "warrants") in a</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">certificate store, and only issues proxies. This forces one of two architectures:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(a) There is an intermediate Proxy between Client and Resource that</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(b) The user runs a program that connects to the cert store to obtain a</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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*.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(2) The HEP model assumes that the Client has the certificate locally.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">-- 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.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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"</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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)<SPAN class="Apple-converted-space"> </SPAN>to run proper CAs that would be trusted by anyone outside the immediate VO.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">If these can be eliminated, I would be happy with using VO-sanctioned cert authorities.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">well I think that you probably could not use them anyway for NESSI to connect to HEP grids.</DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Thank you</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Roy</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Paul Harrison</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ESO Garching</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">www.eso.org</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> </BLOCKQUOTE></DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">--------------------------------------------------------------</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">VO-DCA WP5 coordinator</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">+39 040 3199273</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">INAF <SPAN class="Apple-converted-space"> </SPAN>SI - Osservatorio Astronomico di Trieste</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Via G.B Tiepolo 11, I-34131 Trieste</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ITALY</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN></SPAN> </DIV><BR></DIV></BODY></HTML>