Re: [dispatch] Work for IETF114

Tim Bray <> Fri, 10 June 2022 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BC67C1A7F1D for <>; Fri, 10 Jun 2022 09:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bBqkO2LMYqFi for <>; Fri, 10 Jun 2022 09:06:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 78ABEC175066 for <>; Fri, 10 Jun 2022 09:06:27 -0700 (PDT)
Received: by with SMTP id m20so54273975ejj.10 for <>; Fri, 10 Jun 2022 09:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KTd4cyhcLB/xEoohxSyMKNzsvcOsGb7kxipWGguI+l4=; b=vXSv8DLzU3oziS0qrwuO0MNPq56POOg1icXgnoTZz1Mxv3ujpjOtt1zyieOkxei1P2 QNcrGY2QUVheVz1CmyKnkz9042x2qiPl97G4hkkPHDjGEbLDVuhooQmgUSrtxgtOhCWO uomUpyrPvboSgjC4ziZSW7KXrZY0VcmzTcB0RAWkr2isFEvSKJu0Qd7Df6rELVHfO1YX O2gsIHhXETtGXQDlJu/Z1Qd5+4KgES9MIDS+sXFIpkjAn8enb6xxFubpxECbgo1G2w69 EWsMYM0nd+EVG/K8HgPPe9okAN9OvE402uwGr8pi9XWC+zWshKFJn9HO5GKmeuh4YK+4 z6Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KTd4cyhcLB/xEoohxSyMKNzsvcOsGb7kxipWGguI+l4=; b=nMF1dmtkm+JyDNXQAMaJBP+ZSGz9V03JudF9W86E8WXwh/fVEKPb4fQ6Erwf9TdBNl sM34DbQtXSEB1M4BbzeAxIkc1AUbbf+rI6dKWUpmnsruCwmQnsdoQMhDLp7avHdy4zid 871xWICJPX9Rek6dJcU529IXgrWClggG+IexhzI3t5d0J6pgXlUn/wyCb2QO8dLIFDQU vzLeDXOJVlyGpYQyTXG6zmfN2lf9sZezyzM80NphUs446mZzJcCagPi3jJ5Fwn7CQxdo 62vLFlBmoyYzzw0tBoXBgHHf5qJFQLU7pIpArqmZWuQjnzsuEarBoVS4P/8ka1DZG8I2 Rfsg==
X-Gm-Message-State: AOAM5327L107MG2epthttb9rBo5we0rVwkYgncEgXptmE6iIgeGl74az j/pNHYkGRr7xmWA2/6MfYpPiYWU7/l945vbpXHk8LvTVIN4jQNEG
X-Google-Smtp-Source: ABdhPJwSHKudyV6a8T0daEa38BJzIxhWg17QelfkVxybcPKKnoURaql+tia6M8pxjI6F217b+OxpD9iOr4EKdN4IEmA=
X-Received: by 2002:a17:907:1b1a:b0:703:a290:98f1 with SMTP id mp26-20020a1709071b1a00b00703a29098f1mr41422859ejc.418.1654877185695; Fri, 10 Jun 2022 09:06:25 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tim Bray <>
Date: Fri, 10 Jun 2022 09:06:14 -0700
Message-ID: <>
To: Bron Gondwana <>
Cc: DISPATCH list <>
Content-Type: multipart/alternative; boundary="000000000000ccfb5b05e11a1ee2"
Archived-At: <>
Subject: Re: [dispatch] Work for IETF114
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jun 2022 16:06:31 -0000

You know, you wouldn't have to invent *that* much new. When you retrieve, 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 ( 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.

or possibly even

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  and the receiver only really needs to
decide to trust  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 <>

> 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
> _______________________________________________
> dispatch mailing list