Hi,

is it normal that, during the SSL handshake,
the disabled removable token is asked for the authentication certificate/key, please?


We are developing a xulrunner extension that acts as the client of 'SmartCard Manager' . In some modes this application uses two tokens: operator's and the user's ones .

The user's token should not be used for the authentication purpose,
so, I try to use the PK11_UserDisableSlot() to disable the corresponding slot.

Doing that, the user's token is not more used when the CA or server certificates are looked for,
but, still, it's asked for the client authentication certificate/key .

Looking though the sources, it appears that, when getting the client authentication data,
the 'disabled' flag is ignored for the removable tokens .
(For the permanent tokens, the 'disabled' flag is checked in nssToken_IsPresent()) .

The following patch works for me. What do you think about it?
--- ./security/nss/lib/pki/trustdomain.c.orig 2009-01-04 02:42:18.000000000 +0100 +++ ./security/nss/lib/pki/trustdomain.c 2009-01-05 16:55:01.000000000 +0100
@@ -297,6 +297,8 @@
         tok != (NSSToken *)NULL;
         tok  = (NSSToken *)nssListIterator_Next(td->tokens))
    {
+       if (PK11_IsDisabled(tok->slot->pk11slot))
+               continue;
       if (nssToken_IsPresent(tok)) {
           myName = nssToken_GetName(tok);
           if (nssUTF8_Equal(tokenName, myName, &nssrv)) break;



Another question is:
does the name of the active token has to be the unique one?

When both tokens have the same name, it happens that the operator's token is not more asked for
client authentication data.
(In fact it happens, when the operator's slot number is greater that the user's one .) IMHO, it's because the NSSTrustDomain_FindTokenByName(), used by nsNSS_SSLGetClientAuthData(),
is not conceived to return multiple results .
That's why one of the tokens 'hides' the other one.

Kind wishes,

--

Viktor Tarasov  <vtara...@opentrust.com>

_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to