Re: [dispatch] Work for IETF114

This "upload an encrypted thing and send the URI+key" design pattern is
ubiquitous in messaging, so it's not implausible to me that a common scheme
would get some use.  But it would be good to benefit from prior art here.
For example, this is the scheme that Webex messaging uses:

https://www.npmjs.com/package/node-scr

```
scr {
  "enc" : string,   ; Content Encryption Algorithm from [RFC7518]
  "key" : string,   ; base64url-encoded raw key value
  "iv"  : string,   ; base64url-encoded initialization vector
  "aad" : string,   ; Additional authenticated data (AAD)
  "loc" : ? uri,    ; Location of encrypted content
  "tag" : ? string  ; base64url-encoded authentication tag
}
```

Note that there are more fields there than the algorithm and key your URI
thing envisions.  AAD could be left blank, and the tag might be part of the
ciphertext (as called for in RFC 5116 but not universally implemented).  So
the main problematic thing is the IV.

There's probably some requirements work to be done here, for questions like
whether anything can be assumed about the structure of the content aside
from being a ciphertext for a given algorithm.  (If not, you could attach
the IV.)  If there's interest, a focused working group would probably be my
preferred path.

--Richard

On Fri, Jun 10, 2022 at 9:22 AM Bron Gondwana <brong@fastmailteam.com>
wrote:

> Yep, me again with something new that's bubbling up out of the "large
> files over email" problem.
>
> I'm not quite sure the shape of this, but I'd like some time to talk about
> something which might be a media type, might be a URI scheme, might be... I
> dunno.  I'm sure the group will have zillions of opinions about both what
> the work should be, and what it should look like.  I can give you the user
> experience and use-case that I want anyway.
>
> ...
>
> 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, encoded into the
> URI in such a way that it's not provided to the server.  There are pros and
> cons of different approaches, but ideally the operating system / browser /
> library transparently does the decryption as part of the fetching such that
> a piece of client software doesn't care if the data is stored in plaintext
> and transferred over HTTPS (or whatever), or stored encrypted on the server
> with zero knowledge - either way the client program / library gets the raw
> data plaintext and doesn't have to care what the sender intended.
>
> Obviously, this only works if the recipient supports it, so bootstrapping
> is going to be a pain.  But I haven't seen something like this existing,
> and it would be SOOOOOO much nicer to have this transparently able to be
> embedded in the URI and handled by lower levels rather than having to
> design and specify an optional encryption layer in the email large file
> handling stuff.
>
> ...
>
> I'll put together a better proposal in the next couple of weeks, but just
> requesting the agenda time now :)
>
> And I would LOVE it if someone already knows that such a thing exists and
> can point me to it instead of having to reinvent the wheel.
>
> Cheers,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>