Ok thanks. That was really helpful. What about the latest Communicator clients (6.x)? Do they suffer from using an old NSS, or are they using the latest and greatest? If so, then card middleware providers will have to support the later browser versions and should therefore implement more of the PKCS#11 spec (so that NSS-enabled apps other than Communicator can do business!).
-- P "Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Patrick wrote: > > > > Well, I'd be curious to know if you could use any of those acpkcs.dll with > > an NSS-enabled client app and successfully use a cert off an ActivCard > > smartcard for SSL client auth? > > So would I. I've got two readers and all the drivers, but no cards for the > readers. Our IT department is not ready to distribute them yet. :( > > > And how does ActivCard exactly make their supposedly generic PKCS#11 library > > usable in Communicator? That answer will explain how the PKCS#11 lib then > > gets "hobbled" with respect to usage in latest NSS. > > Communicator didn't use all the possible facets of PKCS#11, so a module > vendor could implement just the subset that Communicator used and stop > there instead of implementing the full thing. Many vendors did exactly that. > > Say, PKCS#11 defines some function that returns a structure with 15 members, > but Communicator only uses 11. Some implementations might only fill in > those 11 members and leave the other 4 uninitialized or filled in > incorrectly. But NSS might use all 15 of them, and when NSS goes to use > one of those 4 that weren't initialized correctly, boom. > > For example, PKCS#11 defines a struct named CK_TOKEN_INFO. The last 4 > fields in that struct are: > ulTotalPublicMemory, > ulFreePublicMemory, > ulTotalPrivateMemory, > ulFreePrivateMemory. > As the names imply, those are 4 "unsigned longs". I know of one vendor's > implementation that seems to fill in those fields with values that can > be expressed as > (correct_value << 16) | 0x4000. > AFAIK, Communicator doesn't care about those values, so... > > PKCS#11 defines a large collection of "object attributes" that objects like > keys are supposed to have. An application should be able to set or > interrogate them all (although some are sensitive). Some vendors don't > implement the ones that Communicator didn't use. NSS uses more than > Communicator did, so again ... > > An example of this is the CKA_MODULUS_BITS attribute on a private key. > It's merely the length of the modulus in bits, and should be a readable > attribute. Communicator apparently didn't ask for that. NSS does. > > I believe that a module that works with NSS should also work with > Communicator. Communicator uses a subset of what NSS uses. > > -- > Nelson Bolyard > Disclaimer: I speak for myself, not for Netscape
