Subject: Mapping certificate to directories

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 02 Mar 1999 10:38:44 -0700

Well at long last, we are beginning to address the 
extremely complex issue of mapping between the contents 
of a certificate, and in particular the "distinguished name,"
and the structure and schema that might reasonably be used
to contain such certificates, CRLs, and other useful information.

Here are a couple of things to keep in mind:

1. At present, we don't even have an agreed to method of finding
where a directory  that contains a certificate, etc., might be located.
and once we do find such a directory, we don't know what the DIT 
or the schema looks like.

2.  Without attempting to predict what will happen in the future,
we must observe that for today, at least, there is no widely-agreed to
standard for how directory trees should be constructed, and in general
every organization that implements a directory tends do to it differently.
(I believe I've mentioned before that once in a talk I mentioned our
own tree internal structure (e.g., bjueneman.nsrd.prv.novell) as an 
example of that fact, only to have someone remark that they did
the same thing -- all their NetWare systems used "novell" as the 
top leaf in the tree.  Presumably they had other directory systems which 
ended in "microsoft".  Arrgh!)

3.  The problem will probably get worse before it gets better, if that 
ever happens.  If I am running my e-mail system while sitting on an 
airplane, I would probably look for certificates in my own personal
directory or cache, which might or might not be organized in accordance 
with my company's corporate directory.  If I don't find what I am looking for
there, I would next check the corporate directory, and if that doesn't work,
I would want to try to search in either the originator's directory, if possible,
or in the CA's directory (if they maintain one), or in some repository that either
the originator or I might happen to have a contract with for such purposes.

4.  It is entirely conceivable that every single one of these directories 
will have a completely different DIT structure, and probably a different 
schema for what attributes are allowed in a DN as well.

5. It is important to remember that existing directory structures are 
created for the convenience of their administrators, primarily, and 
reflect design properties that are strongly influenced by delegation
of authority and geographical and/or organizational proximity.  This is,
the top-level system administrator will own something like our DS-ROOT,
and will closely guard who has write privileges into that tree.  Then he
will delegate subtree rights to other sub-administrators, most often on
a geographical basis (Provo, San Jose, Bangalore). Sub-sub-administrators
may then create additional nodes in the tree, sometimes on a 
organizational basis and perhaps more often on a geographical basis 
that more or less mirrors the router connectivity.  I guess it should be 
obvious that this structure doesn't break down neatly on geopolitical
or even organizational lines.

6.  In general, system administrators haven't made any kind of 
systematic provision for external users or organizations outside their 
own organization. If they had, they might well have adopted 
a structure closer to the X.400/X.520 model, but since directories are 
normally rolled out for internal purposes long before people start thinking 
about integrating them with other organizations, it is often too late
to change them in any kind of systematic or organized way.

7.  All of this has of course nothing whatsoever to do with legal names
or other niceties, especially those that might be expected to show up 
in some relying party's browser or e-mail program, where the user or RP
might reasonably expect to see a name that bears some reasonably 
correspondence to SOMETHING that he recognizes in the "real world,"
whether that is an e-mail address, physical (postal) address, or 
organizational structure (business card like).

8. At present, we are between a rock and a hard place.  We have 
implemented certificates using the DN construct to contain
information that is usually intended to be displayed and hence 
considered reasonably meaningful (although we don't even have
a standard for that means), yet the DN was really supposed to 
be the primary search index into a directory that contains that 
certificate. But the directories aren't built that way, in general,
and probably aren't going to change, and in the meantime very
few products display alternate names at all, and the path 
processing for alternate names rather than the DN is something 
that I don't even want to think about.

I have the direct responsibility for trying to resolve this architectural 
issue within Novell, including integrating both our NDS and our 
PKI products, and I confess that I am just about stumped as to what to recommend. I don't like ANY of the alternatives very much.

I am beginning to think that it may be necessary to recommend to 
customers that they graft on a subtree to their DIT, maybe called 
something like CertificateIssuer, and then file all certificate issued by
a given CA under that CertificateIssuer node, and hope and pray 
that the CA has enforced some kind of common tree structure 
on the certificates they issue. Then regardless of what the 
certificate specifies as a DN, it would be filed under the 
CertificateIssuer node, as though CertificateIssuer had been 
an implicit top-level RDN.

Unfortunately, I'm not at all confident that every CA in the world has
been completely consistent -- they may have issued certificates containing 
whatever DN the requestor requested, regardless of whether it
complied with a common DIT for that CA or not.  I don't know.
anyone want to take a guess?

