Subject: Signing what you don't understand

From: "denis bider" <[email-masked]>
Date: Tue, 11 Jul 2000 19:46:10 +0200

The most important point of my previous message was buried under a pile of
other stuff, so I am repeating it here:

It is my proposal that a signature format is designed which will allow an
entity to say: "I signed this data, but I didn't understand what I signed.
You are free to use this signature as proof that I possess a certain private
key, but this is also the only purpose for which this signature can be
used."

Currently, I am not aware of a signature format that allows an entity to do
that. And because there is no such signature format, people are constantly
going ahead and signing data they don't understand anyway! Smart cards, as
currently used, are a perfect example of this behavior(*).

I am convinced that a signature format is needed that will allow an entity
to safely sign information that it does not understand. Otherwise, people
will continue to sign such information with a protocol that BINDS them to
what they have signed, regardless of the fact that they are not sure about
what they are signing.

(*): You may think you know what you're signing, but trust me, you don't. It
is preposterously easy to write a virus that will circumvent any smart
card's security without being noticed. I will do it for $25,000; a college
student next door will do it for free.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Jul 2000 09:48:56 -0400

Denis,

>key, but this is also the only purpose for which this signature can be

We have had an analogous debate on this list last year.  This is one 
motivation for the use of the non-repudiation bit in certificates, 
i.e., if this bit is NOT asserted, one can reasonably interpret the 
signature as not binding.  This does not require a change to the 
signing format, but rather appropriate use of key usage bits in 
certificates. As others have pointed out, the preferred way to 
represent the distinction between binding and non-binding signatures 
is via flags in certificates, e.g., key usage, cert policy, etc.

Steve