February 26, 2003
Attendees

* Eric Norman, U. Wisconsin
* Bob Brentrup, Dartmouth
* Neal McBurnett, Internet2
* Jeanette Fielden, Internet2
* Steve Olshansky, Internet2

Discussion

NSC/CREN root: The proposal is getting more concrete for NSC to be a third party organization to run a CA for an institution. The institution would essentially outsource that part of their operation to NSC, and or other qualified third parties, and would still get its institutional CA signed through Internet2. NSC would handle the technical aspects on behalf of the institution. NSC already helps campuses with student loan information and has information on students and campuses for that purpose.

Questions that come into play are: how is the certificate set up, what does it say it's signed, and who is the originating issuer etc? This is where things start to become very complicated. But in general we're talking about moving beyond simply maintaining the CREN CA, to trying to make it an integral and ongoing part of higher education trust and PKI. The hope is that other organizations like Educause would want to affiliate in making the Higher Ed PKI infrastructure hold together. Jeff Schiller will be talking with NSC and more information should be available after that conversation.

There may be an opportunity to rename the certificate. Jeff sent a note that the battery in the box, that makes sure nobody is tampering with it, only lasts a certain amount of time and is not replaceable and is approaching the end of its lifespan. That would be an opportunity to re-key, change the name and any other aspects desired.

One challenge is expanding the deployment of the cert. For client certificates the boxes that have to trust it are not browsers, they are servers, which are easier to deploy to. One place where the cert needs to be in a widely-deployed clients, is for S/MIME functionality. A significant barrier has been trying to get people to install it. The InCommon work is one example of trying to make the problem more manageable, since it doesn't require every browser that uses the infrastructure to be upgraded.

Is there precedent for a little script someone could run from the desktop that would insert a certificate for use by the client? At Wisconsin a script was written to configure and reconfigure standard desktop software. There should be some knowledge to expand on to get it to plug-in certificates. Would this be considered a security threat? Not any more of security threat than the current state of things. People download whole browsers and software and how often do they currently check them? It is not clear exactly what restrictions or permissions are required on different versions of operating systems being used to write to the registry.

Please send feedback and suggestions on the NSC/CREN cert to Neal.

Eric provided an update on the U. Wisconsin root certificate. They are moving ahead to issue server certificates. The driving factor is cost due an Oracle product that requires a large number of certificates be issued. Wisconsin does not have a CREN signature on its CA. Wisconsin will not be able to do that until they get an official Wisconsin top level CA generated. There are "practice" certs for which the key hasn't been well protected.

When applications are strictly internal it isn't an issue if you use a self-signed cert. When you go between campuses or vendors it may be an issue since a common root is an easy way to share a trust relationship. It was agreed that it doesn't dd another cert, such as CREN.

The next call is Wednesday March 12, 2003