RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Steve:

I do not disagree with your conclusions.  But, depending on organization
policy to publish signature certificates or not, depending on different
certificates issued for different certificate policies, and certificates
due to re-key, there could be several certificates for an user entry.

You definitely need to store the latest encryption certificate or all
latest encryption certificates for the various policies.

If you decide to publish signature certificates, you need to store all
unexpired (in order to verify signatures) signature certificates.  These
could be multiple due to re-key and/or due to different certificate
policies.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Steve Hanna
Sent: Monday, November 25, 2002 4:10 PM
To: Ramsay, Ron
Cc: Housley, Russ; ietf-pkix@xxxxxxx
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)



"Ramsay, Ron" wrote:
> The problem with this method is that you must retrieve all the 
> certificates in the entry even if you want only one. You also must 
> scan each certificate looking for the one you want (using your ASN.1 
> tools?). If certificates are stored in subordinate entries, a search 
> will return only those certificates that match the search criteria 
> (doesn't require ASN.1 tools).

How many certificates will one user generally have in their LDAP
directory entry? I suspect that the average will be between one and two
(omitting those users that don't have any certificates). A few users
might have five or more certificates, but I suspect that will be very
rare.

So downloading all the certificates in a user's directory
entry doesn't seem like a big problem to me. Certainly, I
don't see why we need to make big changes to solve it.

As for the need to parse ASN.1, why is that a problem?
If you're going to use the certificates, you generally need
to parse them.

> Also, storing certificates in user entries limits your scope in 
> searching for them. You cannot use auxiliary attributes for 
> serialNumber, etc. You have to use a ceriticate matching rule. I think

> your clients are going to have some trouble with this! However, if you

> are going to recode them to use matching rules, why not also change 
> the base-object search to a whole-subtree search and then it will be 
> transparent to the application whether the certificate is in the entry

> or in a subordinate entry.

When (and how) do you think I will want to search for user certificates?
I expect that the common case will be "get me the S/MIME certs for
steve.hanna@xxxxxxx", which would be handled by searching on the mail
attribute. Then I could download the certificates from the
userCertificate attribute and see which ones I wanted. In general, it
seems unlikely that I would need to search by a certificate field that
is not in inetOrgPerson.

If this is a solution without a real problem, I think we
all have better things to do.

Thanks,

Steve