On Jul 10, 2009, at 7:55 PM, Kamil Dudka wrote:
> 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().

indeed

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

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

No, this should be a runtime option. The scenarios I've thought of are
these

1) using CURLOPT_SSLCERT (+ optional CURLOPT_KEYPASSWD)

Use SelectClientCert to do the stuff we do today except
nss_Init_Tokens and pass along the password from CURLOPT_KEYPASSWD as
PKCS11PinArg on the socket. If the cert by the given name can't be
found or the password is wrong this will result in an error as it does
today. This is what most users will use.

2) using CURLOPT_USE_NSS_CLIENTCERT_HOOK (+ optional CURLOPT_KEYPASSWD)

Use NSS_GetClientAuthData and pass NULL as the argument to the hook
which will result in NSS_GetClientAuthData to try to find the best
matching cert. Pass along the password if it's set as the PKCS11PinArg

3) use CURLOPT_USE_NSS_CLIENTCERT_HOOK + CURLOPT_SSLCERT (+ optional
CURLOPT_KEYPASSWD)

Use NSS_GetClientAuthData but pass the cert name as argument to the
hook so it basicly just does a PK11_FindCertByName as SelectClientCert
but the user will automaticly get any NSS fixes if they update how
things work. Also sets PKCS11PinArg if CURLOPT_KEYPASSWD is specified.

This way we leave SelectClientCert hook untouched and it'll work like
normal and we'll have a the possibility to use client certs where we
don't know the name of the specific certificate as this is sometimes
the case when using hardware tokens.

HAVE_PK11_CREATEGENERICOBJECT would not be affected by this and would
stay in as it does now.

Cheers,
Claes
Received on 2009-07-10