Subject: RE: Current signature formats insufficient

From: Thierry Van Doninck <[email-masked]>
Date: 11 Jul 2000 15:57:44 +0200

Hi,

Another example of a non-binding signature : the signature could just be used to assure the integrety of a message.

Thierry

denis.bider%globera.com@Internet
11/07/2000 15:34
To:	frankb%valicert.com@Internet, ietf-pkix%imc.org@Internet
cc:	 (bcc: Thierry Van Doninck/GKBCCB)

Subject:	RE: Current signature formats insufficient

Hello Frank,

in the context of my original message, a "non-binding signature" would be a
signature for the purposes of, say, authentication.

Suppose you are connecting to a secure website - say, an e-banking
application - that requires private key authentication. For the purposes of
authentication, your equipment will have to sign a challenge that is sent to
you from the server. Now, since this signing process is intended only for
authentication, you want the resulting signature to reflect this fact. You
don't want to find yourself in a situation where you signed something that
you thought was intended only for authentication, only to find later that it
was in fact the hash of a contract that you have never seen before.

To sum up: for the scope of this discussion, we could vaguely define that a
signature is "binding" if it can be used as a legal tool to force the signer
to do something or not to do something. Otherwise, a signature is
"non-binding".

Examples: if you sign a contract, that is a binding signature. If you sign a
purchase order, that is a binding signature. If you sign a cryptographic
challenge intended for authentication, that is a non-binding signature.

Regards,

denis

-----Original Message-----
From: Frank Balluffi [mailto:[email-masked]]
Sent: 11. julij 2000 14:49
To: [email-masked]'; [email-masked]
Subject: RE: Current signature formats insufficient

Denis,

You refer to non-binding signatures. Why would I bother signing something if
it were non-binding?

Frank

> -----Original Message-----
> From: denis bider [mailto:[email-masked]]
> Sent: Tuesday, July 11, 2000 4:42 AM
> To: [email-masked]
> Subject: Current signature formats insufficient
>
>
> Hello folks,
>
> we probably agree that smart cards, as well as a variety of
> other similar
> cryptographic tokens, are insecure. Their primary insecurity
> lies not within
> the tokens themselves, but rather in the way they are most
> commonly used.
> Most frequently, a cryptographic token is attached to a PC,
> and it does
> whatever cryptographic operation the PC tells it to do.
>
> This concept is obviously insecure, since:
>  - PCs are insecure. Every average hacker down the street can
> break into
> anyone's Windoze PC, and it is trivial to write an exploit
> that will capture
> a smart card's PIN, wait for the smart card to be inserted
> and then perform
> a signature operation.
>  - Even if the user is as security conscious as to use a
> secure PIN entry
> device, or a fingerprint scanner for that matter, it is still
> the PC that
> decides exactly what information the smart card is going to
> sign. It is
> again trivial to write an exploit that will make the smart card sign
> something that the owner did not mean to sign.
>
> With the advent of digital signature laws which make digital signing
> commonplace, it is time to remove these security holes before
> hackers and
> newspaper articles start popping up. (How would any of you smart card
> manufacturers like to see your company's name placed
> conveniently next to
> "FRAUD!!" in TIME Magazine?)
>
> The ultimate solution, of course, would be for everyone to
> have a secure
> device, containing the private key, with the following
> characteristics:
>  - In order to sign anything, the user must put their finger on the
> fingerprint scanner. (Or other biometrics...)
>  - In case the signature is binding (ie, contract as opposed to
> authentication), the user must check the contents being
> signed on the screen
> of the secure device.
>  - In case the signature is binding, the user must enter a signature
> passphrase (PIN) as well.
>
> Now, since users do not want to enter passphrases every time
> something needs
> to be signed, and since that would be dangerous in the first place
> (increased risk of passphrase exposure), there is a practical
> need for the
> secure device to be able to distinguish between a binding
> signature and a
> non-binding signature.
>
> In the case of a non-binding signature (eg, proof of
> identity), the behavior
> of the secure device could simply match the behavior of all the
> cryptographic tokens currently out there. Ie, the device
> would sign anything
> that it receives - most commonly a hash of something -
> provided that the
> user confirms the signature operation by putting their finger on the
> fingerpring scanner. However, in contrast to the cryptographic tokens
> currently being used, any such signature would be explicitly
> marked that it
> cannot be considered binding.
>
> In the case of a binding signature (eg, a contract), the
> secure device would
> insist on receiving the entire content that is being signed,
> formatted in a
> well-known and secure format, so that the content can be
> shown to the user
> before anything can be signed. The user would also need to
> authenticate
> themselves in a more secure manner before a binding signature
> is made; and
> when it is made, the signature would be explicitly marked
> that it CAN be
> considered binding.
>
> It is my opinion that the following efforts need to be made:
>  - The current signature formats need to be extended so as to include
> information about the extent to which the data being signed
> was verified by
> the signer - or simply whether the signature can be
> interpreted as binding
> or not.
>  - A format for binding content needs to be selected or
> defined. (RTF, ASCII
> text, anything?) - this is the format in which any binding
> content is sent
> to the secure device so that it can be shown to the user, who in turn
> decides whether to sign it or not.
>  - The current APIs for communication with cryptographic
> tokens need to be
> modified to support this. Eg, in PKCS#11, the following modes
> of signature
> could be introduced:
>         - sign this hash and mark the signature as non-binding
>         - here is the 34kB file containing the binding
> content to be signed,
> show it to the signer, sign it and mark it as binding
>         - here is a hash of the binding content to be signed,
> sign it and
> mark it as binding (deprecated, but must be included since it
> is not yet
> possible to transmit 34kB of data to every kind of
> cryptographic token)
>
> I feel that the above issues are important and that somebody
> needs to take
> them on. I cannot decide whether or not this workgroup should
> do it; but
> somebody has to. (Or else...)
>
> Comments are welcome. Also, does anyone have information whether these
> issues have been addressed by the xmldsig workgroup, or is
> their format as
> clueless as the ASN.1 signature format?
>
> Regards,
>
> denis bider
>
> //
> //  denis bider, [email-masked]
> // [alternative: [email-masked]]
> //  globera d.o.o., Ljubljana, Slovenia
>     http://www.globera.com
>     +386 1 510 7740
>
>
>

