Re: certificateExactMatch, why it doesn't work and how to fix it.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:16 AM 12/11/2002, Mark Ruijter wrote:
>Thanks for your fast response. We have tested your recommendations and here is the outcome against an 'out of the box'
>version of openldap-2.1.9 with an unmodified core.schema

Okay, I dug a bit and found:
  http://www.openldap.org/lists/openldap-devel/200110/msg00077.html


which shows that the code, in fact, was intended to be used with
as an equality rule, not an extensible rule.  That is, simply
by adding "EQUALITY certificateExactMatch" to the description
of "userCertificate".

No changes to "certificateExactMatch" should be needed.

I note that this is based on an Internet Draft, so its quite
subject to change.  The only way to use certificateExactMatch
with userCertificate (as defined in RFC 2256) is via an
extensible matching rule.  I note as well that this Internet
Draft is not necessarily consistent with our implementation
nor other implementations.  It is, after all, "a work in
progress."

>#
># filter: (userCertificate:certificateExactMatch:= 56 $ <mailto:email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl>email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl )
># requesting: ALL
>#
> 
>ldapsearch: ldap_search_ext: Bad search filter (87)

That's a client side error and may indicate a bug in the parser
(as the filter string looks valid per RFC 2254).


># filter: (userCertificate:certificateExactMatch=56 $ <mailto:email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl>email=devnull@blackhole.org,cn=snx,ou=myou,o=snx,l=amsterdam,st=noordh,c=nl )

This filter is actually invalid.  Likely the client should
catch this... but the server does treat this approrpaitely.

>filter: (?=undefined)

> [stuff about indexing]

I generally worry first about getting it right before I worry
about getting it fast.   But, yes, there are extensible
indexing issues which likely need to be addressed.

>>I note that one generally shouldn't muck with standard track
>>schema elements.
>Point taken..

I note that this is one case where the standard track schema
is known to be inconsistent with X.500 specifications.  So,
one can view the additional as an "unmucking" of the RFC muck.

>(I note that if this doesn't work, there may very well be a bug somewhere
>in the code...  I don't use this feature regularly, but I think I understand
>how its intended to be used.)
>This seems to be the case then... 

I should have said, I understood how the rules are intended
to be used in LDAP (as presently defined).  The code, from
a message I referenced above, appears to be intended to be
used as an equality rule.

>>>To get certificateExactMatch to work i therefore changed schema_init.c as shown in the patch below: 
>>>
>>>diff -urN openldap-2.1.9/servers/slapd/schema_init.c openldap-2.1.9a/servers/slapd/schema_init.c 
>>>--- openldap-2.1.9/servers/slapd/schema_init.c Tue Nov 26 19:26:19 2002 
>>>+++ openldap-2.1.9a/servers/slapd/schema_init.c Tue Dec 10 13:13:12 2002 
>>>@@ -4711,7 +4711,7 @@ 
>>> 
>>>#ifdef HAVE_TLS 
>>> {"( 2.5.13.34 NAME 'certificateExactMatch' " 
>>>-  "SYNTAX 1.2.826.0.1.3344810.7.1 )", 
>>>+  "SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )", 
>>>  SLAP_MR_EQUALITY | SLAP_MR_EXT, certificateExactMatchSyntaxes, 
>>>  certificateExactConvert, NULL, 
>>>  certificateExactMatch, 
>So I do agree however that the syntax is correct and that I shouldn't change it.

Good.  (sorry about getting the reference wrong)

>But there seems to be a bug that prevents the assertion syntax from being 'mapped' with the value syntax.

Okay.  Let's fix that.  Let's also fix the extensible matching
problem (which is the only way the rule can be used with the
schema as defined on the Standard Track).

>If certificateExactMatch is implemented in openldap then this would suggest that core.schema is incorrect

core.schema reflects RFC 2256, an in-force Standard Track
specification.

>and that EQUALITY certificateExactMatch should be added.

We won't change userCertificate in core.schema until a
RFC 2256 is superseded because, until then, we won't know
exactly what to replace it with.  While it is quite likely
that the replacement will align the LDAP schema with the
X.500 schema (e.g. add the rule), it is not clear exactly
what the LDAP string encoding of the assertion value will
be.

Kurt