Certificate Matching was:RE: Basic Cert-2-Directory mapping question

["Steven Legg" <steven.legg@xxxxxxxxxxxxx>]

Michael,

> -----Original Message-----
> From: michael@xxxxxxxxxx [mailto:michael@xxxxxxxxxx]On Behalf 
> Of Michael
> Str der
> Sent: Tuesday, 16 January 2001 21:50
> To: ietf-pkix
> Subject: Re: Basic Cert-2-Directory mapping question
> 
> 
> Tom Gindin wrote:
> > 
> > wouldn't it be reasonable to define a search
> > syntax for them which uses keywords to identify fields, 
> rather than the
> > generic ASN.1 facility you proposed?  I cannot believe that 
> it is really
> > appropriate to require LDAP queries for known ASN.1 types to specify
> > matching rules within the query.
> 
> As far as I understand this I-D the LDAP client will just construct
> LDAP filter strings as usual. The LDAP server deals with the ugly
> stuff as it deals with ASN.1 structures when doing searches anyway.
> 
> Steve, David, correct me if I'm wrong.

More precisely, the assertions in an LDAP filter are still text strings,
so a user doesn't need to understand BER to use component matching.
An understanding of the ASN.1 syntax definition of the attribute type
being searched helps, but it is possible to write the PKI profiles such
that ASN.1-unaware users can easily formulate useful queries.

An LDAP filter has actually always been a mix of BER and text encodings.
APIs generally hide the BER parts from users. An LDAP filter has a string
representation according to RFC 2254, but this is not used by the LDAP
search operation. 

Regards,
Steven

> 
> Ciao, Michael.
>