Re: Questions about certificate(Exact)Match in HEAD code.(ITS#2719)

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

[redirected from -software to -devel]

While RFC 2256 defined userCertificate as:
  ( 2.5.4.36 NAME 'userCertificate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

the IETF community appears to have consensus to add in the missing
equality rule.  Hence, the schema description should become.
  ( 2.5.4.36 NAME 'userCertificate' EQUALITY certificateExactMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

Until this change is made, equality assertions upon userCertificate
are Undefined.  (So, your first search below should return no entries).
The current code, I assume, is intended to be used with extensible
matching.   For example:
  (userCertificate:certificateExactMatch:=12345$cn=Joe,dc=example,dc=net)

As I used a string form of the assertion syntax (serial number
and DN), hence no ;binary.  (Note that there is some debate over the
string form of this syntax.)

Now, if I wanted to assert a whole certificate, I'd use:
  (userCertificate;binary:certificateMatch:=\30...)

As I used the BER (DER) encoding form of the assertion syntax, I
specified ;binary.  (certificates don't have string forms, so ;binary
is mandatory.)

Now, when description of userCertificate is modified to have the
certificateExactMatch equality matching rule, one can do:
  (userCertificate=12345$cn=Joe,dc=example,dc=net)
and
  (userCertificate;binary=\30...)

The second case is interesting as the sequence could be a BER
encoded serial number/DN or a whole certificate.

So, now, let me respond to your post.


At 08:43 AM 9/18/2003, Mark Ruijter wrote:
>I've read the current certificate match code in the HEAD branch and
>found it to be confusing.

Yes.  And it likely needs to be reworked significantly (which is
why I asked you to look at HEAD :-).

>Part of the code seems to implement binary Matching (certBinMatch?) by calling octetStringMatch. 
>This would allow queries like: 
>ldapsearch -h localhost -b dc=com -D cn=manager,dc=com \ 
>    -w secret -x "userCertificate=\30\82\03\ae\30\82\03\17.............

Bogus: ;binary is missing.

>Another part of the code still does something with serial $ issuerdn?

Yes: the assertion value can either be a serial number/DN or a
certificate.  If the latter, the server must extract the serial
number/DN from the asserted certificate and use this to find
certificates with the same serial number and DN.

That is, (userCertificate;binary=\30...) matches all certificates
which have the same serial number and the issuer DN of the asserted
certificate.  It does NOT match whole asserted certificate with
the whole stored certificate.

>Question: What do we need? certBinMatch, certExactMatch or both? 

Let me explain how this should work with extensible matching.  Then
we can talk about how to make it work with a modified schema description.

The normalized form of a certificate should be its serial number
and issuer DN in "pretty" form.  The normalized form of a serial
number and issuer DN should be the serial number and issuer DN in
"pretty" form.  Then octet string matching (and indexing) can be
used.

The serial number and issuer DN syntax implementation should be modelled
after the name and optional UID syntax implementation.  The certificate
syntax code is similar. needs to construct a serial number and issuer
DN string from the certificate and then call the serial number and
issuer DN pretty routine.

So (userCertificate:certificateExactMatch:=12345$cn=foo) is made,
the value is normalized (and prettied) per the serial number and
issuer DN assertion syntax.  Then the server looks for values matching
it in userCertificate and its subtypes.  It should find matching
values stored in userCertificate;binary.

Likewise for (userCertificate;binary:certificateMatch:=\30....).

Now, to get (userCertificate=12356$cn=foo) and/or
(userCerticate;binary=\30...) gets a bit more involved.  I wouldn't
attempt to implement that until extensible matching worked.

Kurt