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 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".
--
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
