Hi Kamil.

sorry for the delayed answer.

On Jul 10, 2009, at 10:10 PM, Kamil Dudka wrote:
> Claes, could you please have a look at the attachment? It's a
> proposal only.
> It'll definitely need a review (as Friday evening), but it works for
> me in all
> three cases. Note that your original patch is included.

The patch looks good to me. Some logging what's going would be nice
tho such as what certificate it's going to use.

> In the most common case (meaning PEM module not available) is always
> used
> the NSS_GetClientAuthData() function. If you don't specify any
> nickname, NSS
> tries to find the cert automagically. Any possible problems here?

Not really except we can't log what's going on in
NSS_GetClientAuthData but as we don't do it in SelectClientCert today
that's probablly not an issue.

> If you have the PEM module loaded, you have all three choices. You
> can specify
> either nickname, or a file name, or even nothing. In the last case the
> certificate is found automagically as well.
>
> It runs properly with my test suite. Could you try it with the HW
> token, etc.
> and summarize what is missing/not working? Thanks in advance!

Tried it with my setup where the PKCS#11 module I'm using both handles
a soft token and a h/w token for me. Tried both with specifying
exactly what certificate to use and also letting NSS select the right
one and it all passes.

Comparing NSS_GetClientAuthData with the old SelectClientCert the only
potential problem I can see is that when using a nickname
NSS_GetClientAuthData seems to limit this to certs registered as
client-certs whereas PK11_FindCertByKey might return *any* cert afaik
(purely speculative tho as my NSS-fu is not strong enough). So if your
certs aren't registered properly in the NSS DB this might break
backwards compat. But I think this is actually positive since it
encourage people to setup things correctly =)

Cheers,
Claes
Received on 2009-07-12