---

From: Frank Balluffi <[email-masked]>
Date: Tue, 11 Jul 2000 06:56:03 -0700

Denis,

By convention, many standards (e.g., protocols) represent a signature with a
SEQUENCE containing an AlgorithmIdentifier and a BIT STRING. If your use of
current signature formats refers to the above convention, I am not convinced
that the problem is with the signature format. Perhaps the problem is with
what you sign.

In the case of an authentication protocol, you could include an OBJECT
IDENTIFIER or string in the data to be signed to constrain the use of the
signature. For example:

AuthenticationInfo ::= SEQUENCE {
    disclaimer UTF8String,
    nonce      OCTET STRING
}

Another technique would be to use PKCS #7 authenticated attributes.

Could these be used to solve your problem?

I'm still a little confused about what problem you are trying to solve.

Frank

> Sent: Tuesday, July 11, 2000 9:37 AM
> To: 'Frank Balluffi'; [email-masked]

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 12 Jul 2000 05:28:21 (NZST)

Paul Koning <[email-masked]> writes:

>I don't understand the notion of a non-binding signature.  To put it
>differently, the purpose of a signature is to bind your identity to some
>assertion.  The only question is what that assertion is.

"I assert through the squiggle I have made on this page that I acknowledge that
without making the squiggle they won't give me a 'Visitor' badge and let me in
the door".

Peter.

---

From: Frank Balluffi <[email-masked]>
Date: Tue, 11 Jul 2000 10:21:19 -0700

Denis,

Good point!

I am not sure I would consider this a protocol problem. I think this goes
back to your original point (which I agree with) that computers used by
ordinary people do not boot securely and lack trusted paths to devices. My
guess is that over time computers used by ordinary people will gain these
features. But who knows?

Frank

