Re: future SFTP version question

[jason bailey <jbailey%aol.net@localhost>]

Allow me to clarify some of my terminology.

When I first made the suggestion, I had in mind a possible change to the
protocol where a receipt would be returned upon successful completion of
a file transfer. Upon further thought and input I recognized that an
extension would be more then suitable.To be accurate that is no longer a
receipt, it would be a manifest. Proof of existence of a specific file
on a particular server at a particular time, with no regard to how it
got there.

Whether it is a manifest file or a receipt, both provide similar
functionality, which is an aspect of non-repudiation.

The mechanism that you describe is technically correct. However it is a
simplification of the issue and misses some of of the inherent problems.
Yes, you can write a server (utilizing any protocol) that will accept a
connection , receive a file, manifest the file and then return the
manifest. In fact my current solution for this is done over https to a
customized tomcat server.

So if I have a solution in place why am I bringing this up?

My answer relates in part to the last observation

> but I seriously doubt it's worth the
> effort; it seems too obscure and specialized.

Non-repudiation is a growing demand in the corporate world. It is
inextricably tied into secure file transfers. In a system which requires
non-repudiation, sftp fulfills all the necessary requirements ( key
handling, secure transmission, validation ) everything, except for the
digitally signed receipt/manifest. 

There are standards that implement the necessary non-repudiation. EbXML
and Rossetta are the two that come to my mind. However these are ugly,
bloated, protocols. Completely unsuitable to do something as simple and
as straight forward as moving a file from a to b.

The reason I am bringing this up is because from my point of view having
sftp adopt this as an extension would create a standard which would
result in quicker deployments, better integration with other companies,
happier customers, happier management, and costs savings that extend
into the 10's of millions of american dollars for my company alone.

I also see this as something that would be equally beneficial to the
third party companies I work with as it is to ours.

Is it obscure? Not from my perspective, nor the companies I work with.
Is it specialized? possibly.
Is it worth the effort. I really can't answer that from this groups
perspective.

I was surprised to realize that no one had brought this up before. I
don't have a problem if, at this time, the working group doesn't believe
that this is a suitable fit as an extension to the current protocol.
However I do believe it deserves more critical consideration.

-Jason


On Thu, 2004-10-28 at 03:22, Niels Möller wrote: 
> I agree this seems to be beyond what standard sftp is supposed to do.
> And I also don't see why sftp extensions are crucial for supporting
> the given use case. One could use plain sftp (or *any* file transfer
> mechanism, for that matter) and the following convention:
> 
>   * Client uploads the file "foo" into a particular directory or using some
>     particular naming scheme.
> 
>   * When upload is complete (sftp close), the server processes the
>     file using the signature mechanisms of its choice (pgp, s/mime,
>     whatever), and writes a receipt as a new file "foo.receipt".
> 
>   * The client downloads "foo.receipt". Everyone is happy.
> 
> Adding extensions to sftp to do this have the potential advantage of
> letting us standardize it, but I seriously doubt it's worth the
> effort; it seems too obscure and specialized.
> 
> Regards,
> /Niels