[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
clarifying RFC2251
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
Chris.Oliva@entrust.com
http://www.entrust.com
-----------------------------------------