June 18, 2003
Attendees

* Jeff Schiller, MIT
* Scott Cantor, OSU
* Jim Jokl, U. Virginia
* Nathan Faut, Educause
* Steve Worona, Educause
* Neal McBurnett, Internet2
* Steve Olshansky, Internet2
* Eric Norman, U. Wisconsin
* Ken Klingenstein, Internet2
* Bob Morgan, U Washington

Discussion

Steven Worona and Nathan provided an update on the Fed/Ed PKI meeting. VeriSign and Microsoft have an agreement and their PKI code will be in the next major windows release. It is not clear, exactly what's being released technically.

The meeting included a discussion about how people who run a bridge ensure that people who cross certify with the bridge follow their CP's and CPS's, especially in situations where the CPS's are secret for security reasons. There is a memorandum of agreement (MOA) that gets signed and it delineates what they are 'really' agreeing to do. This will likely be incorporated into the draft agreements for the Higher Education bridge. A template is available at: http://www.cio.gov/fpkipa/documents/moa_template.pdf or
http://www.cio.gov/fpkipa/documents/moa_template.doc

The eGrants initiative to create an electronic storefront for grant applications has been renamed to Grants.gov (http://www.grants.gov/). It will provide a common way for everyone applying for a government grant to authenticate themselves before going to the site of the granting agency. It is strictly an authentication gateway have anything and not related to electronic signatures in any way. It should be operational by October of 2003.

The University of Texas Health Science Center Houston (UT-HSCH) has been using PKI and S/MIME extensively for several years and has trained all their staff on it.

The Globus CA is going away in January. It is not clear how/what will replace it.
They will establish a simple web based certificate service to be available in August that is only recommended for those that can't do any other kind of CA.
InCommon CA

In the CREN CAT document the USHER CA is the top level, under that is an InCommon CA for doing server certs that is parallel to the institutional certs. The motivation in decoupling the USHER CA and the InCommon CA is to create forward movement for adoption. The goal is to make the campus infrastructure trustworthy enough that it can issue InCommon or other federation certs. Each federation will get to decide how much of their trust issues they want to anchor around the signing certs. Setting up just the InCommon CA for signing server certs and adding the USHER CA would mean starting with a self signed InCommon CA that later gets signed by USHER. Re-keying for a software-to-software change of the CA software wouldn't be likely but would probably be needed for hardware based changes. For an InCommon CA, the trust is established by the root and is not bilateral. Nothing would break with an InCommon CA that was temporary as long as everyone installed the USHER root by a set date.

A quick CA for InCommon, based on a machine turned off most of the time, could issue temporary InCommon certs relatively quickly. Focus on the strong INA process and have the resulting certificates for the temporary InCommon CA only usable for InCommon. Transitioning from a temporary InCommon CA to a more permanent one would be relatively clean; a new root would be installed ahead of when the previous one expires. It's also clean on the validation side because the trust files are distributed in an automated way using the provided utilities. If the CA was used to sign the meta data or the trust file itself people would have to download that piece so they could begin using that key to verify their meta-data. It can be run in parallel, and the file signed twice. The need is to get the temporary certificate built and the INA process started before issuing club Shibboleth certs.

While it is plausible for USHER certs to be used to create InCommon certs the decision will be up to the InCommon management mechanism. The question for consideration is "how does whatever policy authority we think is needed for USHER relate to whatever management group is going to be doing InCommon policies?" How can it be managed until a group is in place? There are two CP's to think about, the USHER CP and the InCommon CP. One suggestion is a temporary/one time CA for InCommon that could grow or not grow depending on how USHER proceeds. For the USHER CP it could be that campuses might issue end-entity certs from it. This means it's important that USHER CA can be operated at a level to support that and how it maps/fits with the federal Citizen and Commerce CP. It should be planned that C4 issued certs will be mapped into the hierarchy, probably on a case-by-case basis, at basic or medium depending on the variations C4 allows. The work on the recoverable key is critical so campuses can move from source to out source as desired. The issue of whether we can do recoverable keys and what level of security we can achieve is one of two or three issues that we want to tackle specifically. The C4 policy says that an external audit by an organization qualified to do CA audits is needed. We can help address this issue if we create a one-day course on internal auditing that covers how to validate CA operations against whatever policy is selected.

Next steps: There are a number of schools interested in signed e-mail so that is a good place to distribute USHER certs to begin experimentation. In the shorter term the question is: "Is there an expedient solution or do we focus on getting the InCommon and USHER CP's out the door?" They should be close to each other and look fairly close to some recommendations we give to campuses on how they set up their sub-hierarchies and what might be a reasonable procedural basis for issuing end-entity certs, so those certs can qualify under C4.

The next call is July 2, 2003.