Dear crypto-groupe
,
below i wrote down our Technical cause analysis for Thunderbird
problem with the search for certificates in the  S-TRUST trust list
service and will please you, to support us with this question:

the analysis of the phenomenon has proved that the problem is caused
client-sided – by the Thunderbird application.
The application Thunderbird uses two different variations to
communicate with the LDAP. The first one is to complete the name
(AutoCompletion), the second call loads the certificates to the client
which were found to the completed email address. By the LDAP queries
(searchRequests) a limitation of the return results is put in each
case client-sided by the server (sizeLimit in searchRequest). For the
AutoCompletion inquiry this is adaptable sizeLimit from the user
(default = 100). Nevertheless, for the inquiry of the certificates to
be downloaded not the configureable value is used, but a heuristics
which is defined in the source code is applied. This heuristics
assumes from the fact that there are two certificates (signature and
encoding) for every email receiver. Therefore are put exactly the
double number in results like email addresses as sizeLimit in
searchRequest. The developer of this routine has already indicated in
a comment in the source text the problems perhaps resulting from it:

[...]
// Max search results =>
// Double number of email addresses, because each person might have //
multiple certificates listed. We expect at most two certificates,
// one for signing, one for encrypting.
// Maybe that number should be larger, to allow for deployments,
// where even more certs can be stored per user???
[...]

Therefore Thunderbird can evaluate maximum two certificates of the
email receiver, even if the email receiver owns more than two
certificates. This behaviour prevents that the encoding certificate is
found by our test-account (test person has 4 certificates on one E-
mail-account).

Finally the  "kickOffSearch()" of the  Quellcode from  Thunderbird:
[...]
function kickOffSearch() { try { var prefix1 = ""; var suffix1 = "";
var urlFilter = gLdapServerURL.filter; if (urlFilter != null &&
urlFilter.length > 0 && urlFilter != "(objectclass=*)") { if
(urlFilter[0] == '(') { prefix1 = "(&" + urlFilter; Seite: 2 von 2 27.
Mai 2010 }
else { prefix1 = "(&(" + urlFilter + ")"; } suffix1 = ")"; }
var prefix2 = ""; var suffix2 = "";
if (gEmailAddresses.length > 1) { prefix2 = "(|"; suffix2 = ")"; } var
mailFilter = ""; for (var i = 0; i < gEmailAddresses.length; ++i) {
mailFilter += "(mail=" + gEmailAddresses[i] + ")"; }
var filter = prefix1 + prefix2 + mailFilter + suffix2 + suffix1; var
wanted_attributes = new Array();
wanted_attributes[0] = CertAttribute; // Max search results => //
Double number of email addresses, because each person might have
// multiple certificates listed. We expect at most two
certificates, // one for signing, one for encrypting.
// Maybe that number should be larger, to allow for deployments, //
where even more certs can be stored per user???
var maxEntriesWanted = gEmailAddresses.length * 2; getLDAPOperation();
gLdapOperation.searchExt(gLdapServerURL.dn, gLdapServerURL.scope,
filter, 1, wanted_attributes, 0, maxEntriesWanted); } catch (e)
{ window.close(); } }
[...]

Is there any bug-fix  available or  scheduled?

Friendly regards,
Marcus
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to