RE: Mapping certificate to directories

[Andrew Probert <AndrewP@xxxxxxxxxxxx>]

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>


> 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.
> 
	[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.

> 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!)
> 
	[Andrew Probert]  Sympathies.  But DIT structure is not the issue.
Naming and prefixes is.

> 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.
> 
	[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.

> 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.
> 
	[Andrew Probert]  Yep. That's why PKIX should put a stake in the
ground about some of this.

> 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.
> 
	[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....

> 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.
> 
	[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?


> 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.
> 
	[Andrew Probert]  .. consider Alias processing in directories, then
the server side does this, not a client responsibility.

> 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.
> 
	[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.

> 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?
> 
	[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 
> like to hear it.
> 
	[Andrew Probert]  No magic bullets, but 
> Bob
> 
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> bjueneman@novell.com
> 1-801-861-7387
> 
> >>> Paul Koning <pkoning@xedia.com> 03/02/99 08:33AM >>>
> >>>>> "tgindin" == tgindin  <tgindin@us.ibm.com> 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 (tgindin@us.ibm.com)
>                                      ^^^
> It seems to me you have an existence proof right there that it's not
> at all necessary to subordinate names to countries.
> 
> 	paul