Lower Standards increase lower standards. In this gap why not jump into the position that signature and name are not enough and that an email without a certificate authenticating the origin that correlates to the sender cannot be accepted by client email programs. Avalid email from a legal contractual standpoint must contain sig, name , and certificate. If they are not part of the email then they should not be acceptable to client software.

Jimbo, let me make you answer your own question: this is something that is relatively easily implemented within one's own sphere of competence, i.e. you can make your own email client accept only signed and certified stuff (or I can do it for you; that's beside the point). Now, the question is: ARE YOU READY TO TAKE THAT STEP? Obviously, you are not. For similar reasons, nobody else is.

PS: I do know a crypto-extremist, who only accepts email encrypted to him (but even he does not demand signature), but I suspect that he has another (IRL) personality along with an email address, which is far more permissive.

PS2: While most standards provide sufficient facilities for it, plausibly deniable correspondence, where the recipient is assured of the origin of the message but is not able to prove it to a third party is not implemented, much less used. I wonder why?

>> That might be bad news for all those suppliers of cryptophic signing
>> blah blah out there as all of their theories were expressly intended to
>> override any user intention in order to give recipient more
>> reliability.

Why do you say that? I've always conceived of digital signatures as being something performed by user intent.

What do you mean?

Hi Zooko,

S/MIME couples them to encryption - to get encryption to work you have to sign emails so as to distro your public key.

Smart card systems couple digsigs to other things like payments and authentication and so forth. In order to identify yourself or to authorise some action, you may find that you have "signed" when in fact all you were doing was getting access.

When you click on Yes over a web service, you may have authorised some action. But have you signed it? And does that change if you connected using a client-side certificate?

Marketing has conflated the use of the digital signature in protocols with the use of human signatures to the extent that it is generally unclear whether a human signature is implied or not in any particular system. The biggest problem was the so-called non-repudiability property that was talked about by many cryptographers, and believed by many marketeers.

So I think the key is that, while digital signatures are always coupled to user intent, the intent to do *what* is often ambiguous, or conflated. Your argument is that for them to be legal signatures, then the user must have intended them as signatures and nothing else. Makes sense!

Certainly the intent to do "X" is ambiguous, and the ruling does address that in that the signature has to clearly cover the document it desires to govern.

But I think I go a bit further than that. I say that digital signatures are not in and of themselves evidence of user intent.

For example, consider your client-side certificate again. If a trojan takes over your machine and uses the cert to sign some statement, it is fairly clear that a) there is a digital signature, and b) you did not sign anything.

Non-repudiation tried to overcome this gap - and failed, thankfully. ( As it turns out, in law there is *already* a sufficient legal theory that covers this case, the concept of non-rebuttability. If the digsig marketeers had aligned their claims to that, they might have succeeded. )

But the fact remains that a digital signature is simply evidence that a key did something. To establish that the user *intended to sign* still has to be done, and that is quite hard, and perhaps impossible, if you follow the PKI view.

(Hence, my Ricardian Contract -- linked below -- follows a completely different path of establishing intent by human processes not digital processes. Although, to be fair to history, when I invented it, I only had an intiutive idea as to what I was trying to do ....)

the issue is that does the existance of a digital signature demonstrate human intent ... i.e. that the person has read, understood, and aggrees, approves, and/or authorizes the content.

the issue raised when we were helping word smith the california state and federal electronic signature laws involved being able to demonstrate human intent.

infrastructures have used automatically applied digital signatures for demonstration of authentication and that the subject matter has not been modified. the automatic application of digital signature negates the human intent requirement.

it is possible to create an infrastructure where digital signatures are used for authentication and integrity ... aka out of the security PAIN acronym

