[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CmnLn Elec Exch: 7/28/98 Minutes
CommonLine Electronic Exchange subcommittee minutes for 07/30/98 .
Please respond to the EE listserve with any corrections or additions.
Scott Fullerton* Great Lakes(Chair) sfullerton@glhec.org
Brian Wilson Great Lakes bwilson@goliath.com
Karl Ebert SLMA 105502.3154@CompuServe.Com
Libby Meeker SLMA Libby.Meeker@SLMA.com
Gary Thomas SLMA 70664.401@compuserve.com
Mike Nolan PHEAA mnolan@pheaa.org
Darwin Peiffer* PHEAA dpeiffer@pheaa.org
Chris Seiders* PHEAA cseiders@pheaa.org
Terry Zuch PHEAA tzuch@pheaa.org
John Hall PHEAA
Brian Allison* USA Group BALLISON@usagroup.com
Ron Clark USA Group rclark@usagroup.com
Paul Logston USA Group plogston@usagroup.com
Mike Brannon* USA Group MBrannon@usagroup.com
Matt Parrett* USA Group mparrett@usagroup.com
Paul Jansen USA Group pjansen@usagroup.com
Jon Kroehler USA Group
Ki Ha NELA kiha@nela.net
Gary Burleson TGSLC gary.burleson@tgslc.org
Kelly Klipple TGSLC kelly.klipple@tgslc.org
Will Thien* TGSLC will.thien@tgslc.org
Dennis Alley* TGSLC dennis.alley@tgslc.org
Warren Sherard Edfund wsherard@edfund.org
Patrick Walters SLFC waltersp@slf.org
Gad Hazum Access ghazum@accessgrp.org
Ed McGowan ESF emcgowan@esfweb.com
Matt Downey NYHESC
Kevin Malmberg NYHESC kmalmberg@hesc.com
Mike Schoeppler NYHESC mschoeppler@hesc.com
Jason Mantor* NYHESC
Betty Hansman ISAC bhansman@isc016r1.state.il.us
Deb Phillips ISAC dphillip@isc016r1.state.il.us
Fred Highsmith* Guarantec fhighsmith@guarantec.com
Tim Hearley* KHEAA thearley@kheaa.com
Doug McCaleb Nellie Mae doug_mccaleb@nelliemae.org
Tom Jurado AFSA twjurado@aol.com
Bill Horn College Foundation whorn@cfi-nc.org
Dawn Harris College Foundation dharris@cfi-nc.org
* = present
================
*SUMMARY*
1) Encryption software purchase process
2) Key update procedures
3) Other items to modify in the addendum
4) Review of Chapter 9 of the Manual
5) Schedule for release of the new CommonLine Manual
=================
1) *Encryption Software Purchase Process*
Scott reviewed license terms and and maintenance agreement. He sent
these along to Karen Haney of NCHELP and Jason Swirtley, legal counsel
for PHEAA, for review. He has also requested clarification from Ed
Grace (of AT&T) as to whether the stipulations on transfer are
applicable to the distribution of SBS to schools.
Ed Grace is revising the draft maintenance agreement to clarify the
description of Annual prepaid support.
Scott has drafted a letter of intent and sent this to Karen Haney, Ed
Grace, and Jason Swirtley for review.
A letter to members must be circulated to announce the decision and to
request they hold off contacting AT&T directly until processes are in
place.
Ed Grace has requested members of the evaluation team return any media
and documentation that AT&T provided to support the evaluation
process.
2) *Key Update Procedures*
Dennis Alley and others from TGSLC contributed their reflections on
several update options. They are present on the archive under the
subject headings RFDC...
a Telephone confirmation
When receiving a public key update the recipient must confirm the
update via telephone.
Advantage:
Uses an independent channnel and thus provides positive confirmation
Disadvantage:
Very labor-intensive. A Service Provider is likely to have many
(perhaps thousands) of partners to update. This would mean each
update would cost Customer service as many phone calls.
b Automated confirmation
This could take several forms
i)an e-mail triggered by the update sent to the address from which the
update originated. Presumably in this scenario, the update would be
suspended until the confirmation message was received.
Advantages
Less labor-intensive than scenario 1
Disadvantages
This creates an independent event but does not use an independent
channel, and thus it may not provide the desired level of security.
ii) a fax triggered by the update sent to the fax number associated
with the entity performing the key update. The fax would be signed
and sent back via fax.
Advantages
Uses an independent channel
Disadvantages
About as cumbersome as scenario 1
c Key Server
Dennis's scenario 2. This was discussed a little last year and is
very well presented in Dennis's document.
Advantages
Conceivable positive confirmation. Theoretically a less complex
arrangement. The key server would take responsibility for maintaining
the correct current key.
Disadvantages
Complexity in practice. One entity must assume responsibility for
maintaining the service and providing 24x7, fail-over. This does not
fit our current model.
d Embedding key in hardware lock
Presented in Dennis's scenario 3
e UPS for key update
Use UPS to ship the key update electronically.
Advantages:
This would ensure authenticity.
Disadvantages:
It turns out that UPS charges $7/electronic document ($4/document for
volumes of 1000 or more documents). This is an unacceptable cost
f Verisign for key update
Use a certification service such as Verisign to authenticate the key
update.
Advantages:
This would ensure authenticity (at least to a satisfactory level)
Disadvantages:
Requires s/mime compliant mail systems to use (this would pose a large
extra burden on SBS developers).
Some on the call have been frustrated with the difficulties obtaining
Verisign certificates.
There is a cost to each party that uses a certificate.
g 3DES to encrypt update key
Encrypt the key update with a symmetric key known to all parties.
Advantages:
This poses another hurdle for intruders
Disadvantages:
This poses another hurdle for legitimate participants. The hurdle for
intruders is not all that high
h Nothing beyond what we have already specified
Keep the specification as it stands
Advantages are obvious
Disadvantages:
The security exposure is a concern to at least one member
Follow-up:
1) The committee requests legal counsel from PHEAA and from NCHELP to
review our liability under scenario (h)
2) Scott will inquire of Ed Grace whether AT&T has guidelines for use
relevant to our situation.
3) *Other Items to Modify in the Addendum*
In the initial review, the team saw no need to change anything else in
the addendum except the references to PGP and NAI.
4) * Review of Chapter 9 of the Manual *
Mike Brannon, technical writer for CommonLine, requested assistence
reviewing chapter 9 for accuracy (we are assuming CommonLine will
still be using CompuServe oldmail for some transitional period after
the new standard is implemented). There were no volunteers.
5) * Schedule for release of the new CommonLine Manual*
Mike Brannon stated the manual was scheduled to be released for
comment at the end of August
=================
*ELECTRONIC EXCHANGE LISTSERVE*
These minutes will go out via the Electronic Exchange listserve. They
can be viewed with a browser at the archive site
<http://lists.glhec.org/cl-elec-exch> (case sensitive). To subscribe
to the listserve, send a message to
cl-elec-exch-request@lists.glhec.org.
Put the word subscribe in the body of the message (You may make the
subject anything you want). To post to the listserve, send messages
to cl-elec-exch@lists.glhec.org (You must first have subscribed).
--------------------------------
NEXT SCHEDULED MEETING:
Thursday 8/7/98 10a.m. central time. The number to call is (800)
374-8567. When asked for the name of the conference, reply "CommonLine
Electronic Exchange." If asked for the host's name, reply "Scott
Fullerton."
------------
Agenda
PLEASE REVIEW ADDENDUM
1) Purchase process update (Scott)
2) Key update procedures (committee)
3) Other items to modify in the addendum
------------------------------------------------------