1) there ae a certain class of certified terminals with security modules, tamper evident, and are known to always present an accurate text of what is about to be signed ... and then asked the person if they agree with what was presented .... which they have to indicate by pressing some button (or set of buttons)
2) these are a certain class of certified hardware tokens which contain unique private keys.
3) the specific certified hardware terminals are able to verify what kind of hardware token they are dealing with and only work with the appropriate hardware token
4) the specific certified hardware tokens are able to verify what kind of terminal they are dealing with and only work with the appropriate hardware terminals.
5) relying party gets a signed message
6) the relying party can verify the digital signature with a specific public key known to be associated with a known hardware token
7) the known hardware token is known to be in the possession of a specific person .... which implies "something you have" authentication
8) the known hardware token is known to satisfy requirements #2 and #4
9) the corresponding terminals that the hardware token works with are known to satisfy requirements #1 and #4
10) given conditions 1-9, the relying party has some assurance that the token owner has actually read, understood, and agrees with the contents of the message.
In this scenario the relying party wouldn't need direct evidence included as part of the integrity of each message that the signing took place in an non-repudiation environment .... the infrastructure assurance as to the kind of terminals, tokens, and procedures provide such indirect evidence as part of the infrastructure operation (aka the chain of evidence/trust scenario .... having nothing at all to do with traditional third party certification authorities and their certificates).
This kind of scenario falls apart .... if the hardware token ever digitallly signs some contents that is not provided by a trusted terminal. In which case the chain of evidence/trust is lost as to whether the token owner has read, understood, and agrees, approves, and/or authorizes the contents of what is being signed.
Either you
1) have some proof that every use of the specific hardware token (and its corresponding unique private key) digital signing always meets the requirements laid out as to human reading, understanding and agreeing, approving and/or authorizes the contents of what is being signed ... and it can never be used in any other way
2) or that every use of the specific hardware token (and its corresponding unique private key) digital signing that is purported to meet the requirement for human reading, understanding and agreeing, approving and/or authorizes the contents of what is being signed .... carries in the integrity part of the message some indication/proof of the human reading, understanding and agreeing, approving and/or authorizes (and that indication can't be fraudulently fabricated if the hardware token was to ever be used in signing some message that doesn't involve reading/understanding/approval by the token owner).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
