Re: [dispatch] Work for IETF114

[Tim Bray <[e-mail]>]

On Wed, Jun 15, 2022 at 7:19 PM Martin Thomson <[e-mail]> wrote:

 I am not sure about use of key identifiers vs. keys.
>

D'oh, if you're going to send the URI over a secure channel you could just
put the key right there in the fragment (*cough* ed25519 *cough*). And
arguably you shouldn’t be doing this kind of thing without a secure
channel. After all, in Bron's scenario you're emulating the semantic of a
(presumably unencrypted) attached file.


> On Thu, Jun 16, 2022, at 12:09, Tim Bray wrote:
> > 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/
> >>
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>