Subject: Re: Secure mailing list service using OpenPGP

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 05 Feb 1999 17:11:24 -0500

In <[email-masked]>, on 01/27/99 
   at 09:40 PM, Edwin Cremer <[email-masked]> said:

>I have the same problem :-(

>my solution is:
>the server check the signatur and decrypt the message.
>if both ok the server write a new footer with the output of the 
>signcheck and then sign and encrypt the new message. if you have a
>trusted server, the sigcheck is trust ;-) and the members of the list
>don't need all the key's of all other members. it work's fine with
>(nearly) all of pgp version.

Not a bad idea. :)

I have proposed something similar to this for corporate mail servers where
incoming signed mail is verified at the server and stamped before it is
forwarded to the end-users mailbox. This way the end user is relieved from
the work involved in obtaining & verifying keys for incoming mail (this
job would be off-loaded to the resident company crypto zar).

As an added step outbound messages can be auto-encrypted by the server
thus eliminating most of the public key management from the end user (the
end user doesn't even need PGP on his workstation execpt for signing &
decrypting).

I also have been using in my PGP E-Mail implemntaions of doing the PGP
processing as the messages are downloaded by the mail client (decryption &
sig verification) with the results being appended to the bottom of the
messages. Below is an example:

from 100.100.100.1 by whgiii (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id
RAA024.81; Fri, 5 Feb 1999 17:28:03 -0500 Message-Id:
<199902052228.RAA024.81@whgiii> From: "William H. Geiger III"
<[email-masked]> Date: Fri, 05 Feb 1999 17:27:30 -0500
Subject: sigh
X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1
X-Distribution: [email-masked]
To: [email-masked]
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.52 b52 
Status:   

sigh!!

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
- ---------------------------------------------------------------
 
Tag-O-Matic: Rumour: NT means Not Tested

--------------------------------------------------------------------
MR/2 PGP Decryption  5 Feb 1999 17:35:01
--------------------------------------------------------------------

Opening file "NUL" type text.
Message is encrypted.
Opening file "WHGIII\36BB7213" type text.
Opening file "NUL" type text.

--------------------------------------------------------------------
MR/2 PGP Signature Check  5 Feb 1999 17:35:01
--------------------------------------------------------------------

Opening file "NUL" type text.
Opening file "WHGIII\36BB7213" type binary.
Good signature made 1999-02-05 21:27 GMT by key:
  1024 bits, Key ID A035CA9B, Created 1998-01-23
   "William H. Geiger III <[email-masked]>"
   "William H. Geiger III <[email-masked]>"
Opening file "NUL" type text.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
---------------------------------------------------------------
 
Tag-O-Matic: I use OS/2 2.0 and I don't care who knows!

---

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 05 Feb 1999 17:11:24 -0500

Not a bad idea. :)

sigh!!

- -- 

 
 
Tag-O-Matic: Windows: The CP/M of the future!

---

From: "Black Unicorn" <[email-masked]>
Date: Fri, 5 Feb 1999 18:02:27 -0600

> >(nearly) all of pgp version.

Not a bad idea, maybe, if there were no requirement for non-repudiation by
the receiving party.  (And if there isn't, then what's the point of this
solution?)  Falling back on a solution which requires a trusted server which
is still operated by the party which may later wish to present self serving
evidence to support itself in a suit is just a mistake.

Take the example of a brokerage which needs to incontrovertibly prove a
client (or a client's key) ordered a given transaction.  How will the above
help?  Clearly, it won't.  The bottom line is that in the mad rush to
implement "one pass" functionality PGP dropped the ball by killing this very
important functionality.

An enterprise cannot now archive mail which can later be searched by keyword
in the message body and still be verifiable ex post with respect to origin
and message integrity.

Big mistake.

I wonder (doubt) if it will ever be fixed.

---

From: "Anthony E. Greene" <[email-masked]>
Date: Sat, 6 Feb 1999 03:34:42 +0100 (CET)

>in the message body and still be verifiable ex post with respect to origin

They could archive both the original message and the processed copy then
tie the two together using the SMTP Message-Id or a locally generated
substitute.

-- 
 Anthony E. Greene <[email-masked]>
 Homepage & PGP Key <http://www.pobox.com/~agreene/>

---

From: Carl Ellison <[email-masked]>
Date: Fri, 05 Feb 1999 20:20:10 -0800

-----BEGIN PGP SIGNED MESSAGE-----

At 06:02 PM 2/5/99 -0600, Black Unicorn wrote:
>solution?)  

Sorry, but you hit one of my buttons.

What do you (or does anyone else) mean by non-repudiation?

To me, it means that I can take you into a courtroom and prove, somehow, 
that you signed the digitally signed message I hold in the floppy in my hand.

That means that the mechanisms we have set up defeat all your attempts to 
defend yourself against that accusation.  That is, you are unable to 
repudiate the signature because of the mechanism we have established.

Tell me how I can prove otherwise when you claim:

1.	my private key was on my computer, but I didn't sign that message.  I 
never saw that message.  It is quite possible that someone else found my 
computer logged in while I was in the bathroom and signed that message with 
my computer.  Therefore, you need to track down and bring in that other person.

2.	I was at my computer when that message was allegedly signed, but I never 
saw it and never signed it.  I did try to sign some other message -- even 
put my thumb to the thumbprint reader to release the signing key -- but that 
signature attempt failed, so I had to do it again.  There could have been a 
virus on my machine that used my unlocking of the private key to sign the 
message in question.

etc.

	--------------------------------------------------

