*MACE-Dir Conference Call*
October 29, 2001

*Participants*

Keith Hazelton -- Wisconsin(chair)
Tom Barton -- Memphis
Steven Carmody -- Brown
Bob Morgan -- Washington
Ellen Vaughan -- Internet2
Nate Klingenstein -- Internet2(scribe)

*Discussion*

PKI and eduOrg

        x.509 contains two different auxiliary types of
certificate-carrying objects; pkiUser(11.1.1 in x.509) and
pkiCA(11.1.2). pkiUser consists of an ID and a userCertificate, while pkiCA contains a
cACertificate, a certificateRevocationList, an authorityRevocationList,
a crossCertificatePair and an ID.  The group wasn't certain whether either
or both of these object classes would be appropriate supplements to eduOrg,
and continued to discuss it at length.
        The heart of the question came to be whether there could be a
single CA identified with an institution, and what the uses of the
certificate of the CA could be.  The group identified use cases where it
would be very handy to be able to easily look up an organization's
top-level CA's entry in its eduOrg; however, there would also be
instances where an institution would want to officially notarize documents and Bob
suggested that this should not be done using an institution's signing
key. One method of doing this the group suggested would be to have the
university's CA issue a CA to the university itself so the university
could use this key to officially sign documents.
        There are many questions here.  Can one CA at a university, an
organizational type renowned for its fiefdoms, be considered the single
top-level CA for the entire institution?  Tom pointed out that this is
not very feasible as an eduOrg inclusion because in pkiCA, there are many
attributes which must be corrolated, and placing multiple instances of
this object in a single directory entry would lose this mapping.  Who is
responsible for maintaining and guarding these certificates, especially
if there is an official institutional certificate for notarizing things
other than certificates which bears no obvious relation to a tangible entity
such as a CA?
        "I'm humbled back to information-gathering at this point," said
Keith, after the group tried to reason its way through some of these
questions.  There is a large number of sources that were suggested as
possible places to ask for advice on how to represent an institutional
PKI in a directory; the two HEPKI lists, MitreTek, which has extensive
experience with cross-certification, universities which have implemented
early PKI's locally, or others which have outsourced.  [AI] As a first
step towards gathering enough information on current practices to determine a
best one, Keith will draft some of these questions, send them to
MACE-Dir for review, and hope for lots of input.

eduPerson playGround Attributes

        Before the call, Keith suggested in an email two attributes to
extend eduPerson and some conventions to put in place so people can play
well and without hurting each other too much.  eduPersonExtGroup was
intended to carry values that assert group membership, such as
associating an entry with a certain class, major, or department.
eduPersonExtEligibility, by contrast, is meant to express directly that
the person associated with the entry is eligible for a particular resource
or service, such as access to a particular vendor-provided online journal
database or a set of project web pages.  Clashes were to be prevented by
use of the ubiquitous domain name system, constructing attributes in the
form "fooEdu:major:physics", where fooEdu would be wiscEdu, brownEdu,
etc. A controlled vocabulary for these attributes was being carefully
avoided, but it was intended that some important ways of completing these
attributes, such as filling eduPersonExtGroup with department or course
in a standard way, would be strongly suggested.
        Bob demonstrated that, as this system was intended to make the
attributes unique to the .edu namespace, there is a certain amount of
practice in the real world of using URN's as OID equivalents.  There has
been a push to have the IANA start doing more in the way of URN
assignments, which must go through the RFC process to be officially
registered.  If there were a URN namespace registered for this purposes,
then these strings could be constructed of the form
"URN:xxx:fooEdu:major:physics", which would make these globally unique
and put the approach on the road to standardization.  If the difficulties in
defining the URN in an RFC prove insurmountable, then there is no real
harm done by taking this approach anyway, since, in Bob's words, there is
always the trapdoor of saying "we were just playing."  [AI] Bob offered to dig
up the various RFC's on URN's and send out references to them to the group.
        Tom challenged the group on whether these were the appropriate
or only two attributes to construct a playGround from; it was apparent that
these two had arisen directly from the needs of Shibboleth.  He noted
that it is quite easy to define some schema, add it into your directory and
share it with an institution who has done the same thing, while some
other members of the group thought that redefining values of attributes was
easier than defining new ones such as this.  Bob found
eduPersonExtEligibility to be "defensible" as an attribute to handle
groups in groups.  This could even be made to refer to an actual LDAP group
object.  The maintenance of something of this could be challenging
because it would have to be automatically updated as students changed majors, or
added or completed courses.  More interestingly, the sensitivity of the
release of the information in the playGround attributes to others
depends entirely on the value of the attribute, not the name of it.  Lots of
this would have to be done out of band.

*Action Items*

1.  Keith will draft some of these questions, send them to MACE-Dir for
review, and hope for lots of input.

2.  Bob offered to dig up the various RFC's on URN's and send out
references to them to the group.