| 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 [EMAIL PROTECTED]