[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comment on I-D ACTION:draft-ietf-ldapbis-dn-08.txt
Kurt
I dont like the general thrust of this ID regarding the use of alternate
DN strings.
I would like the following text from 2.3 to be struck out of the current
ID, as it unduly prejudices the use of additiional DN strings
"As no extension could reasonable require all existing
implementations be updated to recognize additional type name
strings, this table is not extensible."
I would like 5.3 to be edited as follows
5.3. Use of Other Names
Attribute type names are not unique unless recorded in an
internationally agreed document (such as an IETF standard like this one)
or registry (such as IANA). A string representation
generated with names other than those in the Section 2.3 table or
other internationally agreed document or registry is likely to be
ambiguous. That is, two applications may recognize the string as
representing two different DNs possibly associated with two different
entries. This may lead to a wide range of unexpected behaviors which
can have both direct and indirect impacts upon security.
For example, a distinguished name consisting of one RDN with one AVA
of the known locally attribute type FOO and the value "BAR" (an
octetString) could be represented in LDAP as the string FOO=BAR. As
the name FOO does not uniquely identify an attribute type, the DN
FOO=BAR is ambiguous. That is, FOO could be recognized as the
attribute type 1.1.1 by one application and 1.2.3.4 in another and not
recognized by another. This may lead to operations not behaving as
intended.
Applications desiring to generate an unambiguous string representation
of a DN SHOULD generate string representation per section 2, not use
names other than those in the Section 2.3 table or other
internationally agreed documents or registries, and while taking
Section 5.2 into consideration.
DELETE THIS FINAL PARAGRAPH (or else withdraw the whole LDAP user
schema RFC2256)
It is noted that while a registry for attribute type names
(descriptors) has been established [LDAPIANA], this registry does not
remove the ambiguity of attribute types names used in LDAP. It only
removes the ambiguity of attribute type names used in Standard Track
technical specifications.
Regards
David
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351 Fax +44 01484 532930
Mobile: +44 77 96 44 7184
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
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard