dual-use digital signature vulnerability

[Jerrold Leichter]

| the issue in the EU FINREAD scenario was that they needed a way to
| distinguish between (random) data that got signed ... that the key owner
| never read .... and the case were the key owner was actually signing to
| indicate agreement, approval, and/or authorization. They specified a
| FINREAD terminal which supposed met the requirements that the key owner had
| to have read and to some extent understood .... and approved as to the
| meaning of the contents of what was being signed.
|
| However, the FINREAD specification didn't define any mechanism that
| provided proof to the relying party that a FINREAD terminal was actually
| used as part of the signature process.
Fascinating.  They are trying to re-create the historical, mainly now lost,
role of a notary public.

Notary publics came into being at a time when many people were illiterate,
and only the wealthy had lawyers.  A notary public had two distinct roles:

	- To ensure that a person signing a notarized document actually
		understood what he was signing;
	- To witness that the signer - who might well sign with just an X -
		is the person whose name appears.

The first role is long lost.  Notary publics don't look at the material being
signed.  We lost our trust in a "public" official explaining contracts - the
assumption now is that everyone gets his own lawyer.  The second role
remained, even with universal literacy.  A notary public is supposed to check
for some form of "good ID" - or know the person involved, the traditional
means.

A traditional "notary public", in modern terms, would be a tamper-resistant
device which would take as inputs (a) a piece of text; (b) a means for
signing (e.g., a hardware token).  It would first present the actual text
that is being signed to the party attempting to do the signing, in some
unambiguous form (e.g., no invisible fonts - it would provide you with a
high degree of assurance that you had actually seen every bit of what you
were signing).  The signing party would indicate assent to what was in the
text.  The notary might, or might not - depending on the "means for signing" -
then authenticate the signer further.  The notary would then pass the text to
the "means for signing", and verify that what came back was the same text,
with an alleged signature attached in a form that could not modify the text.
(E.g., if the signature were an actually RSA signature of the text, it would
have to decrypt it using the signer's public key.  But if the signature were
a marked, separate signature on a hash, then there is no reason why the notary
has to be able to verify anything about the signature.)  Finally, the notary
would sign the signed message itself.

We tend not to look at protocols like this because we've become very
distrustful of any 3rd party.  But trusted 3rd parties have always been
central to most business transactions, and they can be very difficult to
replace effectively or efficiently.
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com