P ... privacy (sometimes CAIN, confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

(NOTE there are also signaficant issues with any application of non-repudiation which has frequently also been severely misunderstood concept)

... in any case, an infrastructure can include digital signatures (for authentication and integrity) along with something totally different for the demonstration of intent.

A simple example is existing POS debit card terminals. The swiping of the card and the entry of the PIN are used for two-factor authentication ... from three factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have (the card)
* something you know (the PIN)
* something you are (typically some form of biometrics)

Neither the card swipe nor the PIN entry are taken as demonstration of human intent ... and therefor a human signature. The POS terminal separately asks for you to hit the "yes" (or agree, confirm, etc) button as indication of human intent (and therefor the equivalent of human signature).

In the mid-90s, the x9a10 financial standards working group was given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments for the x9.59 financial standard.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

So translating X9.59 to the debit card POS, take a chip card
that is digital signs a transaction at POS terminal. This demonstrates (single factor) "something you have" authentication and also provides "integrity" (as per definition of digital signature). Hitting the "yes" button is still required to establish human intent.

The chip can be (card) contact or contactless (or any other form factor) ... as per aads chip strawman (from 1998)
http://www.garlic.com/~lynn/aadsm2.htm#straw

A chip can be configured and certified to indicate whether a correct PIN has been entered as part of the signing. This would add a second authentication factor ("something you know"). Some of the current PIN operations are "shared secrets" ... in that the replying party has a copy of the secret to validate you know what you know. Chips can be configured for purely "non-shared secrets" ... where only the chip you own knows the secret ... but relying parties accept the certified operation of the chip as including correct PIN entry.
http://www.garlic.com/~lynn/subpubkey.html#secrets

As mentioned in some number of previous references ... the nominal purpose of multi-factor authentication is to have authentication mechanisms with different vulnerabilities. Nominal, a PIN is countermeasure to lost/stolen card and card is countermeasure to evesdropping the PIN.

For a little drift, there has been some issues over at least the past 10-15 years with the use of "static data" as indication of authentication for both "something you know" and "something you have". Compromised devices (pos terminal, atm machines, etc) are modified to record "static data" as part of normal operation. As part of normal operation of doing a transaction at such a device represents a common vulnerbility, all static data (magstripe, PIN, etc) can be recorded at the same time (negating the point of multi-factor authentication).

The issue for x9.59 is that digital signatures are "dynamic" data ... changing on every use. This is a countermeasure to replay attacks involving evesdropping/skimming of purely static data authentication (whether performed by extra swipes on a separate device purely designed for harvesting information, or a standard device that has been compromised)
http://www.garlic.com/~lynn/subpubkey.html#harvest

The unique private key (especially in a hardware token) is (unique) "something you have" authentication and the (dynamic) digital signature is countermeasure to any evesdropping/skimming (including countermeasure to evesdropping any "something you know" PIN). The PIN can still be used for two-factor authentication as a countermeasure to lost/stolen token.

The direct application of the x9.59 digital signature to the actual transaction is (also) countermeasure to (man in the middle) MITM-attacks.
http://www.garlic.com/~lynn/subpubkey.html#mitm

recently discussed
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin

For even further drift, there have been some recent news articles about contactless cards may be immune to skimming attacks because the transaction can be done w/o it ever leaving your person. This can be viewed as a countermeasure of extra swipes capturing static data for replay attacks
http://www.garlic.com/~lynn/aadsm22.htm#30 Creativity and security

but is not a countermeasure to valid devices used for standard transactions having been compromised (for skimming static data for replay attacks)
http://www.garlic.com/~lynn/aadsm22.htm#44 Creativity and security

another item similar to the one mentioned in the above:
http://www.morerfid.com/details.php?subdetail=Report&action=details&report_id=1578&display=RFID

the issue now isn't whether it leaves your possession but whether the authentication data is "static" (as in the case of magstripes) or "dynamic" (changing on every use, as can be the case in the use of digital signatures). Dynamic data is general countermeasure to skimming of static data for use in replay attacks.

addenda
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures

... sort of to futher complete the threat landscape.

Compromised and/or counterfeit devices (POS terminals, atm machines) have been used for skimming (authentication) "static data" for the purposes of "replay attacks".

The countermeasure is to have a least one authentication factor be "dynamic" (as a countermeasure to replay attacks).

There is possible threat with compromised/counterfeit devices against "dynamic data" implementations ... that is where the device performs multiple (valid) transactions with an authentication token (w/o the owner's knowledge) or performs the actual transaction for a different value than shown the user.

In the skimming scenario, the crooks want to leave the compromised/counterfeit device in place as long as possible, so that it potentially can provide information for replay attacks against tens of thousands of accounts; aka the actually attacks are done as far away from the compromised/counterfeit device to minimize its character being revealed (leave it in place to maximise its information gathering).

"dynamic data" authentication (like digital signatures) provide preventive to fraudulent "replay attack" transactions. turning off the account provides countermeasure to fraudulent "replay attack" transactions ... but frequently only after some fraud has occured.

A compromised/counterfeit device doing multiple (or incorrect value) transactions with a "dynamic data" hardware token (w/o the owner's knowledge) tends to quickly reveal itself ... which means that it is more likely to be discovered and eliminated (compared to the scenario with skimming compromised/counterfeit devices) ... and therefor much less fraud is likely (and the threat is much lower).

However, one of the x9.59 scenarios for countermeasure to multiple (or incorrect value) transaction fraud was a device and process totally under the owner's control ... like a wireless PDA or cellphone. This is one of the scenarios from the 1998 aads chip strawman
http://www.garlic.com/~lynn/aadsm2.htm#straw

where the possible form factors include PDA or cellphone device that is totally under the owner's control (as countermeasure to compromised/counterfeit device performing multiple or incorrect transactions). this, of course, is modulo virus/trojans compromising the PDA/cellphone and performing fraudulent transactions.

I read this as bad for automated nonrepudiation, but not bad for digitial signatures. If the course of conduct makes it clear that the message is signed to make it binding, that's a contract.

And I'd wait for the Court of Appeal before I got too excited anyway...

in the work on electronic signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

... it wasn't that digital signatures were useless ... digial signatures could provide both authentication and integrity. However for the demonstration of human signature ... something additional was required (proof of some process or other action, in addition to just the simple existance of a digital signature).

this is compareable to some of the more recent work supposedly in the area of non-repudiation (the term still has huge amount of confusion) where there are specific processes, which in some cases, are attempting to provide demonstration of intent.

the existance of the digital signature doesn't demonstrate intent (just provides authentication and possibly integrity), it is the existance of some set of other things that are used for demonstration of intent.

note, with regard to digital signature providing authentication and integrity ... mentioned in the earlier posts
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures. and signs deatch warrant for Digital Signatures

one of the issues mentioned with regard to attempts fixing the "yes card" vulnerabilities and other similar implementations which make use of digital signature on some challenge/response (random) data for authenticating the token (as countermeasure to "replay attacks") ... since the actual transaction isn't being signed ... it isn't providing any integrity for the actual transactions (as repeatedly pointed out as a characteristic of x9.59 financial standard); it purely is a token authentication play, providing nothing additional for integrity (just authentication). It also potentially leaves a big opening for mitm-attacks.
http://www.garlic.com/~lynn/subpubkey.html#mitm

misc. recent posts mentiong the "yes card" scenarios
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)

for a little more completeness on the digital signature threat landscape ... there is also a vulernability if digital signatures on challenge/response (random) data (as countermeasure to replay attacks) are intermixed with digital signatures on valid data ... where there is possible misunderstanding that such digital signature implies human intent aka read, understood and aggrees, approves, and/or authorizes (possibly because of semantic confusion with the two terms: "digital signature" and "human signature" both containing the word "signature").

this is where an attacker substitutes valid transaction for some random data in a challenge/response protocol.

past threads discussion the dual-use vulnerability in possible scenarios where digital signature is misconstrued as actually carrying any human intent properties
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
http://www.garlic.com/~lynn/aadsm20.htm#37 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
http://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?

I often wonder about dedicated what-you-see-is-what-you-sign hardware.
Would there be a market for such a device?
How about integration with cellphones and/or PDA's?

Lynn: If you configure a system so that a token is required to perform a digital signature (e.g. contains the private key), and that a PIN is requested every time the token performs a digital signature (e.g. unlocks the token for a single transaction) - is that sufficient to judge the intent of the user to sign the email? At first glance I would think so, but there is an interesting philosophical line between specific intent and rote practice.

Daniel: I've designed several systems that use a SED (secure entry/display) when insider fraud was of paramount concern. The devices in my systems were usually a programmable point-of-sale terminal (because my solutions were financial security based) - but I’ve seen a PDA with smartcard used the same way (the PDA software was locked down, but not as well controlled as the POS terminals). The system would use the SED first to authenticate the users (x factors), than display the requested action for approval, for the policy determined amount of users.

There are a number of interesting design aspects to this type of system – the POS terminal are almost always designed with less security than the host TRSM (here in the USA at least, cost is a major factor in POS terminal design). Also initially the POS terminals were pretty limited (limited crypto, slow RS232 communications, limited input and displays, etc.), although my last project used very capable devices (32-bit ARM CPU, 1/4 VGA touch screen, TCP/IP with TLS, etc.). It has been interesting how my design techniques (specifically the security relationship between the two TRSM devices) have changed over the year based on the respective device capabilities.

Surely paragraph 30 of the Judgement

"Before leaving this issue I ought to mention the Electronic Communications Act 2000.

[...]

It is noteworthy that the Law Commission's view in relation to this Directive is that no significant changes are necessary in relation to statutes that require signatures because whether those requirements have been satisfied can he tested in a functional way by asking whether the conduct of the would be signatory indicates an authenticating intention to a reasonable person. This approach is consistent with what I have said so far in this Judgment.

[...]"

*upholds* the

Electronic Communications Act 2000 PART II FACILITATION OF ELECTRONIC COMMERCE, DATA STORAGE, ETC.

http://www.opsi.gov.uk/acts/acts2000/20000007.htm#7

and so this Judgement does *NOT* actually "sign the death warrant for digital signatures" ?

The effect of the judgement is a bit subtle. It does not in and of itself sign any death warrant, because it does not address the digital signature as a legal / cryptographic construct. In hindsight I could have chosen a better analogy for the title, but it's close enough for reporting purposes.

What it does do however is affirm the meaning of signature as being a) technology neutral, b) human act and c) human intent. And it does so within the context of today's digital email media. The so-called cryptographic digital signature is not and cannot be a human act because the mathematics are too much for the human mind. So it must be an automated act with a coupling to a human act, and it must show intent.

