Subject: Re: WG Last Call: Certificate Schema

From: Steven Legg <[email-masked]>
Date: Wed, 01 Dec 2004 15:48:45 +1100

David,

David Chadwick wrote:
> Since that time (Spring 2003) suppliers have not moved that far (if at 
> all) towards supporting component matching. Only Steven Legg's 
> Australian company, which had supported component matching prior to 
> publication of the RFCs, and OpenLDAP which I believe can now support 
> it, have done anything in this direction. Attribute extraction on the 
> other hand has double that amount of supporting implementations, plus 
> all clients can naturally support it without any code change.

So is that four client implementations that have support for adding and
modifying entries with certificates according to the attribute extraction
schema using any LDAP directory, or is that four client implementations
that depend on the XPS server to do the attribute extraction for them ?
Isn't there only one XPS(-like) server implementation ? I'm not sure you are
comparing like with like.

Incidentally, yesterday a colleague of mine configured a third-party
LDAP client with no built-in knowledge of component matching to use
component matches in its filters. No re-coding was necessary. Any client
that is configured with LDAP filters in string format or LDAP URLs is
already able to use component matching or the X.509 matching rules.

Regards,
Steven

---

From: Peter Gietz <[email-masked]>
Date: Wed, 01 Dec 2004 14:20:32 +0100

Kurt,

some more remarks from my side.

Kurt D. Zeilenga wrote:

>David,
>
>While there may have been some in this WG that viewed the
>value extraction approach as a pragmatic solution to various
>specific issues, I believe there are also many, like myself,
>who have never considered the value extraction approach, in
>general, to be practical.  And, as I noted in my previous
>response, I do not consider the value extraction approach
>as applied here to certificates and such to be pragmatic
>as it simply does not address requirements I am faced with.
>  
>
One requirement addressed by value extraction is to return to the client 
only the certificate the client needs.
This requirement is not addressed by Component Matching. Only in 
combination with the return value filter (RFC 3876), which defines an 
LDAP control that again has to be supported by Clients and Servers, such 
a behaviour could be implemented. I guess that vendor's support for this 
is even less than for component matching.

>In particular, how does this approach providing for matching
>upon components of the subject (or other) DNs in the certificate?
>
>  
>
Well in our implementation we created another objectclass for such data 
(cn,o,ou,c,dc,emailadress, etc.) and our certificate2LDIF converter 
stores all rdn values of the dn in these attributes. Such an objectclass 
- let me call it "additional metadata objectclass" for now - could be 
specified in a separate document, as well as other extensions 
objectclasses for things like qualified certs etc.

>As we understood long ago, it will take time for this to get on
>the radar of LDAP server developers.  That seems to be happening
>now.
>
>  
>
I hope this discussion about value extraction, will help to get it on 
their radar.

>>Attribute extraction on the other hand has double that amount of supporting implementations, plus all clients can naturally support it without any code change.
>>    
>>
>
>How does an existing client designed to work with person objects
>become aware of, and make use of, subordinate certificate objects
>without being changed?
>
>  
>
Well by sending a search filter and getting back a userCertificate 
attribute. With the above mentioned additional metadata objectclass all 
items of the search filter can be found in the certificate entry. The 
client (provided it does not have things like 
"objectclass=inetorgperson" in its filter) doesn't even  note that the 
answer is from a server supporting our schema. Clients that can have 
their search filters configured could additionally make use of the 
x509schema attributes like x509keyUsage etc.

>>So whilst we might all like the ideal today, pragmatically we need to recognise that this is not the situation on the ground today.
>>    
>>
>
>Pragmatically, we have to realize that the so-called pragmatic
>solution will introduce numerous problems which we could have
>avoided if we would have stuck with the so-called elegant solution
>we knew avoided these problems.
>  
>
The only "problem" I see with our solution is that, as Steve noted, the 
number of entries increases. With the scalability of LDAP servers  I 
don't see this as a real problem.

