Subject: Re: DN revision

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 17 Apr 2001 00:43:42 -0600

I kind of thought this was what was argued against in Minneapolis. My feeling is that this will automatically break many existing implementations, and at best will cause server implementations to incorporate some kind of 'switch' that will be flipped on when performing interoperability tests and off otherwise. 

Unfortunately, many users of commonly found LDAP directories often name entries with textual names not found in the Section 2 table. My guess is that if you poll client implementors, you'll find lots of objections.

The purist in me says: "Yeah, right on, that's a great move", but the pragmatist says: "Danger danger Will Robinson". Unfortunately, I'd rather we word it such that: 

"...Implementations MAY recognize other DN string
representations (such as that described in RFC 1779) but SHOULD only
generate DN strings in accordance with Section 2 of this document, but 
MAY recognize other DN string representations..."

<sorry> Can you restate the problem(s) that we bring on ourselves by allowing servers to generate other names?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 4/2/01 11:51:47 AM >>>
This revision incorporates language to codify a "be liberal
in what you accept, be strict in what you produce" requirement
as discussed prior to and at IETF#50.  In particular, the
following paragraph was added to Section 3 of the I-D:

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2 table, but MAY recognize other
  names (keywords).  Implementations MAY recognize other DN string
  representations (such as that described in RFC 1779) but SHALL only
  generate DN strings in accordance with Section 2 of this document.

Does the addition of this paragraph, specifically the first
sentence, adequately address concerns resulting from the previous
Section 2 clarification of "a published table" to be the table
published in Section 2?  If no, what sort of change do you believe
is necessary? (specific suggestions welcomed)

Does the addition of this paragraph, specifically the second
sentence, adequately address concerns resulting from the previous
removal of the "Relationship to LDAPv2 and RFC 1779" section?
If no, what sort of change do you believe is necessary? (specific
suggestions welcomed)

I note that at IETF#50, there was agreement to form an engineering
team to produce recommendation(s) on how to resolve the significant
outstanding issues with this I-D.  That's still the plan.  Your
answers to the above questions is meant as input to this engineering
team.

Regards, Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 00:48:14 -0700

><sorry> Can you restate the problem(s) that we bring on ourselves by allowing servers to generate other names?

First, s/servers/implementations/.  The issues and requirements
apply to all protocol peers.

By allowing implementations to generate other DN forms (then
described in section 2), one is effectively mandating that all
other implementations recognize these forms.  The question
should not be "what MAY implementations generate?", but "what
MUST implementations recognize?".

That is, while implementations MAY be liberal in what they
accept, they SHOULD be strict in what they produce and they
SHOULD not expect others to offer any particular liberty.

While I personally believe last SHOULD to be a MUST, but I
think I could live with a SHOULD if we state why the
requirement is present.  Hence, I suggest replacing the
paragraph in section 3 with:

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2 table, but MAY recognize
  other names.  Implementations MAY recognize other DN string
  representations (such as that described in RFC 1779). As there
  is no requirement for other names or alternative DN string
  representations be recognized, implementations SHOULD only
  generate DN strings in accordance with Section 2 of this document.

In addition, security considerations related to the use of other
names and/or alternative DN string representations should be
detailed.

Comments?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Apr 2001 11:45:54 -0700

>names and/or alternative DN string representations should be

I offer this additional security considerations regarding
the use of other names.

  5.3. Use of Other Names

  Attribute type names are not unique.  A string representation  
  generated with names other than those in the Section 2.3 table is
  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, in which the type known locally as FOO and the value is of
  the octetString "BAR" 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, and while
  taking 5.2 into consideration.