Re: issues with pre-login to pkcs11 slots when using NSS
Date: Fri, 10 Jul 2009 19:55:54 +0200
On Friday 10 of July 2009 18:46:19 Claes Jakobsson wrote:
> Yes I think we should (and I want to) drop the pre-login completely.
> Not only because there might be PKCS#11 modules that complains when we
> try to authenticate using the wrong password like what I have, but
> also because if you have many tokens then it'll be a substantial
> startup time for the initial socket like when used with the curl
> command line tool. The later mostly applies to hardware tokens like
I have no problem with dropping the nss_Init_Tokens() function completely. But
it might be also good to get it agreed by Rob (CC) as the (probable) original
author of nss_Init_Tokens().
> NSS also provides a fairly reasonable hook, NSS_GetClientAuthData,
> that just picks the best available cert or a cert by nickname that I'd
> like to be able to use instead of SelectClientCert. As it's not as
Great. I have the NSS_GetClientAuthData() function already used in my (not yet
published) test suite for curl/nss. It works well with the NSS database, but
not so well with the cert/key loaded by the PEM reader.
What about calling the NSS_GetClientAuthData() from SelectClientCert() if the
nickname is not equal to "PEM Token"? It might then work in both cases fairly
> predictable as SelectClientCert I propose we make it available as an
> option, for example CURLOPT_NSS_USE_BUILTIN_CLIENT_CERT_HOOK ( or
> something a bit shorter =) ).
Do you mean a compile-time option? Does the option have to be mutually
exclusive with HAVE_PK11_CREATEGENERICOBJECT (or its more accurate
equivalent)? I personally prefer any solution where no more compile-time
options are needed.
> If the above about dropping nss_Init_Tokens and the option are ok I'll
> go ahead and fix it and provide a new patch.
Dropping nss_Init_Tokens() is ok for me, but I am not so sure with the
compile-time option. I don't think it's really necessary.
Received on 2009-07-10