Subject: [ldapext] objectIdentifierMatch

From: Howard Chu <[email-masked]>
Date: Wed, 15 Feb 2006 03:23:07 -0800

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?
-- 
   -- 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: Wed, 15 Feb 2006 11:08:53 -0800

>It seems this matching rule is rather difficult to use in practice,

with descriptor support, yes.

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

It's difficult to know whether a particular descriptor
unambiguously refers to a particular OID.  LDAP has always
allowed an OID to refer to different OIDs in different contexts.

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

I'd prefer something like X-OID-CONTEXT than
X-NAMESPACE as the latter is not OID-specific.  And as values,
I would spell them out for clarity.  That is,
        X-OID-CONTEXT 'attributeTypes'

Of course, even descriptors naming a particular kind of object
may be ambiguous, like 'x-foo'.  This is why I suggested
'X-OID-CONTEXT' instead of 'X-OID-KIND'.  The term context
implies which kind of object is being named, but the source
of the names (for 'attributeTypes', the controlling schema).

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 15 Feb 2006 11:48:12 -0800

I note that in some cases OID and objectIdentifierMatch are
used where it would be more appropriate for the syntax/matching
rules for attribute descriptions to be used.  Attribute
descriptions allow language and other tags to be specified.

Unforunately, matching rules commonly used for attribute
descriptions do not deal with ambiguity in naming of attribute
types (cn v commonName v 2.5.4.3) as well as ambiguity
caused by ordering of attribute options.

So, we might consider designing robust 'attribute description'
syntax and matching rules (instead of or in addition to
an attribute type schema description extension).

Kurt

---

From: Howard Chu <[email-masked]>
Date: Wed, 15 Feb 2006 12:04:41 -0800

> an attribute type schema description extension).

That makes a lot more sense. We probably still need the schema extension 
to address the other uses.

---

From: Steven Legg <[email-masked]>
Date: Thu, 16 Feb 2006 11:07:09 +1100

Howard,

> 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

---

From: Steven Legg <[email-masked]>
Date: Thu, 16 Feb 2006 11:30:07 +1100

Kurt,

Kurt D. Zeilenga wrote:
> syntax and matching rules

I support this. I can't stuff an LDAP attribute description into
an OBJECT IDENTIFIER in X.500, so "attribute description" needs to
be a distinct syntax for LDAP/X.500 alignment. My preference would
be for the underlying ASN.1 type of such a syntax to be the same
as the AttributeDescription type I have defined for XLDAP, i.e.

   AttributeDescription ::= SEQUENCE {
        type        ATTRIBUTE.&id({SupportedAttributes}),
        options     SEQUENCE SIZE (1..MAX) OF
                         option UTF8String OPTIONAL }

even if the LDAP-specific encoding is defined to be the ABNF
for AttributeDescription from RFC 2251.

Regards,
Steven

> (instead of or in addition to