April 11, 2001
Attendees
* Jim Jokl (chair) - Virginia
* Bob Brentrup - Dartmouth
* Ed Feustel - Dartmouth
* Chris Misra - Massachusetts
* Judith Boettcher - CREN
* Michael Gettes - Georgetown
* Jeff Schiller - MIT/CREN
* Keith Hazelton - Wisconsin
* Scott Cantor - OSU
* Ellen Vaughan - Internet2
* Eric Norman - Wisconsin
* David Wasley - UCOP
* Deb Crocker - Alabama
* Bob Morgan - Washington
* Ben Chinowsky (scribe)
- Internet2
Discussion
The minutes of the previous meeting were approved without changes; TAG then reviewed the action items from that meeting.
1. David, making use of
legal help as necessary,
will find out if the VeriSign
CPS prohibits alternative
uses for SSL certs. David
reported that the VeriSign
CPS posted on the Web mentions
no restrictions on the use
of server certs; VeriSign
has not yet responded to
his email asking if the
CPS is complete and authoritative
in this respect.
2. David will find out if
VeriSign charges for cert
revocation. Again, David
has not yet gotten a written
answer; however, a VeriSign
representative has told
him that there is no charge.
3. Judith will find out
how CREN certs can be revoked
and how the CREN CRL will
be checked. Judith addressed
this in a message sent to
the list on April 4; revocation
will be accomplished via
a CRL kept in the CREN repository.
Jeff recommended that the
CRL distribution point be
specified in any certs signed
by CREN. This led to a short
discussion of the relative
merits of CRLs (lightweightness)
and OCSP (scalability);
Jeff suggested that once
a few dozen schools are
involved, they may want
to use OCSP while CREN continues
to use a CRL. [AI] Judith
and Jeff will see that an
extension for a pointer
to a CRL is added to the
CREN cert profile.
4. All will send Jim lists
of their projected PKI apps
for the spreadsheet. [AI]
All who have not yet sent
Jim a list of their projected
PKI apps, will do so. [AI]
Jim will send out a URL
for the PKI apps spreadsheet.
5. All will send the TAG
list information on tools
they know of for looking
at certs. Done.
6. Bob J. will send his
cert out to the list, and
all will see if they can
open it. Done.
7. Neal will send the list
a link to a site in the
Netherlands that will "take
certs and do something with
them." [AI] Jim will
check with Neal about the
Dutch cert-processing site
he referred to on the March
28 call.
8. All who have feedback
to provide on the CREN cert
download process will send
it to Judith. Judith noted
that she had gotten feedback
and used it to improve the
process. [AI] All will try
to find non-TAG members
to try the hopefully-now-much-easier
CREN cert download process.
Within TAG, [AI] Ed will
try the improved CREN cert
download process.
9. Judith will send Ken
the CREN cert fingerprint
for posting on the I2-MI
site. Not done yet. CREN
is working on a page that
describes what a fingerprint
is and how to use it, to
be distributed for posting
with the fingerprint itself.
The fingerprint and accompanying
information will be available
for posting on other sites
as well; contact Judith
if you are interested. [AI]
Bob B. and Keith will put
the CREN cert fingerprint
on their respective PKI
Labs sites.
10. Judith will find out
about the possibility of
bundling multiple CA certs
into a single download from
CREN. Jeff is handling this
question; he suspects that
there is no way to do this,
but [AI] Jeff will try to
figure out how to "trick
the browser" to make
it possible to download
many certs at once.
Bob Morgan noted that he is working on a document detailing the PKI issues confronted by the Shibboleth project; TAG will revisit these issues once Bob's document is available.
The TAG-Mobility group has decided to go into hibernation for a while; a summary of its work so far will be out soon. It appears that not much is happening with smartcards, including in SACRED; several schools are looking into options, but no large-scale deployments are happening at the moment. TAG noted the availability of a Sun Ray machine which uses a Schlumberger card to store users' desktop configurations -- put the card in, and your desktop appears; remove it, and your desktop vanishes, along with all information about you. The Sun Blade machine also has a smartcard reader; [AI] Chris will get some information on the Sun Blade machine at Massachusetts. Bob M. said that he is "cautiously optimistic" about work in SACRED; they appear to be moving toward consensus on a protocol, but slowly. Sun, Baltimore, Entrust and RSA are all participating in SACRED.
Eric called TAG's attention to a substantial discussion of the pros and cons of bridges now underway in PKIX. Ed said that the upshot of the discussion is that given the alternative of domain PKI with app-app security guarantees, bridges may not be necessary; Anders Rundgren's Purple (http://www.x-obi.com/purple/) exemplifies the domain PKI approach. [AI] Ed will send out Anders Rundgren's list of URLs on domain PKI. [AI] Jim will add further discussion of bridges vs. domain PKI to the next TAG agenda.
Finally there was a long
discussion of TAG's growing
concern that the complex-document-heavy,
multi-assurance-level structure
that has emerged from HEPKI's
work with the Feds is likely
to be a formidable barrier
to implementation of the
technology. There was great
interest in figuring out,
as Ed put it, "where
do we get the most bang
for the buck?", and
in refocusing TAG's effort
accordingly. Specific suggestions
included starting with a
rudimentary level of assurance
only, or even choosing the
initial assurance level
on the basis of what can
be achieved with existing
campus ID procedures (Judith),
an LDAP-Recipe-like guide
to getting started with
issuing certs on campus,
together with tools for
understanding the full,
heavyweight docs once schools
are ready to step up to
using them (David), and
finding out what schools'
earliest uses of PKI are
likely to be (Ed). With
respect to this last idea,
one suggested use was interaction
with the Feds, e.g. for
student loans, but there
was no consensus here. Jeff
argued that it would be
better if certificates for
such interactions were provided
by the Feds themselves,
and that for now at least
HEPKI should concentrate
on intra-higher-education
uses for certs, such that
policy mapping is not required.
There was agreement that
coming to grips with PKI
terminology is a non-trivial
aspect of the PKI implementation
process; [AI] all who know
of good Web glossaries of
basic PKI terms will send
the list their URLs. [AI]
Judith will make a list
of content providers who
might want to help with
a HEPKI Lite effort.
Action Items
* [AI] Judith and Jeff
will see that an extension
for a pointer to a CRL is
added to the CREN cert profile.
* [AI] All who have not
yet sent Jim a list of their
projected PKI apps, will
do so.
* [AI] Jim will send out
a URL for the PKI apps spreadsheet.
* [AI] Jim will check with
Neal about the Dutch cert-processing
site he referred to on the
March 28 call.
* [AI] All will try to find
non-TAG members to try the
hopefully-now-much-easier
CREN cert download process.
* [AI] Ed will try the improved
CREN cert download process.
* [AI] Bob B. and Keith
will put the CREN cert fingerprint
on their respective PKI
Labs sites.
* [AI] Jeff will try to
figure out how to "trick
the browser" to make
it possible to download
many certs at once.
* [AI] Chris will get some
information on the Sun Blade
machine at Massachusetts.
* [AI] Ed will send out
Anders Rundgren's list of
URLs on domain PKI.
* [AI] Jim will add further
discussion of bridges vs.
domain PKI to the next TAG
agenda.
* [AI] All who know of good
Web glossaries of basic
PKI terms will send the
list their URLs.
* [AI] Judith will make
a list of content providers
who might want to help with
a HEPKI Lite effort.