Now, we know that such a coupling is very expensive. What Judge Pelling said was that there was no signature in the email, but if the the guy had put his name at the bottom, and changed the text to say he was signing, then that would have been good enough. For a signature.

So on the one hand we have the so-called cryptographic digital signature. On the other hand we have the user saying "this is signed by me, iang." What's the difference? Simple - the second one is much more economic. It is stunningly cheap to do, whereas the first one is devastatingly expensive in project terms.

This statement has dramatic economic ramifications - in saying that the court will treat a written name and context as sufficient signature, it has destroyed the economic rationale for digital signatures. It's killed them by turning off their fuel, as surely as if you turn off the blood supply or air supply for a comatosed patient.

trsm.mckay on April 18, 2006 06:30 PM wrote:
> Lynn: If you configure a system so that a token is
> required to perform a digital signature (e.g.
> contains the private key), and that a PIN is
> requested every time the token performs a digital
> signature (e.g. unlocks the token for a single
> transaction) - is that sufficient to judge the intent of
> the user to sign the email? At first glance I would think
> so, but there is an interesting philosophical line between
> specific intent and rote practice.

ref:
http://www.garlic.com/~lynn/subpubkey.html#signature

the issue isn't that the PIN is entered every time for the digital signature to imply human read, understood, agrees, approves, and/or authorizes ... the PIN has to be entered in response to a statement asking if the person agrees.

