Jim Jokl, U. Virginia (Co-chair)
Bob Brentrup, Dartmouth (Co-chair)
Stephen Wadlow, Tufts
Eric Norman, UW-Madison
Michelle Gildea CREN
Neal McBurnett, Internet2
Steve Olshansky, Internet2
Jeanette Fielden, Internet2

*Discussion*

*SYMPA Update*
Eric has been working with the Perl X subs and PKCS7 on openSSL testing of SYMPA. One point he raised was how much concern should there be over very large messages. The way the openSSL is written it assumes you read the entire message into memory. The standards are written so this is not required. Being concerned about this issue with openSSL would require rewriting a lot of it. What is the practical limit? If it’s a big machine the memory could be very large and it’s not an issue. Since SYMPA is talking about mailing lists it could be the case that big messages are not a concern.

Dartmouth and Tufts have not yet had time to play with SYMPA. Dartmouth is looking for a suitable opportunity to try the SYMPA software within their current environment. There is also the question of how many campuses would be able convert from their current mailing list servers to SYMPA? There’s considerable inertia in the use of current mailing list servers and there may resistance from campuses to switching. The consensus is that the initial goal is experimentation, with a long-term vision toward generic certificate and configuration management support of list managers with signed messages.

What experiments should be conducted to fully explore the S/MIME functionality of SYMPA? It was decided to start with tests such as how it handles loads, ease of administration, how users change addresses, i.e. day-to-day tasks. Another area to explore is how would archiving of a public list that’s sent encrypted be handled? Additional questions for evaluation include: How are excludes handled? How would only letting certain people post to the list be supported? How are certificates handled? How do you process messages from mail programs that don’t handle S/MIME? The group decided that what was needed was a template of what should be tested in any S/MIME list software. Input will be solicited from the list.

There was also conversation regarding an S/MIME Plug-in for Eudora. Previously a PGP plug-in was located to use as a template at http://web.mit.edu/network/pgp.html. The source code is there for a variety of different platforms. Conversation centered on if creating the plug is as simple as it first appears. Agreement was reached that this was worthwhile to pursue.

The issue of documents for S/MIME applications and toolkits was revisited. It was decided to put this on a backburner for the moment.

One final issue arising from the call was the need for a simple web page to track the status of different items for the list. The page could list the item, identified resources/links and a brief current status. There was general agreement that this should be added to the S/MIME page.