Re: strange uniqueMemberMatch

[Steven Legg <steven.legg@eb2bcom.com>]

Folks,

Hallvard B Furuseth wrote:
> Any progress with this?

I haven't got a response from the X.500 group on the problem of the non-commutative
uniqueMemberMatch matching rule. A resolution is needed so that the syntaxes draft
can be progressed.

This is the current description, which is consistent with the X.520
description:

   The rule evaluates to TRUE if and only if the <distinguishedName> components
   of the assertion value and attribute value match according to the
   distinguishedNameMatch rule and the <BitString> component is absent from the
   attribute value or matches the <BitString> component of the assertion value
   according to the bitStringMatch rule.

To make uniqueMemberMatch commutative I propose changing the description to
this:

   The rule evaluates to TRUE if and only if the <distinguishedName> components
   of the assertion value and attribute value match according to the
   distinguishedNameMatch rule and either, the <BitString> component is absent
   from both the attribute value and the assertion value, or the <BitString>
   component is present in both the attribute value and assertion value and
   the <BitString> component of the assertion value matches the <BitString>
   component of the attribute value according to the bitStringMatch rule.

   Note that this matching rule has been altered from its description in X.520
   [X.520] in order to make the matching rule commutative.

In thinking through the possible solutions I found it convenient to
represent the behaviour in a table like the following, which presumes
that the <distinguishedName> components have already matched.
This table represents the X.520 definition.

                    +------------------------------------------+
                    | attribute value    | attribute value     |
                    | <BitString> absent | <BitString> present |
--------------------+--------------------+---------------------+
assertion value     |        TRUE        |        FALSE        |
<BitString> absent  |                    |                     |
--------------------+--------------------+---------------------+
assertion value     |        TRUE        |        TRUE         |
<BitString> present |                    |     iff the same    |
--------------------+--------------------+---------------------+

The matching rule is commutative if the table is symmetrical about the
diagonal from top left to bottom right (the X.520 definition obviously isn't).

My recommendation changes the bottom left cell from TRUE to FALSE,
but the matching rule could also be made commutative by changing
the top right cell from FALSE to TRUE.

My rationale for recommending the former is this: When a DN is first used to
identify some entity it is not likely to have an associated unique identifier.
If the DN is subsequently reused for a different entity then a unique
identifier will be assigned at that time. I may wish to refer to both entities
in the same uniqueMember attribute. The recommended solution allows this, the
alternative doesn't.

We could also resolve the problem with uniqueMemberMatch by having it
behave differently when used to compare attribute values versus comparing
an assertion value and an attribute value. I recommend against doing this
because in some implementations, or in some application domains, the
information to distinguish between the two cases may not be available.

The original X.520 definition provided a degree of leniency in matching
NameAndOptionalUID values. So that the utility of the original X.520 definition
is not lost I propose adding the following text to the description of
uniqueMemberMatch:

   When performing an approximate match on an attribute where the equality
   matching rule is uniqueMemberMatch, an attribute value without a <BitString>
   component SHOULD match an assertion value with the same <distinguishedName>
   component regardless of the <BitString> component of the assertion value.
   Likewise, an assertion value without a <BitString> component SHOULD match
   an attribute value with the same <distinguishedName> component regardless
   of the <BitString> component of the attribute value.

Regards,
Steven

> http://www.OpenLDAP.org/lists/ietf-ldapbis/200301/msg00027.html
> http://www.OpenLDAP.org/lists/ietf-ldapbis/200301/msg00029.html
>
> At 08 Jan 2003, Kurt D. Zeilenga wrote:
>
> > At 08:36 PM 1/5/2003, Steven Legg wrote:
> >
> > > The uniqueMemberMatch rule is an equality matching rule that is not
> > > commutative, which causes problems in deciding whether attribute values
> > > are equal or not when adding or deleting values. I've raised this with
> > > the X.500 working group and I'm waiting to see how they resolve it.
> >
> >
> > We likely should nudge them on this.  The current
> > definition is, I think, problematic because uniqueMember
> > is not single-valued.