>  
>
>>If it were I would happily forget the attribute extraction IDs. My main desire is that we need to provide LDAP support to X.509 users today. We should recognise that it will be many years before the big LDAP suppliers might eventually decide to support component matching. After all, there are several very basic features of LDAP that some large LDAP suppliers dont yet support, even though they have been standardised for over 10 years.
>>As several well known people have already said, LDAP has not done a good job at supporting PKI.
>>    
>>
>
>To the LDAP community, PKI is just another application of the
>directory.  The LDAP community tends to focused on mechanisms
>which support a wide range of applications (including PKI).
>Component matching does this.
>
>I am not sure the LDAP community as a whole sees the danger
>in moving to a value extraction approach generally.  I shutter
>at the thought of having components of every complex value
>extracted into new values, and them in term extracted into more
>values.  I would hope it would be obvious that value extraction
>is not a wise approach, and will lead to numerous other problems.
>
>  
>
such as?

I agree with you that component matching is generally a good solution. 
But I also see that a lot of LDAP deployments use similiar approaches 
than ours for solving the problem of establishing relations between 
values of different LDAP attributes (e.g. this telephone number belongs 
to this room number). I shutter if in future for any such case people 
each time start to define complex syntaxes. Putting such information 
into separate entries does not look too harmfull to me.  Of course the 
family of entries approach would make it look even less harmfull.

BTW: hasn't "Keep it simple" not always been a rule at IETF?

Cheers,

Peter

>>So why believe things will miraculously change overnight with component matching. Be realistic, it wont.
>>    
>>
>
>I don't believe I've ever said that we'd miraculously have wide
>adoption of component matching overnight.  I expect it will be
>years before we see that.
>
>However, I fear that if we are not careful in how we publish
>the value extraction approach, we will be living with the
>problems of value extraction long after we have broad server
>support for component matching.   By noting, using appropriately
>strong language, the standard track approach is to be favored,
>we might be able to minimize this.  Of course, we'd likely
>suffer regardless.
>
>  
>
>>Unless of course Stefan Santesson can now stand up for his supplier and tell us when they will support component matching. That would indeed be very encouraging to us all.
>>
>>thanks
>>
>>David
>>
>>
>>Steve Hanna wrote:
>>    
>>
>>>David Chadwick wrote:
>>>      
>>>
>>>>what ever happened to the concept of let a thousand flowers bloom?
>>>>        
>>>>
>>>Standards work is not about "let a thousand flowers bloom".
>>>It's about agreeing on standards that will help systems
>>>interoperate and work well together. From my analysis,
>>>your proposals do not provide substantial benefit and
>>>they do add substantial complexity. I don't think that
>>>the Internet community will be well served by publishing
>>>these documents. They will only increase confusion for
>>>implementors and add complexity for directory clients,
>>>which will now need to support several directory schemas.
>>>In a separate email, David wrote:
>>>
>>>      
>>>
>>>>At no time to my knowledge was it suggested that this work be removed
>>>>        
>>>>
>>>>from the PKIX set of IDs, otherwise why would they have continued to be
>>>      
>>>
>>>>published with PKIX IDs instead of individual IDs for more than a year
>>>>after the meeting. And why would I have continued to report on their
>>>>progress at PKIX meetings?
>>>>        
>>>>
>>>At IETF 56, there was a discussion about whether to move
>>>to your proposed schemas (at that time, an independent
>>>submission) or stick with the current schema and use
>>>component matching to solve the problem. I raised concerns
>>>about your proposal at that meeting. As noted in the meeting
>>>minutes, a straw poll favored component matching but it was
>>>agreed to take this discussion to the mailing list. I never
>>>saw any discussion on the mailing list.
>>>At IETF 57, it was explained that the question had been
>>>decided in favor of your schema (with no discussion
>>>on the email list). I sent an email to the PKIX list
>>>complaining about this and reiterating my concerns about
>>>your proposal. Sharon Boeyen sent email supporting my
>>>concerns. Nobody sent email favoring the proposals.
>>>Now these documents are in Working Group Last Call.
>>>I have seen several emails from experienced PKI and
>>>directory folks raising concerns about your proposal
>>>and little email supporting it. I think it's clear
>>>there's no WG consensus in favor of your proposals.
>>>I suspect there never was a consensus in favor of
>>>them becoming WG drafts. If anything, the consensus
>>>seems to be that these documents are not representative
>>>of the IETF's future direction and should only be
>>>published with an Experimental status and some sort
>>>of warning.
>>>I'm sorry for any confusion caused by the status of
>>>your documents as WG drafts. It seems clear to me that
>>>they should never have received such a status since
>>>there was never rough consensus in the PKIX WG about
>>>taking them on as work items. However, it is better to
>>>remove this confusion now by publishing them as
>>>Experimental with a warning than to expand the confusion
>>>by publishing them as Informational without a warning.
>>>Thanks,
>>>Steve
>>>
>>>      
>>>
>>-- 
>>
>>*****************************************************************
>>
>>David W. Chadwick, BSc PhD
>>Professor of Information Systems Security
>>IS Institute, University of Salford, Salford M5 4WT
>>Tel: +44 161 295 5351  Fax +44 1484 532930
>>Mobile: +44 77 96 44 7184
>>Email: [email-masked]
>>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>>Research Web site: http://sec.isi.salford.ac.uk
>>Entrust key validation string: MLJ9-DU5T-HV8J
>>PGP Key ID is 0xBC238DE5
>>
>>*****************************************************************
>>    
>>
>
>
>  
>

