*MACE-Dir Technical Advisory Board Conference Call* June 28, 2002 *Participants* Keith Hazelton -- University of Wisconsin (chair) Tom Barton -- University of Memphis Brendan Bellina -- University of Notre Dame Kim Cameron -- Microsoft Corporation Steve Carmody -- Brown University David Chadwick -- University of Salford Michael Gettes -- Georgetown University Peter Gietz -- DAASI International GmbH Bob Morgan -- University of Washington Ed Reed -- Novell, Inc. Nate Klingenstein -- Internet2 (scribe) *Discussion* Project Updates Metamerge, an exceptionally useful metadirectory tool, has recently had its creator company purchased by IBM. The tool had previously been available free of charge to the educational sector, but it's unclear to what degree IBM will continue this practice. Nobody on the call was certain of which part of IBM Metamerge was likely to end up settling into, and Metamerge itself has stated that everything is in a state of flux. However, the Johns Hopkins University recently was granted a new free registration and license. MACE-Dir members expressed that they would be tracking this. The Directory Schema Registry is a minor project funded by TERENA and several other international organizations that is being developed by DAASI International. The project is designed to set up a locus for registration of good and well-documented schema for LDAP object classes. Focus will be powerfully oriented towards documentation of both the schema itself and other information, such as a policy document defining the proper and appropriate use of the OIDs, and possibly a recommendations page for object classes for various problems. There have been ideas about connecting this registry with IANA and the OID registry. The preliminary deliverables this project will develop will likely take the form of a web page to search for schema based on schema metadata, or by OID using value matching capabilities implemented in OpenLDAP 2.1. The intended usership is global, and ongoing maintenance should be limited. The major difficulty will be in generating enough traction with enough schema registered to get started. LDAP & PKI, Continued Kim and David had a discussion following the previous MACE-Dir TAB meeting regarding LDAP support for PKI. The pertinent issue Kim raised is that Microsoft's Active Directory only supports and has no plans to move beyond single-valued RDNs, while the draft utilizes multiply-valued RDNs. There are concerns about what this could mean for DIT structure, as well as the viability of reflecting common and necessary PKI practices such as cross-certification for bridging or chaining capability. Entrust, a well-known PKI vendor, has lowered its assumptions about clients to not require LDAP referrals, and can handle poor firewalls and LDAPv2 rather than v3. Border directories may solve part of the firewall problem, but other issues exist. David noted that he had built an LDAP directory years back that sat in the firewall which received limited response. A paper was recently published on the relative performance of ASN.1 BER encoding and XML. On operations such as path processing validation, which look at large numbers of certificates, ASN.1 BER was roughly an order of magnitude faster overall. A method the group proposed to improve the speed of processing certificates in client software that relies on directories is to translate the XML object stored in the directory into ASN.1 BER, which would both limit the need for adaptation of legacy software and potentially increase the speed of transactions. However, the performance using XML objects is somewhat brought in line with that of ASN.1 BER-encodings if more recent PKIX recommendations are followed in certificate issuance. Some fairly interesting issues regarding how certificate extensions could be stored have emerged, given that LDAP benefits from the standardization of object classes. One obvious suggestion is to make extensions children of certificate objects, which could be decoded and stored appropriately. However, this leads to each extension becoming a subordinate certificate, and this proliferation can proceed indefinitely. Things are confused further by the ability to mark extensions critical. There are many complex issues that this approach to certificate storage may run into as it tries to accommodate some of the more powerful capabilities of X.509 certificates. Attribute Flatness The idea of families of entries in LDAP expired as a draft and was never implemented, but could serve to help address this sort of issue. The idea is almost routine in X.500, but as the LDAP standards have been finished this idea has always fizzled out. The board observed that, generally, there is a lot of thought in later versions of X.500 which never saw implementation. The elementary nature of the attribute has been both a boon and a challenge to the LDAP standard. Attribute flatness problems are encountered routinely in many attempts to make data structures more complex. Many hack jobs have arisen because of this to devise ways to pack multiple items of information into a single LDAP attribute with corresponding client parsing. The idea of having more complex server-side representation is intriguing, the board thought. It is currently very difficult to design an enterprise system which utilizes both a relational directory and an LDAP directory which must interact with one another. There were comments that the appropriateness of this approach could hinge on the amount of experience and skill most directory implementers have. Nevertheless, this is a concept the group thought it worthwhile to look into more deeply. Much of the decision may well hinge on the question of whether LDAP should continue to occupy the enterprise role it has served in so well or whether it should attempt to be more ambitious in its capabilities. "Those with a certain historical perspective think this is the revenge of the hierarchical database," quipped Bob.