May 22, 2003
Attendees

* Neal McBurnett, Internet2
* Steven Carmody, Brown
* Scott Cantor, OSU
* Jeff Schiller, MIT
* Renee Frost, Internet2
* Steve Olshansky, Internet2
* Nathan Faut, Educause
* Bob Morgan, U. Washington
* Eric Norman, U. Wisconsin
* Jeanette Fielden, Internet2

Discussion

Getting Started in PKI draft document by Steven Carmody. Document is available at:
http://stc.cis.brown.edu/~stc/Projects/Security/PKI/PKI-how.html. He is trying to assemble a cookbook and put together a checklist of issues that need to be thought about and welcomes comments and feedback.

While deploying a generalized PKI infrastructure is a large-scale project is it possible that deploying one application in a scoped population with constraints is a reasonably doable project? It depends since the population might have to use different applications, and the users expectations about how they will interact with non-participants could be an issue.

Other campuses have mentioned that they're looking for secure e-mail (signed and encrypted e-mail) for a small set of administrators. Email itself is not the application. You're supporting something and that something that would determine whether the project would have more broad applicability. The key will be to get a set of scenarios, define the exact problem being addressed and requirements.

The issue of escrowing keys came up. It was noted that keys used for signing should never be escrowed, since that allows impersonation of the individual. Escrow is an option for keys used for encrypting important university information, but it introduces new costs and vulnerabilities. Simply escrowing the key does not guarantee the info will be available, which seems to be the real requirement. If there must be a way to ensure the info is available, the options include: escrow the key, save the information in unencrypted form, or encrypt to a key held in some other maintained way.
CA/key Trust Management in the Shibboleth Target

There is a need to manage the trust for how the parties in the Shibboleth communication and their keys are verified. When the handle service sends a signed authentication assertion it is verified via an x.509 operation. For the pilot the reliance has been on commercial and public CAs. For a production system relying on commercial ones is not appropriate and it will rely on a new InCommon CA issued for that purpose.

The issue is targets that need to participate in multiple federations or have one-off relationships with assorted origins they want to work with. Or the case of a campus that provides a service to its local campus and other small affiliated campuses is also part of InCommon. The critical question is: How does it manage verification of signed things across that set without the usual big ball of CA's?

The desire is for capabilities in operating systems and PKI implementations to express this kind of constrained trust. The standards are there in x.509 certs but it is not implemented.

Scott has written a not yet fully documented code and a schema that will let a target have its own list of data structures, each of which is a list of CA's or keys that can be used to verify a set of Shibboleth sites where the site is the atomic concept at this point. So it would be possible to say: "This CA is for all the InCommon origin sites, that CA over there is for another site and so forth." When an authentication assertion comes in, it can be looked at and checked to see if any of the parties that you trust to verify that site has done so.

The code builds on top of code that assumes that the way you do trust is to pass a parameter called CA list. Since that is not sufficient they are trying to engineer a design that will allow them to expand the use of this new layer to replace the existing CA list style stuff that the SSL clients were using. The goal is turn off validation in Mod SSL and LibCurl and bypass it to implement alternate validation.

The current way of doing this with a CA list that contains a list of CA's who you trust to verify the certificates. The CA list is parameterized by the request so for this incoming party I'll check this list, for that party, that list. The goal is to map information in the incoming assertion to trust meta-data and go from site meta-data to trust meta-data. Right now model in federation land is to conflate the two as opposed to keeping them separate and having a separate set of meta-data that binds keys or CA's to federations etc.

The system works by mapping the incoming assertion to a set of information about that incoming request, such as the name of the site that's asserting the data. The target then has to use that meta-data to map to trust information such as specific keys to use, or certificate authorities to verify an incoming certificate with. That piece is separated out and you can do regular expression matching to look up the information. Currently that's contained in several XML files that can be loaded dynamically at the target. This is a step in the desired direction since the authority to do this verification is asserted by somebody and empowers the intermediate keys to do the verification.

The XML schemas Scott has designed allow a degree of signing. Tools come with Shibboleth to download and verify signed meta-data, which is then installed into the target that runs as a chron job to keep the meta-data up-to-date. The assumption is that federations will create these meta-data files and sign them so they function essentially as a certificate authority.

One trust issues is: who are you willing to give out information about local users to? There is checking but the client is relying completely on the SSL client and the mod SSL at the server to do the trust enforcement. No granularity is permitted. If there are multiple federations in play then the trust model is more complex.

The two key issues are:

1. How do we use these certificates? How do we actually make things work during the transaction?
2. How do we organize the whole PKI thing so it fits in with the federations, the targets, and the origins, etc?

What are the implications from a higher education PKI standpoint? Who does the CA work on the targets?
The code is flexible. It is possible to do things that don't require everyone to agree on what CA to use and still have a system that is reasonable manageable. The goal is to try and make it so issues concerning certificate authorities will move out to the policy discussions and away from the implementation discussions.

Continued Topics on the CREN Migration and InCommon
http://bcn.boulder.co.us/~neal/i2/crencat/
In an e-mail discussion it was suggested that Grid proxy cert support wasn't a big problem in terms of being able to support the proxy certs and fit in with the bridge and the right level of assurance. The question is: are there implications for how the bridge works from the existence of proxy certs?
Do you have to be a CA to sign proxy certs? In some ways this is totally outside all the rest of the policy statements and it's just a method to manage keys.

The difficulty with proxy certs is where a user has downloaded a file from a local machine with a proxy cert that works, expects it to work elsewhere and is surprised when it doesn't. The point is to be just like certs though they're not. The issue is currently application specific. There's the whole world that deals with ordinary certs and a few that need to deal with proxy certs. They can write their own policies based on needing to do that.

Levels of assurance:
We want the CA to be the highest level of assurance we can handle. What issues that come up as a result? To create a mapping of the levels through the bridge it will be necessary to talk to the people that operate the bridge to discover what the equivalencies are.

Where is Educause in the process? Educause has accepted Dartmouth to host the technical side of the bridge. Educause is pursuing the framework around the operational structure. They're trying to use templates previously developed by the federal bridge people. Those are in process and will be for months.

Neal closed the call by requesting suggestions for a new name for the CREN CA.

The next call will be June 4, 2003.