> Sent: Tuesday, July 11, 2000 1:05 PM
> Cc: [email-masked]
> [Frank Balluffi in response to Ben Laurie:]
> > For the life of me, I can't imagine a protocol that would expect
> > a device or person to sign a message that only states "...".
> 
> Oh, but there is such a protocol and it is used every day by 
> thousands of
> people. It's called 'a smart card reader'.
> 
> "..." is exactly what a smart card sees when it performs a signature
> operation. Anyone who manages to break the security of the PC 
> (which is
> trivial) can tell the smart card to sign virtually anything.
> 
> This is why I think that we need a more elaborate signature 
> format - one
> which will take the real world, not the ideal world, into account.
> 
> denis
>

---

From: Adrian McCullagh <[email-masked]>
Date: Wed, 12 Jul 2000 06:16:47 +1000

Ben;

The law does not see it that way.  In the UK if you sign a document as
a receipt and there are terms on the receipt then you are deemed to
have read the terms and agreed to be bound by them.  (see the case of 
L'Strange v. Graucob).  The law will not take your subjective view
into account.  The law will look upon the action from an objective
view.  This is only a simplified version and yes there are exceptions
but the general rule is that if a man comes to your door with a
package and asks you to sign the acknowledgement of receipt you will
be bound by the terms on the back of the document.  The same position
also applies in the USA and in Australia.

- -----Original Message-----
From: Ben Laurie [mailto:[email-masked]]
Sent: Wednesday, July 12, 2000 1:04 AM
To: Frank Balluffi
Cc: [email-masked]'; [email-masked]
Subject: Re: Current signature formats insufficient

> You refer to non-binding signatures. Why would I bother signing
something if

When a man comes to the door with a package, I sign it because he asks
for a signature. I do not consider that signature to be binding in any
sense I understand the word.

Cheers,

Ben.

- --
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

From: Michael Zolotarev <[email-masked]>
Date: Wed, 12 Jul 2000 09:40:51 +1000

Denis,

It was a joke, really. Probably a bad one. In Australia we have a phrase
'give me a finger' - similar to what they do in Italy when driving around
like crazy and sticking a hand with one finger up from the car's window.

So I was reading through your message (it was over 10pm, I was still at
work, tired, etc) and I was imagining how you'd be dealing with that
wonder-box. A message on its screen like 'stick your finger', or something
like that.

I was just bitching, really.

Sorry for confusion and possible misunderstanding.

Best regards
Michael

> Sent: Tuesday, July 11, 2000 11:20 PM
> To: 'Michael Zolotarev'; [email-masked]
> Hello Michael,
> I'm not sure I understand you correctly.
> 
> To attempt an explanation: I used the 'fingerprint' example 
> because I like
> this particular technology, because I believe it to be more 
> practical than,
> say, a retina scan, and because it is my perception that it is readily
> accessible for widespread use.
> 
> I am not, however, involved with the production of any secure 
> device such as
> the one I described in the original message. There is no commercial
> background to my proposal - at least none that I am aware of 
> at this time.
> 
> Regards,
> 
> denis
> 
> 
> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: 11. julij 2000 13:39
> To: [email-masked]; [email-masked]
> Don't you find that there is a little bit too much of a 
> 'finger' stuff in
> there... What would be a name for the box?
> 
> :)
> 
> 
> > Sent: Tuesday, July 11, 2000 6:42 PM
> > To: [email-masked]

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 12 Jul 2000 10:52:37 -0700

>also applies in the USA and in Australia.

There are limits to the courts reliance on a purely objective view.
The courts tend to consider what must also be "reasonable."

If I were a pizza delivery person, and I'd crafted an ordinary-looking
receipt, whose fine print on the back reads "I hereby transfer title
to my house ...", I doubt that your signature on that receipt will
enable me to take your house from you.

Most of the "real" legal questions with digital signatures and our
new "cyber" environment will pivot upon the evolving problem of
deciding what are "reasonable expectations", given the technology
and other, less objective considerations.

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Michael Zolotarev <[email-masked]>
Date: Thu, 13 Jul 2000 13:53:25 +1000

