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
