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
> smartcards.

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
well.

> 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.

Kamil
Received on 2009-07-10