Re: [dispatch] Work for IETF114

[Tim Bray <[e-mail]>]

If someone convinced me that there was any actual appetite for such a thing
and it'd have a chance of being implemented, I'd help with an I-D.

On Wed, Jun 15, 2022 at 6:57 PM Mark Nottingham <[e-mail]> wrote:

> Tim's approach is the direction I'd encourage you to go in -- being able
> to reusing an existing scheme has a lot of merit.
>
> Cheers,
>
>
> > On 11 Jun 2022, at 2:06 am, Tim Bray <[e-mail]> wrote:
> >
> > You know, you wouldn't have to invent *that* much new. When you retrieve
> https://example.com/foo#bar, the "#bar" part isn't sent to the server,
> and the rules say it is interpreted with respect to the content-type of
> whatever you get.  It's called the Fragment Identifier (
> https://datatracker.ietf.org/doc/html/rfc3986#section-3.5) and normally
> used to identify a fragment within the resource representation, but let's
> ignore that.  So suppose you invent a new media type, say
> app/encrypted-file.  Then you invent a tiny little language to go in the
> fragment identifier. E.g.
> >
> > https://example.com/#KeyID=48954289574239
> >
> > or possibly even
> >
> > https://example.com/#KeyHost=tbray.org&KeyID=48954289574239
> >
> > When this thing is retrieved (without the #fragment) you get something
> with Content-type: app/encrypted-file
> >
> > Now, there'd need to be serious thinking about chain of trust.
> Obviously you'd require trust and encryption for the channel over which the
> URI-with-fragment is transmitted.  Then there's the matter of where the key
> comes from. In the second form, one assumes the key is in
> example.org//.well-known/something  and the receiver only really needs to
> decide to trust example.org.  The first form, where there's a
> pre-existing out-of-band arrangement about where to get keys from, is
> attractive.  I think you still need the KeyID thing.
> >
> > Wouldn't be that hard to implement.
> >
> >
> > On Fri, Jun 10, 2022 at 6:22 AM Bron Gondwana <[e-mail]>
> 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
> >   [e-mail]
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>