-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114  
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 01 Dec 2004 08:57:57 -0800

At 05:20 AM 12/1/2004, Peter Gietz wrote:
>One requirement addressed by value extraction is to return to the client only the certificate the client needs.

Which certificate is that?  Maybe what the client wants is all certificates of
the person which holds a certificate whose subject DN contains a CN of X.

This highlights one of the problems with this approach.  It seems to be designed
with a specific subset of PKI applications in mind.  The solution, IMO, is not as
broadly applicable as its being made out to be.

>This requirement is not addressed by Component Matching. Only in combination with the return value filter (RFC 3876), which defines an LDAP control that again has to be supported by Clients and Servers, such a behaviour could be implemented. I guess that vendor's support for this is even less than for component matching.

Well, given that it was published as an RFC in September 2004, I would
be surprised if it were widely implemented.  It is implemented in
OpenLDAP Software.

>Well in our implementation we created another objectclass for such data (cn,o,ou,c,dc,emailadress, etc.) and our certificate2LDIF converter stores all rdn values of the dn in these attributes.

Stores? or maintains?  Sounds to me that this is simply a certificate object
creation tool (to be used in conjunction with ldapadd(1) or the like).  Do you
have a tool which ensures these certificate objects are consistent with
information in the person objects?

Anyways, having an ou attribute in the certificate object doesn't meet all the
needs.  Some applications might want to match only on ou's of the person
(plus certificate information), others on ou's of in the subject DN of the
person, others on ou's in the issuers DN.  With only one ou in the certificate
object, all clients cannot be properly supported.  Applications require
flexibility.  And this is one of the key problems with this approach, it is
not flexible.

Clients can only match on the components which have been extracted, and then
only in a manner consistent with that extraction.  Clients cannot match on
arbitrary components of the certificate.  Clients cannot match on extracted
components of the certificates and arbitrary components of the person entry.

>Such an objectclass - let me call it "additional metadata objectclass" for now - could be specified in a separate document, as well as other extensions objectclasses for things like qualified certs etc.
>
>I hope this discussion about value extraction, will help to get it on their radar.
>
>Well by sending a search filter and getting back a userCertificate attribute.

But the client happens to have a hard-coded scope of oneLevel as it was looking
for persons under a specific ou object.  Just changing the filter won't help here.

Even if the scope was configurable, changing it to subtree would bring into
scope not only certificates of the desired persons, but certificates of objects
subordinate to the person objects.  These may not be desirable.

>With the above mentioned additional metadata objectclass all items of the search filter can be found in the certificate entry.

While they might be found, the matching precise semantics are not preserved.
That is, depending on the precise filter specification undesirable entries
may be returned.  This will be bad for any client expecting the filter to
match one and only one entry (such as clients doing identity mapping).

>The client (provided it does not have things like "objectclass=inetorgperson" in its filter)

But it might do that.  Maybe the client is only interested in certificates assigned
to persons, and hence has a (objectClass=person) in the filter.

>doesn't even  note that the answer is from a server supporting our schema. Clients that can have their search filters configured could additionally make use of the x509schema attributes like x509keyUsage etc.

But you also need to adjust the scope.  And then the actual attributes of the person
the client is after may not be in certificate object.  So the client would have to
then go find the person object after finding the certificate object.  And the
client will have to weed out non-desirable certificate objects that might get
returned due to the expansion of scope and/or the less precise matching behavior.

>The only "problem" I see with our solution is that, as Steve noted, the number of entries increases. With the scalability of LDAP servers  I don't see this as a real problem.

