I see nothing that cannot be implemented using existing protocols as
building
blocks. ...
My point was to say that providing "non-repudiation of message receipt" is
rather tricky and that people use "receipt" carelessly in describing what they
offer as a service.
Hmm. Well, I disagree. The meaning of "non-repudiation of message receipt"
seems rather clear to me, and this is precisely the service that is provided by
a signed read receipt that either contains the received message or a digest of
it.
You, on the other hand, are throwing in the complication of wanting to
coordinate return of that receipt to the originator with the receiver
actually gaining access to the message. I see nothing in the phrase
"non-repudiation of message receipt" that implies the presence of such
extended services.
"Strong" receipt requires more than a receipt notification
mechanism, it requires active involvement of a third party or use of an
on-line
protocol.
I agree that "strong" is vague. I have no idea what a "strong" service is. A
better digest? Bigger RSA modulus. Timestamping by a trusted notary? All of
these are possibilites, as is the extended service you're trying to build.
I was not implying the use of any building blocks.
Well, since the entire point here is to provide building blocks, I'm not sure
what you're after.
I hope I've missed something here, but if I haven't I think this pretty much
blows B-CEM out of the water, as least as far as time-critical material and
material available from multiple sources are concerned. ...
What you missed was the existence of the trusted third party (TP) from whom B
can get E anytime.
It seems that you've completely missed my point. I understand about the third
party's role here. My point is that since you cannot prove that B ever got E
from the third party, you have not proved that the message was in fact received
by B. The third party can send the message to B once, twice, a million times.
It can be shouted in the streets, placed in TV ads, whatever. The third party
can publish E in every newspaper and on every email list. It doesn't matter.
All B has to do is deny that he ever got E and that his attempts to obtain E
from the third party were unsuccessful. You have no way of contradicting such a
claim within the protocol. You may be able to claim that its unreasonable to
assume that B never got E, by virtue of the third party never losing mail and
being 100% available during the relevant time and so on, but that's as far as
you can go. The protocol does not provide proof that B was ever in possession
of M as sent by A. It only provides proof of receipt of EM, which isn't the
same thing. And given this fact I don't think the receipt you do have for EM is
worth much.
Emboding third parties with higher powers doesn't seem reasonable to me. The
third party may be trusted by everyone involved, but they are not granted the
gift of universal and absolute communication. And if you take the scenario I
described to court I think you'll lose. And if this is the case it pretty much
ruins the scenario as far as commerce is concerned.
The underlying problem here is that there are two separate transactions going
on here, separated in both space and time. The use of trusted third parties or
incremental baby step protocols cannot change this fundamental fact -- there
are discrete events here that don't mix. The best you can do is confuse the
boundaries between the transactions to some extent, and that's what both of
your protocols end up doing.
Its possible that one of esoteric quantuum cryptographic approaches could be
used to solve this problem. If so, this would provide a real solution
since it would presumably turn the two transactions into a single event.
I haven't thought it through enough to be sure, but such things aren't
practical anyway, so its nothing but an academic question.
Ned