Okay, these two tasks are the last ones, before the signer component
would be ready for wider consumption. Before it's anywhere near sane to
allow user to sign documents that legally binds her, it would be good
idea to:
1) visualize the data about the be signed. We are assuming, of course,
that the data is human-readable text. (There are probably interesting
legal questions around data which is not human readable. For instance,
if I write a contract but never show it to user, and ask the user to
merely sign the contract's SHA-1 hash, would this bind the user to this
contract? Has anyone explored the implications of digital signatures
which bind the user this way?)
I wonder did the pkcs7 message specification talk anything about what
encoding the text to be signed should be stored in the certificate. The
most conservative choice is to just take the passed data in
wsxdatatosign as binary and not make any changes to it, but however for
interests of long-term data storage, an internationally more palatable
UTF-8 format would seem like more reasonable choice. The downside, of
course, is that this appears to corrupt binary data, should someone ask
user to sign such data.
I believe signing of binary data is wrong, so I wouldn't worry about
"trashing" the data presented in non-UTF8 encoding. The most binary data
that can be signed in this scheme are hexadecimal dumps of hashes.
Besides, I believe I've seen my share of corruption in the pkcs7
signatures computed by Setec and id2 personal. For instance, I believe
at least one version of setec translated every newline to sequence of
<br>\n, thus changing the data we asked the component to sign, by
believing it will eventually be dumped as-is on HTML form! It seems that
today, the only thing guaranteed to pass through the system unchanged as
binary is hexadecimal or base64 without newlines. But are signatures on
such documents worth anything?
Is it tenable to ask the user to sign things like xml documents (they
border on readability)? XML would be attractive in that specification
called XML security exists, which has many of the same elements as pkcs7
message. After all, XML is just text, and after canonizing, the SHA-1
hash could be computed of the text, and then the card could sign the
hash, and then the document would be manipulated and the computed hashes
and their corresponding signatures would be injected into the document
in accordance with the XML-security specification. I believe XML is much
more readable than PKCS7, and may well outlive it. With stylesheet, XML
could even be visualised, although the visualisation engine should be
carefully restricted to not be able to hide any data available to
computer. (Such as sections of contract which are invisible on the
user's screen due to browser bug that someone exploits but later makes
the claim that it occured by chance.)
2) defer form submit until user has had chance to review the data, and
press the button that submits the form.
As of currently, the behaviour of the signer component is asking the
user to lend unreasonable level of trust the signer component, because
the user has no chance at all to even make the decision to sign. Being
prompted for the PIN, he may not understand the significance of the
action of entering a couple of digits. This, combined with
nonrepudiation signature, is dangerous combination enough to make one
lose one's night's sleep worrying about it.
Additionally, there is a meta-point in that a maliculous web host might
make the "sign here" button sound less important, such as "please enter
PIN code to view the next page". Someone foolish enough is bound to do
just that. I think there are serious attack vectors against the entire
concept of web-based digital signatures. We should do all we can to make
cryptography on the web easy---but also very, very clear.
Unfortunately, I don't believe there exists a solution to the final
fundamental issue, which is that the user must trust the components on
insecure computers. If mafia takes control of your computer, it's no
brainer to for instance replace the signer component with one that
calculates two messages -- after user signs a phony message, the
component displays a "PIN invalid (2 tries left)" message, causing the
user to type the PIN again, on which time it would now sign the message
he intended originally to sign. The other message is sent to
mafia-controlled computers and would apparently legally bind the user
under the current Finnish law. I don't like this world. Can we take any
steps to repair it?
--
Antti
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
