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. 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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
