Ned,
Non-repudiation with proof-of-delivery can certainly be
handled without return of the entire content. Try
looking at any of the MSP specifications (available from NIST).
This was solved in the 1986 timeframe. It is but one reason
why MSP was chosen over 1988+ X.400 security.
John Lowry
From pem-dev-request(_at_)neptune(_dot_)tis(_dot_)com Sun Oct 1 15:17 EDT
1995
Date: Sun, 01 Oct 1995 11:55:17 -0700 (PDT)
From: Ned Freed <NED(_at_)innosoft(_dot_)com>
Subject: Re: Remote validation servers
To: Ned Freed <NED(_at_)innosoft(_dot_)com>
Cc: Peter Williams <peter(_at_)verisign(_dot_)com>,
"Donald E. Eastlake 3rd" <dee(_at_)cybercash(_dot_)com>,
pem-dev(_at_)TIS(_dot_)COM
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Yesterday I wrote:
(1) Non-repudiation of or proof of delivery. This is about to become
possible
on the Internet once work on delivery notifications is completed. (The
documents are finishing up in last call.)
Specifically, an agent can use a security multipart to sign a delivery
receipt. Since that receipt can include the message that was delivered,
it
makes both non-repudiation and proof of delivery services possible.
Now, while this mechanism will work once the basics are in place, its
really not acceptable for production use. Why? Because it requires that
the original message be returned in its entirety in the receipt. This
constitutes 100% overhead (much more if you use S/MIME) which I regard
as
intolerable. We need to define some extensions to the basic delivery
report format once its stable to allow for the return of just the
signature
on the original message. This will be easy to do given the nature of
the format for delivery reports.
After writing this I decided to review the X.400 specifications to see exactly
what they do or do not allow. And it turns out that as far as I can tell a
proof of delivery object always contains the full message content. There
appears to be no provision for just returning the signature information.
I find it hard to believe that the X.400 specifications would insist on the
overhead of returning the entire content for no reason. Therefore there must
be
something I've missed -- there must be some problem, probably security
related,
with only returning signature information. If so, I must confess I cannot see
what it is. Can someone else shed some light on this?
I note in passing that if there is good reason to insist on return of content,
then once the notifications work is done we'll have all the pieces in place to
provide proof of delivery and non-repudiation of delivery services on the
Internet. No additional work on this service would be required, nor would such
work even be useful if there's a problem with returning just the signature.
The only remaining work to be done would be defining a mechanism to provide a
proof of delivery *request* service. This is by no means required, but would
be
nice to have. Its also straightforward to implement.
Ned