Re: [ldapext] objectIdentifierMatch

[Steven Legg <steven.legg@eb2bcom.com>]

Howard,

Howard Chu wrote:
> RFC4512 and RFC4517  allow OIDs to be either numeric or short-name 
> descriptors, but the objectIdentifierMatch and 
> objectIdentifierFirstComponentMatch matching rules have no way to 
> determine in what context a descriptor resides. That makes it pretty 
> much impossible to validate these descriptors in arbitrary attributes.

There's only a problem if the name is ambiguous, i.e., used in more
than one context. Most descriptors I've encountered have been defined
in only one context. We reject a descriptor if the context cannot be
established and the name is ambiguous, accept a descriptor if it is
unique regardless of context, and output a numeric OID if the context
cannot be established and we can't find a unique descriptor.

> One possible solution would be to specify the namespace in a schema 
> extension:
>
> attributetype ( 1.1.1.1.1.1.1.1.1                NAME 'myAttr' 
>                DESC 'The attribute to use'
>                EQUALITY objectIdentifierMatch                SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.38
>                SINGLE-VALUE
>         X-OID-NAME 'attribute' )
>
> How are others handling this issue?

We use the X.500 definition of AttributeTypeDescription rather than the
LDAP representation to represent schema internally. The X.500 definition
differs from the LDAP representation in that it specifies the syntax
using a DirectoryString containing an ASN.1 type definition, rather than
as an OID. We indicate that an attribute syntax is an OID for an
attribute type by defining the syntax to be "ATTRIBUTE.&id" instead of
"OBJECT IDENTIFIER". The ATTRIBUTE.&id notation happens to be a reference
to the OBJECT IDENTIFIER type, but carries the connotation that it is
restricted to OIDs for a directory attribute type. Similarly, we use
OBJECT-CLASS.&id, NAME-FORM.&id and MATCHING-RULE.&id for the other
contexts. We retain "OBJECT IDENTIFIER" as the syntax when no particular
context applies.

We map all these alternatives into the same LDAP syntax OID, but that's
not a new problem. There are other cases where a single LDAP syntax OID
has been used for attributes or matching rules that have slightly different
ASN.1 type definitions for their syntaxes. Where necessary, we indicate
the specific X.500 syntax with an X-SYNTAX-STRING extension to the
LDAP Attribute Type Description. The X-SYNTAX-STRING value is a direct
copy of the DirectoryString from the X.500 AttributeTypeDescription.

Adding arbitrary new fields to LDAP schema descriptions is problematic
for X.500 vendors since there is no direct way to represent the new
field in a BER encoding of the description. The X-SYNTAX-STRING extension
is an exception because it is exposing an X.500 field that LDAP left out.

Rather than defining an X-OID-NAME, I think a better solution would be
to define some new LDAP syntax OIDs that have the meaning of
"OBJECT IDENTIFIER for an attribute type", "OBJECT IDENTIFIER for an
object class", etc. That way no schema extension is required. The definition
for the objectClass attribute will be an issue though. Either the
definition has to be migrated to the new LDAP syntax OID for object class
OIDs, or 1.3.6.1.4.1.1466.115.121.1.38 can be reinterpreted to be the
syntax for object class OIDs and a new LDAP syntax created to represent
OIDs of no particular context.

Regards,
Steven

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