at POS terminal, the PIN entry and swiping the debit card is taken as two-factor authentication ... not human signature. the current pin-debit has the person entering the PIN and swiping the debit card on every transaction. from 3-factor authentication:
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

where the PIN entry represents "something you know" authentication and swiping the card represents "something you have" authentication (the current debit card PIN entry is equivalent to PIN entry with a digital signing hardware token and the current card swipe is equivalent to a hardware token doing a digital signature)

however, the part of the current POS terminal pin-debit transaction that represents read, understood, agrees, approves, and/or authorizes is NEITHER the PIN entry NOR card-swipe (the PIN entry and the card-swipe just represents two factor authentication).

the part of the current POS terminal pin-debit transaction that represents read, understood, agrees, approves, and/or authorizes (aka human intention or human signature) is when the terminal displays the transactions and asks the person to hit the yes/agree/enter button. Hitting that button is some explicit human operation that carries with it the sense of intent and having read, understood, agrees, approves, and/or authorizes.

In the current POS terminal pin-debit tranactions, neither the PIN entry NOR the card-swipe represents having read, understood, agrees, approves, and/or authorizes (i.e. doesn't represent human intention or human signature).

If the current POS terminal were to be redesigned for an X9.59 transaction
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x599

with a digital signing token that used a PIN ... and the terminal displayed the transactions and asked for the person to enter the PIN if they agreed ... then the entry of the PIN would be a demonstration of intent and having read, understood, agrees, approves, and/or authorizes.

If that PIN entry (in response to the message asking the person to enter the PIN as indication of agreement) and the digital signature was tied to the PIN entry ... then you have a chain of events that could imply having read, understood, agrees, approves, and/or authorizes (aka human intention and/or human signature).

The problem is with out that chain of events ... the PIN entry and digital signature is purely an indication of authentication and is not tied to any indication of having read, understood, agrees, approves and/or authorizes (or human intention and/or human signature)

It isn't that the digital signature can be demonstrated as part of PIN entry. The digital signature and the PIN entry by themselves are still simple pieces of multi-factor authentication and by themselves doesn't rise to the level of human signature.

It is some human action in response to something ... that rises to the level of intention and having read, understood, approves, agrees, and/or authorizes. The "PIN entry" as a human action in response to a message asking for "PIN entry" as indication of agreement then rises to the level of intention and having read, understood, approves, agrees, and/or authorizes.

previous posts in this thread:
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

aka, the PIN entry and the digital signature are purely multi-factor authentication.

re:
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/subpubkey.html#signature

however, if a certified environment can tie the digital signature to the PIN entry ... and the PIN entry to a human response/action asking for indication of agreement ... then that sequence of certified operations can be traced back to a specific human response asking for indication of agreement ... then you have a basis for tieing the existance of a digital signature back through a sequence of operations to some human response that can be taken as an indication of having read, understood, agrees, approves, and/or authorizes (i.e. human intent, human signature).

the digital signature as an indication of human intent ... has very little to do with the word "signature" appearing in the term "digital signature" and also in the term "human signature". the "digital signature" is purely an indication of some operation. if a particular "digital signature" can be shown to be the final operation in a sequence of certified opeations that originated with some human response/action in response to something ... then you can use that sequence of certified operations as an indication of read, understood, agrees, approves, and/or authorizes (human intent, human signature).

this is one of the justifications for the x9a10 financial standards working group to have allowed for an x9.59 transaction to having a pair of digital signatures.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

the initial digital signature is supposedly from an entity's hardware token that is part authenticating that entity.

the second digital signature is by the digital signing environment ... say something like a certified finread terminal
http://www.garlic.com/~lynn/subpubkey.html#finread

the second digital signature is authenticating that a certified digital signing environment was used for the first digital signature ... and that certain certified operations occured as part of the generation of the first digital signature. again ... the digital signatures themselves are not indications of human intent or human signatures.

the first digital signature is to authenticate the human (not directly indicate human intent)

the second digital signature is to authenticate the digital signing environment ... and for specific certificate digital signing environments there may also be certified sequence of operations that are required to occur that then may be taken as an indication of a human having read, understood, agrees, approves, and/or authorizes (human intent, human signature).

it isn't the digital signatures themselves that indicate the human intent.

the first digatal signature can be taken as authenticating a specific hardware token ... implying "something you have" authentication for a human. it is also possible that the speicific hardware token is certified to operate in a specific way (say the entry of the correct PIN or biometrics) as part of producing the digital signature. In that case, the first digital signature might be taken to imply both "something you have" authentication (the person has the token) and "somethin you know" authentication (the person has entered the correct PIN).

Then the second digital signature can be taken as authenticating a specific digital signing environment ... and that digial signing environment has a certified process that has a specific sequence of events. For a specific POS terminal environment, the certified sequence of events is that the terminal displays the transaction amount and asks the person to enter the (hardware token) PIN if they agree to the transaction.

It isn't the existance of either digital signature that directly establishes a human having read, understood, agrees, approves, and/or authorizes (human intent, human signature). It is that the digital signatures are taken as authenticating specific certified operations.

The first digital signature can be taken as implying two-factor authentication since there is a specific hardware token that is certified as having a unique private key and that the use of that private key to generate a digital signature is certified as requiring the correct PIN.

The second digital signature can be taken as implying a specific digital signing process because there is a specific POS terminal that is certified as having a unique private key and that the use of that private key to generate a digital signature is certified as only happening after a sequence of other events involving a hardware token and human actions.

This basically corresponds to the current direction of non-repudiation. The (stale, static) x.509 digital certificate non-repudiation bit has pretty much been totally depreciated. What is now being defined for non-repudiation are various kinds of "services" which are certified as executing a specific sequence of processes.

In that sense, the certified terminal operation discussed in this posting is a service that has a specific certified sequence of processes. furthermore, the terminal also digitally signs the operation as authenticating the service/processes associated with the hardware token digital signature.

again, there appears to have frequently been semantic confusion with the word "signature" appearing in both the term "digital signature" and the term "human signature". the term "digital signature" is purely a manifestation or representation of a specific certified sequence of operations.

in order to understand what a "digital signature" might represent ... you then have to understand the exact sequence of operations that can be certified as occuring leading up to the generation of the "digital signature"

so lets look at it from a slightly different perspecitve.

things end with the existance of a digital signature. the actual digital signature is representative of "something you have" authentication. it is the process of getting to the digital signature that correlates the creation of the digital signature with having read, understood, agrees, approves, and/or autherizes (human intent).

your suggestion was creating a certified process that can demonstrate that the generation of the digital signature was dependent on some human action (entering a PIN).

however, what was missing was being able to demonstrate any relationship between the human action entering of the PIN and having read, understood, agrees, approves, and/or autherizes (huamn intent).

so you need to show that

1) the human response was a result of having read, understood, agrees, approves, and/or authorizes (human intent)

