Subject: clarifying RFC2251

From: Christopher Oliva <[email-masked]>
Date: Fri, 27 Aug 1999 13:07:59 -0400

I have a couple of points which may need clarification for RFC2251:

1) Relationship between the ;binary attribute option and the Binary syntax
of RFC2252.

The description of the ";binary" attribute option indicates that it must be
used in order to specify BER encoded attribute values in cases where the
attribute syntax may have a non-BER presentation or ASN.1 syntax. The
example given is for the Certificate syntax. But what about cases where the
attribute syntax is Binary? In this situation, the only permissible
presentation of the attribute values will be the BER encoding. In this case
the ;binary option is redundant. I'm sure the most common interpretation of
the RFC is that even for the Binary syntax, the attribute type must be
referenced using the ";binary" option however there is no supporting
documentation in the RFCs for this.

I would suggest that when the attribute is referenced in client requests,
that the ;binary option tag MUST be present. Also, when the server responds
to a query where the attribute type was explicitly requested, the ;binary
option MUST also be present. However when the client performed a request and
did not explicitly request the attribute type, the server SHOULD include the
;binary option tag.

2) BER vs DER in ASN.1 signed data types (Certificate etc.)

Many popular implementations of PKI software actually requires DER encoding
to be returned by the directory. However, the RFC currently only specifies
BER encoding. Section 5.1 of RFC 2251 says that the "lightweight" BER rules
of ldap do not apply to attribute values therefore you could get anything
back as values which conform to BER - example. indefinite length encoding.

The situation could easily be remedied by saying that for signed data
structures, the server should always return the exact same encoding in a
response as the encoding which was originally added. This is currently not
stated and some servers attempt to re-encode values.

3) X.500 interoperability for ldapv3 Binary syntax

What X.500 schema configuration is compatible with the ldapv3 Binary syntax?
My understanding is that the ASN.1 ANY syntax is deprecated and should not
be used. What other syntax can be used in order to ensure consistent X.500
interoperability (shadowing etc.) for the Binary syntax? 

4) Ambiguity of the ldap modifyDN operation

The ldap Add operation requires that the list of attributes which comprise
the DN be included in the "attributes" parameter. Given this behaviour for
the add operation, the Modify DN operation is ambiguous since the RFC does
not state if the list of attributes which comprise the "newrdn" parameter
must already be present in the directory entry being renamed. If it is not
necessary that they be present, then why must the distinguished values be
included in the attribute list for the Add operation (X.500 does not have
this requirement)? Either way, the Modify DN operation should be clarified.

Chris.

-----------------------------------------
Chris Oliva
Entrust Technologies

(613) 248-3014
[email-masked]
http://www.entrust.com
-----------------------------------------

---

From: John Kristian <[email-masked]>
Date: Mon, 30 Aug 1999 10:38:05 -0700

Christopher Oliva wrote:

> 1)  ... I'm sure the most common interpretation of the RFC is that even for
> the Binary syntax, the attribute type must be referenced using the ";binary"
> option ...

I don't interpret it that way, nor does anyone I know.  Has someone taken a
survey, to see if it's the 'most common' interpretation?  Any relevant
anecdotes?

Do you propose a similar relationship between the ;binary option and other
syntaxes that have no UTF-8 representation?  Some examples are Audio, Fax, JPEG
and (arguably) Octet String.  Why should these syntaxes be treated differently
from Binary?  They should not; the Binary syntax should not be special.

The ;binary option was the least evil way to rectify a deficiency in LDAP v2;
that is, the LDAP v2 printable syntax for userCertificate and related
attributes was inadequate to support public key infrastructure.  Although the
;binary option was less evil than alternative solutions to that problem, it is
nonetheless evil and should be deprecated.  Its use with other attribute types
is generally a bad thing.  Certainly it should not be required.

> that the ;binary option tag MUST be present.

That would contradict some precedents, including RFC 2251 (section 4.1.5) and
<draft-ietf-ldapext-lang-01>.  An AttributeDescription with one or more options
is treated as a subtype of the attribute type without any options [RFC 2251],
or fewer options, in general.  So, when a client sends an attribute description
without options, the server implicitly considers it a reference to the named
attribute with or without options.  For example, a client reference to "foo" is
implicitly refers to both "foo" and "foo;binary".  This intepretation is
implemented in Netscape Directory Server, at least.

> Also, when the server responds to a query where the attribute type was
> explicitly requested, the ;binary option MUST also be present.

I agree, unless the query also requested the attribute without options, in
which case the server may send attribute descriptions both with and without
options.

> However when the client performed a request and did not explicitly request
> the attribute type, the server SHOULD include the ;binary option tag.

No; the server should include the ;binary option IF it was included by the
client that stored the value, originally.  That is, the server should be a
neutral repository for options.

- John Kristian <[email-masked]>

P.S. These are my opinions, and don't necessarily reflect my employer's
policies.

---

From: "Alexis Bor" <[email-masked]>
Date: Mon, 30 Aug 1999 14:28:10 -0400

We need to be careful here.  If we have to take surveys to figure out how to
interpret an RFC, then we need to update the RFC to be more clear and
specific.  Perhaps an 'implementor agreement' type of RFC - but that too can
cause trouble...

I read it the same way as John did below in his response.  Are there a lot
of different interpretations?

-- Alexis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 30, 1999 1:38 PM
To: Christopher Oliva
Cc: [email-masked]
Subject: Re: clarifying RFC2251: ;binary option

Do you propose a similar relationship between the ;binary option and other
syntaxes that have no UTF-8 representation?  Some examples are Audio, Fax,
JPEG
and (arguably) Octet String.  Why should these syntaxes be treated
differently
from Binary?  They should not; the Binary syntax should not be special.

The ;binary option was the least evil way to rectify a deficiency in LDAP
v2;
that is, the LDAP v2 printable syntax for userCertificate and related
attributes was inadequate to support public key infrastructure.  Although
the
;binary option was less evil than alternative solutions to that problem, it
is
nonetheless evil and should be deprecated.  Its use with other attribute
types
is generally a bad thing.  Certainly it should not be required.

> that the ;binary option tag MUST be present.

That would contradict some precedents, including RFC 2251 (section 4.1.5)
and
<draft-ietf-ldapext-lang-01>.  An AttributeDescription with one or more
options
is treated as a subtype of the attribute type without any options [RFC
2251],
or fewer options, in general.  So, when a client sends an attribute
description
without options, the server implicitly considers it a reference to the named
attribute with or without options.  For example, a client reference to "foo"
is
implicitly refers to both "foo" and "foo;binary".  This intepretation is
implemented in Netscape Directory Server, at least.