> > So, what are we left with? Do I hear "Can we make a signature to
> communicate
> > extra attributes"?
> >
> > Yes, we can.
> 
> But should we ? I think signatures are fine the way they are.
> 
That's what I meant by saying 'we can'. I should've made myself clearer.

---

From: Michael Zolotarev <[email-masked]>
Date: Thu, 13 Jul 2000 14:45:09 +1000

Adrian,

God, do you guys ever come to understand Russian sense of humor?

I was just trying to show that introducing a special key usage bit is not
going to solve the problem. Which is, of course, to indicate whether a
signer agrees or not with the content of the message.

I was saying that you can do it only by having a statement (AGREE or DO NOT
AGREE) INSIDE the content, and signing that content with your key. Exactly
as you do it on the paper: "Solemnly agree:_______".

Following the 'key usage bit' approach you'd have to have two different keys
- one for 'agree with the content', and another for 'do not agree with
content'.

My 'agree with doubts' list was an [unsuccessful] attempt to demonstrate
what kind of absurd you can get into with using the key usage flags.

Best regards
Michael

PS Are you in Sydney, BTW?

> From: Adrian McCullagh [mailto:[email-masked]]
> Sent: Thursday, July 13, 2000 2:29 PM
> To: 'Simon McMahon'; Michael Zolotarev; Tony Bartoletti; P.J. Ponder
> Cc: Paul Koning; [email-masked]; [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael & Simon;
> 
> I do not agree with your position.
> 
> You either agree or you do not agree.  The positions are mutually
> exclusive.  The issue of qualification if put forward only complicates
> the situation.  If you want to qualify then you must in my opinion
> fall within the "do not agree" position.  
> 
> Why complicate the situation with:
> 
> > 1. Strongly agree
> > 2. Agree
> > 3. Agree with reservations
> > 4. Agree with a certain doubt
> 
> What is the difference between agree and strongly agree.  It does not
> add anything by qualifying the agreed position.  A certainly doubt
> that a Court would take notice of varying positions of agreement.  You
> either agree or do not agree.
> 
> 
> 
> From: Simon McMahon [mailto:[email-masked]]
> Sent: Thursday, July 13, 2000 2:09 PM
> To: Michael Zolotarev; Tony Bartoletti; P.J. Ponder
> Cc: Paul Koning; [email-masked]; [email-masked]
> Michael wrote :
> > Using a special key usage bit to specify your agreement is not very
> > practical. Why? You'd have to define the following set:
> >
> > 1. Strongly agree
> > 2. Agree
> > 3. Agree with reservations
> > 4. Agree with a certain doubt
> >
> 
> Thats right - the content contains all the details about what and how
> much
> committment is being made. The signature format is irrelevant accept
> that it
> has to be validatable.
> 
> Simon.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Edition 6.0.2
> 
> iQA/AwUBOWy4RZWt1NGjt4vzEQL3iQCg6potAez5JhLSDtdGF26UaeG2ziUAoOmy
> sdwXFWc2hVsvm4P00KfXJz21
> =H1pM
> -----END PGP SIGNATURE-----
>

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 13 Jul 2000 14:36:29 +1000

Adrian,

You appear to be agreeing with Michael, and I do, too.

The signature means "I signed this document (blob)". If I have to agree with
the contents of the document, the document (blob) should contain a place for
this.

Ron.
-----Original Message-----
From: Adrian McCullagh [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 14:29
To: 'Simon McMahon'; Michael Zolotarev; Tony Bartoletti; P.J. Ponder
Cc: Paul Koning; [email-masked]; [email-masked]
Subject: RE: Current signature formats insufficient

Michael & Simon;

Simon.

---

From: [email-masked]
Date: Thu, 13 Jul 2000 11:26:32 -0400

Qualification of a signature to say a) I saw this, but I am not
agreeing with it; b) I agree with this; c) I promise to do this (or other
similar qualifications) strikes me as a good use of PKCS #7 Authenticated
Attributes, CMS Signed Attributes or XML Signature Properties.  I thought
that Denis' original proposal was intended to allow a smart card itself to
incorporate some very simple assertions about signature conditions into the
signature.  If the smart card is restricted to a single format, it might be
able to place such an assertion into that format.  If it's like one of
today's smart cards, it's not very format aware which is why placing the
assertion into the signature itself was attractive.

          Tom Gindin

