RE: future SFTP version question

["denis bider" <ietf-ssh%denisbider.com@localhost>]

> > 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. 

I agree with Jason's assessment and disagree about this extension being "too
obscure and specialized". It is so simply because there is no simple way of
doing it. If we come up with an extension that provides a simple way of
doing it, I believe there will be plenty demand. I would implement it in our
server.

Someone needs to draft an extension though. That ought to be Jason because
he has background knowledge about the problem and can likely come up with
something that will be simple enough yet will work.

I propose this be done here because we've had at least 2 positive responses
(I don't recall if there were more) and just one negative. If this is an
optional extension, people who don't want to implement will not be impacted
by it, whether it's part of SFTP or a separate draft.

What does Joseph as the SFTP draft editor think about making this an
extension in the SFTP draft, one like MD5 hashes for instance? (which I
think were an excellent idea btw)

If this is too complex to be an extension in the same draft, I think Jason
can just go get xml2rfc or a similar utility and write up an Internet-Draft
for this - am I right? How would he submit it when he writes one?

denis