On 6/7/09 08:42, Nelson Bolyard wrote:
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.
Right. It's not a big burden, just irregular bursts of trauma. The
other big factor with which I've improved things dramatically is to
insist on Mac only.
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.
Oh. Logic :)
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.
This is a great description. It should be in a FAQ somewhere.
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. :)
lol, touche!
So let's do that again :) Seriously, this is the sort of muscle that
Mozilla has. That it doesn't use it saddens me immensely.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
