Subject: Attribute Name Length Bounds

From: "Chris Apple" <[email-masked]>
Date: Fri, 13 Jun 2003 03:28:54 -0400

I have encountered a problem while attempting to extend the basic schema
of several different LDAPv3 server implementations. Specifically, some of
them place restrictions on the length of attribute names. In one case,
the attribute name length restriction is rather short, too short to
make it possible for it to distinguish between two different attribute
names with the same character string as a prefix. Take a look at the
DEN schema for examples of such attribute names.

So far, I cannot find a requirement in any LDAP-related RFC or I-D
that addresses the issue of attribute name length bounds.

This means that you cannot take the same schema specification and apply
it verbatim to different LDAPv3 server implementations and to me
represents an inhibitor to interoperability of clients and servers
that have different attribute length restrictions/constraints/etc.

However, I am not sure where to suggest adding such a requirement
to clarify the nature of the problem to implementers so that this
interoperability impact can be minimized.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Jun 2003 12:03:42 -0700

I have a few (personal) thoughts on this issue...

From a protocol point-of-view, interoperability can be said to
be demonstrated if a presented overly-long attribute descriptor is
treated as unrecognized type.  Likewise for attribute options and
other such protocol tokens.  Additionally, no harm (to protocol
peers, security, the Internet) is done by an implementation which
simply treats overly long (by whatever definition) as unrecognized.
Hence, I don't think an RFC 2119 imperative is not warranted here.

This is not to say that an implementation which imposes significant
limits on the length of attribute descriptors, options, and other
such things has not limited its applicability.  It just to say its
not a protocol interoperability issue.   Implementations should be
free to limit their applicability.

There are many issues that a technical specification detailing
how to support "open-ended sets of attributes" likely would
need to address.  I think these issues can be left to a future
document.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 13 Jun 2003 17:44:27 -0400

Are you saying that you believe that SHOULD (rather than MUST)
is the appropriate strength of requirement to use so that
implementers can limit their scope of applicability as they
see fit?

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kurt D. Zeilenga
Sent: Friday, June 13, 2003 3:04 PM
To: [email-masked]
Subject: Re: Attribute Name Length Bounds

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Jun 2003 16:53:52 -0700

>implementers can limit their scope of applicability as they

No.   I am saying that, in my opinion, no RFC 2119 imperative
is warranted here.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 16 Jun 2003 21:46:20 -0700

In re-reading the top of this thread, I have a comment which are
covered well in other follow-ups.

At 12:28 AM 6/13/2003, Chris Apple wrote:
>names with the same character string as a prefix.

Are you saying that a server is treating two different short
names (descriptors) as being equivalent because the first few
characters of the name happen to be the same?

That is, an implementation is ignoring the difference in
  'x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-1'
and
  'x-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-2'.

If yes, I would consider that to be an implementation bug.  I
suggest you report this to the implementor.  Two names should
only be considered equivalent if they contain the same set of
characters (ignoring case).

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 17 Jun 2003 01:19:19 -0400

That's an accurate example of what I observed.

The implementer is aware of the issue.

I do see your point that this might be considered
a bug.

I also think that the fact that this bug can exist
is a result of an ambiguity in the LDAPv3 proposed
standard specs.

Based on one way of reading the specs, the two attributes
are actually the same from the perspective of the
implementation. This is based on there not being any
minimally supported length requirement. In this case,
from a protocol perspective, the attributes really are
the same and therefore should not be distinguishable
Because the implementer chose to give precedence to the
allowance of unbounded attribute types over the requirement
to distinguish unique attribute type names based on their
unique octet string representations.

Based on another way of reading the spec, the two attributes
are different because they were intended by the folks deploying
the implementation in question to be different. This interpretation
requires that an implementer prioritize the requirement that two
attribute type names be considered equivalent iff they are
represented by the same character string over the implicit
allowance that attribute type names are to be unbounded
with respect to length.

Either interpretation is arguably correct given the state of
the currently published proposed standards documents for
LDAPv3. Thus implementers choosing either strategy are correct
when they claim compliance with the specs.

I believe the best way to address this problem is by clarifying
a minimally supported length as it would remove the ambiguity.

DSI Consulting, Inc.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2003 12:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Attribute Name Length Bounds

Kurt

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 17 Jun 2003 02:20:45 -0700

> [mailto:[email-masked]]On Behalf Of Chris Apple

> when they claim compliance with the specs.

????? If I send an ASN.1 encoded message to a server, and the server
arbitrarily  truncates the end off any of the several length-encoded fields
of the message while processing it, the server has corrupted the message. I
don't see how you can possibly interpret this as correct behavior in the
server.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 17 Jun 2003 12:07:09 -0400

The server wouldn't truncate it. It might say that it
doesn't support the attribute if it is longer than
the value it recognizes as significant for it. Or it might
reply back with some error message. Even though the
sending entity did have a resonable expectation that
it would be recognized...

And since there are not requirements in the specs
about a minimally supported attribute type name length,
replying to attribute types longer than a natively
constrained minimum with a message indicating an unsupported
attribute type is possible and could even be argued as
being compliant with the specs.

The point is that the possibility of interpreting
the specs in this way already set us up for deployment
issues related to several published schema with attribute
names on the longer side of what might have been considered
typical a few years ago.

DSI Consulting, Inc.

-----Original Message-----
From: Howard Chu [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2003 5:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Attribute Name Length Bounds

  -- Howard Chu

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 17 Jun 2003 20:29:09 -0700

> From: Chris Apple [mailto:[email-masked]]

(reposting to the list...)

> names on the longer side of what might have been considered

If the server rejects overly-long names with an error message, fine, but your
message implied that it silently ignored the characters comprising the excess
length in the name. If it seems that the spec is ambiguous about the
significance of characters in a short name, perhaps it would be sufficient to
state in the the spec "all of the characters in an attribute name are
significant. If an attribute name is presented that exceeds a server's
implementation limits, the server MUST fail the request with an error code."
(Maybe NAMING_VIOLATION or CONSTRAINT_VIOLATION...) This would satisfy the
basic need without specifying arbitrary numbers for minimum acceptable
lengths.

  -- Howard Chu

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Jun 2003 20:01:42 -0700

At 08:29 PM 6/17/2003, Howard Chu wrote:
>significant.

One could argue that the TS should be clarified to say:
  All bits of very octet of the PDU are significant unless stated otherwise.

However, I think basically already says this already in X.680/X.690.  But,
I don't see much harm in restating this in [Protocol] (even though I think
it a bit redundant and quite obvious).

I, however, think we should avoid per field statements (except for the
otherwise cases).

>If an attribute name is presented that exceeds a server's

That would be, in general, a bad thing.  Servers should treat attribute type
names they don't recognize as unrecognized attribute types and many of these
cases don't result in an error being returned.

Kurt