Re: [dispatch] Work for IETF114 message external bodies

[John Levine <[e-mail]>]

It appears that Bron Gondwana  <[e-mail]> said:
>Use case: user wants to store a file encrypted on a server, and provide a link such that their recipient can get the
>decrypted file, without the server ever seeing the plaintext content.
>
>Which basically means - the URL/URI that the sender provides to the recipient contains the key data to decrypt the content,

When this came up before we noted that the message/external-body MIME type defined in RFC 2017 gets us most of the way
there.  It currently lets you point at a URL, and it would be straightforward to add a few new headers along the lines of:

    Content-ID: <[e-mail]>
    Content-type: message/external-body; access-type=URL;
                  URL="http://www.foo.com/myconfession.mp4"

    Content-type: video/mp4
    Content-Transfer-Encoding: binary
    Content-Length: 1234567890
    Content-Hash: SHA1/22od022m2m3s00ll2lo23ou32
    Content-Encryption: AES-CBC
    Content-Key: swordfish

    THIS IS NOT REALLY THE BODY!

The length and hash let the client verify that the file hasn't changed, the encryption and key let the client
decode it.  The key is optional, if missing the user provides it if you don't trust the MTAs that forward the message.

The Content-ID is optional, so other parts of the message can refer to this part as cid:[e-mail] if you
want to put a link in an HTML part.  See RFC 2392.

A security issue is that if the key isn't in the message, whatever
malware checking you do has to be able to run at the point the user
provides the key so it'd be in the MUA rather than the delivery agent.

R's,
John