This is just the start of possible defenses.  After I made a list of them a 
little longer than this, I came to the simplifying conclusion that we should 
never use the term "non-repudiation" and should, in fact, strongly reprimand 
anyone who tries to.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://www.pobox.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

---

From: "Black Unicorn" <[email-masked]>
Date: Fri, 5 Feb 1999 22:54:43 -0600

> -----Original Message-----
> From: Carl Ellison [mailto:[email-masked]]
>

I avoided getting into picking one of the 20 kinds of non-repudiation
because non-repudiation is a process, not an event.

It's moot anyhow as I quite directly defined what I was looking for.
Specifically:

"Take the example of a brokerage which needs to incontrovertibly prove a
client (or a client's key) ordered a given transaction."

> that you signed the digitally signed message I hold in the floppy

To digress:

In your context that can't be proven even if you have witnesses to the act
and a tape recording.  (Witnesses are notoriously unreliable.  The tape was
out of context, or has been modified).

There are always arguments against certain facts.  If "truth" was really
accessible we wouldn't need the judicial process.  The point is to give one
enough evidence to be persuasive of the truth, not to establish it.

> my computer.  Therefore, you need to track down and bring in that

"But the agreement you signed with the brokerage waives the brokerage's
liability for transactions where your keys are used."

This is, in fact, being done today with e.g., passwords and faxes.
Historically this kind of risk allocation has been done with checks as well.
If the signature is actually forged and the bank still cashes the check,
they are liable.  If it is not forged (the client put it on a blank check
which was then lost) then the client eats it.  I think this is unacceptable.

This is impossible to do given the lack of functionality I have pointed out.

"But you seem to have failed to follow the brokerage's password policy,
which absolves the brokerage of liability."  (Like leaving your keys in the
car).

Can't even get to this point if you can't establish that the signature was
at least made from the client's key.

> virus on my machine that used my unlocking of the private key to sign the

"But the agreement you signed with the brokerage waives the brokerage's
liability for transactions where your keys are used."

> etc.

Yes, etc.

I concede that non-repudiation and its definition are issues but this is
more than a bit defeatist.  The excuse that "non-repudiation is too
non-defined for us to try and accommodate any functionality that approaches
it" is just silly.

I could apply this approach to encryption.  "Why bother to encrypt?  I have
no idea who's at the other end.  Anyone could be a man in the middle for my
friend.  They could sniff it with a Trojan horse on his computer.  They
could put a video camera in his ceiling and watch his screen, or his
keyboard."  This is effectively the approach you are taking.

My point is that the brokerage does not now have the tools to even provide
evidence of the signature in the first place, which- in fact- makes use of
the signature pointless as it provides not even the slightest advance in
non-repudiation.  Might as well just keep taking passwords or use
handwriting analysis.

If you want this software to be utilized in places where it counts, which is
of course why we are in this game, or should be, then you have to improve
the product/protocol, not try to explain why functionality that is
needed/useful doesn't exist.

>  - Carl

Mr. Geiger points out that this functionality, or lack thereof, is not a
consequence of the OpenPGP data structure itself.  Insofar as that is so
this discussion is probably out of place anyhow.

---

From: Carl Ellison <[email-masked]>
Date: Fri, 05 Feb 1999 22:53:25 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>liability for transactions where your keys are used."

That's perfectly valid.  It's the signer relinquishing his right to 
repudiate, because of a normal contract he signed with the verifier of the 
signature.  What's enforced in court is the normal contract, not some 
fiction about non-repudiation as a side effect of using digital signatures.

>non-defined for us to try and accommodate any functionality that approaches

I'm quite happy with the contract approach you outlined.  It's just the 
silly talk we occasionally hear about digital signatures giving 
non-repudiation -- or some certificate from a properly blessed CA giving 
non-repudiation that I contest.  There are laws (e.g., Utah) that deprive 
you of the right to repudiate if you get a certificate from some CA they 
bless -- which is enough reason, in my mind, never to get a certificate from 
such a CA.  It was, after all, the Reg E right to repudiate credit card bill 
line items that made electronic commerce thrive.

>keyboard."  This is effectively the approach you are taking.

In fact, I use that argument too.  There is no such thing as a man in the 
middle attack if I'm communicating with someone I don't know already.  If I 
have made contact with a stranger and some man in the middle is there, then 
I'm still communicating directly and privately with a stranger: the man in 
the middle.  I have no reason to prefer him over the other stranger, given
that I don't already have a relationship with either of them.  One might 
argue that the MITM is dishonest while the other bloke is honest, but I defy 
someone to create a protocol that tests for honesty.

>non-repudiation.  Might as well just keep taking passwords or use

Don't run down handwriting too much.  The handwritten signature is, after 
all, a biometric.

>needed/useful doesn't exist.

Of course.

>this discussion is probably out of place anyhow.

Probably.

 - Carl

---

From: "Anthony E. Greene" <[email-masked]>
Date: Sat, 6 Feb 1999 08:43:40 +0100 (CET)

>Tell me how I can prove otherwise when you claim:
[snip]

You arguments apply as well to pen/ink signatures. What you're overlooking
is that in this context 'non-repudiation' refers to legal proof, not
logical proof. The references to enforcing a contract in court clearly set
the context of the discussion.

Even though it's possible for someone to forge a handwritten signature, if
it looks enough like yours, and you don't have some independent evidence
that you did not make the signature, you will be legally bound by it.

We have not established the case law yet to support digital signatures.
But when we do, the examples you gave will not hold up in court any more
than making an *unsupported* claim that you're not responsible for the
use of your ATM card. If the only evidence you have that it wasn't you is
your own word, it won't be sufficient in court.