[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: DN->DNS mapping in draft-ietf-ldapext-locate-05.txt
RL 'Bob' Morgan wrote:
>
> David:
>
> > Can you give us more details about how this migration path is supposed
> > to work. And also why creating low down dc branches is more beneficial
> > than creating dc branches from the root. I would like to understand
> > how and why they want this change in the locate ID to be made, and if
> > there is a sensible technical reason for choosing the method they are
> > proposing, rather than one that conforms to the existing locate ID.
>
> Well ... because with an already-deployed directory it's (perceived as)
> easier to change names of lower nodes rather than top ones.
>
> But I have to think that the burden of proof goes the other way. What is
> the "sensible technical reason" for having the mapping the way it is in
> -05? Why is a mapping that imposes more limitations on naming better than
> one that permits more options, however unsightly they may seem to some?
> So far there has been a lot of hand-wringing but not a single substantive
> reason that I can see.
My opinion is that we cannot convert from all possible LDAP DNs to DNS
names. I think everyone agrees with that (too many attribute types). We
can only convert dc attribute types. And we have made the decision to
restrict that to single AVA RDNs, thereby forbidding dc=abd+dc=com for
example. We could convert from all possible combinations of single AVA
dc RDNs in a DN into DNS names, (e.g. dc=abc, ou=x, dc=xy, o=efg, dc=
def, dc=com, c=gb -> adc.xy.def.com) or we could convert all contiguous
dc RDNs into DNS names (in which case the last example poses a problem,
is the answer abc or xy or def.com?) or we could convert all contiguous
dc RDNs from the root (which is the current approach of Locate-05 and
would yield null in the current example) or all contiguous RDNs from the
leaf (in which case abc would be the answer), or the first contiguous
set of dc RDNs working from either the leaf or the root (giving answers
of abc and def.com respectively).
So there are many possible algorithms. Do you agree? So which is the
best?
In order to answer this we might ask why are we using dc based RDNs. The
answer is firstly to leverage the DNS name registration scheme to get
globally unique LDAP DNs. In which case, the dc based names will start
at the root of the DIT and will name the context prefix entry.
Thereafter the organisation can build its tree without using the dc
naming attribute, and can use the dc components to perform SRV lookups
(the purpose of the locate draft). Thus the sensible algorithm is to use
contiguous dc RDNs from the root (and guess what - this is what
locate.05 already says).
Then someone suggests an alternative algorithm (yourself) which is more
flexible and when asked to justify the requirements does not have one,
other than a spurious reason that its easier to change nodes lower down
in the tree. Heck, as LDAP administrator I can create nodes anywhere in
the DIT with minimum of hassle. SO I dont buy that one.
Then someone says, my PKI CA creates subject DNs where they are all
subordinate to the name of the CA, hence I cannot change the top of the
DIT, only the leaves. But that is not true. Firstly you cannot change
any subject names without creating new certificates. So when you create
your new certificates, it already contains the CA (authority) name and
the subject name can be anything to uniquely identify the subject, so
why not use the globally unique dc based name form starting from the
root (which was one of the original drivers for dc names). Why would you
want to stick some dc based names at the end of the new subject name
thus making it unduly long? And have the CA name twice in the
certificate? It simply does not make sense to me. Instead, create a new
dc based tree for new subjects and let the old tree based on the CA name
at the top, wither and die (as it was a dumb naming scheme anyway).
Incidently, the algorithm for finding the LDAP server for these
certificates could be based on the CA (authority) name and not the
subject name, since it could be the LDAP server for the CA that we want
to find (but that is a separate issue).
David
>
> - RL "Bob"
--
*****************************************************************
David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351 Fax +44 161 745 8169
*NEW* Mobile: +44 77 96 44 7184 *NEW*
Email: D.W.Chadwick@salford.ac.uk
Home Page: http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500: http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
x-mozilla-cpt:;11160
fn:David Chadwick
end:vcard