directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject directoryStringFirstComponentMatch & LDAP & ACIs
Date Tue, 09 Jan 2007 19:19:29 GMT
Hi all,

I think directoryStringFirstComponentMatch matching rule was designed
with respect to X.500 semantics in the old days (which were really
cool). Here is the definition for it from RFC 4517:
-------
The directoryStringFirstComponentMatch rule compares an assertion
   value of the Directory String syntax to an attribute value of a
   syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
   first component of the DirectoryString ASN.1 type.

   Note that the assertion syntax of this matching rule differs from the
   attribute syntax of attributes for which this is the equality
   matching rule.

   The rule evaluates to TRUE if and only if the assertion value matches
   the first component of the attribute value using the rules of
   caseIgnoreMatch.

   The LDAP definition for the directoryStringFirstComponentMatch
   matching rule is:

      ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   The directoryStringFirstComponentMatch rule is an equality matching
   rule.  When using directoryStringFirstComponentMatch to compare two
   attribute values (of an applicable syntax), an assertion value must
   first be derived from one of the attribute values.  An assertion
   value can be derived from an attribute value by taking the first
   component of that attribute value.
-------

As X.500 was not as verbose as LDAP for string representations, the
first component of an SEQUENCE was really the value of the first
component. However when translating ASN.1 definitions to LDAP string
representations as suggested by RFC 3641, the "first component" in
SEQUENCES are no longer kept. For example prescriptiveACI attribute
type is defined as follows:
-------
attributetype ( 1.3.6.1.4.1.18060.0.4.1.2.12 NAME 'prescriptiveACI'
  DESC 'Access control information that applies to a set of entries'
  EQUALITY directoryStringFirstComponentMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
  USAGE directoryOperation )
-------
So it uses the directoryStringFirstComponentMatch for equality checks.
The first component of an ACI is the identificationTag, a simple
identifier string. However in LDAP string representation an ACI starts
as follows:

{ identificationTag "SomeID", ...

The intended first component here is "SomeID", but as you see we have
'{' and "identificationTag" before it. So one question arises here:
"How should we implement directoryStringFirstComponentMatch for LDAP?"
Should it skip a '{' and an identifier ("identificationTag" here) and
then handle the third component?

If we do not do this properly, we'll not be able to compare ACIs correctly.

WDYT?

-- 
Ersin

Mime
View raw message