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
-