the fundamental issue is that there are infrastructures using the same public/private key pair to digital sign
1) random authentication data that signer never looks at and believe is of low value ... if they connect to anybody at all ... and are asked to digitally sign some random data for authentication purposes ... they do it.
2) contents that they supposedly have read, understood, and are indicating that they agree, approve and/or authorize.
i haven't seen any definition of data arriving at the relying party where the relying party has proof of whether it was case #1 or case #2. The closest was the non-repudiation bit in a certificate. however, the non-repudiation bit in a certificate was put in there at the time the certificate was manufactured and in no way applies to the environment and conditions under which the signature in question actually occurred.
there are definitions like non-repudiation services and/or the EU FINREAD definition ... which purports to specify the environment under which the "signatures" take place. Note however, while the EU FINREAD defines an environment where there is some indication that the signing party might have read and agreed to the contents of what is being signed .... there is nothing in the EU FINREAD specification that would provide proof to the relying party that a FINREAD terminal was actually used for any specific signing. Anything, like a flag ... not part of a signed message ... that might be appended to the transmission ... that makes claims about whether a FINREAD terminal was used or not ... could have originated from anywhere .... analogous to the example where a relying party might be able to substitute a certificate with the non-repudiation bit set .... in order to change the burden of proof from the relying party to the signing party (in a legal dispute ... more the mid-90s ... where non-repudiation flag in a certificate might have been thought to have some valid meaning (since the certificate wasn't covered by the signature .... anybody could claim any valid certificate was the certificate used for the transaction)
In any case, if a signing party has ever used their private key to sign random data that they haven't read ..... and they are ever expected to use the same private key in legal signing operations where they are presumed to have read, understood, and approve, agree, and/or authorize the contents .... and there is no proof provided (or included) as part of the signed message that the signing occurred in a specified (non-repudiation) environment ... then there is no way that a relying party can prove or disprove under what conditions a digital signing actually occurred.
misc. past post reference EU FINREAD:
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
