Technical Activities Group Meeting Minutes
HEPKI-Tag Call Wednesday

February 12, 2003
Attendees

* Jeff Schiller, MIT
* Scott Cantor, OSU
* Steve Hanna, Sun
* Jim Jokl, U. Virginia
* David Wasley, UCOP
* Bob Brentrup, Dartmouth
* Neal McBurnett, Internet2
* Jeanette Fielden, Internet2
* Eric Norman, U. Wisconsin
* Chris Misra, U. Massachusetts

Discussion

Eric is working on his demo and will be in touch when it is ready.

Hardware CA key protection devices: Dartmouth is using the "Chrysalis Luna CA3" key protection system. They are also evaluating the IBM 4758 coprocessors. Virginia is working to incorporate the nCipher card into its CA code for its high assurance CA. MIT is using the BBN Safekeeper to protect the CREN CA. Wisconsin is looking at the Cryptoswift card for possible use.

Bob has forwarded the Microsoft contacts and Jim is working to reach them and invite them to participate in a future call.

Steve Hanna from Sun was able to participate in the call and discuss the bridge path validation support built into Java. The bridge path validation code is in all forms of the current Java distributions. This includes the JDK and the Sun Java browser Plug-ins. This has been in place since JDK 1.4. Some PKI portions of the present Java code are not yet upgraded to use the bridge support, for example the signing code. SSL however is all right. The Authority Information Access field of the certificate is not presently used to search directories for needed cross certificates. The needed cross-certificates can be loaded into Java at the file level. Everything needed to support rfc-3280 including name and policy constraints and UTF8 strings is in Java code now.The CertPath code is in J2SE and J2EE 1.4 and later (which is what most people use). But it's not in J2ME (Java 2 Micro Edition, the special version of Java for cell phones and similar small devices).

There is need to be careful about loops when building paths. There are paths that include loops where if you remove the loop the path is not valid but if you leave the loop in it is valid. Suppose you get different policy mappings on different paths? Do you take any path you can find or the highest level of assurance path? For path building and validation you say: Here are the policies that the relying party considers acceptable. Those policies can be mapped along the way into different policies in the target domain but still can be mapped back to policies in the relying party's domain. The relying party can say I'm willing to accept paths with policies A, B, and C and if a path can be built that maps back to one of those policies it is considered a valid path. If not then an exception is generated and an error message returned.

Does the JDK ship with any demo applications that would make it easy to test with signed documents and play with path validation across the bridge? Not really. Scott has the validation side coded for Shib. If you have a certificate, on the other side of the bridge, that you can plug into the origin site code of Shib to sign assertions, the target site code has programs to validate the incoming signatures on those assertions. There are test harnesses in the SAML code that attempt to validate incoming signatures. That code relies right now on a limited set of policies. It's hooked into the JDK so tests could be built to explore what the Java calls are.

A really nice demo would be in support of the FedCommons project, a common web based portal for applying for grants. http://www.fedcommons.gov. The goal is to create a common entry point for all granting entities and at least a partial common application and validation process. After a proposal has been submitted through the portal, the research office logins to the web site brings up the proposal and digitally countersigns the proposal using their private key. In order to validate the signature the federal agencies will have to follow the path through one or two bridges (federal and/or higher education) back to the campus's PKI domain. The ability to do that as a support for the path validation and signing would be a good one to demonstrate. Steve indicated that he would be willing to assist with such a demo.

From the Sun perspective, is operating systems support for security services on the horizon?
Yes there is support for building more and more security services, such as random number generation, certificate processing etc. into the Solaris platform.
Update on CREN CA:

There is a draft agreement between CREN and the National Student Clearing House to have the Student Clearing House do client certs for students. Neal's understanding is that the client certs should be issued from the institutional CA, by NSC, for institutions that want to outsource the operation of their CA's. There is also discussion about institutional certs derived from the CREN root where Internet2 would manage the CREN root and provides flexible policy control for institutional certs though there is still some uncertainty over the exact role Internet2 will play. It also is not completely clear what list of functions NSC is going to provide. Jeff is meeting with them and will pass along what he learns.

Jeff explained how the CREN CA worked. CREN certs were only available to CREN members through the relationship CREN had with the CREN representative on campus. There would be a PGP key exchange and a fingerprint exchange between known parties to establish a path between CREN and the institution representative. The institution would have their technical person create a PGP key pair; introduce that to the CREN office who then introduce them to Jeff. Jeff would do a key fingerprint exchange as an extra check and they would submit the digital signing request and after verifying validity of the request, set it up.

CREN's replacement will be the organization that provides the formal "yes this person is the institution's representative" verification. Given the different levels of membership in Internet2 there may be a need for an additional vetting process. What needs to be developed is the mechanism and policy to follow. Internet2 would only take responsibility for following the process and not for anyone who fraudulently uses the process.

The next call will be February 26, 2002.