2) the entering of the PIN was a specific a human response

3) the generation of the digital signature was the result of
entering the PIN

4) the existance of the digital signature was the result of the generation of the digital signature.

the previous postings describe a second digital signature by a digital signing environment ... that digital signing environment is certified as requiring steps 1-4 as part of having the existence of a specific digital signature in conjunction with some specific item that has been digitally signed.

ref:
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

the other way of looking at it is from a trust path analysis for assurance and integrity. imagine the existance of a digital signature is the trunk of a tree. there are possibly millions of root endings that can lead to having the existance of a digital signature as a result. I choose the root endings that specifically start with human intent and then demonstrate a trusted path from the start at "human intent" (at some set of root endings) until I arrive at the existance of a digital signature (at the turnk)

then i work the process from the reverse direction ... can I start with the existance of a specific digital signature and have proof that it only traces back to starting with "human intent" ... or is it possible I could have arrived at the existance of a specific digital signature by starting someplace that doesn't involve human intent at all.

this is somewhat how i came up with the dual-use vulnerability of using digital signatures for both plain authentication as well as demonstration of "human intent" (i.e. read, understood, agrees, approves, and/or authorizes). I show that you can establish a trusted path from human intent to digital signature existance.

I then show that common digital signature authentication mechanisms will pass some random data to the client for digital signing (as countermeasure to replay attack on authentication). The client signs the random data w/o looking at it. I now can demonstrate getting to the existance of a digital signature that didn't originate with human intent.