Scalability is the least of my worries here.  I am more worried about
interoperability, consistency issues, management issues, and security issues.

For instance, having duplicates makes it much harder to control access...
making it far more likely that information will be mistakenly disclosed.

There will be data inconsistencies, and I haven't thought through all the
problems that will cause.

And managing all these duplicates certainly will get messy.  It seems for this
approach to be deployed, one might have to change a number of existing clients
(clients which one might not have source to).

>>is not a wise approach, and will lead to numerous other problems.

See above.

>I agree with you that component matching is generally a good solution. But I also see that a lot of LDAP deployments use similiar approaches than ours for solving the problem of establishing relations between values of different LDAP attributes (e.g. this telephone number belongs to this room number). I shutter if in future for any such case people each time start to define complex syntaxes. Putting such information into separate entries does not look too harmfull to me.  Of course the family of entries approach would make it look even less harmfull.

The family of entries approach failed to gain any traction in
the LDAP community for good reason, but that's another debate.

>BTW: hasn't "Keep it simple" not always been a rule at IETF?

Component matching and value matched control are far more simple
than value extraction approach.   Value extraction does nothing but
push the complexity of compound structures onto clients.  Component
matching and values matched control keeps the complexity in the
directory service.

I argue that implementation of XPS-like systems, especially ones that
deal with non-certificate matching issues, consistency issues, etc.,
and their deployment, is actually quite complex.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Dec 2004 09:01:44 -0800

At 07:58 AM 11/30/2004, Kurt D. Zeilenga wrote:
>And, as I noted in my previous

Here's another kind of search which the value extraction
approach does not address well:

A client wants to obtain the user information for each
user which possess both a certificate issued by CA A
and a certificate issued by CA B.  With value extraction,
the client must issue two search, one for certificates
of CA A and one for CA B, and then correlate the results
itself, and then fetch the users individually.  For 1M
users with certificates, with 1K having certificates
from both CAs, the client will have to obtain 2M
certificate objects to find the 1K certificates,
then will have to issue 1K searches to obtain
the user information (or fetch 1M user entries
to get the 1K user entries).

With component matching, this is done in one search
request.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 16:28:55 +0000

Kurt D. Zeilenga wrote:
> general, to be practical.  

Others take a different view. Take a look at a paper from a recent IEEE 
conference in Portugal this summer "Multi-level trust in e-government 
certification practice" by Amel Meddeb et al, National Digital 
Certification Agency, Tunisia (I can send you a copy if you need it). 
This proposes using the attribute extraction approach to search for 
certificates of a particular trust level.

noted in my previous
> as it simply does not address requirements I am faced with.

It does solve all the ones that I and others have been faced with so 
far. Please give me a real use-case example that cant be solved with it 
(ie. not some esoteric dreamt up case that we know it cannot solve)

> upon components of the subject (or other) DNs in the certificate?

As you know, distinguished names only support exact matching. Thus if 
the client does not know the DN of the subject, he would have to do a 
standard search for this first, and then use it to find the certificates 
containing this DN. The same for the issuer DN. Perhaps you are arguing 
for a DN substring matching rule or component matching rule to be added 
to X.520?

regards

David

-

---

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 16:46:26 +0000

Steve Hanna wrote:
> 
> David,
> 
> Thanks for providing some information on server
> support for your schema and for component matching.
> I would like to mention that component matching
> is not the only server-side solution. X.509 and
> draft-zeilenga-ldap-x509-00.txt (the successor
> to RFC 2587) include a CertificateAssertion that
> should be easy to implement on the server side.

Steve

I believe that this matching rule and assertion was first provided by 
myself in "Additional LDAP Schema for PKIs and PMIs" 
<draft-pkix-ldap-schema-00.txt> in July 2000. And the exact match was 
implemented shortly afterwards in OpenLDAP. So exact certificate 
matching is not difficult. It is when you want to match on arbitrary 
certificate contents that it gets difficult.

All LDAP clients that allow configuration of the attributes to be 
searched for support attribute extraction

regards

David

> 
> You say that "all clients can naturally support
> [your schema] without any code change". This isn't
> true. 

Sorry, but it is. In your argument below you forget two things. Firstly 
when searching for an entry you do NOT know the DN of the entry 
(otherwise a full subtree search is not needed, and a pseudo-read 
[search base entry only] is used). Thus is makes no difference where the 
certificate is located with a full search. Secondly, by storing the 
certificate in both places, which is specifically allowed for, then both 
sets of clients can be supported ie. ones that know where to read, and 
ones that dont.

