Subject: Re: future SFTP version question

From: Ben Laurie <[email-masked]>
Date: Mon, 01 Nov 2004 16:41:58 +0000

Peter Gutmann wrote:
> [email-masked] (=?iso-8859-1?q?Niels_M=F6ller?=) writes:
> 
> 
>>Then I think the first thing you have to do is to write up the requirements.
>>"Non-repudiation" is a very fuzzy concept to me, and I'll have a hard time
>>participating in discussion of details in a non-repudiation mechanism.
> 
> 
> It's a fuzzy concept to everyone, so much so that after 20-odd years of trying
> the X.509 guys gave up and renamed the nonRepudiation flag in certs to
> something that actually had a meaning.  Calling it a "delivery receipt" would
> be better, that's what S/MIME (which is the only major standard to
> specifically address this) calls it.  In fact you could probably lift a lot of
> the S/MIME stuff, since they've looked at it in some detail.

Its actually a concept with a perfectly well-defined meaning in law - 
which is, it is something that is _defined by law_ to be non-repudiable 
(i.e. you can deny it, but it doesn't get you anywhere). An example is 
the UK Customs and Excise electronic VAT returns - they are 
non-repudiable by statute.

If anyone cares, this whole debate caused me to write a paper about this 
(and other things) with a lawyer: http://www.apache-ssl.org/tech-legal.pdf

Section 2.7 deals with non-repudiation.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 02 Nov 2004 21:23:30 +1300

Ben Laurie <[email-masked]> writes:

>Its actually a concept with a perfectly well-defined meaning in law - which
>is, it is something that is _defined by law_ to be non-repudiable (i.e. you
>can deny it, but it doesn't get you anywhere). An example is the UK Customs
>and Excise electronic VAT returns - they are non-repudiable by statute.

Well, that's the problem, legal nonrepudiation is well-established and well-
defined, but technical nonrepudiation isn't.  The best advice I've seen (from
talking to lawyers) is (1) back everything up with paper documents and written
signatures and (2) pray you never become the test case.

Peter.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 02 Nov 2004 12:11:56 +0000

> signatures and (2) pray you never become the test case.

Technical nonrepudiation is just a stupid idea, which could be why 
no-one ever agrees about it.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 02 Nov 2004 09:02:34 -0500

> signatures and (2) pray you never become the test case.

I think I've seen enough on this thread.  

My take:

Reusing keys used for authentication and/or key management within SSH to
also sign the receipts seems like a bad idea.

Defining a receipt format is out of scope for this WG, in part because
it involves too many political and financial layer considerations.

A draft explaining how to carry someone else's receipt format as an
opaque bag of bits within ssh/sftp might potentially be in scope, if an
appropriate one which meets relevant layer-8 and layer-9 requirements
exists and can be referenced. 

						- Bill

(N. B. since it's been a while since I've seen those T-shirts for sale
at an IETF... I'm using the quasi-satirical IETF extension of the ISO
reference model to add layer 8 (financial) and layer 9 (political) on
top of layer 7 (application).