> -----Original Message----- > From: Bob Relyea [mailto:[EMAIL PROTECTED] > Sent: 23 January 2006 17:31 > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: PKCS#11 module and FireFox password promting > > > If the SSL site is not requesting client auth, then the prompts for your > token pin during SSL may have to do with how the token was installed. If > the token was installed as 'the default RSA device', then NSS assumes > the token is a hardware accelerator and will try to use the token to > verify RSA signatures and encrypt RSA keys. > > Try doing the following: > 1. go to the Security Devices menu > 'options->Advanced->security->security devices'. > 2. Select the SaveSign Module ("It will say something like "SafeSign > Module" and have a +/- twisty in front of it. > 3. In the right hand window there should be a line labelled 'Path'. > Copy that value (data following 'Path'). Note, the path may be quite > long, and you may have to adjust the window to see the whole thing. > 4. With the module selected click the 'Unload' button. > 5. Click the load button, for 'Module Name' give "SafeSign Module", > for 'Module filename' give the value you copied from Path in step 3. > 6. click 'OK'. > > This should remove all the configuration bits set for your module. You > will notice password prompts whenever NSS needs to look up certificates, > but that should be restricted to SSL client auth sites and bringing up > the certificate viewer. > Thanks for this Bob, unfortunately the behaviour still remains unchanged, as soon as I go to the login page of my Yahoo account I get a smartcard PIN request screen, which is strange as the Yahoo login is not even SSL.
I am not convinces the behaviour was the same with FireFox 1.07 so I'll try to pop that back on another machine and see. Thanks for you comments, Mark. > Mark Hobbs wrote: > > I am currently using FireFox V1.5 (Windows XP) and use a smartcard based > > DigitalID (private key and X509 cert) via a commercial PKCS#11 > DLL marketed > > under the SafeSign name. > > > > My question concerns the frequency I am prompted for my > smartcard password. > > It appears that when FireFox tries to perform some SLL related action it > > requires that I have an "active" smartcard session (e.g. I have recently > > entered my PIN) despite the fact that for normal SLL, no client > > authentication, there is no reason at all for it to need it. > > > > Surely this is not correct operation. It's certainly a pain. > > > > I have also noticed that when I use client authenticated SSL I am quite > > rightly asked for my PIN but the internal caching of > authentication tokens > > appears to be different between the smartcard and the internal > crypto device > > as I am constantly asked to re-enter the smartcard PIN after periods of > > inactivity (say 10 or 15 minutes). > > > The card module controls it's own login state. Some cards may have a > timeout value built into them. By default, NSS does not have a timeout, > though one can be set either globally or on a card basis. If NSS is > enforcing this, the steps described above should reset the token to use > the system default. > > Probably not a fault as such but inconvenient. Cheers, I'll try to contact the supplier to ask the question although using the same card under IE with the companies CAPI CSP I don't get the time-out "problem". Obviously CSP is different to PKCS11 although I would expect a similar approach to time-outs for both. > > > > Regards, > > Mark. > > > > > > > > > > Diginis is an ISO 9001 certified company > > > > > > Simple, Safe, Secure e-Solutions > > This electronic transmission and any files attached to it are strictly > > confidential and intended solely for the addressee. If you are not the > > intended addressee, you must not disclose, copy or take any action in > > reliance of this transmission. If you have received this transmission in > > error, please notify us by return and delete the same. Although > Diginus Ltd > > rigorously endeavours to maintain a virus free computer environment, the > > sender does not warrant that this transmission is virus-free > and will not be > > liable for any damages resulting from any virus transmitted. > > > > > > _______________________________________________ > > dev-tech-crypto mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-tech-crypto > > > > _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
