directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: directoryStringFirstComponentMatch & LDAP & ACIs
Date Wed, 10 Jan 2007 17:58:48 GMT
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



Mime
View raw message