Subject: I-D ACTION:draft-ietf-ldapbis-dn-08.txt

From: [email-masked]
Date: Tue, 27 Aug 2002 07:50:14 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP (v3) Revision Working Group of the IETF.

	Title		: LDAP:String Representation of Distinguished Names
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-ldapbis-dn-08.txt
	Pages		: 13
	Date		: 2002-8-26
	
The X.500 Directory uses distinguished names (DNs) as primary keys to
entries in the directory.  This document defines the string
representation used in the Lightweight Directory Access Protocol
(LDAP) to transfer distinguished names.  The string representation is
designed to give a clean representation of commonly used distinguished
names, while being able to represent any distinguished name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapbis-dn-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapbis-dn-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 Aug 2002 20:57:37 -0700

This is a revision I submitted a couple a weeks ago, so it
doesn't include clarifications recently discussed.

- In Section 2.4, clarified that the <hexstring> notation
  should be used where the LDAP string representation is not
  restricted to UTF-8 encoded UCS.  Reworked order of 2.4
  statements for clarity.
- Reworded Section 1.
- Added note to 5.3 regarding why [LDAPIANA] descriptor registry
  doesn't resolve the short name interoperability problem.
- Added (non-normative) appendix discussing presentation
  issues (not involving translation or transcoding).
- Used UCS code points instead of ASCII code points.
- A number of editorial changes.

I hope to produce a subsequent revision shortly which:
- clarifies in Section 1 that:
  Section 2 is the RECOMMENDED algorithm;
  other documents may detail other algorithms;
  all algorithms MUST adhere to Section 3 requirements.
- adds text in Section 3 regarding how ABNF productions
  relate to the ASN.1 DN data type;
- provides additional editorial changes.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Wed, 28 Aug 2002 15:39:34 +0100

Kurt

The ID states "It is not expected that LDAP
  implementations with a human user interface would display these
  strings directly to the user, but would most likely be performing
  translations (such as expressing attribute type names in one of the
  local national languages)."

I think it is important that the ID adds after this

"However, it is expected that LDAP APIs will return these strings as
parameters to the calling program"

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: [email-masked]
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

*****************************************************************

---

From: David Chadwick <[email-masked]>
Date: Wed, 28 Aug 2002 16:13:39 +0100

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

--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 Aug 2002 09:37:13 -0700

>  local national languages)."

as did RFC 2253.

>parameters to the calling program"

While for low-level APIs, this might be expected.  But a
high-level API designed to produce a string suitable for
presentation to the user, it might be expected to perform
translations.  I don't this document (or any "core" document)
has any business delineating what behaviors are to be
implemented above or below API boundaries.  APIs should
be viewed as beyond our scope.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 Aug 2002 10:00:43 -0700

>      strings, this table is not extensible."

The phrase "This table is not extensible" is necessary for
interoperability of the RECOMMENDED algorithm.  The "As
no extension could... " part was intended only to explain
why the table isn't extensible, not to unduly prejudices
the use of additional DN strings (beyond that detailed in
5.3).  I am fine with striking the "As ...," part.

I'll comment separately on your section 5.3 suggestion.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 Aug 2002 10:07:21 -0700

At 08:13 AM 2002-08-28, David Chadwick wrote (in part):
>or registry (such as IANA).

No.  RFC 2251 says:
   Attribute type textual names are non-unique, as two different
   specifications (neither in standards track RFCs) may choose the same
   name.

This means that there cannot be two "foo" on the Standard Track.
But there can be a "foo" on the Standard Track and multiple "foo"s
defined otherwise.

We'd actually have to mandate that only registered short names
(and private use names, e.g. x-name) be used in LDAP to eliminate
the possibility that a future registered name doesn't conflict
with preexisting names.

Is that what you want?  What do others think?

Kurt