Michael Zolotarev <[email-masked]> on 07/13/2000 12:45:09 AM

To:   Adrian McCullagh <[email-masked]>, "'Simon
      McMahon'" <[email-masked]>, Michael Zolotarev
      <[email-masked]>, Tony Bartoletti <[email-masked]>, "P.J.
      Ponder" <[email-masked]>
cc:   Paul Koning <[email-masked]>, [email-masked],
      [email-masked]
Subject:  RE: Current signature formats insufficient

Adrian,

Following the 'key usage bit' approach you'd have to have two different
keys
- one for 'agree with the content', and another for 'do not agree with
content'.

Best regards
Michael

---

From: [email-masked]
Date: Thu, 13 Jul 2000 11:33:02 -0400

I think the witness is also usually witnessing the signer's identity,
that the signer is physically present and is not obviously being coerced.
In fact, he's a lot better at witnessing these things than that the signer
read the document in full, far less than that he understood it.  A
biometric device might be a valid witness to some of these things, but not
all, and the other devices involved are witnesses to much less.
     The smart card itself is witnessing only that certain procedures
involving it directly have (or have not) been carried out, and that it was
sent the data it is signing.

          Tom Gindin

"Simon McMahon" <[email-masked]> on 07/13/2000 02:26:48 AM

To:   "Adrian McCullagh" <[email-masked]>, "'Tony
      Bartoletti'" <[email-masked]>, "'Ben Laurie'" <[email-masked]>,
      "Frank Balluffi" <[email-masked]>
cc:   <[email-masked]>, <[email-masked]>
Subject:  Re: Current signature formats insufficient

Adrian,

> If you would like I have 2 academic papers that deal with the issues
raised
> here from a legal perspective.  Both papers have been published by
> universities but I am not sure whether they are on the internet.
>
I'm sure they will be tough reading but, yes, please post the URLs if they
exist or post binaries direct to me (I think mailing list policy is not to
post binary attachments).

I understand that a human withness to a digital signature is at a
disadvantage for the reason you stated, but couldn't the law recognise a
certified "device" operating under its normal operating conditions as a
witness to the affixation of a digital signature to some content ? It is
after all the device doing it. A human witness could still be involved but
would be witnessing something else, e.g. that the signer understood the
content.

German law obviously already recognises certified signing devices as
relevant to legally binding signatures.

It looks to me like the concept of a witness is overloaded because humans
are naturally pretty versatile. Breaking down what a witness does, or is,
might make it easier to digitize their functions. Maybe that is what your
paper's "verifier" is.

What happened to "Current signature formats insufficient" ? Better post me
those papers quick !

Thanks,

Simon McMahon

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 13 Jul 2000 11:14:54 -0700

At 03:03 PM 7/13/00 +1000, Adrian McCullagh wrote:

>The first paper provides an argument that the concept of witnessing is
>inappropriate for the electronic commerce environment.  A new position
>legally should be the concept of verifying.  At law a witness must have an
>uninterrupted view of the signer actually affixing the mark that will bind
>the signer to the contents of the document.  Now a witness can not actually
>see such an affixation in the digital environment.  All a witness can do is
>see the person pressing some keys.  The program could be doing anything.  So
>in my scenario the verifier will first verify that there does exist,
>attached to the document, a digital signature that has been affixed using
>the alleged signers private key.  Once verified the verifier will affix
>their digital signature that will clearly note the second signer as a
>verifier and not as the person who is to be bound by the contents of the
>document.  My paper expands this concept somewhat.

Not being a lawyer myself ...

In the paper tradition, I assume (based in part on the Almedio case
you described earlier) that the witness has at least some implied
obligation to reasonably ensure that the signer, beyond simply
affixing their signature, understands what is being signed.
(In the case you describe, is seemed plain that it should have
been obvious to the witnesses that the signers likely could not
understand the terms sufficiently.)

Does this quality of "witnessing" carry over into the digital realm?
(Another multiple-choice test protocol, perhaps? :)

