Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 2009-07-05 16:03 PDT, Ian G wrote: > On 4/7/09 23:19, Nelson B Bolyard wrote: >> You provide customer support for Firefox? > > Yup. Doesn't everyone who is a techie? I mean, I don't want to, but > because I am a techie, people assume that I know Firefox back to front > and can make it do circus tricks. I can't of course, but I can solve > some problems. Well, I formerly provided it to immediate family members, but that has fallen way off. >> Your user thinks that you control the behavior of Firefox? > > Yes. Doesn't every user? No, definitely not. I probably do have more effect on FF than most, but I make it very clear to all and sundry that my influence is very limited in scope. >>> I can't get through the message to her that the >>> "software security device" is just some broken metaphor for her >>> certificate, because she's convinced Firefox is telling her there is >>> piece of hardware gone wrong, and she knows it hasn't. >> >> Yeah, I don't like that name either, but it's not under the NSS team's >> control. > > Oh, ok, I didn't know that. The main thing that I see there is that it > is a hopeless sort of throw back to imperial times where smart card > tokens were considered to be the "ideals" and software certs were > considered to be "compromises". Until that notion is debunked there is > little hope in filing a bug. It's an artifact of an architectural choice made by the NSS team years ago. The NSS team played a major role in devising and promoting PKCS#11. The original motivation for that was to enable users of Netscape/Mozilla browsers and also Netscape/Sun/RedHat servers to be able to use third party crypto hardware with their NSS-based client and/or server software. Until then, each hardware maker had its own API, and applications that used a hardware vendor's API were pretty much locked into that vendor's hardware. Each HW vendor wanted NSS to adopt their API. All the NSS-based products (client and server) were multi-platform, and the NSS team desired that NSS-based products should be able to work with multiple-vendors' crypto hardware on each platform, so an open multi-vendor multi-platform (multi-OS) API was needed. To that end, the NSS team worked with the PKCS#11 working group (whose other members were mostly crypto hardware vendors), with the result that, today, PKCS#11 is the number 1 (maybe only) hardware vendor-neutral OS-neutral application-neutral crypto API. Initially, NSS could either use its own software crypto, or could use PKCS#11 crypto, and this meant that a LOT of code was full of if-then-else cases, e.g. if using-hardware then use PKCS#11 else use NSS's own internal software. We realized that NSS could be greatly simplified if we took NSS's own software crypto engines and cert and key storage and put all of that into a pure-software PKCS#11 library. Then NSS would always use PKCS#11 for all crypto operations, and for all cert and key storage. NSS migrated to that architecture. First, we made NSS use PKCS#11 for all crypto operations, but NSS still had two ways of doing cert and key storage. Then in NSS 3.4 (IIRC) we finally made NSS so that it only and exclusively used PKCS#11 for all crypto operations and all cert and key storage. In the PKCS#11 model, each vendor has a "module" (library) that interfaces to "slots" (logical connectors) into which "tokens" may be plugged. Tokens are any "devices" that are capable of crypto operations and/or storage of keys and/or certs. NSS's own crypto libraries and cert and key storage became a PKCS#11 "module" (library) implementing a number of pure software slots, each containing a pure-software token. NSS's PKCS#11 modules, slots and tokens behave just like any other PKCS#11 modules, slots and tokens, except that they use no special hardware. Again, the motivation for this was simplicity of software design, rather than any belief that hardware was somehow inherently more secure or ideal than software. Having a single API with a single way of doing any crypto operation or storage, regardless of whether or not it used hardware under the hood greatly simplified MUCH NSS software. It was elegant. No more "hacks" of doing things one way or a second way. Just one way to do each and every operation, whether there was hardware involved or not. There was no need to explain two separate alternative models, one that used hardware and one that used only software. Users would have a single model of how things worked, whether their certs and keys lived in a gizmo in their pocket or on their computer's hard disk. This was an obvious win for the developers, but it meant that we had to introduce users of NSS-based applications to the PKCS#11 concepts (e.g. modules, slots and tokens) and terminology. The server folks didn't object to this, and seemed to like a single unified model and its terminology. Sun Microsystems adopted that model and terminology for all its crypto software and hardware products. Vir
SSL module for nginx implemented using NSS
Hello, Does anybody know if there is an SSL/TLS module for nginx implemented using NSS? The module that ships with nginx uses OpenSSL. I didn't find anything on Google. Best Regards, Peter Djalaliev -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: W3C Terminates XHTML2)
Anders Rundgren wrote: There is also no natural home for these issues since Mozilla, Apple, Google and Microsoft haven't heard about such requirements which is due to the fact that two-factor-authentication on the US consumer market is close to zero. In fact, in the Information Card forum which I'm member of, the US participants always say that "people hate tokens"; completely ignoring that tokens are more or less a standard utility in the EU, be it mostly of the OTP kind. Anders What you need is a way to recognize the existing token cards already issued to people in the States. Every time I go to an ATM I put my token card into the machine and enter a PIN. So if you wish to identify individuals in the States, you have to connect to a credit card issue's network. Move that code from purchasing code and put it where you want to use it to identify individuals. You have to assume the possession of the card and knowing of the PIN, identifies the individual whose name is encoded on the card. I see this has been done in banking and commerce. So what problem are you trying to fix? Or am I misunderstanding what you mean by two-factor? -- Bill -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 4/7/09 23:19, Nelson B Bolyard wrote:
On 2009-07-04 04:19 PDT, Ian G wrote:
Some remarks.
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.
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problem reading certificate from hardware token
On 07/06/2009 01:44 AM, Nelson B Bolyard: 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 tokenbut 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 wellbut I found out after banging my head against Thunderbird for a while it's better to remove the CA certificate from my smart card. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problem reading certificate from hardware token
On 2009-07-04 04:31 PDT, Eddy Nigg wrote: > 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 tokenbut 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
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..." 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 " 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate fromhardware token)
>Nelson Bolyard wrote: >> 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 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: W3C Terminates XHTML2)
William L. Hartzell wrote: >I assume that you been following IETF RFC on the Crypto subject. They >just released a series of RFC on management of keys. I have not heard of this before unless you are talking about TAM, TAMP or KEYPROV. None of these efforts have any relevance for the subject in question since they do not address browsers. Browsers have IMHO been excluded from innovation in this space since Netscape Navigator 4.0 with one notable exception: Microsoft Information Cards. >As you know, keys >are used in all layers of the OSI ref. stack in some form of security >protocol. I think we should follow the IETF lead and implement those >concepts that fit within SASL or TSL or MINE, etc., The application >layer stuff as defined by IETF. I'm not sure what you are referring to here. >There is no point in trying to be universal, because that is impossible. This is an interesting subject. The problem is that "universal" means very different things to different people. One thing is for sure, browsers represent a truly universal application. My contribution to this universal application is a multi-issuer, universal method for distributing and managing cryptographic keys for end-users. I'm not aware of anything similar since standardization efforts for *consumers* doesn't work since there is no "paying customer" and associated software licenses. >Also note the Trusted Computing Platform work. I'm a former member of TCG and the stuff I'm working on is nothing but a soaped-up version of the TCG work although I have taken the liberty of separating key storage and platform integrity measurements because I feel that these are better run as separate projects. >At present, no operating system is FIPS140-2 level two >or better without some hardware support. Where do you wish to take >this? Note I am not a programmer, just a lurker. At present those >crypto USB keys are used in a Kerberos corporate environment to id is more likely to find Trusted Computing Modules on Corporate machines >where the decrypting key would be a local corporate key embedded in >TCM). Speaking of Kerberos, do you know if GSS-API in Mozilla has been >extended to support channel bindings, if supported in Ipsec? So you >say, where does this fit into WEB signing? You cannot sign web sites >without keys and some way to check them securely (that the management individuals, SASL with authentication of applications or users (roles >aspect), TSL with authentication of servers (running code, not >machines), and IPsec with authentication of hardware (machines). Ipsec >is outside Mozilla code responsibility (other than checking channel >bindings). Here you lost me. >So what is this WEB signing? And where does this fit in the >scheme of things? NOTE Oasis and IETF are working together on common >issues. Does HTML5 cover any of the issues you'd like to see covered? There are no "real" standardization efforts whatsoever that addresses the stuff that I and Martin Paljak have brought up on this list. There are plenty of national and proprietary schemes that tries to upgrade browsers to the level needed for on-line banking and e-government activities using client-side PKI. There is also no natural home for these issues since Mozilla, Apple, Google and Microsoft haven't heard about such requirements which is due to the fact that two-factor-authentication on the US consumer market is close to zero. In fact, in the Information Card forum which I'm member of, the US participants always say that "people hate tokens"; completely ignoring that tokens are more or less a standard utility in the EU, be it mostly of the OTP kind. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 05.07.2009, at 0:11, 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.
The dialog says "Please enter password for ". 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?)
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 " 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.
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.
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.
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.
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.
The trouble that comes from different server configurations
(SSLVerifyClient require/optional and resulting client behavior) is
already hard to explain to users ("why this cryptic
ssl_error_unsupported_cert_alert, what does it mean?").
Web signing on the other hand is an application level thing. You click
a button on a website that reads "click here to sign the document" and
you already expect what will happen: a popup appears asking for your
PIN code. Easy to comprehend. Whereas TCP connections and certificate
authentication by a browser is not easy to understand and it is
initiated by the browser not by the user.
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
