October 22, 2003
Attendees

* Jeff Schiller, MIT
* Jim Jokl, U. Virginia (chair)
* Eric Norman, U. Wisconsin
* Steve Worona, Educause
* Shelly Henderson, USC
* Mark Franklin, Dartmouth
* Jeanette Fielden, Internet2
* Renee Frost, Internet2
* Neal McBurnett, Internet2
* Steve Olshansky, Internet2

Discussion

Jim has sent the profiles to the list for final comments. Please review and let him know of any changes.
USHER and InCommon CA

The names are still being reviewed. There will be two USHER roots, USHER lite and the bridge compliant version. The USHER manager CA could sign both the lite and the basic versions. For each of the USHER certs there will be a specific name and task.

For CRL and AIA URL's there is a desire to have redundancy. Does that require separate DNS names or can redundancy be done via DNS round robin? There are a couple of different approaches. One that is in certificates now is pointers to different machines. Another one is to have multiple address records in the DNS for one URL. This assumes the software works correctly and will try the multiple A records that it retrieves. It is unknown how well all the different PKI software works when handed multiple A records. There is code available that will try multiple records but it's not known how widely deployed the code is.

At Wisconsin they are not going to put DNS items in the certificates because they're not confident they'll be valid for 10-20 years. People will have to go through a manual install process. In the current design of the bridge pilot project, DNS is required for correct operation only in the end entity certificates. They may revisit this decision when they re-key if DNS items appear to be stable enough.

Jeff's understanding of the specification, not the bridge requirements, is that a given cert has to have pointers to the list for its issuing CA. The cert above it would the pointers for the CA above it etc. In the original vision the root would not have a certificate. The root key is known implicitly and the private half is used to sign cert underneath. Passing the keys around as a self-signed cert is a convenience. There is no need to put URL's in root cert. The CREN root was pretty sparse with no e-mail addresses.

The general consensus is to remove other information of the top-level root for Usher that signs the other CA's, but to investigate what information other certs contain.
[AI] Jim will go through a number of roots in IE and Netscape and see what providers are including in terms of URL's and e-mail addresses. Special emphasis will be given to where CA providers differ.
CREN Migration

Jeff asked for input on what should happen if someone wants to renew a CREN certificate. While he does the technical work of the renewal he wants policy direction from the working group. If someone asks for renewal tomorrow, what is the process? Changing roots is non-trivial. If USHER is up and running, it may be necessary to renew CREN certs to give a school enough time to transition to USHER. There was general agreement to grant Jeff permission to renew current CREN certs until USHER is up and running. Once USHER is operational a process and transition timeline will be worked out so it is clear how much time a university needs to be granted to transition an expiring CREN cert to USHER.

Review and prioritization of topics from Internet2 Member Meeting session:
The non-prioritized list of topics that more than one school was interested in is:

1. Hardware tokens; survey, documentation, recommendations
2. Windows domain authentication
3. CA Audits - preparing your internal audit
4. EAP-TLS for wireless authentication
5. Updated work on S/MIME
6. Introductory materials for sites getting started (CA software, applications, cookbook, etc)
7. Others discussed briefly: Grid integration, survey, bridge testing, document/webform signing,

What is needed is for schools to champion a topic and devote time to developing it. USC has primary interest in C and F. Dartmouth's first priority is F. Wisconsin is interested in G, C, and E. All topics were of interest to schools represented on the call.
[AI] Jim will send a request to the list for people to signup to work on list items.

Eric suggested that the topic of offline CA's be added to the list.

In terms of the introductory materials for sites getting started there is the recipe that Steven Carmody wrote: http://stc.cis.brown.edu/~stc/Projects/Security/PKI/PKI-how.html
and The Guide for Getting Started with Digital Certificates from CREN
http://www.cren.net/crenca/onepagers/guidebook.html. Neal has pointers to these and other documents at: http://bcn.boulder.co.us/~neal/i2/crencat.
Conferences, Seminars, and Institutes
Fellowship and Scholarship Opportunities
Higher Education IT Events Calendar
Awards
Volunteer Opportunities
Job Opportunities