Re: General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)

--===============4816084494071879611==
Content-Type: multipart/alternative; boundary="f403045fc07cffb2a9055e11e651"

--f403045fc07cffb2a9055e11e651
Content-Type: text/plain; charset="UTF-8"

> ---------- Forwarded message ----------
> From: Bron Gondwana <[email protected]>
> To: [email protected]
> Cc:
> Bcc:
> Date: Wed, 15 Nov 2017 01:06:58 +1100
> Subject: Re: [imapext] General Request for Assignment (imap-keywords)
> (was: [JMAP] SMIME Attachments)
>
> On Tue, 14 Nov 2017, at 19:25, Arnt Gulbrandsen wrote:
>
> Hi,
>
> sorry about the late response. I suck at the moment.
>
> I don't understand the semantics here.
>
> If present, it means that someone has checked and found an encrypted
> attachment. And if absent, it means nothing. There may or may not be an
> encrypted attachment.
>
> So my question is, what advantage does this provide over checking the
> bodystructure?
>
>
> The usecase is that the entire message is encrypted as a single blob, but
> it contains an attachment.  The client wants to mark that so that other
> clients know it has an attachment.
>
> There are questions about that being a metadata leak that haven't been
> addressed.
>
> There are questions that Barry and I spoke about briefly on Saturday about
> pairing it with a $HasNoEncryptedAttachment or something so you can tell
> that it's been checked already, which led to a general discussion about
> paired keywords and what it means if they're both set and wouldn't it be
> nice if we had tristate keywords and what about per-message-annotations and
> doesn't everything suck.
>
> But yeah, I'm pretty sure the intention was just that clients would use it
> to communicate to each other something about the content of the message
> inside the related opaque blob that is the message, in a case where a user
> has multiple clients that all know how to decrypt the message, but the
> server doesn't.
>
> I have no idea where that most idea of the server setting the flag in
> Vaibhav's most recent email came from - the whole point in the original
> scenario is that the server doesn't know anything about the content of the
> email.
>
> Sorry if there has been some miscommunication from my side, of the server
being the entity setting the flag. The flag will be set by the party having
access to the decryption keys (almost always the MUA), but this information
will be stored as part of the message meta information, intermediated by
the server.

Thanks,
Vaibhav

Anyway, I don't think the whole way this would work has been well thought
> out yet.
>
> Bron.
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   [email protected]
>
>
>
>
Regards,
Vaibhav Singh

--f403045fc07cffb2a9055e11e651
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><br>---------- Forwarded message ---=
-------<br>From:=C2=A0Bron Gondwana &lt;<a href=3D"mailto:brong@fastmailtea=
m.com">[email protected]</a>&gt;<br>To:=C2=A0<a href=3D"mailto:imapext=
@ietf.org">[email protected]</a><br>Cc:=C2=A0<br>Bcc:=C2=A0<br>Date:=C2=A0We=
d, 15 Nov 2017 01:06:58 +1100<br>Subject:=C2=A0Re: [imapext] General Reques=
t for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)<br><u></u>




<div><div style=3D"font-family:Arial"><br></div>
<div>On Tue, 14 Nov 2017, at 19:25, Arnt Gulbrandsen wrote:<br></div>
<blockquote type=3D"cite"><div>Hi,<br></div>
<div><br></div>
<div>sorry about the late response. I suck at the moment.<br></div>
<div><br></div>
<div>I don&#39;t understand the semantics here.<br></div>
<div><br></div>
<div>If present, it means that someone has checked and found an encrypted<b=
r></div>
<div>attachment. And if absent, it means nothing. There may or may not be a=
n<br></div>
<div>encrypted attachment.<br></div>
<div><br></div>
<div>So my question is, what advantage does this provide over checking the<=
br></div>
<div>bodystructure?<br></div>
</blockquote><div><br></div>
<div style=3D"font-family:Arial">The usecase is that the entire message is =
encrypted as a single blob, but it contains an attachment.=C2=A0 The client=
 wants to mark that so that other clients know it has an attachment.<br></d=
iv>
<div style=3D"font-family:Arial"><br>There are questions about that being a=
 metadata leak that haven&#39;t been addressed.</div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">There are questions that Barry and I spoke=
 about briefly on Saturday about pairing it with a $HasNoEncryptedAttachmen=
t or something so you can tell that it&#39;s been checked already, which le=
d to a general discussion about paired keywords and what it means if they&#=
39;re both set and wouldn&#39;t it be nice if we had tristate keywords and =
what about per-message-annotations and doesn&#39;t everything suck.<br></di=
v>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">But yeah, I&#39;m pretty sure the intentio=
n was just that clients would use it to communicate to each other something=
 about the content of the message inside the related opaque blob that is th=
e message, in a case where a user has multiple clients that all know how to=
 decrypt the message, but the server doesn&#39;t.<br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">I have no idea where that most  idea of th=
e server setting the flag in Vaibhav&#39;s most recent email came from - th=
e whole point in the original scenario is that the server doesn&#39;t know =
anything about the content of the email.<br></div>
<div style=3D"font-family:Arial"><br></div></div></blockquote><div>Sorry if=
 there has been some miscommunication from my side, of the server being the=
 entity setting the flag. The flag will be set by the party having access t=
o the decryption keys (almost always the MUA), but this information will be=
 stored as part of the message meta information, intermediated by the serve=
r.</div><div><br></div><div>Thanks,</div><div>Vaibhav<br></div><div> <br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div><div style=3D"font-family:Arial"></=
div>
<div style=3D"font-family:Arial">Anyway, I don&#39;t think the whole way th=
is would work has been well thought out yet.<br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">Bron.<br></div>
<div style=3D"font-family:Arial"><br></div>
<div style=3D"font-family:Arial">--<br></div>
<div id=3D"m_5742012608132063126sig56629417"><div class=3D"m_57420126081320=
63126signature">=C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd<br></div>
<div class=3D"m_5742012608132063126signature">=C2=A0 <a href=3D"mailto:bron=
[email protected]" target=3D"_blank">[email protected]</a><br></div>
<div class=3D"m_5742012608132063126signature"><br></div>
</div>
<div style=3D"font-family:Arial"><br></div>
</div>

<br></blockquote></div><div class=3D"gmail_signature" data-smartmail=3D"gma=
il_signature"><div dir=3D"ltr"><div><br></div>Regards,<div>Vaibhav Singh</d=
iv></div></div>
</div></div>

--f403045fc07cffb2a9055e11e651--


--===============4816084494071879611==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext

--===============4816084494071879611==--