Subject: [ldapext] objectIdentifierMatch

From: Howard Chu <[email-masked]>
Date: Fri, 06 Oct 2006 11:39:25 -0700

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.

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?

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 08 Oct 2006 15:47:36 +0200

At 04:39 AM 10/7/2006, 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.

For operational attributes, the context is implicit.

>That makes it pretty much impossible to validate these descriptors in arbitrary attributes.

For user application attributes, it is not possible for the server
to know what the context is without some additional information
I think it reasonable to provide this information in an attribute
type description extension as you propose.

Kurt

---

From: Steven Legg <[email-masked]>
Date: Tue, 10 Oct 2006 16:48:24 +1000

Howard,

> 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.

> attributetype ( 1.1.1.1.1.1.1.1.1                NAME 'myAttr' 
>                EQUALITY objectIdentifierMatch                SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.38
>                SINGLE-VALUE
>         X-OID-NAME 'attribute' )
> 

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