Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 6/7/09 08:42, Nelson Bolyard wrote: On 2009-07-05 16:03 PDT, Ian G wrote: On 4/7/09 23:19, Nelson B Bolyard wrote: You provide customer support for Firefox? Yup. Doesn't everyone who is a techie? I mean, I don't want to, but because I am a techie, people assume that I know Firefox back to front and can make it do circus tricks. I can't of course, but I can solve some problems. Well, I formerly provided it to immediate family members, but that has fallen way off. Right. It's not a big burden, just irregular bursts of trauma. The other big factor with which I've improved things dramatically is to insist on Mac only. Your user thinks that you control the behavior of Firefox? Yes. Doesn't every user? No, definitely not. I probably do have more effect on FF than most, but I make it very clear to all and sundry that my influence is very limited in scope. Oh. Logic :) I can't get through the message to her that the software security device is just some broken metaphor for her certificate, because she's convinced Firefox is telling her there is piece of hardware gone wrong, and she knows it hasn't. Yeah, I don't like that name either, but it's not under the NSS team's control. Oh, ok, I didn't know that. The main thing that I see there is that it is a hopeless sort of throw back to imperial times where smart card tokens were considered to be the ideals and software certs were considered to be compromises. Until that notion is debunked there is little hope in filing a bug. It's an artifact of an architectural choice made by the NSS team years ago. This is a great description. It should be in a FAQ somewhere. The NSS team played a major role in devising and promoting PKCS#11. The original motivation for that was to enable users of Netscape/Mozilla browsers and also Netscape/Sun/RedHat servers to be able to use third party crypto hardware with their NSS-based client and/or server software. Until then, each hardware maker had its own API, and applications that used a hardware vendor's API were pretty much locked into that vendor's hardware. Each HW vendor wanted NSS to adopt their API. All the NSS-based products (client and server) were multi-platform, and the NSS team desired that NSS-based products should be able to work with multiple-vendors' crypto hardware on each platform, so an open multi-vendor multi-platform (multi-OS) API was needed. To that end, the NSS team worked with the PKCS#11 working group (whose other members were mostly crypto hardware vendors), with the result that, today, PKCS#11 is the number 1 (maybe only) hardware vendor-neutral OS-neutral application-neutral crypto API. Initially, NSS could either use its own software crypto, or could use PKCS#11 crypto, and this meant that a LOT of code was full of if-then-else cases, e.g. if using-hardware then use PKCS#11 else use NSS's own internal software. We realized that NSS could be greatly simplified if we took NSS's own software crypto engines and cert and key storage and put all of that into a pure-software PKCS#11 library. Then NSS would always use PKCS#11 for all crypto operations, and for all cert and key storage. NSS migrated to that architecture. First, we made NSS use PKCS#11 for all crypto operations, but NSS still had two ways of doing cert and key storage. Then in NSS 3.4 (IIRC) we finally made NSS so that it only and exclusively used PKCS#11 for all crypto operations and all cert and key storage. In the PKCS#11 model, each vendor has a module (library) that interfaces to slots (logical connectors) into which tokens may be plugged. Tokens are any devices that are capable of crypto operations and/or storage of keys and/or certs. NSS's own crypto libraries and cert and key storage became a PKCS#11 module (library) implementing a number of pure software slots, each containing a pure-software token. NSS's PKCS#11 modules, slots and tokens behave just like any other PKCS#11 modules, slots and tokens, except that they use no special hardware. Again, the motivation for this was simplicity of software design, rather than any belief that hardware was somehow inherently more secure or ideal than software. Having a single API with a single way of doing any crypto operation or storage, regardless of whether or not it used hardware under the hood greatly simplified MUCH NSS software. It was elegant. No more hacks of doing things one way or a second way. Just one way to do each and every operation, whether there was hardware involved or not. There was no need to explain two separate alternative models, one that used hardware and one that used only software. Users would have a single model of how things worked, whether their certs and keys lived in a gizmo in their pocket or on their computer's hard disk. This was an obvious win for the developers, but it meant that we had to introduce users of NSS-based applications to the PKCS#11 concepts (e.g. modules, slots and tokens) and
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. Virtually all crypto hardware vendors have adopted it.
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
Users are never told that a PIN is a password is a passphrase. So, 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 Bolyardnel...@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?) 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). -- 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)
Martin, 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. -- 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 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?) 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. 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 would help
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 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. -- 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: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
As I have written one of those many plugins used in EU (used in 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
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
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. 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.
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
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?) 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. -- 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-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? 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! -- 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 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 -- 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 07/03/2009 08:15 AM, Anders Rundgren: 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. -- 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: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
Anders, I think you must take your ideas to a standards body 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 RD 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 Eddy Nigg wrote: On 07/03/2009 08:15 AM, Anders Rundgren: 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. -- 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 3/7/09 07:15, Anders Rundgren wrote: 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. 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? 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 -- 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 3/7/09 09:30, Martin Paljak wrote: ... 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. -- 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-03 00:30 PDT, Martin Paljak wrote: 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. -- 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-03 05:29 PDT, Ian G wrote: 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