Any client that tries to retrieve certificates
> from an LDAP directory will need to look in a
> different location. If the client doesn't know
> which schema is in use (which will often happen
> since clients are rarely configured with schema
> information), it must look in both places.
> Maybe you mean that clients don't need to change
> if the certificates are stored in both locations,
> but this is only a transitional situation.
> 
> So I would say it's more accurate to say that
> clients must change for your solution but need
> not change for the CertificateAssertion or
> component matching solutions. Could you tell me
> about any clients that support your solution?
> I believe it's true that there are many more
> client applications than server applications
> so it will be much more difficult to change
> the clients than the servers.
> 
> Thanks,
> 
> Steve
> 
> David Chadwick wrote:
> 
>> Steve
>>
>> we have had the meeting at IETF 56 and the majority agreed that 
>> component matching was the best long term solution to aim for. That is 
>> on the record. But also on the record is the note that vendors appear 
>> to be reluctant to support this, and that support for attribute 
>> extraction is a short term pragmatic solution that is much easier for 
>> suppliers and users to support. It does not add complexity to clients, 
>> on the contrary it makes it easier for clients. Consequently the ADs 
>> agreed that component matching should be published as Information RFCs.
>>
>> So whilst we might all like the ideal today, pragmatically we need to 
>> recognise that this is not the situation on the ground today. If it 
>> were I would happily forget the attribute extraction IDs. My main 
>> desire is that we need to provide LDAP support to X.509 users today. 
>> We should recognise that it will be many years before the big LDAP 
>> suppliers might eventually decide to support component matching. After 
>> all, there are several very basic features of LDAP that some large 
>> LDAP suppliers dont yet support, even though they have been 
>> standardised for over 10 years. As several well known people have 
>> already said, LDAP has not done a good job at supporting PKI. So why 
>> believe things will miraculously change overnight with component 
>> matching. Be realistic, it wont. Unless of course Stefan Santesson can 
>> now stand up for his supplier and tell us when they will support 
>> component matching. That would indeed be very encouraging to us all.
>>
>> thanks
>>
>> David
>>
>>
>> Steve Hanna wrote:
>>
>>>
>>> David Chadwick wrote:

--

---

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 15:54:48 +0000

Steven

Peter listed the implementations in an earlier message (which I have now 
deleted) but I believe it was 3 of the former and 1 of the latter (which 
actually equates to a very large number of clients).

> already able to use component matching or the X.509 matching rules.

Could your colleague send us the string that he had to type in e.g. to 
find a certificate containing a particular email address or key usage

thanks

David

--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Dec 2004 03:01:33 -0800

At 08:28 AM 12/2/2004, David Chadwick wrote:
>As you know, distinguished names only support exact matching.

You seem to have missed my point(s).

The purpose of value extraction is to allow the client to match
on components of the certificate.  My point is that is that
the approach fails to allow the client to match on all components
of the certificate.  It only allows the client to match on
extracted components of each of the certificates, and then only
on an separate basis.

(The separate basis part I raised in separate email.)

>Thus if the client does not know the DN of the subject, he would have to do a standard search for this first,

In my example, the client wasn't asking for the return of the subject DN,
it was asking for the return of the entry containing a subject DN
with contained certain components.

>and then use it to find the certificates containing this DN.

In my example, the client was interested in non-certificate
information in the entry representing the entity possessing the
certificate.

>The same for the issuer DN. Perhaps you are arguing for a DN substring matching rule or component matching rule to be added to X.520? 

As Component matching supports DNs, there is no reason to ask for
it.  My point is that the value extraction approach is an
incomplete and problematic solution to matching of components.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Dec 2004 10:49:58 -0800

At 08:46 AM 12/2/2004, David Chadwick wrote:
>I believe that this matching rule and assertion was first provided by myself in "Additional LDAP Schema for PKIs and PMIs" <draft-pkix-ldap-schema-00.txt> in July 2000. And the exact match was implemented shortly afterwards in OpenLDAP. So exact certificate matching is not difficult.

I note that one of your draft says:
   A couple of Internet Drafts [9,10] have been specified,
   but implementation of them is complex.