If someone has a magic bullet solution to this problem, I'd certainly 
like to hear it.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Paul Koning <[email-masked]> 03/02/99 08:33AM >>>
>>>>> "tgindin" == tgindin  <[email-masked]> writes:

 tgindin> I think that country name should be made mandatory.  If
 tgindin> country name is made optional, how is the number of
 tgindin> first-level entries in the global directory tree going to be
 tgindin> held down to navigable levels?...
 tgindin> Does anyone know of an alternative attribute that
 tgindin> organizations could be made subordinate to?

 tgindin> Tom Gindin ([email-masked])
                                     ^^^
It seems to me you have an existence proof right there that it's not
at all necessary to subordinate names to countries.

	paul

---

From: Andrew Probert <[email-masked]>
Date: Wed, 3 Mar 1999 09:45:16 +1100

Succintly put.

I had a busy few years promoting electronic mail gateways that did
translational mapping between MSMail, ccMail, Notes, X.400, SMTP ad
infinitum.  We had extensive rules for address matching / mapping between
proprietary name spaces to a common representation (X.400 / SMTP).  These
products are still out there and organsations that have a lot of
administrative baggage / systems must continue to buy and implement them
because its cheaper than alternatives of renaming all users.

But at the end of the day, the whole concept is *broken* and people should
bite the bullet on rationalising namespaces, to not do so only defers the
inevitable and results in kudge upon kludge until you get to where you are
hamstrung by your naming and architectures..

N.B.  Directories can be established to systematically apply Prefixes to
namespaces, which masks the problem.

<snip>

> or the schema looks like.
	[Andrew Probert]  The DIT should not be relevant if the certificate
is in that directory system, you simply do a read by presenting the
distinguished name of the certficate to the directory.  It will return a
certificate anywhere from within the DIT.  

	There should be enough standardised schema to get back critical
data.  Auxilliary items etc could be ignored.

> ended in "microsoft".  Arrgh!)
	[Andrew Probert]  Sympathies.  But DIT structure is not the issue.
Naming and prefixes is.

> the originator or I might happen to have a contract with for such
	[Andrew Probert]  By convention most products out there seem to be
handling this with a 
	local representation  Nickname -> Real Address / Certs / Other data.
As per a previous posting by Alan Lloyd and interesting suggestion is to
have a local LDAP cache.  Of course size and currency and numerous other
issues arise.

> schema for what attributes are allowed in a DN as well.
	[Andrew Probert]  Yep. That's why PKIX should put a stake in the
ground about some of this.

> or even organizational lines.
	[Andrew Probert]  .... and in general organisations will not publish
*all* of their internal directory to the outside world.  More likely it will
be a subset of people allowed to talk to the outside world....

> to change them in any kind of systematic or organized way.
	[Andrew Probert]  ... Lifecycle cost of maintenance, generally means
that they will pay in the end for deferring the problem.  One could adopt
the approach of saying there aren't a lot of certificates in use yet out
there.  So, as each user requires a certficate, lets sort the naming out as
we go, then rationalisation becomes a ongoing process not a single massive
event?

> that I don't even want to think about.
	[Andrew Probert]  .. consider Alias processing in directories, then
the server side does this, not a client responsibility.

> PKI products, and I confess that I am just about stumped as to what to
> recommend. I don't like ANY of the alternatives very much.
> 
	[Andrew Probert]  Again, you could do this by fabricating Alias
entries as pointers into the actual Directory Information Base.  This could
be done systematically, by extracting cert contents.

> anyone want to take a guess?
	[Andrew Probert]  Some I know have flat namespaces e.g. every
domestic citizen in the one arc [double-arrgh!]
> If someone has a magic bullet solution to this problem, I'd certainly 
	[Andrew Probert]  No magic bullets, but

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 02 Mar 1999 18:08:52 -0700

"Succinctly put."  Can I quote you on that?  That's certainly 
not what most people would say about me, I'm afraid! :-)

I want to think about the rest of your comments some more.  

I do increasingly like the concept of either applying or stripping 
a directory prefix, and not insisting on everything in the 
certificate matching the directory, all of the way up to the root.

Otherwise, I think that the answer that people will settle on is
a very flat file of employee numbers, SSNs, etc., which concerns me
from both a performance and a dossier/privacy standpoint.

 I certainly agree that we should have standardized on SOME 
kind of a schema, clear back in the PEM days.  Not to have
one by now is nearly inexcusable.  If we did have such a set of
preferred attributes and a strongly suggested directory tree, I 
might even give up on my MPEG-movie-of-my-cat attribute in
my DN.  :-)

And I agree that organizations will not publish all of the directory
content externally. However, and perhaps unfortunately, it won't be 
the case that they will allow some entire subtree to be published.
Instead, only certain attributes across the entire tree will be extracted.

>>> Andrew Probert <[email-masked]> 03/02/99 03:45PM >>>
Succintly put.

<snip>