Ersin Er wrote:
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.
Oye vey more X.500 LDAP theory stuff. My immediate question is "Why use
directoryStringFirstComponentMatch for ACIs.
Define a new matching rule that will cater to the needs of comparing
ACIs properly rather than using this really general matchingRule which
in my opinion is useless for complex structures with their own syntax
like ACIs.
Now regardless this has to be solved for
directoryStringFirstCompoenentMatch properly. IMO I would follow the
spec as literally as possible after laying the X.500 concepts dealing
with ASN.1 onto the LDAP concepts dealing with equivalent string
representations. Meaning you would be matching for the '{' in this case
if you were *incorrect* and used directoryStringFirstComponentMatch for
doing ACI substr or equality matching.
SUMMARY
=======
Implement directoryStringFirstCompoenentMatch literally according to
spec which would mean you would match for the '{' in the ACI.
Don't use directoryStringFirstComponentMatch for ACI matching. Define a
more specific matchingRule.
Regards,
Alex
begin:vcard
fn:Alex Karasulu
n:Karasulu;Alex
org:Apache Software Foundation;Apache Directory
adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA
email;internet:[EMAIL PROTECTED]
title:Member, V.P.
tel;work:(904) 791-2766
tel;fax:(904) 808-4789
tel;home:(904) 808-4789
tel;cell:(904) 315-4901
note;quoted-printable:AIM: alexokarasulu=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo!: alexkarasulu=0D=0A=
IRC: aok=0D=0A=
PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A=
x-mozilla-html:FALSE
url:http://people.apache.org/~akarasulu
version:2.1
end:vcard
