[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] objectIdentifierMatch


Howard,

Howard Chu wrote:
It seems this matching rule is rather difficult to use in practice, given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.)

I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions? 

The problem is wider than just attributes with the OID syntax. OIDs can
be embedded in more complex syntaxes. When GSER encoding or decoding
values of these syntaxes the context of an OID descriptor becomes an
issue.

In our implementation we exploit a feature of ASN.1 to determine
the appropriate context. The X.500 ASN.1 definitions typically refer
to an OBJECT IDENTIFIER for an attribute type with the notation
ATTRIBUTE.&id, which means the id field of the ATTRIBUTE information
object class (not to be confused with entry object classes).
The type of that id field is OBJECT IDENTIFIER, so as far as most
encoding rules are concerned, OBJECT IDENTIFIER and ATTRIBUTE.&id
are equivalent. However for GSER we use ATTRIBUTE.&id as an indication
that the context for any OID descriptors is attribute types.

Similarly, X.500 typically uses OBJECT-CLASS.&id to refer to the
OID for an entry object class, MATCHING-RULE.&id to refer to the
OID for a matching rule and NAME-FORM.&id to refer to the OID for
a name form. X.500 isn't entirely consistent in using the appropriate
referencing notation, so we replace some of the OBJECT IDENTIFIER
references in our ASN.1 sources with the more specific reference.
In particular, we change the X.500 syntax of the objectClass attribute
from OBJECT IDENTIFIER to OBJECT-CLASS.&id.

We haven't changed the LDAP syntax OID of the objectClass attribute,
instead treating this as just another one of those annoying cases where
a single LDAP syntax OID corresponds to a number of slightly different
ASN.1 type definitions.

From my perspective the "correct" solution is to define additional syntax 
OIDs to represent the different contexts of OIDs in LDAP. That is, a
separate LDAP syntax for attribute type OIDs which has the underlying notional
ASN.1 type of ATTRIBUTE.&id, a separate LDAP syntax for object class OIDs
which has the underlying notional ASN.1 type of OBJECT-CLASS.&id, and so on.
The LDAP-specific encoding for each of these new syntaxes would be exactly
the same as the LDAP-specific encoding of the current LDAP OID Syntax.

Regards,
Steven

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext