[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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