November 20th, 2002
* Jim Jokl, Virginia
* David Wasley, UCOP
* Eric Norman, Wisconsin
* Keith Hazelton, Wisconsin
* Jeanette Fielden, Internet2
* Renee Frost, Internet2/Michigan
* Neal McBurnett, Internet2
* Steve Olshansky, Internet2
Outlook/Outlook Express document: It was agreed that the document should include a request that the current default behavior of saving/storing messages encrypted be retained in addition to offering the option to save previously encrypted mail in an unencrypted form. Jim will update the document to reflect this. Jim will send the document to the list and barring any requested changes in response the document will be final.
PKI-Lite profile question: Grid researchers would like to see the key cert sign set to be true to ensure things work well with the Microsoft cert store. This breaks the old RFC on profiles and disagrees with the new one, but they're relatively sure that the Microsoft certificate store is happy with it and lets them have the ability to sign Grid proxy certs cleanly. Jim indicated that if you sign a proxy cert and want to put it into the Microsoft store where it can be used by the software, the functions that they are trying to call will work correctly if your end entity cert is allowed to sign another certificate and CA equal false is not a problem. However, the RFC's call for you to only assert key cert sign if CA equal true.
This is an issue with respect to the fact that an interim solution is needed during the three years before the OGSA (Open Grid Services Architecture) is rolled out to allow people to take advantage of/access software applications that are already out there. The way to approach this is what can be done to the campus CA in order to be able to support the Grid people for the next three years?
The Globus toolkit will generate the proxy cert for you when presented with the identity cert. But it has to be understood by anyone who does chain validation. The relying party wants to be able to validate the certificate. How is that done? The belief is that standard off the shelf SSL is being used, and the desire is for slight modifications to standard off the shelf SSL to get them through this interim period.
The discussion generated a number of issues that need clarification. How does the Grid community in actual practice use these certs? Why does it matter if it looks like a CA signed this or not? Is it because they're using SSL setup to retrieve the cert? How does the Grid software actually manipulate the certificates? What does it do with them, how does it pass them around, how does it even get it issued initially? Is there a special Grid CA that signs these? At what level in the software or function calls are problems happening? Is it Grid software or some sort of standard software? Until we understand the architecture of what they're doing that way in a great level of detail, it's not clear that we can understand what the right approach would be.
Grid people are worried about these proxy certificates since you can have these long running batch jobs that migrate among unused computers. People's private security keys must be available even when they're not present. The Grid people have recognized that people will not wish to take their often only private key and make it available to other machines to achieve proof of possession during the SSL handshake. They came up with the concept of putting the next certificate in the chain and restricting it to the user, but with a different private key that is short lived and willing to take the risk of exposing it to other machines. The idea is to create a limited short lived power of attorney for running these programs. I.e. "To whom it might concern this letter is written by David and authorizes the bearer to perform the following actions with respect to program X"
A number of options were discussed. One option is have a CA that can do one policy or the other. If people are in fact doing Grid computing then clearly they would need a cert that has this notion of a signing bit set true. That would quarantine this to Grid specific certs and not impede the profile. The advantage is the PKI-Lite CP and the Grid CP appear to line up fairly well so it appears that a lot of modification would not be necessary (a CRL would be required). The downside to this you can't issue a cert on campus that's good for everything. So anyone working with Grid will need two certificates. More than one cert is an issue since there could wind up being multiple flavors of certs. So instead of the researcher going to a CA, get a cert and everything works, he has to get a cert to go get another cert. One advantage of using a direct campus issued cert is that if you load the right set of roots you're done.
PKI-Lite is only one possible campus authentication mechanism. Shibboleth is another. The target resource is the Grid identity certificate-issuing thing. The campus does the initial INA, and the Shibboleth AA asserts to the Grid CA issuer that this person is eligible for Grid services. Then that person has a Grid issued ID for whatever term it is. Then the person uses that ID cert to sign the proxy certs. Kx.509 does that for Kerberos.
Why not have the Grid people run something and issue ID certs for the Grid community? If there is trust between communities there could be a recognized few Grids CA's that issue certs for all communities. Two issues: A Grid identity certificate, which does not currently exist, and a proxy certificate for use of the Grid that's a short lived special purpose thing. What the Grid people want in the first instance is an identity cert that doesn't have to be long lived. And what kx.509 does at Michigan is take your Kerberos stuff and place the lifetime of the certificate in your credential cache so when you go off and do a Grid job, the Grid stuff that generates proxies can use that one to sign the proxies. So the CA that generates these is in the kx.509 box. The campus CA that's issuing longer-term identity certs is a completely different machine, policy server, everything. If you're not a Kerberos site it's complicated but that's the point of talking about *x.509. It was suggested that somewhere within the Grid community identity cards that happen to be x.509 objects with a CA bit set could be issued. That CA does not necessarily need to be run by the Grid community, it could be outsourced.
A second approach discussed was the batch processor that will accept this request to run this big job at some later time on the Grid, would send a public key and an XML markup object that describes the actions that are going to be authorized. The user then uses their identity certificate to sign this XML object with the public key in it and that goes back to the batch processor along with all the software and everything else that's needed. Within the Grid infrastructure that object is recognized as a proxy authorization on behalf of XYZ to run that job and only that job. The difficulty is none of that uses SSL or standard software.
Another suggestion was to finesse the issue is to have a flag on the CA. You check the flag and get the normal cert if the flag is not set, and the Grid cert if it is. The difficulty is this won't work with all issued certs.
Jim: will try to contact
the Grid people try to get
answers to the questions:
What are they trying to
sign and what calls are
they making to where? It
is not clear this is completely
native to the Globus toolkit
or in other code being developed.
Keith will also be talking to a contact at USC about their experiences.
Bridge testing and issuing test certificates: There are important questions around the testing of the bridge that are vague. What exactly verifies bridge aware? What does bridge aware really mean? Does bridge aware mean that I can verify signatures on S/MIME mail? As certs are issued and we start playing with applications these issues can be explored, documented and better defined. The key is to issue certificates so the bridge can be tested.