Michael Bell wrote:
>
> Hi,
>
> during I work around the Email= problem I discovered two other problems
> (if I interpret something wrong then forget it)
>
> 1. the DN does not contain the serialNumber. So this cause several other
> problems
> a) ca has to starts at every time with certificate 0. So old signed
> certificates can not be validated and all old signed documents are a
> problem.
> b) one user can only have one certificate. So it is impossible to
> impement non-repudation and to store old certificates (expired or
> revoked) for verification of old signatures.
This is not correct, if you have more certificates for one user, the LDAP saves
them correctly as it works, I think, whith ashes : if data passed is different
it adds it, not replace it. You can verify it by using Netscape: if you view
the user search result you'll see all the certificates you added, not only the
last...
> 2. I discovered that you are using the (E)mail or the cn to check for the
> existence of a DN. This is very critical due to server admins which often
> write their names into the server's certificate. So the filter should be
> the real proposed DN (best with included serial number ;-) ).
I see, but if you seach by DN you add more certificates to different CN, let's
say a user has two certificates:
1. DN: Email=my@email, CN=Name Surname, OU=My Unit 1, O=Org, C=CT
1. DN: Email=my@email, CN=Name Surname, OU=My Unit 2, O=Org, C=CT
If you search by DN you'll not find the User and will add another one while
the user do exists after adding the first certificate. So searching by CN
and/or by Email should solve this problem. The Serial could be inserted into
the DN, this is a choice - also if you think that the latest ietf rfc
say it is best adding the Email into the subjectAltName extention and not
into the DN... you know the DN must be unique so the serial could guarantee
this ...
C'you,
Massimiliano Pala ([EMAIL PROTECTED])
S/MIME Cryptographic Signature
