Subject: strange uniqueMemberMatch

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 4 Jan 2003 16:41:01 +0100

[Syntaxes] 5.2.21 (uniqueMemberMatch) says:

   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.

Thus, assertion value cn=foo#'0101'B matches attribute value cn=foo.
Is that intentional?  X.520 paragraph 6.2.11 says the same thing.

-- 
Hallvard

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 6 Jan 2003 15:36:05 +1100

Hallvard,

Hallvard B Furuseth wrote:
> Is that intentional?

Yes, because ...
> X.520 paragraph 6.2.11 says the same thing.

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.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Jan 2003 11:41:02 -0800

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

To resolve this, I think the ITU should change the
uniqueMemberMatch semantics to:
   The rule returns TRUE if and only if the dn components
   of the attribute value and the presented value match
   according to the distinguishedNameMatch rule and, if the
   uid component is present in both values, the uid of the
   attribute value matches the uid from the presented value
   according to the bitStringMatch rule.

That is, 
  Assertion Value       Attribute Value Result
  cn=foo#'0'B           cn=foo#'0'B     True
  cn=foo#'1'B           cn=foo#'0'B     False (uid mismatch)
  cn=bar#'0'B           cn=foo#'0'B     False (dn mismatch)
  cn=foo                cn=foo#'0'B     True
  cn=bar                cn=foo#'0'B     False (dn mismatch)
  cn=foo#'0'B           cn=foo          True
  cn=foo                cn=foo          True
  cn=bar                cn=foo          False (dn mismatch)

Also, I think X.501 should be state that only single-valued
attribute types can have non-commutative equality rules.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 9 Jan 2003 11:12:12 +1100

Kurt,

>   cn=bar                cn=foo          False (dn mismatch)

That's a reasonable way to make the matching rule commutative
however it does have the consequence that the uniqueMember
attribute cannot simultaneously hold the values cn=foo and
cn=foo#'0'B.

If the rule is changed to return TRUE if the uid component is
absent in both the attribute value and assertion value, or present
and the same in both the attribute value and assertion value then
both cn=foo and cn=foo#'0'B can simultaneously appear in the
uniqueMember attribute.

The old semantics of uniqueMemberMatch (or else your suggestion) are
suitable to be recommended for approximate matching of the uniqueMember
attribute, so as to retain the flexibility of the current matching
rule in some form. 

> attribute types can have non-commutative equality rules.

That, or require all equality matching rules to be commutative.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Jan 2003 16:47:39 -0800

Your alternatives seem reasonable as well.

Of course, what we need is for the ITU to come out
with fixes (to both the general problem and the
specific instances) that we can align to.   Can
you nudge them for response to your previous
enquiry?

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 9 Jan 2003 11:59:23 +1100

> you nudge them for response to your previous

Yes.

Cheers,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 9 Jan 2003 16:39:57 +0100

Steven Legg writes:
>> (...)

That's better than what we have today:

- If cn=foo already exists in an entry, cn=foo#'0'B cannot be
  added because it tests out to be equal.  However, if cn=foo#'0'B
  already exists, cn=foo _can_ be added.  Or maybe the server does
  it the other way around, the standard allows that too.

- Similarly, an add request which adds both values at once will
  succeed or fail depending on which value is added first.

> That, or require all equality matching rules to be commutative.

Commutative or take different types (the -firstComponentMatch rules).

-- 
Hallvard