October 14, 2003
Discussion

The discussion focused on what topics should the HEPKI-TAG group take on next.

HEPKI-TAG is not a standards group. Member of the group participate in standards groups such as Oasis and IETF. The TAG group is a technical advisory group. Where there is sufficient interest the group focuses efforts on finding a set of applications and common practices to start with on a desired topic. For example, if there were consensus that something was needed to sign XML documents, TAG would look for applications, work already done on the topic, and common practices. A subset of the group will get together, decide how it will be done, put a set of documents out explaining what and how, with the goal of getting everyone to start using the same technology and not reinventing the wheel.

The following list of topics was agreed upon for future exploration:

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/web form signing,

Steve Worona monitors PKI for Educause and mentioned that Nathan Faut of Educause has an assignment to collect examples of deployed, in production, higher education end user certs based applications. About six have been located and there may be more. Some of the work at U. Washington and U. Virginia may qualify. If people are aware of qualifying projects please forward to the list.

Work was done on hardware tokens two year ago and there is a table on the HEPKI-TAG website. Given all the advances this is a good time to revisit the subject and update the table. Differentiating between smart cards and tokens is a matter of form and preference rather than functionality. For example, UT-Galveston, owns parking garages, buildings, and their security system. They opted for smart cards because they can print out an ID badge from the university with a magnetic stripe reader for the buildings, a proximity antenna for garages, and a chip for creating and storing their public/private key pair. UT-HSCH (Health Science Center Houston) doesn't own the parking garages or the buildings, and is only interested in controlling access to computers. All computers already have a USB port so they opted for a USB token.

UT-HSCH is using the Rainbow 2000. They are looking at the Aladdin e-token since Aladdin writes their own software and promises to support multiple platforms including Linux and Mac. Aladdin has promised an MAC OS X compliant driver in Q1 of 2004. The rainbow iKey supports a 2048 bit public key while the current e-token only supports 1024.

Virginia is about to go with the Rainbow 2032. The claim is it also supports Windows 2000 authentication. There is not currently a guarantee that it will support MAC OS X. They also considered the Schlumberger e-gate product, which uses the same chip set for both the smart card and USB tokens and allows the use of the same software and smart card reader for both devices. This is true of the Aladdin e-token as well.

A question was asked about being able to read the key on the Aladdin. Being able to display the private key modulus and export it is not the same. On the Aladdin it can be displayed but not exported. What is being displayed is not sufficient to sign a message or re-import the key back onto a token. There are number of different token technologies. Token technology that will allow a key pair to be generated on the token rarely gives you the ability to export the key. If the public/private key pair is generated on the token, not exportable, and the token is lost, the only thing that protects the key is the pin/password that secures opening the key store on the token. Terminology is tricky. The certificate itself takes a public key. The private key is the item that can't be accessed.

Another class of devices is secure memory, which may allow the full key to be displayed.

Certificate Signing: Bill Weems of UT-HSCH did some work on document signing for a web application several years ago. If anyone interested the document can be made available. The process is to take a file, hash it, sign it, store it, and then upload it. The document is separate from the signature. The personal key of the person who signs the document is used to sign the hash before it's stored to ensure that the document retrieved is unchanged from the document stored.

David Wasley believes security services need to be built into the OS so the ability to sign something is a system call from an application. Standards for what is signed and how it's signed would abstract away what kind of software is used to sign it, so the signature can be checked without needing to know what software was used to sign it. Once there is OS support, applications using the functionality should appear rapidly.

Bob Morgan talked about standard XML digital signatures, which covers the signing of anything in XML. If anything in XML required additional profiles in order to do something, short profiles of "here's how to use XML signature on this kind of XML thing" can be created.

Cookbooks and documentation: Barry Ribbeck talked about the need for educating users and moving beyond the same questions being asked over long periods of time. It is not a technical problem but it needs to be addressed. User education is needed for understanding what they're doing, what is happening as a result, and understanding what to do next and how when things go wrong.

Auditing: There is a need for process and project information to help internal auditing get up to speed as well. Shelly Henderson has written a certificate policy she is willing to share and will be part of the project. The TAG group can provide assistance in helping to make the document comprehensible for the university legal staff.

S/MIME has been looked at previously and there are documents on interoperability between clients. There are new clients that need to be tested. The S/MIME web site has documentation that covers S/MIME challenges. Though written for Outlook and Outlook Express, the basic issues covered are true for most S/MIME enabled clients.

There has been previous discussion of putting together documentation to help a site get started with PKI. On the website there is a lot of information that would make up the chapters of such a document but the document itself does not exist. The same is true for S/MIME. Topics for both S/MIME and PKI would include how to choose a CA product and which one, choosing a profile, how to build and setup an application, and how to evaluate whether to in-source or out-source the project. Consideration would have to be given to whether the need is to sign high value transactions or use PKI for authentication of high value transactions. There are also issues concerning assurance levels and business cases.

There was also discussion of the need to collect experiences, and case studies so that lessons learned, issues and solutions could be offered as a reference. It might require a dedicated position to collect the information and generate the document.

There is interest in wireless EAP-TSL since many are doing PKI for Grid work.

There is also a desire to better understand how windows XP does Bridge support that builds on earlier work.

PKI for windows domain authentication is another area of interest.

David Wasley offered an alternate point of view in approaching PKI. The list of issues grew out of "here's an x.509 object and I want to use it for x, y, and z and what does it take to do that" as opposed to "asymmetric cryptography as a mathematical technology that can support a number of different kinds of functionality." While it was felt it was an important thing to keep in mind in approaching the groups' work it is larger in scope than what the TAG group is looking to address.

Prioritizing the work and soliciting volunteers will happen on the next conference call on October 22, 2003.