____tony____

---

From: "Rich Ankney" <[email-masked]>
Date: Thu, 13 Jul 2000 15:24:38 -0400

I agree.  This is similar to the "commitment type" in the ETSI electronic
signature work, the "signature purpose" in ANSI X9.45 and ASTM
E-2084, and the "business purpose of assurance" in X12.

/ Rich

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Michael Zolotarev <[email-masked]>
Cc: Adrian McCullagh <[email-masked]>; 'Simon McMahon'
<[email-masked]>; Tony Bartoletti <[email-masked]>; P.J. Ponder
<[email-masked]>; Paul Koning <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, July 13, 2000 11:30 AM
Subject: RE: Current signature formats insufficient

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 14 Jul 2000 14:33:09 -0400 (EDT)

> From: "Simon McMahon" <[email-masked]>
> 
> I dont agree with either digital alternative for indicating the signers
> intention in a legally binding way, i.e. boosting or removing
> non-repudiation.

Agree!

> Firstly that the certificate's usage attributes should
> dictate anything about the private key since they may not both be stored on
> the same device and the association is not trivial to check,

I don't understand this. The association between private and public
keys is trivial to check, regardless of where the certificate is
stored.

If there is a device that generates keypairs and exports only the
public key for certification (i.e. no private key export), the CA could
certify public keys generated by such devices under physical control of
the CA or its agents.  The CA can then legitimately make a usage
statement that a particular private key may be or cannot be copied, and
such a statement is useful input into a non-repudiation process.
Even with cryptomodules of lesser assurance, a statement that the
private key has been copied or should not be copied is useful, though
to a lesser degree.

> or, secondly,
> that the signature format should indicate my intention when I signed. All of
> my intentions should be indicated in the content of what I signed.

Agree!

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 18 Jul 2000 08:59:49 -0600

I've been perhaps uncharacteristically quiet on this issue so far, having gone though these discussions many, many times in the past.  But let me offer some observations..

First, I believe that it is important to differentiate between "authentication" and a "signature".  

Although people could certainly quibble about wording (neither the technical nor the legal community have been exemplary with respect to clarity on these points), to my mind "authentication" has to do primarily with the origin of a _session_, i.e., a sequence of data interchanges.  The authentication might very well involve a digital signature technical mechanism during the session startup, e.g., during SSL, but it might also involve the typical user name and password.

The authentication may substantiate my right to do certain things, receive certain information, update my bank account, sell shares of stock, etc.  So the legal and/or financial consequences of my actions may be quite significant -- certainly hundreds of thousands and potentially millions of dollars. (If only my E-trade account were really worth that much!:-)

Whether or not an order transmitted over such an authenticated connection is legally binding or not is normally established by virtual of a pre-existing relationship, normally a contract, between the two participants.  Whether I deposit money in the bank, or stock in my brokerage account, or bales of cotton in a warehouse in Memphis; if the responsible institution and I agree to certain security procedures by which an order may be placed, then such an order would generally be viewed as legally binding, even though there might be nothing that would even approximate a "signature" per se on the transaction.

I can for example place a telephone call to my broker, identify myself by name, account number, PIN number, my current address, etc., and cause whatever assets I have in that account to be sold, and the money wired to a specific account, all with no written record at all -- certainly not at my end.  Could such a transaction be repudiated? Maybe, at least to the extent of filing a claim against the person who received the money if it was sent to a bogus account somewhere.  But could I undo the transaction, perhaps because I could get a better price today, vs. yesterday?  Highly unlikely.

