September 11, 2002
Attendees

* Jim Jokl, Virginia
* Bob Bentrup, Dartmouth
* Bob Morgan, Washington
* Judith Boettcher, CREN
* Eric Norman, Wisconsin
* Michelle Gildea, CREN
* Jeff Schiller, MIT
* Steve Worona, Educause
* Deb Crocker, Alabama
* David Wasley, UCOP
* Jeanette Fielden, Internet2
* Renee Frost, Internet2/Michigan

Discussion

Subject name fields in certificates: David sent some questions about subject names to list. His concern is will it cause problems if the subject name field in certificates is modified? The desire is not to have a subject name that breaks anything in the PKI space. The subject name field is supposed to be unique for that CA. The question is: "If a different kind of field is inserted and put in a subject name instead of the cn field will that break something?" The answer is that it's likely that a piece of software somewhere will not be able to handle it. There is no easy way to get a comprehensive list of how the various available pieces of software handle this. He's willing to use cn= UID in the certificate if it's felt to be safe. The consensus is that using cn=UID is safer than DC naming so DC naming will be removed.

There was also agreement that right way is to put an extension that explains 'this is how you get in the directory'. David plans to write this up. Suggestions and help in doing so are welcomed.

LDAP and FERPA: If John Smith is a student a school and has opted out of the directory what happens when you search for him, knowing that he goes to that school? According to FERPA, not only won't you give his directory information, you will say I can't even acknowledge that he's a student at this institution.

It's not 100% clear if this translates to a certificate. You can argue that if student is warned that presenting the certificate discloses who they are then it's publicly published. It is not fully established how that is handled with respect to FERPA. But LDAP directory and certificate issues are believed to be separate.

An adjacent issue is how do you identify that John Smith is the same John Smith at two different locations? Currently there is no easy way to do so. There is a proposal for an extension called permanent identifier that is supposed to solve the problem of identifying the same person over time at different locations.

Microsoft CA discussion: Jim is hitting two new pop-ups labeled potential scripting violations.

1. The web site is requesting a new certificate on your behalf.
2. Trying to accept the certificate now warns you, you are about to add a certificate.
* No one else recalls seeing those messages so Eric and Jim will play some more to verify behavior.

Hardware tokens: Jim is updating the list of key attributes people care about for personal hardware tokens to evaluate what the main issues are in looking at all the new hardware tokens that are around.
The group came up with the following list:

* Can key pair generation happen on the device? Can you export a key pair generated on the token?
* Can you generate the key pair for escrow and then load it into the token?
* What kind of software support is available? Software upgradeability on the chip itself?
* How are pins handled?
* Are private key imports possible, how are they handled?
* Are encrypted certificate imports possible, how are they handled?
* Do the same chips or the same background infrastructure/ databases work in multiple form factors?
* Evaluation of true memory only devices.
* For chips with processors what operating system can the chip support?
* GSA – NIST interoperability standard – is it supported?
* Can the hardware token be reused?
* How is the token accessed? Is it by USB, dongle's etc.
* What happens when the token is lost? How is continuity maintained, what is the alternative method?
* Physical ruggedness of token/dongle, how durable/strong? Resistance to abuse, cold, hot, water resistance etc. How resistant are other identifier credentials on it – magnetic stripe, bar code etc?
* Ease/ usability of Token/certificate registration in a kiosk environment.

Other items for the matrix are welcome. Please send them to the list.

There was discussion of how to create a less awkward method to activate/deactivate certificates in a true plug and play manner. The goal is a user walks in; plugs in dongle and that would be used as their identity. Currently it's not that simple. Even if the software exists on the platform, you still have to literally register the presence of your certificate on the USB dongle the first time you insert it. That goes into a registry that's maintained on the platform and expanded every time another dongle is inserted. You not only have to train them what to do the first time they insert the dongle, they then have to scroll through the entire list of dongle's and find theirs. This is a very unfriendly user interface. There is an effort to develop software that will make it true plug and play. You walk up, plug in and go. The certificate from the dongle would be dynamically inserted for that session and deleted when the session ends and the dongle is removed. It's not a token issue as much as a software on the platform issue. It is a key usability issue.

The Outlook/Outlook Express issues document is intended to be framed around the idea that we want to be able to do encryption but there are things in Outlook/Outlook Express that make it harder. Jim will edit the document to emphasize that approach. There was also a request to include in the list: adding a preference selection that you can set before it prompts you for your certificate to remind you that the e-mail came in signed do you want to send it out signed and encrypted or not.

For the S/Mime document it was agreed that it would be useful to know which clients can forward a signed message. Also, when you forward a signed message you don't sign it yourself, some clients aren't sending it as an attachment for the whole message.

Next call is Wednesday September 25, 2002.