*MACE-Dir Technical Advisory Board Conference Call* April 12, 2002 *Participants* Keith Hazelton -- University of Wisconsin (chair) Rob Banz -- University of Maryland, Baltimore County Tom Barton -- University of Memphis Kim Cameron -- Microsoft Corporation Steve Carmody -- Brown University David Chadwick -- University of Salford Renee Frost -- University of Michigan & Internet2 Michael Gettes -- Georgetown University Ken Klingenstein -- University of Colorado & Internet2 Bob Morgan -- University of Washington Ed Reed -- Reed-Matthews, Inc. Mark Smith -- Netscape & America Online, Inc. Kurt Zeilenga -- OpenLDAP Foundation Nate Klingenstein -- Internet2 (scribe) *Discussion* Executive Summary Keith extended a very warm welcome to all the members of the MACE-Dir Technical Advisory Board at the outset of the call. The panel of directory experts has been convened to discuss the more pressing and challenging questions facing MACE-Dir as it moves to engineer new systems and further deploy existing designs. Discussion included conversation about creation of a dynamic registry for basic DN components, which was referred back to LDAPbis, discussion of how to map OIDs to values more appropriate for user consumption and use, evaluation of eduPersonRDN as a further qualification to make DNs unique when transported across realms, promotion of eduPersonOrgUnitDN and eduPersonOrgDN to standards under x.520, and potential topics and directions for future calls by the group. Subsequent calls will occur on the third Friday of every month. RDN & DN Registries Certificates and LDAP have several disjoints in implementation which present difficulties in use of certificates in directories. A primary issue has to do with the DN strings as currently defined by an RFC which are limited to a very specific, short list of 11 components, such as C, O, OU, etc. The latest revision of LDAP states that if the desired component is not listed, then the OID that corresponds with it must be placed in the RDN to identify it. This is a serious issue for PKI because the qualified certificate profile currently has three additional component types which are not part of the LDAP basic list. These cannot be sent as string representations, but must only be sent as OID's. Conveniently, all attributes in x.509v3 certificates already have OID designations. To attempt to encompass this situation, the board engaged in a protracted discussion about whether it made sense to switch to a relatively dynamic list of DN components. Curiously, LDAP v2 had such a dynamic table, originally planned as a registry operated by IANA, which never really materialized into a functional service. The rationale behind moving to the static list for LDAP v3 is as yet unknown to the group. This nevertheless posed an interesting opportunity for the group to consider. Bob pointed out that this type of service is generally well-plowed ground, with a traditional pro of allowing greater configurability, but the con of trying to maintain consistency across implementations. If something new is placed into the registry, he reasoned, must he implement it, or is it optional? Does Bob's implementation become non-compliant if he does not do so within a given time frame? Another interesting approach to the problem is to maintain a semi-static table which would have intermittent updates, such as every 6 months. This would allow implementors greater leeway and more precisely specify exactly what must be supported, while still allowing for somewhat dynamic updating of the list when necessity arose. OIDs and User Interfaces Bob pointed out a slant to the viewpoint of TAB and other similar groups; they are necessarily composed much more of directory implementors rather than users. David commended this juncture between MACE-Dir and LDAPBIS for this reason, stating that it did a nice job of bringing together "implementors wanting to rip out requirements and users wanting to add them." This launched a discussion about the usability of OIDs and how to better present the components to a user. OIDs are clearly not particularly easy for humans to parse, although using them for this sort of application is appropriate. For this reason, the typical strings are generally mapped to text strings or a user interface which is easier for humans to use. In current implementations, any OID-defined DN must be processed and turned into an appropriate text string, while the others must not be processed as OIDs, instead being used directly. This sort of processing model is somewhat difficult. David preferred saying explicitly that every DN must be an OID, forcing the mapping and simplifying the task of parsing. To send OIDs on the wire and present some sort of consistent user experience, there needs to be a registry to perform the maintenance of DN's and strings and the mappings between them. Kurt had several concerns about this approach, however; right now, for any particular x.500 BER-encoded DN, there are multiple ways of generating the strings. There are also multiple cases where an OID or a string can be used, as well as other encoding possibilities, but currently, all implementations have to recognize strict names to strict OIDs. Kurt's concern is that if a table is used instead, then this congruence cannot be well-maintained across the many implementations. Ed believes that all that can be mandated is that if a given application is supported by a particular directory, then that directory must also support a particular set of DN to OID mappings. The board resolved to carry the issues surrounding a dynamic table to LDAPbis as the likely place for this discussion to occur among a broader audience. Kurt recommended additionally that an engineering team investigate why the decision to move away from the static table were made and what should be done next. eduPersonRDN A related concept is that of eduPersonRDN. This attribute was proposed to address issues surrounding the portability of directory entries by adding a unique string. This partly addresses a usability scenario of the Directory of Directories for Higher Education (DoDHE -- see http://middleware.internet2.edu/dodhe/DoDHE-UI-9-July-2001.txt) for the need to be able to transport entries to a central deposit from institutional directories and avoid inevitable DN problems to whatever degree possible. Michael has observed that most sites have placed some site-defined attribute into their DN "for the hell of it." The essence is realizing that, as institutions may want to share data between directories and build larger app-specific directories with multiple DIPs, getting some reasonable commonality between DNs is important. Another feature generally considered important about eduPersonRDN is that it wouldn't be indexed. The board was wary of this approach. They felt that the scenario should be viewed as an application use of shared data problem, and this would then imply a preference towards not placing restrictions when possible on attributes which can be used for naming. This constraint should only be used extremely carefully when necessary. Kurt preferred to solve this using the same IANA dynamic-table approach suggested earlier. There was also a general feeling that there are already lots of attributes to choose between to perform the functionality indicated. UIDs or RDN and several other possibilities were named, and the board didn't feel that these attributes were so overused by current applications as to be broken for this purpose. Kurt mentioned that if the directory will be turned into application-specific partitions, then it should be deployed such that common attributes are used. Bob also felt that these attributes are reasonably well-defined, and that they are largely used inside that original meaning. David drew an analogy: "If people start to use them outside the scope of their original intention, then you can't help fools who drive cars on the wrong side of the road; can't legislate for that; can't say we just don't know what side of the road cars will go on anymore." eduPerson, eduPersonOrgUnitDN, & eduPersonOrgDN eduPerson has designed entirely as an auxiliary object class. The philosophy in mind when it was designed was to create a set of attributes designed to be used alongside x.521 attribute classes such as orgPerson. eduPerson-specific attributes are all prefixed with eduPerson and intended only to be an additional set of values. Keith pointed out that "when [MACE-Dir] gives advice for [use of orgPerson attributes and those from other object classes], it's within our community that we agree to play with these tighter rules. In this general theme eduPersonOrgUnitDN and eduPersonOrgDN were suggested. While orgUnit and organization are present in the orgPerson definition, these are not DNs, which implies the need for these additional attributes. organization and orgUnit are just the simple names of the organization and organizational unit, intended to be fully user-friendly, while the DNs have obvious other uses. David performed once a critical appraisal of the eduPerson spec, and suggested that eduPersonOrgUnitDN and eduPersonOrgDN were such important attributes that they should be promoted into the x.520 standard. Additionally, the board recommended that these two attributes be made multi-valued instead of single-valued. There will be additional conversations about how to appropriately begin the process of promoting these attributes. Future Goals One thing to begin worrying about is connectivity between directories, allowing people at one institution to find out things they need to know using other institutions' directories in a relatively seamless way. This is part of a general federation problem which will need to be addressed soon as part of directory evolution. While DC naming may be part of the solution, there are other notable problems in the area. Generating interdirectory ACLs and implementing some sort of control over discovered information is virtually unexplored at this point. Understanding this is important for protection against misuse of information for marketing or other denial-of-privacy attacks. This needs to be accompanied with a movement towards developing a general awareness of what public means, to avoid, in Keith's words, administrators suddenly stating, "Oh my gosh! You can't do that with our data!" The struggle for development of the proper level of access control for both the public and for internal uses is a widespread one currently. Issues such as to what extent the directory is used for collaboration, the amount of out-of-band communication assumed, and the degree of resource discovery necessary should drive that conversation. There are many application-specific motivations for a systematic design, such as videoconferencing and grid computing. The standard used to do this is unimportant in Bob's eyes, as the hard part of access control is the pieces that are independent of the bits on the wire. Kim thought that moving things to a centralized directory facilitates the design and maintenance of ACLs. An area that Kim is interested in as well is searchability. Efficient, effective, and useful searches performed in a directory the scale of Internet2's logical directory is a very interesting and important capability. Referring to DoDHE, which is designed to function both as a distributed system of networked institutional databases and optionally as a central deposit for institutions which would prefer not to be queried real-time, Kim far prefers putting all data into a central deposit. He feels that this allows for interesting algorithms, and design of more intelligent clients and more useful visualizations. Mark mentioned a XEROX PARC visualization method of several years back that he found very impressive and would like to someday be able to implement.