I can also start with some other set of root endings that has a unique private key in a specific hardware token and that hardware token is given to a specific individual. I then show a direct path to the same "digital signature" at the trunk.

Starting with the "something you have" authentication root ending, you arrive at the existance of the digital signature representing "something you have" authentication. I may also be able to get to the same digital signature from starting with "human intent" and show a directly connected, certified, trusted, sequence of operations also results in the existance of the same digital signature. However, w/o one the one set of sequence of events, it is impossible to assume "something you have" authentication. W/o the other sequence of events, it is not reasonable to assume "human intent".

So the dual-use attack is can any server pass some valid transaction or contract in the guise of random data and have it signed w/o "human intent" being involved.

So there has been a couple of different suggestions as countermeasure to digital signature dual-use vulnerability. One is that you can proove that for every instance where you have applied a digital signature that didn't involve human intent, you appended a disclamer to the random data first, stating this particular digital signature was to not imply human intent. One problem is prooving a negative is
difficult (showing that you have never generated a digital signature w/o first including the disclamer).

The other approach is having the digital signing environment also digitally sign the operation. The first digital signature by some "something you have" authentication is some certified mode of operation (that can be trusted by relying parties). The second digital signature attests to the certified sequence of operations that results in the existance of the first digital signature. This is sort of the certified EU finread terminal with the additional that the terminal also has to sign the same operation.

As I've commented before, some of this is possibly semantic confusion where the word "signature" occurs in totally different terms: "digital signature" and "human signature".

The other scenario may be akin to the comfort that many people get from digital certificates.

For centuries, credentials, certificates, diplomas, licenses, letters of credit, letters of introduction, etc ... have been used to represent some information and/or processes.

Digital certificates are the electronic equivalent to this physical objects that have existed for centuries (as representation of something). My long tirad is that with online connectivity it is no longer necessary to settle for digital signatures as a substitute representing something ... you can have direct, real-time access to the real thing.

A digital signature on something is also a representation of something. However, a digital signature represents "something you have" authentication ... it doesn't represent human intent (as in read, understood, agrees, approves, and/or authorizes). This confusion is somewhat similar to peoples' mistaken perception that the existance of the "non-repudiation" bit in digital certificate as representing "non-repudiation" (just because some set of words are used in naming something ... doesn't automatically convey any attributes normally associated with the individual words ... to the named thing).

some past posts mentioning digital signature dual-use vulnerability:
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
http://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance