Subject: RE: Repudiability

From: [email-masked]
Date: Tue, 7 May 2002 10:33:11 +0100

> -----Original Message-----
> From: Andrew McNaughton [mailto:[email-masked]]
> Sent: 06 May 2002 16:55
> To: [email-masked]
> Subject: Repudiability
> 
> 
> 
> Suppose someone refutes that they have sent information to a Web site
> owner, how is the Web site owner to prove that the information was in
> fact received and that it was signed with a given key?
> 
> To do this, the Web site owner would presumably need to be 
> able to produce
> the still-encrypted post as sent by the user, but from a 
> quickish reading
> of the mod_ssl reference, I don't see any way to log this information.
> 
> Andrew McNaughton

Provided you know the time of the transaction, the web server logs will give
you details of the IP address all the web transactions are coming from. You
can find who owns this IP address via the Ripe (www.ripe.net), Arin
(www.arin.net) or Apnic (www.apnic.net) websites.

>From this you can find which ISP this address belongs to, and that ISP can
verify who was using that IP address at the time. How much assistance you
receive from each ISP will vary.

That may give you sufficient information to press a case against the person
who alleges they didn't access your website, but IANAL. 

I'm not sure what you mean about information being signed with a given key.
Do you mean a personal key like a digital signature, or do you mean the SSL
key?

- 
John Airey
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [email-masked] 

The teaching of evolution as a proven fact rather than a theory has done
more harm to scientific progress than anything else in history.

- 

NOTICE: The information contained in this email and any attachments is 
confidential and may be legally privileged. If you are not the 
intended recipient you are hereby notified that you must not use, 
disclose, distribute, copy, print or rely on this email's content. If 
you are not the intended recipient, please notify the sender 
immediately and then delete the email and any attachments from your 
system.

RNIB has made strenuous efforts to ensure that emails and any 
attachments generated by its staff are free from viruses. However, it 
cannot accept any responsibility for any viruses which are 
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk 

14th June 2002 is RNIB Look Loud Day - visit http://www.lookloud.org.uk to
find out all about it.

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Balázs Nagy <[email-masked]>
Date: Tue, 07 May 2002 07:58:21 -0600

> who alleges they didn't access your website, but IANAL. 

John, unfortunately IP hijacking is so trivial (see threads on bugtrack) that
this method will not work with reasonable certainty.

> Do you mean a personal key like a digital signature, or do you mean the SSL

The Andrew is right.  Repudiation or rather non-repudiation
can be achieved with public-private<->private public encryption.
Owen is right SSL/HTTPS doesn't support that in itself. Here is how
public-private auth/encoding should work:

Message = M
Transmitted = T
Public Key = pub
Private Key = priv
Transmision of Message M: M->T--transmit-->T->M
pub-priv enc works like T = enc(pub, M) <=> M = dec(priv, T)
                         T = enc(priv, M) <=> M = dec(pub, T)

Non repudiation: send T = enc(priv_sender, enc(pub_receiver, M))
                  receive M = dec(pub_sender, dec(priv_receiver, T))

Of course this is simplifed, but holds the principle.

With HTTPS, the only way to authenticate for sure the message
sender, is with the sender's cert (CLIENT CERT). If you log that
auth, then you know for sure who came to the site. For that, you
need to restrict that part of the site to auth with client certs.

The astute reader noticed that all this digital signature shebang
works only if solely the owner uses his cert.

Hope this helps.

Cheers,
	Balázs

-----------------------------------------------------
Balázs Nagy                           TheNewPush, LLC
Managing Partner                 tel. +1-303-523-5729
Research & Development           fax. +1-720-294-0933
=======>Internet Infrastructure and Presence Provider

---

From: Andrew McNaughton <[email-masked]>
Date: Wed, 8 May 2002 08:24:02 +1200 (NZST)

> > who alleges they didn't access your website, but IANAL.

Logs are easily faked, as are the contents of databases.  If you are a
party  to a dispute, then this data is far from hard evidence.

Currently the state of electronic transactions seems analogous to the
following way of conducting a paper transaction.

  You exchange signatures with your customer, diligently verify their
  authenticity, and then throw them away.  Then you send a form to your
  customer.  They fill in their information on a separate piece of paper
  (out of context) and send it back.  You copy that information to your
  database, and throw away what the customer sent you.

Seriously, if you were designing the system to avoid having any evidence
that the customer acted as you say they did, then you couldn't do much
better.

> this method will not work with reasonable certainty.

This is a separate problem, and assuming the private keys are in fact
private, not really an issue.

> need to restrict that part of the site to auth with client certs.

The client can prove to you that he is who he says he is, but it seems you
can't prove it to anyone else.

It seems that the reason why SSL can't provide this evidence is that the
private keys are only used to establish a symetric session key.  The
actual data exchanged in the transaction is not encrypted or signed with
the private key, so nothing of evidential value is transferred.  The only
thing you've got is the users' public key, evidence that they agreed to
use an arbitrary session key and some data encrypted with that session key
which you could have as easily encrypted yourself.

It seems we have a poor basis for a new economy given that we know how to
do these things properly.  I wonder how long it will be before a test case
arises.

Apart from the SSL stuff, we also need to be able to have the client sign
both the recieved form and the data they return as a single unit in order
to prove the context of their submission.

Andrew

---

From: "Aryeh Katz" <[email-masked]>
Date: Tue, 7 May 2002 16:42:49 -0400

> It seems we have a poor basis for a new economy given that we know how
> to do these things properly.  I wonder how long it will be before a
> test case arises.
> 
> Apart from the SSL stuff, we also need to be able to have the client
> sign both the recieved form and the data they return as a single unit
> in order to prove the context of their submission.

I don't know that we're that bad. Netscape communicator does have a Javascipt function called signText, which you could use of form submission (along with client 
certs). It's similarly possible to code an activex control for IE that would sign a form.
This is not to say that there couldn't be better repudiation in the ssl layer. Merely, that if you had to, you could conduct business in a reasonable fashion.

---
Aryeh Katz
VASCO 			
www.vasco.com

---

From: Andrew McNaughton <[email-masked]>
Date: Wed, 8 May 2002 09:30:22 +1200 (NZST)

On Tue, 7 May 2002, Aryeh Katz wrote:

> Date: Tue, 7 May 2002 16:42:49 -0400
> From: Aryeh Katz <[email-masked]>
> Reply-To: [email-masked]
> Subject: Re: Repudiability
>

Certainly people go ahead and conduct business.  What happens though if a
test case comes up with a ruling that insufficient evidence exists to
prove a given transaction happened as the vendor claimed?

If Javascript or Active X has access to the user's private key, then there
has been a serious breach of security.  If any organisation is signing
ActiveX controls which access the user's private key, then those
organisations signing authority should certainly not be trusted.

Andrew

---

From: Balázs Nagy <[email-masked]>
Date: Tue, 07 May 2002 15:42:23 -0600

> organisations signing authority should certainly not be trusted.

This is the whole beauty of the public-private key auth scheme.
You don't need to have the users private key to make sure that
the user signed the message.  In fact, the private key is useless
for that purpose.  Instead, you validate the signature with the
users public key, which is OK to have access to...

-- 
Cheers,
	Balázs