thanks Valdis.
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?
(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.
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.
Peter.