Subject: alternate "dc" naming conventions

From: Michael Helm <[email-masked]>
Date: Mon, 19 Mar 2001 15:51:46 -0800

I'm working with a directory implementation that needs something
like DNS SRV records and the locater draft to scale.  But the
current locater  draft doesn't fit well with this implementation.
I think it is in our interest to ask that the locator draft
be extended to include some other well-structured cases
beyond the current right-most dc= list.  If that's done, then
our standards process can reference the IETF's work & hopefully
interoperate.   Alternatively, I can produce a knock-off of the 
current locator that would describe our requirement.  (How
useful would this be?)

The DIT in the directory software supporting Grids
(see http://www.gridforum.org and www.globus.org)
has a number of conventions in its history.  The original one,
which still exists in some large deployments, looked like
this:

(grid dn components), o=Your Name Here, o=Globus, C=us
that is, a non-conformant X.500 style of naming.

The current implementation supports names like this:
(grid components), dc=biglab, dc=org, o=grid

The planned implementation wants dn's to look like this:
(grid components), dc=biguni, dc=edu, vo=Internet, o=Grid
and
(grid components), vo=MyOrg, o=Grid

The assumption here is that whoever is querying the directory
service (whatever directory service) somehow "knows" where the
server that supports the suffix "vo=MyOrg, o=Grid" is ab initio.

But no such asssumption about "dc=biguni, dc=edu, vo=Internet, o=Grid"
is made for the benefit of this server.  Ideally the server deals with
this by a referral.   The nature of the software supporting the grid
architecture requires a large number of referrals as the mesh grows, 
and maintenance of these records individually won't scale well.
Thus the utility of DNS SRV.

It's likely that Grid certificate authorities  will issue certificates
with these kinds of names in the near future.  The security services
are evolving requirements for directory, and probably also will
have to interoperate with existing PKI's that may have adopted
X.500-type naming conventions such as Tim Polk described.

(NB: I would appreciate any comments on this, but please
separate your comments & reaction on the architecture from those  related
to the request to extend  the locator draft :^)  Thanks, ==mwh

Michael Helm
ESnet/LBNL  (mailto: [email-masked])