Problem reading certificate from hardware token
Udo Puetz
I've googled to and fro and have only found another poster having
roughly the same problem as I. The situation is this:
I want to authenticate against a juniper SA 2500 firewall with a user
and password AND a certificate. I have a safenet iKey 1032 token where
I imported the p12 certificate. In firefox (tried 2.0.x, 3.0.x and
3.5.x) I imported the safenet K1PK112.DLL PKCS#11 module. In the
firefox cryptography module manager I now see the token and can (after
entering the pin) see the certificate. So firefox _can_ read the
certificate off of the token.
But when I go to the juniper firewall website I get the error message
that the certificate can't be found.
When I (for testing) take out the token and import the p12 certificate
directly into the firefox certificate store I can authenticate against
the juniper firewall website with user and pass and the certificate.
So the problem seems to be that in the cyrpto module manager firefox
can read a certificate off of a token and can't read it off when
queried by a website.
Where would you think is the problem? Is it within firefox or a
problem with the third-party pkcs#11 module? (I'm also in contact with
the safenet folks)
Thanks a lot,
regards
Udo Puetz
Anders Rundgren
with a diagnostic at least. Which is? Smart card vendors have
spent decades on fighting each other on the spec/middleware
side and naturally we all have to pay the price.
Tokens for consumers have therefore been [rightfully] rejected on
the pragmatic US market.
Is there a workaround? Yes, instead of chasing middleware issues
another 10 years or so, I think that "the authentication people" including
Mozilla should define a token with a standard interface that is included
in the platform itself regardless if that is Firefox or Windows.
The opposite to that is the OpenSC project where every card
profile, vendor, and local country variation is treated as "feature",
while it from a usability point-of-view is really more like a bug".
Anders
--
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Nelson B Bolyard
> I want to authenticate against a juniper SA 2500 firewall with a user and
> password AND a certificate.
> I have a safenet iKey 1032 token where I imported the p12 certificate.
> In firefox (tried 2.0.x, 3.0.x and 3.5.x) I imported the safenet
> K1PK112.DLL PKCS#11 module. In the firefox cryptography module manager I
> now see the token and can (after entering the pin) see the certificate.
> So firefox _can_ read the certificate off of the token.
While in this state, go into Firefox's certificate manager, and look through
the tabs to find the cert. Tell us in which tab(s) the cert
appears. In particular, does it appear in the "Your Certificates" tab?
Also, in that tab, note the value in the "Security Device" column in the
row for your certificate.
Then, Select your certificate and click the "View" button. A Certificate
Viewer Dialog will appear. In that Dialog, select the "Details" tab.
In that tab are 3 boxes or "panes", the top one of which is labeled
"Certificate Hierarchy". That box will contain some number of lines.
Please copy the contents of that box (you may have to retype it by hand).
I will explain below what to do with this information.
> But when I go to the juniper firewall website I get the error message
> that the certificate can't be found.
Where do you see this message? Is it in a Juniper log file? Or Firefox?
If it is a Juniper log file, can you tell from the message whether it is saying:
a) That it received no certificate from the browser, or
b) That it cannot validate the certificate chain received, or
b) That it does not recognize the validated cert as being authorized?
> When I (for testing) take out the token and import the p12 certificate
> directly into the firefox certificate store I can authenticate against
> the juniper firewall website with user and pass and the certificate.
> So the problem seems to be that in the cyrpto module manager firefox can
> read a certificate off of a token and can't read it off when queried by a
> website.
While in this state, please repeat the steps I gave above, noting the tab of
the certificate manager in which your certificate appears, the security
device associated with your certificate, and the contents of the Certificate
Hierarchy pane in the Certificate Viewer.
Then compare these two sets of results. I suspect they will differ.
It may be that, in one case the certificate appears in "Your Certificates"
tab, and in the other case, it does not appear in that tab, but appears
in some other tab. Or, it may be that in one case the Certificate Hierarchy
contains multiple lines (corresponding to multiple certificates) and in the
other case, it contains fewer lines (perhaps only one).
Or perhaps you will find both of these differences. Or perhaps neither.
Any of these differences could explain your problem, I believe.
If you do not find any of these differences, then I can suggest some
additional (more complicated) diagnostic steps.
> Where would you think is the problem?
> Is it within firefox or a problem with the third-party pkcs#11 module?
> (I'm also in contact with the safenet folks)
At this point, with the information I have, I can only speculate.
There are many possibilities. Here are some:
1) In addition to needing the certificate, Firefox also needs to be able
to access the private key on the token. It may be that it cannot access
the private key on the token, but can access it when you import the PKCS#12
file into Firefox's own software token (a.k.a. "Software Security Device").
If Firefox can access the private key, then the certificate should appear
in "Your Certificates", otherwise it will appear in one of the other tabs.
If you find that the certificate does not appear in "Your Certificates",
then that is the problem. This would very likely be a problem in the
PKCS#11 module and/or token, not in Firefox.
2) It may be that your certificate has a hierarchy with more than two
certificates in it, and all of those certificates are stored in Firefox's
software token when you import the PKCS#12 file there, but not all those
certificates are being stored on the token when you import the PKCS#12 file
there. In order to be able to successfully do client cert authentication,
Firefox needs access to the entire correct certificate hierarchy. It cannot
succeed if certs are missing from the hierarchy. If you find that
the two hierarchies seen in the steps above are different, that is the
likely cause. In that case, you really should try to import the missing
certs into the token. If you cannot do that, that is a bug in the token
or PKCS#11 module, however, there is a workaround. You can import the
missing CA certs into Firefox's software token instead.
Hope this helps.
> Thanks a lot,
> regards
> Udo Puetz
--
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
Anders Rundgren
either must be nuts, a masochist, very smart, or highly committed.
For ordinary users it makes little sense.
Hardware tokens: there are any number of different types
PKCS #11: the most difficult to program and administer middleware known to mankind
Firefox: doesn't support CA issuers or Windows CSPs
Linux: doesn't even provide a crypto service API, or does it?
Anders
Nelson B Bolyard wrote:
> On 2009-07-02 02:58 PDT, Udo Puetz wrote:
>
>> I want to authenticate against a juniper SA 2500 firewall with a user and
>> password AND a certificate.
>> I have a safenet iKey 1032 token where I imported the p12 certificate.
>> In firefox (tried 2.0.x, 3.0.x and 3.5.x) I imported the safenet
>> K1PK112.DLL PKCS#11 module. In the firefox cryptography module manager I
>> now see the token and can (after entering the pin) see the certificate.
>> So firefox _can_ read the certificate off of the token.
>
> While in this state, go into Firefox's certificate manager, and look through
> the tabs to find the cert. Tell us in which tab(s) the cert
> appears. In particular, does it appear in the "Your Certificates" tab?
> Also, in that tab, note the value in the "Security Device" column in the
> row for your certificate.
> Then, Select your certificate and click the "View" button. A Certificate
> Viewer Dialog will appear. In that Dialog, select the "Details" tab.
> In that tab are 3 boxes or "panes", the top one of which is labeled
> "Certificate Hierarchy". That box will contain some number of lines.
> Please copy the contents of that box (you may have to retype it by hand).
> I will explain below what to do with this information.
>
>> But when I go to the juniper firewall website I get the error message
>> that the certificate can't be found.
>
> Where do you see this message? Is it in a Juniper log file? Or Firefox?
> If it is a Juniper log file, can you tell from the message whether it is saying:
> a) That it received no certificate from the browser, or
> b) That it cannot validate the certificate chain received, or
> b) That it does not recognize the validated cert as being authorized?
>
>> When I (for testing) take out the token and import the p12 certificate
>> directly into the firefox certificate store I can authenticate against
>> the juniper firewall website with user and pass and the certificate.
>> So the problem seems to be that in the cyrpto module manager firefox can
>> read a certificate off of a token and can't read it off when queried by a
>> website.
>
> While in this state, please repeat the steps I gave above, noting the tab of
> the certificate manager in which your certificate appears, the security
> device associated with your certificate, and the contents of the Certificate
> Hierarchy pane in the Certificate Viewer.
>
> Then compare these two sets of results. I suspect they will differ.
> It may be that, in one case the certificate appears in "Your Certificates"
> tab, and in the other case, it does not appear in that tab, but appears
> in some other tab. Or, it may be that in one case the Certificate Hierarchy
> contains multiple lines (corresponding to multiple certificates) and in the
> other case, it contains fewer lines (perhaps only one).
> Or perhaps you will find both of these differences. Or perhaps neither.
>
> Any of these differences could explain your problem, I believe.
> If you do not find any of these differences, then I can suggest some
> additional (more complicated) diagnostic steps.
>
>> Where would you think is the problem?
>> Is it within firefox or a problem with the third-party pkcs#11 module?
>> (I'm also in contact with the safenet folks)
>
> At this point, with the information I have, I can only speculate.
> There are many possibilities. Here are some:
>
> 1) In addition to needing the certificate, Firefox also needs to be able
> to access the private key on the token. It may be that it cannot access
> the private key on the token, but can access it when you import the PKCS#12
> file into Firefox's own software token (a.k.a. "Software Security Device").
> If Firefox can access the private key, then the certificate should appear
> in "Your Certificates", otherwise it will appear in one of the other tabs.
> If you find that the certificate does not appear in "Your Certificates",
> then that is the problem. This would very likely be a problem in the
> PKCS#11 module and/or token, not in Firefox.
>
> 2) It may be that your certificate has a hierarchy with more than two
> certificates in it, and all of those certificates are stored in Firefox's
> software token when you import the PKCS#12 file there, but not all those
> certificates are being stored on the token when you import the PKCS#12 file
> there. In order to be able to successfully do client cert authentication,
> Firefox needs access to the entire correct certificate hierarchy. It cannot
> succeed if certs are missing from the hierarchy. If you find that
> the two hierarchies seen in the steps above are different, that is the
> likely cause. In that case, you really should try to import the missing
> certs into the token. If you cannot do that, that is a bug in the token
> or PKCS#11 module, however, there is a workaround. You can import the
> missing CA certs into Firefox's software token instead.
>
> Hope this helps.
>
Michael Ströder
> Linux: doesn't even provide a crypto service API, or does it?
There's a PKCS#11 driver implementation by OpenSC project (see
http://www.opensc.org/).
Ciao, Michael.
Eddy Nigg
> If you want to use Hardware tokens, PKCS #11, and Firefox you
> either must be nuts, a masochist, very smart, or highly committed.
>
For all those which are nuts, masochists, smart and highly committed I
blogged this article which shows how easy it can be, specially on Linux:
http://blog.startcom.org/?p=82
Enjoy :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Kyle Hamilton
to extend that by adding a generic "oh, it also has a device in a slot
that performs these functions" layer that was exposed through the
device-reader profile, it would be universal -- and universally
implemented in the platform itself.
-Kyle H
On Thu, Jul 2, 2009 at 3:16 AM, Anders
Rundgren<anders....@telia.com> wrote:
> I can't help you with the specific problem [:-(] but I can "help" you
> with a diagnostic at least. Which is? Smart card vendors have
> spent decades on fighting each other on the spec/middleware
> side and naturally we all have to pay the price.
>
> Tokens for consumers have therefore been [rightfully] rejected on
> the pragmatic US market.
>
> Is there a workaround? Yes, instead of chasing middleware issues
> another 10 years or so, I think that "the authentication people" including
> Mozilla should define a token with a standard interface that is included
> in the platform itself regardless if that is Firefox or Windows.
>
> The opposite to that is the OpenSC project where every card
> profile, vendor, and local country variation is treated as "feature",
> while it from a usability point-of-view is really more like a bug".
>
> Anders
>
> ----- Original Message -----
> From: "Udo Puetz" <inex...@googlemail.com>
> Newsgroups: mozilla.dev.tech.crypto
> To: <dev-tec...@lists.mozilla.org>
> Sent: Thursday, July 02, 2009 11:58
> Subject: Problem reading certificate from hardware token
>
>
Anders Rundgren
I'm not aware of any such profile. There is smart card profile
but I doubt it has much to do with PKCS #11, it is rather about
7816.
Anyway, the way Firefox is linked to PKCS #11 is probably OK
in Linux-land.
However, in Windows-land where 80% of all users live it doesn't fill
the bill.
BTW, we still don't have a credible system for *remote* provisioning of
smart cards on any OS, so we shouldn't expect too much progress here
because PKCS #11 can't do that job actually!
Anders
Nelson B Bolyard
> If you want to use Hardware tokens, PKCS #11, and Firefox you
> either must be nuts, a masochist, very smart, or highly committed.
>
>
> Hardware tokens: there are any number of different types
> PKCS #11: the most difficult to program and administer middleware
> known to mankind
> Firefox: doesn't support CA issuers or Windows CSPs
>
>
Anders, The user has made a decision and we're helping him with it.
I don't find your sniping helpful in any way. I am aware that you
have proposed alternative technologies to many of those used in Firefox,
and I imagine that you're frustrated that the major browsers are not
excitedly switching to those alternatives, but please don't take it out
on us. Please refrain from further sniping in this mailing list and
newsgroup. Constructive contributions are welcome.
In answer to your question: Yes, the Linux Software Base now includes NSS.
Numerous products use it, including Google's Chrome and Adobe's Flash Player.
Eddy Nigg
> In answer to your question: Yes, the Linux Software Base now includes NSS.
> Numerous products use it, including Google's Chrome and Adobe's Flash Player.
>
Hoho....I didn't noticed that...perhaps....because it just works?
Anders Rundgren
>> If you want to use Hardware tokens, PKCS #11, and Firefox you
>> either must be nuts, a masochist, very smart, or highly committed.
That's fine, I have personally noted that these kinds of problems are rather
common while for example using a FAT-formatted USB mass storage
unit works without hassles on multiple platforms. This is not something
that You or Mozilla is responsible for, it is the *industry* that we both
represent that IMO have screw-up big-time.
See Kyle's posting regarding on-line banking.
>I am aware that you have proposed alternative technologies to many
>of those used in Firefox, and I imagine that you're frustrated that the
>major browsers are not excitedly switching to those alternatives.
It is very frustrating that EU banks and governments are spending
hundreds of million dollar per year on software that basically replace
the browsers' client-side PKI stuff because the latter are all-over-the-map
and does not support the tiniest of requirements such as PIN-codes for soft tokens.
Many of these efforts also bypass TLS client-cert-auth for essentially
the same reasons why practically nobody uses HTTP Basic or Digest
Authentication. but rather make auth a part of the app protocol.
Anyway, my analysis shows that updating browser mechanisms like
<keygen> wouldn't actually solve anything because the token products
on the market were never designed for on-line provisioning.
According to most people who are into consumer PKI, Java applets is the
best solution for cross-browser PKI. I think Java applets suck but indeed,
that's really all we got.
>but please don't take it out on us. Please refrain from further sniping
>in this mailing list and newsgroup. Constructive contributions are welcome.
I'm sorry about that. Is there any other place where Mozilla people hang
out where there is an interest in trying to understand why and what is
happening on the PKI side for consumers?
Regarding constructive contributions: IF it would be possible to get some
architectural support for introducing XML protocol support in Firefox,
I think we could actually move things forward a bit:
http://webpki.org/papers/web/XMLBrowserExtensionScheme.pdf
If Mozilla want to do this in another way that's fine, the important thing is to
get something universally usable running!
>In answer to your question: Yes, the Linux Software Base now includes NSS.
>Numerous products use it, including Google's Chrome and Adobe's Flash Player.
That's good to hear!
Regards
Anders Rundgren
Martin Paljak
On 03.07.2009, at 8:15, Anders Rundgren wrote:
> According to most people who are into consumer PKI, Java applets is
> the
> best solution for cross-browser PKI. I think Java applets suck but
> indeed,
> that's really all we got.
>
>> but please don't take it out on us. Please refrain from further
>> sniping
>> in this mailing list and newsgroup. Constructive contributions are
>> welcome.
>
Some constructive suggestions; mostly for Firefox:
1. Use platform API-s where appropriate: cryptoapi (and basecsp via
this) on windows; cdsa/keychain on macosx. Yell at both companies at
the same time to fix their API-s as well (pinpad support, multiple PIN
support, GUI hints (PIN vs password) etc). IIRC http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/
was the thing that should enable this, it dates back to 2005, why
this has not been polished and included with latest releases? Linux is
the spaghetti mix where PKCS#11 indeed might be the best option, but
once the big desktop players (KDE, GNOME) (re-)implement the relevant
(bicycle/)API-s, there might be QCA (http://api.kde.org/kdesupport-api/kdesupport-apidocs/qca/html/
) and something similar for GNOME as well. Should they be below NSS or
above it in the software stack? Hard to say.
FYI, to make sense to users of eID cards currently one has to embed
the word PIN into the token description as well, so that the prompt
that Firefox displays would make sense: "Please enter password for:
MARTIN PALJAK (PIN1)" GUI hints would be useful...
2. Fix Firefox/NSS - Firefox still thinks that you should be able to
authenticate to websites with certificates *without* TLS client
authentication extension. Add automatic certificate selection, and you
get trouble.
2a. I don't know if the defaults have changed lately, but allow the
end user to define the "friendly certs" option for PKCS#11 tokens,
which currently has no UI except the Javascript loading function which
got removed from UI land and moved to XPI land in FF 3.5. There are
tokens that require this feature, but some PKCS#11 providers like
OpenSC which support many different tokens have no easy way to work in
both ways.
3. For Firefox only: provide a useful JS interface to allow access to
keys which are not used for web authentication but present under "my
certificates" for real-life online signing procedures. I know that
here the vision of a polished solution differs between people but I
also second Anders that there are many (tens?) custom built modules
here in EU which re-implement at least the minimal part: signing a
hash. GUI requirements (like displaying the title of a document,
displaying a legal warning, displaying the whole document to be
signed) could be worked upon in a common way once the basics are
agreed upon to be useful.
For now, I think the reason why there is so little interest for this
field is that it is really hard to market such features. The reason
why Apple has very low prirorities for smart card related fixes is
that it is really hard for Steve to demo this on the big stage. Same
goes with Firefox. And "those who really want it, can in theory
achieve their goals with extras and extensions" works as well.
--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495
Udo Puetz
my colleague has run off with the test token so I can only show you
some screenshots I made for the german support of safenet. These show
roughly what you requested. When my colleague returns I'll make new
screenshots (in english if I manage somehow). Here are the shots:
http://www.i-nex.de/uploads/certificate-view.JPG
http://www.i-nex.de/uploads/cryto-module-firefox2.JPG
http://www.i-nex.de/uploads/ff2-ikey-problem.JPG
The last one is made with firefox 2, but like I said also FF3 and
FF3.5 exhibit the same problem. We also looked with livehttp-headers
what get's to and fro, maybe I can dig out a log or something there
too.
Thanks a lot,
regards
Udo Puetz
now I think ALL OSs suck when dealing with cryto tokens and such. And
don't get me started on RSA SecurID tokens and vista...But let's
please stick to the matter at hand.
Eddy Nigg
> I'm sorry about that. Is there any other place where Mozilla people hang
> out where there is an interest in trying to understand why and what is
> happening on the PKI side for consumers?
>
Anders, I think you must take your ideas to a standards body - I think
that's the only way to move it forward. I highly suspect that Mozilla
will not adopt something which isn't more or less universally
recognized, specially in this field.
Anders Rundgren
Eddy, this is exactly what I believed/hoped/craved for.
Unfortunately, the people who represent "stake holders" like EU
governments and banks do participate in International foras like OASIS
and IETF, nor fund such developments. It also seems that
browser-standards are difficult to get anywhere with even if you are W3C.
So for good or worse, I have come to the conclusion that Open Source and
to some extent also Open Hardware (new tokens) is *my* way forward.
I don't expect or need a Mozilla endorsement, but it would be awfully
nice if we could get an XML protocol extension scheme running and then
let Mr. Darwin figure who's extensions are the best! There are tons of
stuff waiting for such a facility but instead of fixing it, everybody is
trying their own scheme leading to miserable stability and very slow
progress.
NSAPI isn't really cutting it, because it is is for people doing web
content.
It would cost a week or two of Mozilla R&D but I am sure it would be
worth it. I would do it myself but a Mozilla spokesman said that it
would fail for every marginal revision and that put me down :-(
Anders
Ian G
> Nelson B Bolyard wrote:
>> but please don't take it out on us. Please refrain from further sniping
>> in this mailing list and newsgroup. Constructive contributions are welcome.
>
> out where there is an interest in trying to understand why and what is
> happening on the PKI side for consumers?
No, there is none as far as I know. Mozilla outsources the security
architecture, partly because it subscribes to standards, partly because
it is really interested in browsers and users rather than security and
protocols, and partly because it (Netscape) tried it once in 1994, and
got slapped down.
As a historical legacy, Mozilla has chosen the 1980s design of PKI, and
that's that. This isn't going to change any time soon. We, the
industry, are locked in a deadly embrace on security.
I admit to being fooled by this, and it took me years to figure out why
people here didn't respond. Basically, Mozilla doesn't do security
architecure. They just do security programming. They'll take whatever
standard comes out of the standards groups, and implement them if and
when they become necessary.
Which means as an unfortunate side effect. When there is a bug in that
architecture, Mozilla is powerless to fix it. Even if liable! It's not
their fault, and there isn't much use in railing against it.
(Mind you, it would help if Mozilla people also realised their position,
and didn't encourage false expectations based on some sort of claim to
security leadership.)
iang
Udo Puetz
Hi all,
I'll answer Mr. Bolyards questions briefly because I think we found
the culprid. See at the bottom.
> > I have a safenet iKey 1032 token where I imported the p12 certificate.
> > In firefox (tried 2.0.x, 3.0.x and 3.5.x) I imported the safenet
> > K1PK112.DLL PKCS#11 module. In the firefox cryptography module manager I
> > now see the token and can (after entering the pin) see the certificate.
> > So firefox _can_ read the certificate off of the token.
>
> While in this state, go into Firefox's certificate manager, and look through
> the tabs to find the cert. Tell us in which tab(s) the cert
> appears. In particular, does it appear in the "Your Certificates" tab?
Yes it does.
> Also, in that tab, note the value in the "Security Device" column in the
> row for your certificate.
There it lists the ikey device
> Then, Select your certificate and click the "View" button. A Certificate
> Viewer Dialog will appear. In that Dialog, select the "Details" tab.
> In that tab are 3 boxes or "panes", the top one of which is labeled
> "Certificate Hierarchy". That box will contain some number of lines.
> Please copy the contents of that box (you may have to retype it by hand).
> I will explain below what to do with this information.
There is only one line, that of the user certificate.
> > But when I go to the juniper firewall website I get the error message
> > that the certificate can't be found.
>
> Where do you see this message? Is it in a Juniper log file? Or Firefox?
> If it is a Juniper log file, can you tell from the message whether it is saying:
> a) That it received no certificate from the browser, or
This.
> b) That it cannot validate the certificate chain received, or
> b) That it does not recognize the validated cert as being authorized?
>
> > When I (for testing) take out the token and import the p12 certificate
> > directly into the firefox certificate store I can authenticate against
> > the juniper firewall website with user and pass and the certificate.
> > So the problem seems to be that in the cyrpto module manager firefox can
> > read a certificate off of a token and can't read it off when queried by a
> > website.
>
> While in this state, please repeat the steps I gave above, noting the tab of
> the certificate manager in which your certificate appears, the security
> device associated with your certificate, and the contents of the Certificate
> Hierarchy pane in the Certificate Viewer.
The difference to the above is that in the pane view it now shows the
CA and
below that the user certificate.
> Then compare these two sets of results. I suspect they will differ.
> It may be that, in one case the certificate appears in "Your Certificates"
> tab, and in the other case, it does not appear in that tab, but appears
> in some other tab. Or, it may be that in one case the Certificate Hierarchy
> contains multiple lines (corresponding to multiple certificates) and in the
> other case, it contains fewer lines (perhaps only one).
> Or perhaps you will find both of these differences. Or perhaps neither.
>
[...]
> 2) It may be that your certificate has a hierarchy with more than two
> certificates in it, and all of those certificates are stored in Firefox's
> software token when you import the PKCS#12 file there, but not all those
> certificates are being stored on the token when you import the PKCS#12 file
> there. In order to be able to successfully do client cert authentication,
> Firefox needs access to the entire correct certificate hierarchy. It cannot
> succeed if certs are missing from the hierarchy. If you find that
> the two hierarchies seen in the steps above are different, that is the
> likely cause. In that case, you really should try to import the missing
> certs into the token. If you cannot do that, that is a bug in the token
> or PKCS#11 module, however, there is a workaround. You can import the
> missing CA certs into Firefox's software token instead.
What we've found out now is this:
there is no CA certificate on the token. And it seems that firefox
needs the CA
and the user certificate from the same place:
Test: we unplug the token, clean up so that no user cert and CA cert
is there. Import the p12 file.
Then we have a CA cert in the authorities tab, a user cert in the
"your certificates" tab with software
store as device and in the details pane the CA with the user cert
below it. Then the authentication works.
If I clean up again (no user cert and CA cert there), plug in the
token I only get the user cert, no CA cert.
If I import a CA cert only into the authorities tab and plug in the
token I (naturally) have both, the CA and
the user cert BUT in the details pane there is still only the user
cert there, it's NOT below the corresponding
CA cert. That's the problem.
That's why I reason that the CA and user cert have to come from the
same source, either the software storage
or the token. But mixing the stores doesn't seem possible.
My colleague is now trying to import the CA onto the token. As seen
above the p12 file includes both the CA cert
and the user cert. But if one imports it with the safenet ikey token
utility the CA cert file seems to get lost.
This seems now to be a problem with the token import utility. Do you
agree? Or should firefox accept a CA cert and
user cert from different stores?
Thanks a lot again for your help
regards
Udo Puetz
Ian G
...
> 2. Fix Firefox/NSS - Firefox still thinks that you should be able to
> authenticate to websites with certificates *without* TLS client
> authentication extension. Add automatic certificate selection, and you
> get trouble.
Yes, this makes cert login as bad as other forms of login. We
desperately need some form of whitelisting in Firefox so that each site
always gets presented the same cert. If browsers can remember cookies
and username/passwords, then they can remember cert/domain combinations.
> 2a. I don't know if the defaults have changed lately, but allow the end
> user to define the "friendly certs" option for PKCS#11 tokens, which
> currently has no UI except the Javascript loading function which got
> removed from UI land and moved to XPI land in FF 3.5. There are tokens
> that require this feature, but some PKCS#11 providers like OpenSC which
> support many different tokens have no easy way to work in both ways.
As an aside, does anyone have any stats about how many people use these
non-Firefox security devices? It is somewhat clear that most end-users
can't use these things, only corporates can. So Mozilla priority for
these things might be lacking.
Whereas, end users can use browser-embedded certificates.
> 3. For Firefox only: provide a useful JS interface to allow access to
> keys which are not used for web authentication but present under "my
> certificates" for real-life online signing procedures. I know that here
> the vision of a polished solution differs between people but I also
> second Anders that there are many (tens?) custom built modules here in
> EU which re-implement at least the minimal part: signing a hash.
Are these easy-to-deploy open source plugins of some form?
> GUI
> requirements (like displaying the title of a document, displaying a
> legal warning, displaying the whole document to be signed) could be
> worked upon in a common way once the basics are agreed upon to be useful.
Right, digital signing would be a good application. But can't be done
properly without the browsers accepting a common protocol.
> For now, I think the reason why there is so little interest for this
> field is that it is really hard to market such features. The reason why
> Apple has very low prirorities for smart card related fixes is that it
> is really hard for Steve to demo this on the big stage. Same goes with
> Firefox. And "those who really want it, can in theory achieve their
> goals with extras and extensions" works as well.
Concur.
Nelson B Bolyard
> Some constructive suggestions; mostly for Firefox:
>
> 1. Use platform API-s where appropriate: cryptoapi (and basecsp via
> this) on windows; cdsa/keychain on macosx.
Regardless of who does it, this triples/quadruples the amount of work
to be done and code to be supported. Google did that. I'm not opposed
to it, if Mozilla wants to fund it.
> FYI, to make sense to users of eID cards currently one has to embed
> the word PIN into the token description as well, so that the prompt
> that Firefox displays would make sense: "Please enter password for:
> MARTIN PALJAK (PIN1)" GUI hints would be useful...
Please elaborate.
> 2. Fix Firefox/NSS - Firefox still thinks that you should be able to
> authenticate to websites with certificates *without* TLS client
> authentication extension. Add automatic certificate selection, and you
> get trouble.
Extended Key Usages do not ADD to a cert's capabilities. They take way from
it. A cert with no EKU extension is valid for all EKUsages (with very few
exceptions - only one comes to mind).
But it's certainly true that if Firefox will take a cert with an EKU
extension that does NOT include TLS client auth and use that for TLS client
auth, that's a bug, pure and simple. File a bug on it if you have a
working example.
> 2a. I don't know if the defaults have changed lately, but allow the
> end user to define the "friendly certs" option for PKCS#11 tokens,
> which currently has no UI except the Javascript loading function which
> got removed from UI land and moved to XPI land in FF 3.5. There are
> tokens that require this feature, but some PKCS#11 providers like
> OpenSC which support many different tokens have no easy way to work in
> both ways.
I agree that one way to fix this is to provide some UI by which the PKCS#11
module can be configured as friendly when it is added. but I think we can
probably just figure it out with s simple run time test, and then ignore
the configuration bit. That's a better solution, if we can make it work.
Please file an RFE about this.
> 3. For Firefox only: provide a useful JS interface to allow access to
> keys which are not used for web authentication but present under "my
> certificates" for real-life online signing procedures.
Are you aware of crypto.signtext? (Please, No ranting!)
If you are aware of it, please write specifics about what else you need
that's not there. It produces a full CMS (PKCS#7) signature.
Be aware that any proposed signature method that doesn't show the user
what he's signing will probably not be allowed. So, a method to sign
a bare hash, without knowing where it came from is a non-starter.
A method to take data and hash it, and then sign that could be made to
work, but that's what crypto.signtext does.
Nelson B Bolyard
> We desperately need some form of whitelisting in Firefox so that each site
> always gets presented the same cert. If browsers can remember cookies
> and username/passwords, then they can remember cert/domain combinations.
This goes double for Thunderbird and mail servers, which are configured,
not browsed.
Bug 155089: Need a better way to associate a certificate to a mail account
for authentication
just had its 7th birthday.
> As an aside, does anyone have any stats about how many people use these
> non-Firefox security devices?
I don't have numeric statistics. Users in certain countries, and users
who are customers of certain banks, use them a lot. Banks in some countries
give them away to customers. But elsewhere they're mostly used in "closed"
corporate or governmental environments. (I guess banks and their customers
are "closed" environments, too.)
> It is somewhat clear that most end-users can't use these things, only
> corporates can. So Mozilla priority for these things might be lacking.
The average browser user doesn't even set/use a "master password". So,
the site passwords that his browser remembers are stored "in the clear".
The reason is not that the user doesn't know about master passwords.
It's that users don't want to be bothered with a password request, EVER,
not even once per browser process lifetime.
These same users complain that Firefox has a dialog that will show them
their saved web site passwords. They're (rightly) afraid that others will
use this feature to steal their passwords when they're not looking. (Of
course, they could also set their screen savers to require a password to
unlock, but they don't do that, either.) When told that setting a master
password will prevent Firefox's passwords from ever being shown without
entering it immediately before the display, they balk at having to set a
master password. They don't understand that, as long as the passwords are
stored "in the clear", they're vulnerable, whether FF displays them in a
dialog or not.
My point is that I think the relevant questions are:
- how many end users who *want* to use them can do so? and
- What are the reasons they don't?
I think we'll need something that is as widely accepted as a credit card
before this takes off. But that by itself won't suffice. It will also
require identity theft to get a LOT WORSE before the average consumer
decides that having to lift a finger to protect himself isn't such a bad idea.
Nelson B Bolyard
> What we've found out now is this: there is no CA certificate on the
> token. And it seems that firefox needs the CA and the user certificate
> from the same place:
I don't believe it is true that Firefox requires both to be in the same
token.
> If I import a CA cert only into the authorities tab and plug in the token
> I (naturally) have both, the CA and the user cert BUT in the details pane
> there is still only the user cert there, it's NOT below the
> corresponding CA cert. That's the problem.
Agreed that the problem is that Firefox does not find the CA cert, but I
think more investigation is needed. I highly doubt that the matter is
purely one of where the cert is loaded (though it may seem that way).
I have some ideas for more tests below.
> That's why I reason that the CA and user cert have to come from the same
> source, either the software storage or the token. But mixing the stores
> doesn't seem possible.
Except that I do that all the time.
> My colleague is now trying to import the CA onto the token. As seen above
> the p12 file includes both the CA cert and the user cert.
Actually, I haven't seen evidence of that, although you did claim that when
you imported the PKCS#12 file into the software token, that the missing CA
cert was then found present.
> But if one imports it with the safenet ikey token utility the CA cert
> file seems to get lost.
Seems to. I have a hunch that the CA certificate may have some issues that
cause it to not be recognized as a CA cert.
If you have a certificate that does not appear on its face to be a CA
certificate, when you store it in Firefox's soft token, it can be marked
with a flag that says "treat this like a CA cert, even if it's not a CA
cert". This flag is known as the "Valid CA" flag. One possible explanation
for what you're seeing is that that the CA cert is being marked with this
flag when it is imported into the softoken from the PKCS#12 file, but is not
being marked with that flag when it is imported into the hardware
token. Consequently, it is not seen in the Authorities tab when it is in
the token. It may be in one of the other tabs.
> This seems now to be a problem with the token import utility. Do you
> agree?
Not necessarily, but perhaps. I can think of at least two explanations for
the behavior you're seeing that do not imply that there is a problem with
the token import utility. I can think of numerous tests that you could
perform to better diagnose the problems, some of which use NSS utility
programs that are not distributed with Firefox.
Here are some tests you can try.
1a. Remove the token with the EE (SSL client authentication) cert.
1b. Import the PKCS#12 file into the software token again.
1c. Verify that this works (can client auth).
1d. Exit Firefox. Make sure that it's not running any more.
1e. Make a copy of cert8.db and key3.db in another folder.
Let's call that folder "Pair1".
1f. Restart Firefox.
1g. Using Firefox's certificate manager, delete the EE certificate from
"Your certificates" tab, but leave the CA certificate in place.
1e. Shut down and Restart Firefox, again.
1f. Insert the Token and authenticate to it (enter the token PIN).
1g. Now view the EE cert in the cert manager and see if Firefox finds
the EE cert beneath the CA cert in the cert hierarchy pane.
1h. See if you can do client authentication there.
Now, most of the rest of the diagnostics steps that occur to me involve
using NSS command line tools that you probably don't have and with which
you probably aren't familiar. So, rather than telling you how to get them,
how to install them and how to use them, I'm going to suggest that you
email me one file, namely the cert8.db file that you saved in "Pair1".
I want only the cert8.db file, which contains only the public certificates,
and not the key3.db file that contains your private keys, or any other DB
files. I don't need any private keys to do this analysis I want to do.
You can email it to the address from which this email comes.
Regards,
/Nelson
Eddy Nigg
>> That's why I reason that the CA and user cert have to come from the same
>> source, either the software storage or the token. But mixing the stores
>> doesn't seem possible.
>>
> Except that I do that all the time.
>
>
True.
> Actually, I haven't seen evidence of that, although you did claim that when
> you imported the PKCS#12 file into the software token, that the missing CA
> cert was then found present.
>
It's not a good idea to place the CA certificate on the token because
the trust bits may get confused. It's better to import the CA root into
the software store.
Martin Paljak
Estonia on Mac OS X and NPAPI compatible browsers, which means firefox/
safari/opera/camino ...), my opinions might be biased, but they
reflect real life requirements.
On 04.07.2009, at 1:04, Nelson B Bolyard wrote:
>> FYI, to make sense to users of eID cards currently one has to embed
>> the word PIN into the token description as well, so that the prompt
>> that Firefox displays would make sense: "Please enter password for:
>> MARTIN PALJAK (PIN1)" GUI hints would be useful...
>
> Please elaborate.
Firefox displays a "Please enter password for ..." dialog, which is
ambiguous for casual users who need to be said very clearly when they
need to enter the PIN of 4 or more digits. Right now my Firefox speaks
Estonian but I also remember a phrase "master password" somewhere...
On Windows, using CryptoAPI would eliminate this problem as CryptoAPI
would deal with the GUI issues (native language, pinpads etc). I know
that some PKCS#11 providers accept passwords, but very often the
providers mask smart cards where the credential is always a PIN code.
A similar problem exists on Safari/Mac OS X, where the unchangeable
keychain GUI asks for "enter your password for keychain "yourcard""
and people have been typing they login password over and over until
the card gets locked... Even "enter your password for keychain
"yourcard (PIN1)"" does not help - some people still try different
passwords.
> But it's certainly true that if Firefox will take a cert with an EKU
> extension that does NOT include TLS client auth and use that for TLS
> client
> auth, that's a bug, pure and simple. File a bug on it if you have a
> working example.
Maybe it was bad wording from my side but I tried to explain that a
few years back when the "non-repudiation" feature introduced the
problem. I'll open a new one with a different approach one day.
>> 3. For Firefox only: provide a useful JS interface to allow access to
>> keys which are not used for web authentication but present under "my
>> certificates" for real-life online signing procedures.
>
> Are you aware of crypto.signtext? (Please, No ranting!)
Yes.
> If you are aware of it, please write specifics about what else you
> need
> that's not there. It produces a full CMS (PKCS#7) signature.
1. Certificate selection. Usually the website that requests a
signature knows which signatures are required to give candy to the
user, rather than "here is the stuff, sign it with what you can and
we'll see how we can go forward". My eID has two certificates from the
same CA, one for authentication and one for signatures. Firefox
happily allows me to sign with the authentication certificate which
the website will reject. Further filtering of the certificate to be
used would be required. Maybe regexps ?
2. Cleartext/data transfer issue. Not all things that I sign can be
displayed. I have signed .zip files with programs and documentation,
source code repositories, iso files with backups, timestamp-protected
business ideas etc. Signing PDF and word documents is I assume the
most common thing in Estonia people do outside of web self-service
portals which use digital signatures.
First - you can't have universal visualization for all the things one
would want to sign; second - if there is a 500 page PDF report, sized
38MB - you just can't download it for the purpose of signing to the
client side. In those cases you use a specialized client side software
to do your things. Web signing is used in e-banking (to sign
transactions which "belong to" the bank anyway), document management
systems to sign things in a workflow (the document "belongs to" the
document management system) and so on. Basically in places where the
website is *requesting* higher assurance from the client, rather than
the client *offering* higher assurance to the website. You already
have trusted your bank to keep your pennies, you already have trusted
the document management system to deal with your documents - the trust
relationship has already been established, you don't need an extra
"trusted display". But it would be good to have it, in some cases.
> Be aware that any proposed signature method that doesn't show the user
> what he's signing will probably not be allowed.
The "What you see is what you get" problem has been solved in Estonia
so that the user must have a possibility to download the signed
document after signing it, to verify the content of it. For those who
object it with "but then it is too late, you already have sold your
house" - the same laws that give the digital signature the same power
as a handwritten one to allow such huge transactions, protect you from
fraud and unlawful actions by 3rd parties. As signed documents in
Estonia include a signed OCSP response, it is even easier with digital
signatures than it is to overturn a deal done when drugged by your
business partner - OCSP requests leave a track...
> So, a method to sign
> a bare hash, without knowing where it came from is a non-starter.
> A method to take data and hash it, and then sign that could be made to
> work, but that's what crypto.signtext does.
You know where it comes from - the site you are visiting! Once people
are educated well enough to know that "PIN2 == handwritten signature"
they know not to type it in when visiting a porn site. Of course there
is a small % of people who sign anything they are asked to, but the
number of Nigerian scam victims is shrinking...
Access control like Google Gears does is sufficient - "Do you trust
secure.yourbank.com to have access to your certificates and to perform
digital signatures? Yes/No/Remember my choice".
Ian G
On 4/7/09 12:18, Martin Paljak wrote:
> Firefox displays a "Please enter password for ..." dialog, which is
> ambiguous for casual users who need to be said very clearly when they
> need to enter the PIN of 4 or more digits. Right now my Firefox speaks
> Estonian but I also remember a phrase "master password" somewhere...
Yes, I get this frequently with my one user who demands my support.
When Firefox asks for a password, I always get called to answer what it
is. It starts from the basics ("why,what,which,...") and continues
through to hatred and loathing.
The worst one is the "software security device" or somesuch. My user
does not want a "software security device." My user tells me loudly to
make it go away. 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.
The security messages (in english) are just completely useless before
real life users. I have no doubt it gets worse in other languages :)
(BTW, my user is not dumb, just average. Is also somewhat au fait with
certificates, being quite well involved with CAcert, but not technical
at all. Techies will say that this is a dumb user and must be ignored,
but I search these people out because they tell me whether the tech will
work in the real world or not.)
(people will say, why don't you help? why not fix the messages, instead
of just picking at flaws and being nasty? Because the messages are not
the bug, they are just the symptom. Until we can see movement and
compromise on the underlying model, there is no point in fixing the
messages.)
> On
> Windows, using CryptoAPI would eliminate this problem as CryptoAPI would
> deal with the GUI issues (native language, pinpads etc).
Are you saying that the cryptoapi has all the phrases and translations
in it? Wow. I'm not sure if I like that solution from a technical pov,
but if it works...
> A similar problem exists on Safari/Mac OS X, where the unchangeable
> keychain GUI asks for "enter your password for keychain "yourcard"" and
> people have been typing they login password over and over until the card
> gets locked... Even "enter your password for keychain "yourcard (PIN1)""
> does not help - some people still try different passwords.
:) Precisely. At the interface between one security model and another,
the whole thing falls apart. This is the core killer of the smart card,
it's extremely secure, but it's only half the model. It will therefore
always be a disaster, which people will keep working on, saying "if
only..." for years.
The common joke was to refer to "next year is the year of the smart card..."
>> But it's certainly true that if Firefox will take a cert with an EKU
>> extension that does NOT include TLS client auth and use that for TLS
>> client
>> auth, that's a bug, pure and simple. File a bug on it if you have a
>> working example.
> Maybe it was bad wording from my side but I tried to explain that a few
> years back when the "non-repudiation" feature introduced the problem.
> I'll open a new one with a different approach one day.
Non-repudiation: should be deleted where ever seen.
>>> 3. For Firefox only: provide a useful JS interface to allow access to
>>> keys which are not used for web authentication but present under "my
>>> certificates" for real-life online signing procedures.
>>
>> Are you aware of crypto.signtext? (Please, No ranting!)
> Yes.
>
>> If you are aware of it, please write specifics about what else you need
>> that's not there. It produces a full CMS (PKCS#7) signature.
> 1. Certificate selection. Usually the website that requests a signature
> knows which signatures are required to give candy to the user, rather
> than "here is the stuff, sign it with what you can and we'll see how we
> can go forward". My eID has two certificates from the same CA, one for
> authentication and one for signatures. Firefox happily allows me to sign
> with the authentication certificate which the website will reject.
> Further filtering of the certificate to be used would be required. Maybe
> regexps ?
Although your point is on target, it only reveals the difficulties that
we are facing, which are immense and hard to write in a simple post.
A problem with digital signing is that it only works if the person, the
CA, the 3rd party, the law, the browser, the certificate, the server and
no doubt other meddling parties as well, *all understand and all agree*.
If anyone of those points break, it doesn't work. And if it doesn't
work, the user will reject it. Quite fairly, because otherwise it would
be fraud.
This is Anders' nightmare. To get all the components in place requires
significant cooperation from all these parties. But most all of these
parties have no clue what he is talking about. They literally do not
understand, so agreement is impossible.
So we're stuck.
> 2. Cleartext/data transfer issue. Not all things that I sign can be
> displayed. I have signed .zip files with programs and documentation,
> source code repositories, iso files with backups, timestamp-protected
> business ideas etc. Signing PDF and word documents is I assume the most
> common thing in Estonia people do outside of web self-service portals
> which use digital signatures.
>
> First - you can't have universal visualization for all the things one
> would want to sign; second - if there is a 500 page PDF report, sized
> 38MB - you just can't download it for the purpose of signing to the
> client side. In those cases you use a specialized client side software
> to do your things. Web signing is used in e-banking (to sign
> transactions which "belong to" the bank anyway), document management
> systems to sign things in a workflow (the document "belongs to" the
> document management system) and so on. Basically in places where the
> website is *requesting* higher assurance from the client, rather than
> the client *offering* higher assurance to the website. You already have
> trusted your bank to keep your pennies, you already have trusted the
> document management system to deal with your documents - the trust
> relationship has already been established, you don't need an extra
> "trusted display". But it would be good to have it, in some cases.
Agreed.
>> Be aware that any proposed signature method that doesn't show the user
>> what he's signing will probably not be allowed.
> The "What you see is what you get" problem has been solved in Estonia so
> that the user must have a possibility to download the signed document
> after signing it, to verify the content of it. For those who object it
> with "but then it is too late, you already have sold your house" - the
> same laws that give the digital signature the same power as a
> handwritten one to allow such huge transactions, protect you from fraud
> and unlawful actions by 3rd parties. As signed documents in Estonia
> include a signed OCSP response, it is even easier with digital
> signatures than it is to overturn a deal done when drugged by your
> business partner - OCSP requests leave a track...
So, in effect, Estonia allows repudiation. Good.
>> So, a method to sign
>> a bare hash, without knowing where it came from is a non-starter.
>> A method to take data and hash it, and then sign that could be made to
>> work, but that's what crypto.signtext does.
> You know where it comes from - the site you are visiting! Once people
> are educated well enough to know that "PIN2 == handwritten signature"
> they know not to type it in when visiting a porn site. Of course there
> is a small % of people who sign anything they are asked to, but the
> number of Nigerian scam victims is shrinking...
>
> Access control like Google Gears does is sufficient - "Do you trust
> secure.yourbank.com to have access to your certificates and to perform
> digital signatures? Yes/No/Remember my choice".
Super! So they give users control over sites, on a site-by-site basis?
I think we're agreed this has to happen before client certs are in any
way usable.
(It won't be sufficient for digital signing, but it will help access.)
iang
Anders Rundgren
>> Actually, I haven't seen evidence of that, although you did claim that when
>> you imported the PKCS#12 file into the software token, that the missing CA
>> cert was then found present.
>It's not a good idea to place the CA certificate on the token because
>the trust bits may get confused. It's better to import the CA root into
>the software store.
I think it is Firefox that's confusing.
I'm glad that the payment networks got it right: You don't have to install
any intermediate CA certificates in the POS terminal in in order to perform
a payment with an EMV token.
I don't know what Firefox 3.5 does, but in MSIE you can authenticate with
an EE certificate, the path is built automatically using AIA CA issuers and
you don't have to trust the EE certificate either, that is for the RP to cater for.
Analogy: I can't verify that my VISA card is correct, it just looks ok.
Anders
Eddy Nigg
>
Sure, it's a bug. If the CA root is trusted in the "software security
device", its trust bits should not be overridden by the same CA
certificate on the token....but alas...
> I don't know what Firefox 3.5 does, but in MSIE you can authenticate with
> an EE certificate, the path is built automatically using AIA CA issuers and
> you don't have to trust the EE certificate either, that is for the RP to cater for.
>
I've been begging for this feature to be implement, to no avail...
Eddy Nigg
> I've been begging for this feature to be implement, to no avail...
>
s/implement/implemented/
As such it's amazing to hear the arguments against doing so, specially
when some 70% of the browser market does that successfully with no
drawback or breach of privacy whatsoever.
Nelson B Bolyard
weekend, but right now I just want to try to clarify a couple things.
>>> FYI, to make sense to users of eID cards currently one has to embed
>>> the word PIN into the token description as well, so that the prompt
>>> that Firefox displays would make sense: "Please enter password for:
>>> MARTIN PALJAK (PIN1)" GUI hints would be useful...
>>
>> Please elaborate.
>
> Firefox displays a "Please enter password for ..." dialog, which is
> ambiguous for casual users who need to be said very clearly when they
> need to enter the PIN of 4 or more digits.
The dialog says "Please enter password for <token name>". Is that
ambiguous? Does the user have multiple tokens with the same name?
Does the single token support multiple different passwords?
(And if so, how does changing the token name help the problem?)
> A similar problem exists on Safari/Mac OS X, where the unchangeable
> keychain GUI asks for "enter your password for keychain "yourcard""
> and people have been typing they login password over and over until
> the card gets locked... Even "enter your password for keychain
> "yourcard (PIN1)"" does not help - some people still try different
> passwords.
So, I gather the problem is really that people find that having more than
one password to remember is unmanageable. They cannot (or simply do not
make the effort to) distinguish which password is being requested, and so
they enter the wrong one, repeatedly, even though the prompt tells them
enough that they can successfully choose the right password, if they would
make the effort. Right?
This is a fundamental problem with passwords and people's memories, not
peculiar to Firefox (as you seem to acknowledge).
>> But it's certainly true that if Firefox will take a cert with an EKU
>> extension that does NOT include TLS client auth and use that for TLS
>> client auth, that's a bug, pure and simple. File a bug on it if you
>> have a working example.
>>
> Maybe it was bad wording from my side but I tried to explain that a
> few years back when the "non-repudiation" feature introduced the
> problem. I'll open a new one with a different approach one day.
NR is a KU, not an EKU, IIRC.
>> So, a method to sign a bare hash, without knowing where it came from is
>> a non-starter. A method to take data and hash it, and then sign that
>> could be made to work, but that's what crypto.signtext does.
>
> You know where it comes from - the site you are visiting!
Ha! If you have 3 browser windows open, each with 8 tabs, you typically
have NO IDEA which one of them wants the key. This is one of my big
gripes about FF. I'm constantly getting prompts for tokens and have
NO IDEA why I am being asked for it.
> Access control like Google Gears does is sufficient - "Do you trust
> secure.yourbank.com to have access to your certificates and to perform
> digital signatures? Yes/No/Remember my choice".
Yes, telling the user who wants it would help A LOT. Sadly, that's a
browser architecture matter of which the NSS team has no influence.
Nelson B Bolyard
> Some remarks.
>
> On 4/7/09 12:18, Martin Paljak wrote:
>
>> ambiguous for casual users who need to be said very clearly when they
>> Estonian but I also remember a phrase "master password" somewhere...
>
> Yes, I get this frequently with my one user who demands my support.
> When Firefox asks for a password, I always get called to answer what it
> is. It starts from the basics ("why,what,which,...") and continues
> through to hatred and loathing.
You provide customer support for Firefox?
> The worst one is the "software security device" or somesuch. My user
> does not want a "software security device." My user tells me loudly to
> make it go away.
Your user thinks that you control the behavior of Firefox?
> 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.
> The security messages (in english) are just completely useless before
> real life users. I have no doubt it gets worse in other languages :)
Well, you could develop a localization of Firefox. All those strings are
changeable in a localization. You know, we have EN-us and EN-gb and others.
How about EN-ig? :)
> Non-repudiation: should be deleted where ever seen.
Hear! Hear!
Martin Paljak
>>>> FYI, to make sense to users of eID cards currently one has to embed
>>>> the word PIN into the token description as well, so that the prompt
>>>> that Firefox displays would make sense: "Please enter password for:
>>>> MARTIN PALJAK (PIN1)" GUI hints would be useful...
>>>
>>> Please elaborate.
>>
>> ambiguous for casual users who need to be said very clearly when they
>> need to enter the PIN of 4 or more digits.
>
> ambiguous? Does the user have multiple tokens with the same name?
>
> Does the single token support multiple different passwords?
> (And if so, how does changing the token name help the problem?)
The problem is that an average users thinks like this: "password is
something like 'topsecret123', PIN code is something like '1234', I'm
asked for a password, let me see, which passwords I know that I might
type here..." More experienced people of course figure out what it is
and use the PIN code, but there are sill people who try to type
something that reminds a password to them when asked for it. "Please
enter your PIN for <token name>" is what should be used. I "fixed"
Firefox prompts by making the token name appear as "MARTIN PALJAK
(PIN1)", but the resulting "Please enter password for MARTIN PALJAK
(PIN1)" is still ambiguous with both password and PIN in one dialog.
Right. I might be wrong here but everything worked as expected (even
if it was not theoretically possible when looking at source code at
that time) with Firefox 1.0 series, maybe even 1.5. Most probably
because Estonian ID card has two certificates, one with non-
repudiation KU and one without it. Before the NR changes it worked
because NR certs were unusable for Firefox/NSS. Am I right ?
Anyway, I just tried with FF 3.5 and it happily used the attached
certificate for web authentication. It even suggested this as the
first choice. Got ssl_error_unsupported_cert_alert.
Anders Rundgren
>> Yes, telling the user who wants it would help A LOT. Sadly, that's a
>> browser architecture matter of which the NSS team has no influence.
Martin Paljak wrote:
>I think that approaching Firefox team from the NSS side AND from
>outside would give a better result than just outsiders requesting new
>features/changes.
It seems that we are stuck unless we can gather interest from
1. The Mozilla architecture team
2. Some external parties
Since #2 is difficult due to the political nature of standardization as well as the
fact that a lot of stuff is covered by NDAs and/or is written in languages that few
understand, a working effort must probably start with #1 to provide some ground
for future work.
I still advocate for creating a facility for invoking XML protocols because then
you get a foundation for things that do not really apply to "pages".
Yes, I know <keygen> is page-oriented but I don't see much point with that
if you need more than one step in a process which the majority of applicable
protocols actually do.
If you don't appreciate private efforts such as KeyGen2, you can take a
look on IETF's almost finished DSKKP and tell me how you would integrate
that in Firefox. I would like to see a system where KeyGen2 and DSKPP
can compete as well as the Estonian, Austrian and Scandinavian signature systems,
and then let the market decide if any of those schemes belong to the standard
browser distribution.
A requirement here is that the XML protocol extension must be Java + JavaScript-
based so that we get way from platform-dependent code. If not, the foundation will
be too crippled to function as a test-bed for innovation and proof-of-concept schemes.
Standardization is probably years away but that is something we can live with.
Some of the most important schemes including SSL were actually NOT created
by a committee to begin with.
Anders
Nelson B Bolyard
> The problem is that an average users thinks like this: "password is
> something like 'topsecret123', PIN code is something like '1234', I'm
> asked for a password, let me see, which passwords I know that I might
> type here..." More experienced people of course figure out what it is
> and use the PIN code, but there are sill people who try to type
> something that reminds a password to them when asked for it. "Please
> enter your PIN for <token name>" is what should be used. I "fixed"
> Firefox prompts by making the token name appear as "MARTIN PALJAK
> (PIN1)", but the resulting "Please enter password for MARTIN PALJAK
> (PIN1)" is still ambiguous with both password and PIN in one dialog.
I see. Your token only accepts numeric PINS, not passwords. That's
curious. All the crypto tokens I have, or ever had, accepted passwords.
Dunno why it should matter. Bits are bits.
> Right. I might be wrong here but everything worked as expected (even
> if it was not theoretically possible when looking at source code at
> that time) with Firefox 1.0 series, maybe even 1.5. Most probably
> because Estonian ID card has two certificates, one with non-
> repudiation KU and one without it. Before the NR changes it worked
> because NR certs were unusable for Firefox/NSS. Am I right ?
>
> Anyway, I just tried with FF 3.5 and it happily used the attached
> certificate for web authentication. It even suggested this as the
> first choice. Got ssl_error_unsupported_cert_alert.
The problem with NR remains that different parts of the world have
different ideas on what are the legitimate/expected uses of NR certs,
but they are all sure that their idea is the obvious only-correct way.
In your corner of the world, using NR certs for client auth is unacceptable,
but elsewhere it is acceptable. No single policy can please everyone.
Maybe Firefox needs a "preference" so users can tell it whether to include
NR certs in lists of certs eligible for authentication use, and another
to allow NR certs to be used for email signing use.
> I think that approaching Firefox team from the NSS side AND from
> outside would give a better result than just outsiders requesting new
> features/changes.
The relationship between producers and consumers of software (e.g. NSS
and Firefox, respectively) is like two people with a rope. Consumers
pull when they want to. Producers can either be pulled along, or can
resist being pulled along, but it does no good to push on a rope.
Nelson B Bolyard
> On 07/04/2009 02:20 PM, Anders Rundgren:
>>> It's not a good idea to place the CA certificate on the token because
>> I think it is Firefox that's confusing.
>
> Sure, it's a bug. If the CA root is trusted in the "software security
> device", its trust bits should not be overridden by the same CA
> certificate on the token....but alas...
Is there a bug on file with a reproducible test case?
I'm not aware of any problem in that area.
The trust flags on certificates in the "software security device" token
apply to ALL identical copies of that certificate in any token(s) that
have it.
Eddy Nigg
>> Sure, it's a bug. If the CA root is trusted in the "software security
>> device", its trust bits should not be overridden by the same CA
>> certificate on the token....but alas...
>>
> Is there a bug on file with a reproducible test case?
>
Yup.... https://bugzilla.mozilla.org/show_bug.cgi?id=474729
> I'm not aware of any problem in that area.
>
> The trust flags on certificates in the "software security device" token
> apply to ALL identical copies of that certificate in any token(s) that
> have it.
>
Yes, that's what I thought as well....but I found out after banging my
head against Thunderbird for a while it's better to remove the CA
certificate from my smart card.
Ian G
> On 2009-07-04 04:19 PDT, Ian G wrote:
>> Some remarks.
>>
>> On 4/7/09 12:18, Martin Paljak wrote:
>>
>>> ambiguous for casual users who need to be said very clearly when they
>>> Estonian but I also remember a phrase "master password" somewhere...
>> Yes, I get this frequently with my one user who demands my support.
>> When Firefox asks for a password, I always get called to answer what it
>> is. It starts from the basics ("why,what,which,...") and continues
>> through to hatred and loathing.
>
> 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.
>> The worst one is the "software security device" or somesuch. My user
>> does not want a "software security device." My user tells me loudly to
>> make it go away.
>
> Your user thinks that you control the behavior of Firefox?
Yes. Doesn't every user?
>> 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.
>> The security messages (in english) are just completely useless before
>> real life users. I have no doubt it gets worse in other languages :)
>
> Well, you could develop a localization of Firefox. All those strings are
> changeable in a localization. You know, we have EN-us and EN-gb and others.
> How about EN-ig? :)
Don't say that too loud, someone will file a bug for EN-fem :)
>> Non-repudiation: should be deleted where ever seen.
>
> Hear! Hear!
Thanks! Is there anywhere where it is actually used in Firefox? If I
had my way ("if I was the benevolent dictator") it would be formal
policy within Mozilla to say that non-repudiation is not a valid flag
and is ignored at all times.
iang
Nelson Bolyard
> 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. :)
M.Hunstock
> BTW, we still don't have a credible system for *remote* provisioning of
> smart cards on any OS, so we shouldn't expect too much progress here
> because PKCS #11 can't do that job actually!
Why? What are you missing?
Anders Rundgren
http://webpki.org/papers/keygen2/secure-key-store.pdf
"even if you buy a $100 card; it still doesn�t enable an on-line
issuer to verify that keys were actually created in the card"
The idea is to be able to create so called "hard" certificates using "soft"
methods which has numerous application with mobile phones as the #1 target.
The SIM-vision has proven to be practically useless for reasons like ownership,
business model and limited space.
I recently upgraded the concept so that can be applied to enhanced smart cards
to easier reach critical mass.
So it is not PKCS #11 that is lacking stuff, it is the entire ecosystem from
protocols, middleware, to cryptographic containers.
This may look like a truly suicidal mission but I think it may turn out to
be easier to do something new than trying to "upgrade" stuff that was
conceived in another time and for another purpose! At least you don't
have to worry about backward compatibility[*] since there is none :-)
Anders
*] Key "execution" is unaffected, it is the rest that is "broken".
Martin Paljak
> On 2009-07-05 05:57 PDT, Martin Paljak wrote:
>
>> The problem is that an average users thinks like this: "password is
>> something like 'topsecret123', PIN code is something like '1234', I'm
>> asked for a password, let me see, which passwords I know that I might
>> type here..."
>
> I see. Your token only accepts numeric PINS, not passwords. That's
> curious. All the crypto tokens I have, or ever had, accepted
> passwords.
> Dunno why it should matter. Bits are bits.
It accepts ascii-numeric pins, but it is a PIN (with numbers) for
several reasons:
1. People know PIN codes and use them on ATMs => cards have PINs which
are made of numbers
2. I use pinpad readers for obvious reasons, which only have numbers
3. You are not married to your own computer, you might end up
somewhere else where the only option is to use a pinpad (like e-
service computers in local bank offices)
4. "Software legacy" - the same way it is sometimes hard to introduce
hardware cryptography to existing pieces of software, because it is
built following the "keys are in files which might need a password to
open". Same with "chip and pin" software - PIN is a numeric thing for
the masses, only in strange setups you can use something else..
>> Anyway, I just tried with FF 3.5 and it happily used the attached
>> certificate for web authentication. It even suggested this as the
>> first choice. Got ssl_error_unsupported_cert_alert.
>
> The problem with NR remains that different parts of the world have
> different ideas on what are the legitimate/expected uses of NR certs,
> but they are all sure that their idea is the obvious only-correct way.
> In your corner of the world, using NR certs for client auth is
> unacceptable,
> but elsewhere it is acceptable. No single policy can please everyone.
>
> Maybe Firefox needs a "preference" so users can tell it whether to
> include
> NR certs in lists of certs eligible for authentication use, and
> another
> to allow NR certs to be used for email signing use.
Right, that's why I've chosen workarounds and don't expect Firefox to
handle more than just the bare minimal it has to - one certificate for
SSL authentication. The "universal" token PKCS#11 module (which
exports everything on the card) just does not play well with all others
.
That is also the reason why things like signature plugins have been
and will be "the thing" - because it is almost impossible to get it
right, at lest now.
>
>> I think that approaching Firefox team from the NSS side AND from
>> outside would give a better result than just outsiders requesting new
>> features/changes.
>
> The relationship between producers and consumers of software (e.g. NSS
> and Firefox, respectively) is like two people with a rope. Consumers
> pull when they want to. Producers can either be pulled along, or can
> resist being pulled along, but it does no good to push on a rope.
> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
Anders Rundgren
<snip>
> It accepts ascii-numeric pins, but it is a PIN (with numbers) for
> several reasons:
> 1. People know PIN codes and use them on ATMs => cards have PINs which
> are made of numbers
> 2. I use pinpad readers for obvious reasons, which only have numbers
> 3. You are not married to your own computer, you might end up somewhere
> 4. "Software legacy" - the same way it is sometimes hard to introduce
> hardware cryptography to existing pieces of software, because it is
> built following the "keys are in files which might need a password to
> open". Same with "chip and pin" software - PIN is a numeric thing for
> the masses, only in strange setups you can use something else..
Absolutely! Here is another recent addition to the PKI GUI "trauma":
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certimage-00.txt
I have in KeyGen2 selected another method for certimage which is
defining cert-images as token attributes during the key provisioning phase
to be able to support device size adaptation (mobile phones) and higher
issuer freedom for image data (images are only local, never "published").
I also made passphrase format a token attribute to get away from
middleware-defined PIN dialogs of the kind used in Windows CSPs.
The IETF I-D may prove to be hard to get traction for as it only addresses
a single problem and ignores the middleware/application "PKI GUI ownership"
issues.
I'm trying to make a scheme that unifies PKI and Information Cards
GUI-wise because they can both easily fit the "card" metaphor which
I think is more useful than DN exploration since certificates were
never really meant for human interpretation unless geeks qualify as
humans :-)
This document hopefully shows how it is supposed to work:
http://webpki.org/papers/web/multiple-credentials-in-the-enterprise.pdf
Anders
Kyle Hamilton
they believe that a "PIN" is not a "password", and a "password" is not
a "passphrase". So they think "I have to type my password to get
access to this", not "the device is asking for my PIN to do what it's
been asked to do."
Users aren't used to different parts of their computer system asking
for different passwords/passphrases/etc -- anything that comes up on
the screen was generated by the main computer. They understand that
one computer does not necessarily use the same password as any other
one, and they might even understand they should have different
passwords whereever they can. But they're not used to their computer
not being able to access different parts of itself.
Maybe a change in how things are worded would be useful...
[[The keystore which contains the certificate "yourcertificate" needs
to verify that you are authorized to use it. This is typically done
by entering the PIN or password that you used to secure it.
The device "devicename" requires that you enter your authentication
code in order to use the certificate "yourcertificate" to "SSL
authenticate to (host)|sign this email|whatever it needs access for".
If you wish to perform this action, enter your authentication code.
If you do not wish to perform this action, press cancel.]]
This one adds another term to the mix: "authentication code". It also
suggests features that are not present (the ability to separate the
use of an unlocked token into different types of usage, instead of
simply unlocking the use of it for any type of usage). I'm not all
that happy with it -- any better suggestions?
-Kyle H
On Sat, Jul 4, 2009 at 2:11 PM, Nelson B Bolyard<nel...@bolyard.me> wrote:
> Martin, I want to read your full message and respond fully later this
> weekend, but right now I just want to try to clarify a couple things.
>
>>>> FYI, to make sense to users of eID cards currently one has to embed
>>>> the word PIN into the token description as well, so that the prompt
>>>> that Firefox displays would make sense: "Please enter password for:
>>>> MARTIN PALJAK (PIN1)" GUI hints would be useful...
>>>
>>> Please elaborate.
>>
>> Firefox displays a "Please enter password for ..." dialog, which is
>> ambiguous for casual users who need to be said very clearly when they
>> need to enter the PIN of 4 or more digits.
>
> The dialog says "Please enter password for <token name>". Is that
> ambiguous? Does the user have multiple tokens with the same name?
>
> Does the single token support multiple different passwords?
> (And if so, how does changing the token name help the problem?)
>
Julien R Pierre - Sun Microsystems
Martin Paljak wrote:
> This is because currently tokens are used for low level internet pipe
> things in the form of SSL/TSL. It is impossible to bring those network
> level events to the UI level, and it would not make much sense either.
NSS allows the password prompting callback to be customized - which is
why you get UI prompts for it. And the application that makes NSS SSL
calls is also able to pass any information it wants to this callback, in
the form of a void* pointer. It is purely a matter of Firefox not
bothering to include this information.
Ian G
> 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.
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