IETF X500 Working Group First Meeting 11 Oct 1990 San Jose Ca. Attendees: Jose J. Garcia-Luna SRI joaquin@nisc.sri.com Steve Kille UCL s.kille@cs.ucl.uc.uk Bill Manning Texas Instruments bmanning@houston.sc.ti.com Sze-Ying Wuu JvNCnet, Princeton wuu@nisc.jvnc.net Nancy Schultz JvNCnet, Princeton schultz@nisc.jvnc.net Sergio Heker JvNCnet, Princeton heker@nisc.jvnc.net Alf Hansen UW-Madison Alf.Hansen@pilot.cs.wisc.edu Einar Stefferud NMA stef@ics.uci.edu Mimi Zohar IBM-Yorktown zohar@ibm.com Ly Loi 3COM lll@3com.com David Sutton Retix davids@retix.com YouBong Weon-Yoon ATT Bell Labs youbong@att.com Ken Rossen BBN Communications kenr@bbn.com Larry Kaufman BBN Communications lkaufman@bbn.com Bill Barns MITRE barns@gateway.miter.org Sally Tarquinia MITRE sallyt@gateway.miter.org Alex Brown BNR-Ottowa alex@bnr.ca Dave Brent CDNnet brent@cdnnet.ca Ross Callon DEC callon@bigfut.enet.dec.com Barry Holroyd SUN berries@eng.sun.com Richard Colella NIST colella@osi3.ncsl.nist.gov Thomas Maslen SUN maslen@eng.sun.com Charles Wolverton Aerospace Corp ctw@aero.org Mark L. Lambert Oracle markl@us.oracle.com Naresh Kumar Touch Communications naresh@touch.com Peter Mierswa DEC ------------------ Peter Yee NASA yee@ames.arc.nasa.gov Paul Koski HP koski@hpindog.cup.hp.com Dan Brown Tektronix dib@orca.wv.tek.com Greg Minshall Novell minshall@wc.novell.com Mary Anthony Novell manthony@wc.novell.com Louisa Thomson Hughes thomson@draco.hac.com Gihan Dias UC-Davis gdias@ucdavis.edu Robert Hagens UW-Madison hagens@cs.wisc.edu Dan Molinelli TRW moline@trw.com John Quarterman TIC jsq@tic.com Greg Brown Sterling Software browner@trident.arc.nasa.gov Mylene Marquez Sterling Software mylene@trident.arc.nasa.gov Mohsen Banan Boeing Computer Svcs mbanan@atc.boeing.com Adgenda: Intro/Welcome Background status X500 standardization (activity update) Internet X500 piloting (PSI pilot?) Worldwide pilot Scope & Charter discussion Adgenda agreement White Pages issues Naming Schema Naming Notation X500 extentions Relationship of X500 to DNS Application use of X500 Liaison with RARE-WG3 Date & Venue for next meeting Background & Status: Internet X500 pilot - at this time, it is a grassroots effort, no IAB support Scope & Charter: - Group to provide a framework for x500 pilot within Internet. Revisions to proposed scope V2 include Item 1 - X500 extentions Focus on Internet procedures of operation ie RFC's Avoid areas that will become standardized, but attempt to provide "interim" solutions that will intercept the CCITT/ISO solutions. Areas of concern are: * Replication Knowledge managment Schema managment Access control Authentication - both these should have intercept code from Oct90 Ottowa meeting * Distributied Operations for partially connceted DSAs Presentation Address handling * Areas that this group might profitably address. Item 2 - Application of the directory A prioritised list of areas that pertain to Internet are: i. DNS aspects ii. Yellow Pages and general searching iii. Privacy ie X509 "holes", RFC's 1113/4/5, Policy based routing iv. RFC 1148/987 (as a BOF?) Item 3 - Deployment 3.1 Schema Review THORN/RARE naming architectures as a basis for work. Item 4 - Liaison NIST is already involved via R.Colella S.Kille will initiate RARE WG3 contacts CCITT/ISO IEC - ??? NADF - [ES] to pursue. [ES] North American Directory Group summary: misson statment: collaborate for the purpose of establishing public directory services based on CCITT X500 recommendations and accelerate their implementations in North America and stage impleentations based on CCITT X500 specs. direction statment: decide local (NA) matters and work to resolve global issues. They are a planning forum and hope to flag standards problems. membership requirments: Any ADMD (X400), or ADDMD in NA. They must be willing to work with their peers. Operations is be consenise. Work is based on paper contributions. Approx. 55 documents so far. Overriding them all is a "living" document. member list: AT&T, Ameritech, BellLabs, Bell Atlantic, Bell South, Bellcore, GEIS, IBM-CA, ITT, MCI, Infonet, PACbell, PSI, IBM, Nynex, SWbell, US Postal Service, Sprint, Teleglobe-CA, Western Union. a program plan exists with dates for completion. these dates are INTERNAL targets only and not for public consumption. (there is already some slippage) already seperated into two subgroups: 1. service definitions 2. strawman schema - M. Rose is acting as a consultant here major agreement so far: Share information regarding the location of information holding record for All DN. In other words, Any given DN has a pointer to a DSA that holds the record for that DN. This data could be cached...maybe. [RC] Who owns the records? [ES] Still open for debate, but they must share some information. The minimal set seems to be the pointer to every DN. Can a provider charge for access to data they do NOT own? The problem: There is at least one telco and ADMD in each country. North America has quite a few. They are NOT forceably constrained to cooperate and ARE forceably constrained to compeate. [BM] What about offnet registrations, ie data NOT stored in a ADMD DSA, but in a private DSA? [ES] Not part of the agreements between providers. If the data is not in an NDAF DSA, then all bets are off, since DN's do not say who owns the record. [YB] How are areas handled, ie are there multiple owners by object class? [ES] Local telcos have odd service bounderies, but if you look in a directory, it contains no locality information (who "owns" my number). The real problem is with distributed entries. [SK] X500 replication should be on a per entry basis in a formal, controlled environment. There isn't the concept, as in DNS, of something polling up the tree for information. There is a view that X500 entries are "atomic" ie one person controls the entry not parts of that entry. The problem that Steff refered to was with distributed entries where someone maintains parts of an entry and someone else maintains other parts. For example your telco may want to manage your phone number, while the email provider may want to manage the address part. It is a very real requirment but technically awkward. NDAF has discussed the distributed entry problem and is hoping for it to be solved before implementation, however some feel they ought to proceed under the assumption that there will not be distributed entries. They will have to deal with it some other way. [SK] The issue of distributed entries is actuallly where you need to manage the data that is kept in the seperate DSAs, it might be a type of access control where you have the data in one DSA controlling access to data in a seperate DSA. [ES] Yes, this sharing is kind of interesting because presisley what file systems are presented and where the data resides becomes a matter of negotiation between parties on a per entry basis. (The potential for bandwidth consumption could be enormous! - WCM) [YB] Does that mean that more than one DSA holding partial resolution of an entry? [SK] That is the model that we would like to evolve. That is not what is happening at the moment. [YB] So there is more than one pointer to multiple DSAs? [SK] You get into a mess very rapidly in that case, but that is where its at. [ES] Yes, this is an unsolved technical problem and maybe an as yet udndefined researce problem. [SK] A more general point. It is known that we are trying to be assosicated with the depolyment of a pilot on the Internet. What sort of time frame might be available that could be useful for us? Such as when a registration authority might be available or operational DSAs that could be connected to? [ES] Working on getting some things defined, like service definitions, and design stuff by the end of January 91. Although those are VERY loose dates: Mapping DIA to multiple ADMDs - Jan 91; DSA/DSP operational - Apr 30 '91; Operational Managment Jul 91; Doesn't look like anything coming up prior to the end of 91. [YB] Any time frame for a demonstration? [ES] Not that are published. [ES] I asked Marshel Rose if he had any problems implementing the schema they (NADF) were talking about in his WP project? He said it was a subset of what he is working on. That didn't take care the business of sharing information. That is still being struggled with. ATT's Al Brumstead is working on the problem. The State Department is the USA arbitratior of ISO compliance. They will be responsible to ensure that US carriers will work with international carriers implementations. They have formed a sub-committee to deal with national decisons on X400/X500 issues, specifically to provide registration service and conceivably to write the rules for interworking within the US. The CCITT study group "D" will decide on 29 Oct if they will honor the charter of the group. If it happens, the first meeting will be on Dec 17/18 after the OSI workshop at the State Dept. Scope and Charter Discussion: 1. CCITT is working on Replication/Knowledge Representation. Is it interceptable? 2. Extended information model. subtrees/shared access control/group resources 3. Access control (CDAM stage) authorization is good, but needs ACL 4. schema extention - country/org etc imbedded in the directory 5. improve search / extended attributes - search has the most problems, externalize matching rules 6. intruduction of short form names - < 2 opposing camps in CCITT [RC] #3 may move as a fast track item prior to 92, a possible push for this group [Retix] #3 and replication may get DIS status in Mar'91 per Ottowa mtg. We need to: - define pilot requirements - ad hoc or intercepted stds? - how to share schema information - publish RFCs? - X/Open - POSIX - IETF 400/500 WG meet together? FTAM, VT and other OSI services are already on the Internet What is our compatibility with other working groups? two thrusts - X500 infrastructure - X500 services Schema: [SK] There seems to be a need, if we are going to deploy a pilot on the Internet that have agreement on the things that are to go into the directory and over the past few years and with some experience, particularly with the PSI pilot and the European pilot, that you find things in the directories that are not in the standards, such as mailbox addresses, favorite drinks, and other such useful things that are not defined by the standards. What I would like to see happen out of this group is to define those things that are Internet specific. I would like to see this happen in conjunction with the RARE work. I view the right way to do it is to have an increased involment in defining the Internet architecture for directory services by groups of people who say that they want this feature and that. There needs to be a means for registration on the Internet. [YB] What services does the pilot provide, that doesn't have X400 in it? [SK] The way the architecture, perhaps I've got one copy of it, of the early version, done for RARE, dated May'89. This architecture has been adopted by the PSI pilot, so it seems to be an acceptable beginning. [xx] Since this architecture has been accepted by two organizations, (PSI & RARE), lets make it three. (IETF) [SK] To do so will require that we publish RFC's. They are a little bit strange in that while in principle they carry very little status, but once things make it into RFC status they begin to carry a surprising ammount of weight. Should we publish these activities as RFC's? One of the reasons that Paul was not prepared to release the update was because one thing we wanted was to have a standard pro-forma for submitting requests for defining object classes. This should produce the documentation of the directory structure as well as machine parsable tables. Keeping schema consistant is a pain. Ought to publish an RFC that describes registration that is self documenting and creates machine readable inputs. What things should be registered in an Internet pilot? - Review THORN documentation as a basis. It uses UK/UCL numbers as offical numbers - CRNI's Knowbot ? - SRI-NIC whois database ? Should a "well known attributes" RFC be published? Can we publish/use IAB numbers? [JGL] PSI & NIST, with Internet (Merit,SRI,etc) spoke with Dr. Mockapetris on ISI evaluation. Will use NIST implementation guidelines. Populated with whois and Merit data. Only schema for Internet, not global scope. Name Notation: Proposed syntax - Review S.Kille papers DUA formats, notation which is not distributed name ported names map to quipu. ie FTAM, X500, MHS names RDN Mapped Ported (X400 "name") ------------------------------------------------------------- C=GB Steve Kille Kille, UCL, GB O=UCL Computer Science OU=Computer Science UCL, GB CN=Steve Kille [YBong] Applications, schema etc. can be used to define strings. X500 extentions: Authentication - a draft RFC was requested on a secure pilot. access control on the directory itself? Users should modify (portions) of their own information. This area needs stds and mechanisims published. QIPU has PKS but is unavailable in US (RSA restrictions) Do we want authentication & security in our pilot? - Yes. [RC] Should have an "open" pilot, with multi-implementation representation [PY] Will draft, with help, notes on desirable characterisics of ACL (X509) and authorizations needed to join the pilot. Emphsaise searching and distributed updates. last four - hope to have available by Jan'91 - Replication - Expand QUIPU specs uses protocols has data modeling - uses sibling entries ie DECdns spot shadowing - Knowledge Representation - Distributed Operations - for X.25 ONLY DSA's per RFC 1006 - Presentation Address formats - Check the RFC's [SK] These should be used but will entertain alternatives [ES] Does that mean vendors have to implement THREE forms? Existing, QUIPU, and future CCITT specs? [AB] Schema "kludge" for replication and Knowledge representation? [SK] Yes, but.... (Replication is OK but KR is VERY busy) X500/DNS X500 and domains - draft document describing how mapping might work. There is NOT a tight linkage between X500 and DNS tree structures. At a leaf node, (CN) there can be a linkage, using extended atributes. -------------------- Action items: X500 differences/similarities note to mail list - Richard Colella NIST colella@osi3.ncsl.nist.gov Route PSI presentation - Steve Kille UCL s.kille@cs.ucl.uc.uk Route X500/DNS paper. Jan'90 RFC draft to mail list - Steve Kille UCL s.kille@cs.ucl.uc.uk Circulate calls that replace gethostbyname with X500 / QUIPU API calls Include bind load and directory formats - Alex Brown BNR-Ottowa alex@bnr.ca Liasion request for Schema strawman for the IETF X500 WG from NADF - Einar Stefferud NMA stef@ics.uci.edu Add attendees to minutes - Bill Manning Texas Instruments bmanning@houston.sc.ti.com Circulate THORN documentation to mail list prior to Ineternet draft - Steve Kille UCL s.kille@cs.ucl.uc.uk Develop a draft RFC on secure additions for Internet X500 pilot - Peter Yee NASA yee@ames.arc.nasa.gov - Bill Manning Texas Instruments bmanning@houston.sc.ti.com Note on cahing and ACL approch for use in "secure" X509 RFC - Steve Kille UCL s.kille@cs.ucl.uc.uk - Richard Colella NIST colella@osi3.ncsl.nist.gov Circulate papers on : 1. what is QUIPU? 2. draft RFC on registration issues 3. Cover memo on why X500 - Steve Kille UCL s.kille@cs.ucl.uc.uk Soft copy of Ottowa meeting notes to mail list, particularly on replication - Alex Brown BNR-Ottowa alex@bnr.ca 400-NIST document on directory services for MHS - Einar Stefferud NMA stef@ics.uci.edu Regards, Bill Manning -