RE: mapping identities RE: Compromise Authentication Proposal

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

For my two bobs worth - the fact that certificate have alt names which
is a choice of many things - does not mean that is useful. I did not
like them simply because it just adds yet more confusion to the worlds
name space. IMHO - I do not promote the use of alternates.

The directory is named by DNs - which can take many forms. Entry
attributes under a DN can have attributes which may be other name forms.
It follows if you want to find entity details fast - the name (a
sensible name - the DN) should be used. Otherwise one is wandering and
searching all the direcctories known to man to find any shape or form of
the "alternate name"".. In cert verification and general service
provisioning worlds - having many alternate names with different
syntaxes in different contexts is not really workable. Siply because it
means I need a directory with email address names, local names, numbers,
unique ids, etc.. How do these directory systems inteconnect and scale?

Its easy to promote syntax and more name fields - but that just makes
the system more of a mess and causes knowledge, context, scaling and
operational issues ... Phone numbers are good, DNs for directories
should follow the same plan. By all means use other name forms - but
dont pollute DN semantics..

regards alan

regards alan   

----------
From: Christopher Oliva
To: 'Ed Reed'; Chris.Oliva@entrust.com; ietf-ldapext@netscape.com; 'Paul
Leach'
Sent: 10/10/98 8:34:44 AM
Subject: RE: mapping identities RE: Compromise Authentication Proposal


> > -----Original Message-----
> > From: Ed Reed [mailto:ed_reed@novell.com]
> > Sent: Friday, October 09, 1998 2:10 PM
> > To: Chris.Oliva@entrust.com; ietf-ldapext@netscape.com
> > Subject: RE: mapping identities RE: Compromise Authentication
> Proposal
> > 
> > 
> > For a variety of reasons, some implementation specific, some 
> > foundationally conceptual, I very much want to keep any 
> > access control policy that we wind up with internally 
> > consistent.  Doing that implies that names which are granted 
> > rights must be DNs known (meaning resolveable) to the LDAP 
> > namespace to which they're granted rights.
> 
> Other name forms than DNs are resolvable. Any attribute of an entry
> that is
> unique is resolvable.
> 
> I think we got a layering violation here. Application protocols don't
> define
> security principals -- security protocols do. If this WG wants to go
> to the
> CAT WG and ask for a Kerberos name form for DNs, they are welcome to
> do so.
> But until they do, we can't say that any authentication protocol has
> to
> support DNs for the user name. What we _can_ say (because we do
> directories)
> is that _the directory_ has to be able to map any user name form used
> in an
> authentication protocol into a DN.
> 
> Paul
> 
I'm not advocating a dog's breakfast of alternate name forms. However,
it may make sense to pick a few name forms which are commonly used
rather than relying on possibly unsecured mapping techniques or
embedding alternate name forms within DNs. There may be atleast one
alternate name form which would make a good candidate as an alternative
to DNs. (email address? OID (also heavily used by directories)?)

In any case alternate name forms have already been defined to name
subjects in certificates. Why would directory access controls also not
benefit from this?

Chris.