On 2009-07-05 16:03 PDT, Ian G wrote: > On 4/7/09 23:19, Nelson B Bolyard wrote: >> You provide customer support for Firefox? > > Yup. Doesn't everyone who is a techie? I mean, I don't want to, but > because I am a techie, people assume that I know Firefox back to front > and can make it do circus tricks. I can't of course, but I can solve > some problems.
Well, I formerly provided it to immediate family members, but that has fallen way off. >> Your user thinks that you control the behavior of Firefox? > > Yes. Doesn't every user? No, definitely not. I probably do have more effect on FF than most, but I make it very clear to all and sundry that my influence is very limited in scope. >>> I can't get through the message to her that the >>> "software security device" is just some broken metaphor for her >>> certificate, because she's convinced Firefox is telling her there is >>> piece of hardware gone wrong, and she knows it hasn't. >> >> Yeah, I don't like that name either, but it's not under the NSS team's >> control. > > Oh, ok, I didn't know that. The main thing that I see there is that it > is a hopeless sort of throw back to imperial times where smart card > tokens were considered to be the "ideals" and software certs were > considered to be "compromises". Until that notion is debunked there is > little hope in filing a bug. It's an artifact of an architectural choice made by the NSS team years ago. The NSS team played a major role in devising and promoting PKCS#11. The original motivation for that was to enable users of Netscape/Mozilla browsers and also Netscape/Sun/RedHat servers to be able to use third party crypto hardware with their NSS-based client and/or server software. Until then, each hardware maker had its own API, and applications that used a hardware vendor's API were pretty much locked into that vendor's hardware. Each HW vendor wanted NSS to adopt their API. All the NSS-based products (client and server) were multi-platform, and the NSS team desired that NSS-based products should be able to work with multiple-vendors' crypto hardware on each platform, so an open multi-vendor multi-platform (multi-OS) API was needed. To that end, the NSS team worked with the PKCS#11 working group (whose other members were mostly crypto hardware vendors), with the result that, today, PKCS#11 is the number 1 (maybe only) hardware vendor-neutral OS-neutral application-neutral crypto API. Initially, NSS could either use its own software crypto, or could use PKCS#11 crypto, and this meant that a LOT of code was full of if-then-else cases, e.g. if using-hardware then use PKCS#11 else use NSS's own internal software. We realized that NSS could be greatly simplified if we took NSS's own software crypto engines and cert and key storage and put all of that into a pure-software PKCS#11 library. Then NSS would always use PKCS#11 for all crypto operations, and for all cert and key storage. NSS migrated to that architecture. First, we made NSS use PKCS#11 for all crypto operations, but NSS still had two ways of doing cert and key storage. Then in NSS 3.4 (IIRC) we finally made NSS so that it only and exclusively used PKCS#11 for all crypto operations and all cert and key storage. In the PKCS#11 model, each vendor has a "module" (library) that interfaces to "slots" (logical connectors) into which "tokens" may be plugged. Tokens are any "devices" that are capable of crypto operations and/or storage of keys and/or certs. NSS's own crypto libraries and cert and key storage became a PKCS#11 "module" (library) implementing a number of pure software slots, each containing a pure-software token. NSS's PKCS#11 modules, slots and tokens behave just like any other PKCS#11 modules, slots and tokens, except that they use no special hardware. Again, the motivation for this was simplicity of software design, rather than any belief that hardware was somehow inherently more secure or ideal than software. Having a single API with a single way of doing any crypto operation or storage, regardless of whether or not it used hardware under the hood greatly simplified MUCH NSS software. It was elegant. No more "hacks" of doing things one way or a second way. Just one way to do each and every operation, whether there was hardware involved or not. There was no need to explain two separate alternative models, one that used hardware and one that used only software. Users would have a single model of how things worked, whether their certs and keys lived in a gizmo in their pocket or on their computer's hard disk. This was an obvious win for the developers, but it meant that we had to introduce users of NSS-based applications to the PKCS#11 concepts (e.g. modules, slots and tokens) and terminology. The server folks didn't object to this, and seemed to like a single unified model and its terminology. Sun Microsystems adopted that model and terminology for all its crypto software and hardware products. Virtually all crypto hardware vendors have adopted it. But the browser folks didn't like the terminology. They didn't like the term "token". So, in the browser, they morphed the "software token" into a "software security device". Only the mozilla software imposes that alternative naming. NSS's "softoken" PKCS#11 module identifies its own module names as: - NSS Internal FIPS PKCS #11 Module and identifies own slots and tokens with these names: - slot: NSS Internal Cryptographic Services - token: NSS Generic Crypto Services - slot: NSS User Private Key and Certificate Services - token: NSS Certificate DB All of Mozilla's PSM certificate manager and other dialogs substitute their own names for the names above. Slot name "NSS Internal Cryptographic Services" becomes "PSM Internal Cryptographic Services". Token name "NSS Generic Crypto Services" becomes "Generic Crypto Services". Slot name "NSS User Private Key and Certificate Services" becomes "PSM private keys", and token name "NSS Certificate DB" becomes "Software Security Device". NSS also has a separate read-only PKCS#11 module, slot and token that stores the default list of trusted CA certs. This is known by the names: module: Builtin Roots Module slot: NSS Builtin Objects token: Builtin Object Token PSM does not replace those names with its own. This model and these terms are the same on every platform on which Mozilla products run. Knowledge of how to use it on Windows transfers exactly as-is to Macintosh and/or Linux. This was the NSS team defining the architecture and setting the standard, not merely following standards. You seem to think that's desirable. So don't fight it. :) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto