Re: [dispatch] Work for IETF114 message external bodies

FWIW, this is a much more fully-developed version of the "let
the MUA deal with it and use message/external body" idea in the
note I sent a couple of hours ago.  I see some problems with the
details of what John suggests, but they are details that could
be sorted out rather easily.  Similarly Tim Bray's suggestion
(also within those couple of hours, is a (more complete)
variation on my "trick URL" approach.  The path I was headed
down might do a slightly better job of protecting the key
itself, especially against the unwary, but with emphasis on the
"might".  In both cases, the proverbial devil is in the details.

best,
   john

--On Friday, June 10, 2022 12:40 -0400 John Levine
<johnl@taugh.com> wrote:

> It appears that Bron Gondwana  <brong@fastmailteam.com> 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: <foo123@crudmail.com>
>     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:foo123@crudmail.com 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
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch