multipart/signed
messages/externalbody,access-type=ftp,....
application/signature,....
can you expand it a bit for me?
I want to send an encrypted message to fred, and require that, during
decryption/mime processing, fred's conformant UA *must* perform a
message/external-body operation using the "client-authenticating x-ftps"
access
type, say.
are we saying the technology can do this?
It depends on what you mean by "must". If you mean that the user is forced to
follow the link, the answer is no, you cannot possibly force that. This is
simply impossible to do, no matter what we do. The best you could hope for
is an agent that forces resolution of the external body reference prior to
delivery of the message, but no such service actually exists, and I would
argue rather forcefully against ever creating such a service.
But I suspect this is one of those things like X.400's "guaranteed delivery" --
there is of course no possible way any service can guarantee that a message is
delivered -- what if some system the message must pass through is destroyed
after it accepts responsibility for the message and before it has a chance to
pass it on? But that's not what X.400 means when it says this -- it means that
a receipt is returned when the message is delivered, thus providing a
guarantee that a delivery event actually happened. (Note that this doesn't stop
people from inferring that X.400 has some magical capability to deliver things
that other mail systems do not have.)
The services we have at present can provide (P/NR means proof or
non-repudiation):
(1) P/NR that the message has not been tampered with in transit.
(multipart/signed over the entire message content).
(2) P/NR that the message, including its external reference, but NOT including
the fetch of the external-body, was delivered to the recipient
(multipart/signed around an Internet-standard DSN with full return of
content).
(3) P/NR that the content of the external reference was in fact what the
originator of the message intended it to be (content-md5 header
inside the external-body, which is in turn inside a multipart/signed).
(4) P/NR that the content referred to by the external reference was in fact
delivered to the user (appropriate use of a URL that provides appropriate
security services). (The specifics of the URLs capable of this are not
relevant in this context.)
Now, Peter's goal appears to be to merge (2) and (4) inseparably. My point is
that these are separate events that cannot be merged. You can get proof of each
one, but not at the same time. You can also have delivery of the message
without any retrieval of the external content or with many instances of that
retrieval (and there may be very valid reasons for wanting to retrieve it never
or more than once). You can also have retrieval without the message ever having
been delivered.
Now, if you want to correlate the two proofs you receive, there is nothing to
stop you from doing so. It should be easy to imbed some form of
message-specific material in the URL to facilitate such operations. But you'd
best be prepared to handle cases where proof of delivery is received w/o
proof of retrieval or with multiple proofs of retrieval, and vice versa.
(Im just carrying Ned's simple thought experiment further on.)
for x-ftps, some UAs and users will more naturally substitute https, where the
x-https parameter in the externalbody parameters might refer to the decrypted
URL https://www.x.com/hash.html. A secondary key will then be provided to fred
on the *visual* page (embedded in a gif image perhaps requiring human
intervention)
to decrypt the sensitive subordinate component of the message, once client
authentication succeeds, and the origin is equivalent to the intendedRecipient
of hash.
But non-repudiation of delivery will have been accomplished. If fred chooses
not
to followup the externalbody reference, then fred is denied cryptographic
access to the enclosed sensitive material (which may contain the sender
digital signature and identity)
If this is possible then, then protected email is going to be great fun. It
faciliates ordering properties and anonymity.
Indeed it does, just as long as you're willing to accept the separate
events as truly separate.
Have I got it right? Im planning for a world where ssl and mime-ua are
colocated
and available to millons of people. Some people think of netscape navigator 2
in these terms. Furthermore, the "encrypted mail" might infact be a Web page
delivered only to a user of a client-authenticating browser.
The only thing missing from all this at the present time is a standardized
delivery report that can be correlated with the original message. This work
is nearly done and the specifications for it should be out soon. Once this
happens we'll need to look into the issue of how a delivery report can
provide an unforgable link to the message it refers to without including
the message in its entirety in its content. This is strictly a means of
reducing overhead, but its quite important nevertheless. It isn't appropriate
to start messing with it before the delivery report work is complete though --
trying to tie things into a moving target usually ends up being a waste of
time.
Ned