RE: 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: Wednesday, 24 January 2001 23:07
> To: ietf-pkix@xxxxxxx
> Subject: Re: Certificate Matching was:RE: Basic 
> Cert-2-Directory mapping
> question
> 
> 
> Steven Legg wrote:
> > 
> > It isn't always appropriate that the value of the surrogate 
> attribute
> > matches the value of the corresponding field in the certificate.
> > Maybe the certificate is valid but uses a superseded value for the
> > surrogate attribute (maybe the user has changed ISPs and is 
> waiting for
> > an updated certificate).
> 
> If I understand your example right you would like to use the cert
> retrieved from the LDAP host containing the old e-mail address to
> encrypt a message for the new e-mail address? This behaviour is not
> what I would like to see in my e-mail application. Think of key
> escrow mechanisms in a company...

It was a general statement not directed at any particular attribute
type. Using surrogate attribute values to search for certificates
imposes a constraint between the certificate contents and the contents
of the other attributes in the same entry. I'm not bold enough or
knowledgeable enough to assert that there are NO current or future
applications where this constraint would cause serious difficulties.

As Tom pointed out, we could define a bunch of new attribute types
to act expressly and only as search attributes for fields in certificates.
It then doesn't matter that there is a constraint between the certificates
and the new attributes, except that the task of managing the correspondence
between the two falls to the large number of client implementations.
It makes more sense to change the small number of server implementations
to support direct searching on certificate contents.

> 
> > With surrogate search attributes the client will get back all
> > certificates in the entry and have to filter them itself to find
> > which is the one it actually wants.
> 
> IMHO the main benefit of this I-D would be that applications or
> components not dealing with ASN.1 or certificates itself can
> retrieve the appropriate certificate. If you require the
> client-application to do anything else more than just submitting a
> simple LDAP filter string you can stop writing the I-D.

I hope you haven't confused the issues. There are two things being
discussed.

1) Should surrogate search attributes or direct matching on certificates
be used to search for certificates ?

2) Given that there is direct matching, should the matching rules be a
series of special purpose certificate matching rules or a generic matching
capability that works for any syntax (certificates included) ?

With regard to 1), a search on a single surrogate attribute can only
return all certificates in a matched entry. If the entry contains
only one certificate the client can trust it is the right one (hopefully
the surrogate attribute value is the same as the corresponding field
in the certificate). If the entry contains more than one certificate
then it is up to the client to delve into each certificate to work
out which is the one it actually wanted. Searches on a combination
of surrogate attributes can return entries with certificates that
don't have the desired combination. Again it is up to the client
to delve into the certificates to see which entries and certificates
actually match its criteria. Surrogate search attributes generally require
the clients to be PKI and ASN.1 aware. Direct matching of certificates
doesn't.

With regard to 2), I'm drawing a distinction between LDAP filters that
are simple to use versus LDAP filters that look simple. Special
purpose certificate matching rules can be (relatively) simple to use
and also look simple. I contend that I can write component matching
rule templates that are equally simple to use, though they look more
complicated.

> > I recognize that the need to understand ASN.1 in order to 
> formulate a
> > query is an obstacle to acceptance.
> 
> YES!
> 
> Another real-world example: A system administrator wants to pull
> certificates via LDAP and feed them into a PKI-aware application.
> She/He's using her/his favourite scripting language with a primitive
> LDAP module to download the binary blobs containing DER-encoded
> certificates. In this system the LDAP component itself is not
> PKI-aware and the PKI-aware component is not capable of speaking
> LDAP. Therefore the LDAP component is not able to sort out the right
> certificate.

When you say that the LDAP component is not PKI-aware I take it you mean
that it doesn't understand the ASN.1 type of a certificate and supports
no matching rules for directly matching a certificate. In such a case
your hypothetical system administrator would have to use surrogate
search attributes with all the attendant imprecision. Some sort
of direct matching capability is required for the LDAP component to
return only the right certificate.

Regards,
Steven

> 
> Ciao, Michael.
>