(Am I rather uncomfortable with the notion of having my assets so exposed to possible manipulation?  You bet!  But that's beside the point.)

Now let's talk about a signature, which is of course another form of authentication.

The essential difference is that a signature is (more or less) bound to the transaction itself  -- not to the pipe over which the transaction flows.  We sign the document, not the envelope, in other words.

An authenticated session is essentially ephemeral -- the authentication only persists for the duration of the session.  Granted, the parties at either end might capture the contents of that session, and might try to match up the session authentication mechanism with the contents of the session itself, but such a match-up would fall into the category of business records.  They may be exempt from the hearsay rule, and thereby be admitted into evidence, but in and of themselves they do not provide the type of (more or less) incontrovertible evidence to a neutral third party that a signature does.

This, of course, is why the Statute of Frauds over the last several hundred years, at least in English-speaking countries, has required a signed contract for the transference of real property and certain other goods -- it doesn't depend on an ephemeral connection between an authenticated origin and the transaction itself, and the signed document is capable of being validated by an independent third party, without recourse to records maintained exclusively by the (alleged) parties to the transaction.

(Typically, such transactions are also required to be witnessed by an independent observer, and perhaps even notarized.  The function of that observer is to provide corroborative evidence that the signature is not a forgery, and presumably that the contract was a conscious, willing, and volitional act by the parties -- there was no coercion, the parties appeared to be "compos mentis," etc.)

Unfortunately, there are some gray areas that don't fit neatly into these two categories.  One example which comes up frequently is that of a receipt.  S/MIME V3, as part of the Enhanced Security Services, provides for the issuance of a receipt for certain types of e-mail by the e-mail agent itself, i.e., an automaton.

So here is a case where the user has delegated certain powers and responsibilities to an agent -- in this case a computer program.  This is not particularly unusual -- a spouse, roommate, or other person living at a particular address can also sign for the receipt of a package or document.  By itself, this signature does not prove that the person actually received or read the document that was received, much less agreed with it.  It does, however, provide the basis for a reasonable (rebuttable) presumption of delivery.  It may, therefore, be deemed to constitute effective legal notice to such an individual.  

(Exactly what constitutes legal notice will probably be hotly debated by consumer advocates, especially as a result of the new electronic signature law recently signed by President Clinton.  Since an electronic signature under that all too sweeping and badly drafted bill can apparently be the result of a simple mouse click or other procedural action, even one that is not under the informed control of the user, all sorts of things may end up being treated as legally binding signatures - it's probably too early to tell.)

But I would submit that an automatically generated digitally signed receipt, even if it makes use of the subscriber's private key and corresponding certificate, and even if the process by which the signature was generated took place with at least the user's approval, if not specific, conscious knowledge, is much closer to being a form of authentication than it is a transactional signature.

Although despite many, many rounds of argument we have so far failed to adequately define the semantics of what a (technically) nonrepudiable signature is, most of us would probably be capable of providing examples of what it is not -- e.g., an automatically generated receipt for something.

For that reason, I might not be unwilling to use for this purpose a private key that was held only in software, and which was unlocked when I started up my workstation, even if I was not physically in attendance at all times.  Such a e-mail receipt capability could be signed by my user agent without my having to enter a password or other unlocking mechanism every time the private key was needed.

But such a key and certificate should certainly NOT have the NR bit asserted in it, regardless of what the CA's policy says or doesn't say, unless I am a complete idiot.  Obviously, a key that is maintained in software and capable of being used without human intervention is also capable of being misused or compromised by rogue software such as a Trojan horse.

So far, I've tried to illustrate what does NOT constitute a technically norepudiable digital signature.  I would claim that this includes the following cases:

1.  Where the thing that is signed is an authentication challenge prior to the establishment of a session.  Although the information that flows over the pipe or session may very well have legal consequences and be binding in the sense that the transaction cannot be undone, the legally binding nature of the series of the transaction had little or nothing to do with the digitally signed authentication challenge.  The fact that a digital signature was used for authentication was neither necessary nor sufficient for the transactions (which were authenticate as having come from the originator, but were individually NOT signed per se) to be legally binding.

2.  Automatically generated signatures for such actions as acknowledgments or receipts may be binding in the sense of having constituted legal notice of delivery, but again the use of a digital signature mechanism may provide a heightened presumption of validity, but is not in itself either strictly necessary, nor always completely sufficient, even to prove delivery, any more than a human signature in such a case would necessarily be iron-clad evidence.

The criteria for what SHOULD constitute a technically nonrepudiable signature, and the semantic and technical constraints that should probably be imposed are much more difficult to state, and this note is already far too long, so I'll save that discussion for another time.

Bob