[9,10] respectively refer to draft-ietf-pkix-ldap-pki-schema
and draft-ietf-pkix-ldap-pmi-schema, which appear
to have replaced draft-ietf-pkix-ldap-schema.

This reflects another problem with these I-Ds, much
of the material doesn't appear to reflect the current
state of works in progress, as well as the current
state of works on the Standards Track.  Some updating
here would be useful.

Kurt

---

From: Steve Hanna <[email-masked]>
Date: Fri, 03 Dec 2004 17:34:13 -0500

David,

I'm talking about CertificateAssertion, not
CertificateExactAssertion. The former allows
matching by issuer, subject, subjectAltName,
and several other useful fields. The latter
only allows matching on issuer and serial
number. Of course, you must know all about
this if you invented them both. But I want
to be clear about what I was talking about.

With respect to your argument that all clients
support your schema without code changes, not
all clients do a full subtree search. Some just
retrieve the certificates directly from the user's
or CA's directory entry. Yes, you can work around
the problem by storing the certificates in both
the old and the new location but that has all
the consistency problems that have been described
elsewhere.

Thanks,

Steve

David Chadwick wrote:
>>> component matching was the best long term solution to aim for. That 
>>> is on the record. But also on the record is the note that vendors 
>>> appear to be reluctant to support this, and that support for 
>>> attribute extraction is a short term pragmatic solution that is much 
>>> easier for suppliers and users to support. It does not add complexity 
>>> to clients, on the contrary it makes it easier for clients. 
>>> Consequently the ADs agreed that component matching should be 
>>> published as Information RFCs.
>>>
>>> Since that time (Spring 2003) suppliers have not moved that far (if 
>>> at all) towards supporting component matching. Only Steven Legg's 
>>> suppliers might eventually decide to support component matching. 
>>> After all, there are several very basic features of LDAP that some 
>>> large LDAP suppliers dont yet support, even though they have been 
>>> matching. Be realistic, it wont. Unless of course Stefan Santesson 
>>> can now stand up for his supplier and tell us when they will support

---

From: Andrew Sciberras <[email-masked]>
Date: Mon, 06 Dec 2004 12:01:51 +1100

G'Day David,

> find a certificate containing a particular email address or key usage

What Steven was referring to was an activity that I conducted with the 
Calendra Directory Manager. One of the things that this application can 
do is provide user's with different view's to the directory based on who 
they are. The 'who' can be determined dynamically by the application 
based on an ldap search filter.
So, using your suggestion (i.e Email Address) suppose I want to group 
people with an email address that equals "[email-masked]". The email 
address in this case is the email address within the rfc822Name within a 
subjectAltName extension.

The search filter that I used is:

(userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.extensions.*.extnValue.content.(2.5.29.17).*.rfc822Name", 
rule caseIgnoreIA5Match, value "[email-masked]"})

A better example however is centered around the Mozilla Address book. In 
my address book I can configure a number of different instances of the 
same directory.  With Mozilla, your directory configuration has an 
Advanced setting where you can specify an ldap filter that will be added 
to any searches that you make on the directory.
So, I have a single View500 directory that contains information about 
people. In my Mozilla application I can create the following address 
book instances of the directory:

1.
Title "All Entries"
Filter: objectClass=*
Purpose: I will use this "address book" to attempt to match against 
every entry in the directory

2.
Title "Cert v3 People"
Filter: (userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.version",  rule integerMatch, value 2})
Purpose: Only search for people that have a Version 3 certificate.

3.
Title "Certificates with a KeyUsage Extension"
Filter: (userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.extensions.*.extnValue.content.(2.5.29.15)", rule 
presentMatch, value NULL})
Purpose: This is simply here to illustrate the usage of the presentMatch 
and how it can be applied to single out specific extensions.

4.
Title "Certificates of people from COMPANY"
Filter: (userCertificate:componentFilterMatch:=item:{ component 
"toBeSigned.subject.rdnSequence.*", rule rdnMatch, value "O=COMPANY"})
Purpose: To only search for people with certificates whose subject 
indicates that they belong to an Organization called COMPANY

These filters should work against an LDAP Directory that supports 
Component Matching (I've only used View500) with the current build of 
Mozilla. The filters above are simply 4 examples of, what is 
essentially, an infinite amount of filters that can be applied to any 
component of any ASN.1 type used as a syntax of an attribute.

Cheers,
Andrew Sciberras