[147716] in cryptography@c2.net mail archive
Re: [Cryptography] Encoding Key Identifiers in email addresses
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Oct 17 17:16:23 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CADpjbE2yUmuRP5fTHkincxzh=T+L8LivA0LNHpiJ+q-xBRQyAw@mail.gmail.com>
Date: Thu, 17 Oct 2013 16:40:50 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: David Mercer <radix42@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============5387550533349836130==
Content-Type: multipart/alternative; boundary=001a1133b2d051e16604e8f5d56c
--001a1133b2d051e16604e8f5d56c
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 17, 2013 at 3:26 PM, David Mercer <radix42@gmail.com> wrote:
> On Wed, Oct 16, 2013 at 1:43 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:
>
>> I was noodling round with the problem of how to force an existing client
>> to do the right thing with respect to encryption. One option is to have an
>> email gateway do opportunistic encryption if it can find a key. Which is OK
>> but lacks user control.
>>
>
> *snip*
>
> An email sender may send email to Alice through a compliant gateway as
>> follows:
>>
>
> *snip*
>
>> ACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-DPZJAJ-KAA?alice@example.com Send
>> email to Alice using encryption if and only if an encryption key for Alice
>> can be found that is directly endorsed under the specified key, otherwise
>> report an error. ACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-DPZJAJ-KAA??
>> alice@example.com Send email to Alice using encryption if and only if an
>> encryption key for Alice can be found that is (directly or indierectly)
>> endorsed under the specified key, otherwise report an error.
>>
>
> This reminds me a lot of RFC 5233 email address local-part tagging, e.g.
> having a client convert one of the above to
> alice+ACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-DPZJAJ-KAA@exmple.comwhen it has the key.
>
We could reverse the order if people prefer, that would make it easier for
autocomplete to function since someone is going to start typing 'alice' It
is arguably tidier too since all the user related stuff is at one end and
all the plumbing at the other.
I'll wait for more comments before making any changes though.
The pity is that different systems use a different character: plus (gmail,
> apple, lots of others), a hyphen (yahoo, qmail and courier, notably), an
> equals sign (mmdf) or freaking anything (postfix, didn't look up if there
> is an easily un-commentable default).
>
That is one of the reasons I chose ?, it is not already in use for other
schemes that might conflict.
> Having the key identifier to the left of the untagged local-part is a nice
> twist; the client could then look up an attribute in it's address book to
> see if there was a local-part tag delimiter. This could easy auto-mated
> client and/or gateway processing of the encryption at either or both ends.
>
Just to make clear, this is the option for forcing use of encryption that
is designed for backwards compatibility sending email from existing clients
with the encryption taking place on a local submit gateway on the same
machine.
If someone was to write a new client or plug in that was aware of this
stuff, they would hopefully take the opportunity to do a better job.
--
Website: http://hallambaker.com/
--001a1133b2d051e16604e8f5d56c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Oct 17, 2013 at 3:26 PM, David Mercer <span dir=3D"ltr"><=
;<a href=3D"mailto:radix42@gmail.com" target=3D"_blank">radix42@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>On Wed, Oct 16, 2013 a=
t 1:43 AM, Phillip Hallam-Baker <span dir=3D"ltr"><<a href=3D"mailto:hal=
lam@gmail.com" target=3D"_blank">hallam@gmail.com</a>></span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>I was noodling round with the proble=
m of how to force an existing client to do the right thing with respect to =
encryption. One option is to have an email gateway do opportunistic encrypt=
ion if it can find a key. Which is OK but lacks user control.=A0</div>
</div></blockquote><div>=A0</div></div><div>*snip*</div><div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">
<div dir=3D"ltr"><div></div>
An email sender may send email to Alice through a compliant gateway as
follows:</div></blockquote><div><br></div></div><div>*snip*=A0</div><div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">
<div dir=3D"ltr"><dl>
<dt>ACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-DPZJAJ-KAA?<a href=3D"mailt=
o:alice@example.com" target=3D"_blank">alice@example.com</a></dt>
<dd>Send email to Alice using encryption if and only if an encryption key=
=20
for Alice can be found that is directly endorsed under the specified key,=
=20
otherwise report an error.</dd>
<dt>ACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-DPZJAJ-KAA??<a href=3D"mail=
to:alice@example.com" target=3D"_blank">alice@example.com</a></dt>
<dd>Send email to Alice using encryption if and only if an encryption key=
=20
for Alice can be found that is (directly or indierectly) endorsed under=20
the specified key, otherwise report an error.</dd></dl></div></blockquote><=
div>=A0</div></div></div><div>This reminds me a lot of RFC 5233 email addre=
ss local-part tagging, e.g. having a client convert one of the above to=A0<=
/div>
<div><a href=3D"mailto:alice%2BACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-=
DPZJAJ-KAA@exmple.com" target=3D"_blank">alice+ACACEA-H7MBAA-LAA2RMA-FUAAFQ=
-AADHAHS-KNAL3A-DPZJAJ-KAA@exmple.com</a> when it has the key.</div></div>
</div></blockquote><div><br></div><div>We could reverse the order if people=
prefer, that would make it easier for autocomplete to function since someo=
ne is going to start typing 'alice' It is arguably tidier too since=
all the user related stuff is at one end and all the plumbing at the other=
.</div>
<div><br></div><div>I'll wait for more comments before making any chang=
es though.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">
<div class=3D"gmail_extra"><div>The pity is that different systems use a di=
fferent character: plus (gmail, apple, lots of others), a hyphen (yahoo, qm=
ail and courier, notably), an equals sign (mmdf) or freaking anything (post=
fix, didn't look up if there is an easily un-commentable default).</div=
>
</div></div></blockquote><div><br></div><div>That is one of the reasons I c=
hose ?, it is not already in use for other schemes that might conflict.</di=
v><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div>Having the key identifier =
to the left of the untagged local-part is a nice twist; the client could th=
en look up an attribute in it's address book to see if there was a loca=
l-part tag delimiter. This could easy auto-mated client and/or gateway proc=
essing of the encryption at either or both ends.=A0</div>
</div></div></blockquote><div>=A0</div></div>Just to make clear, this is th=
e option for forcing use of encryption that is designed for backwards compa=
tibility sending email from existing clients with the encryption taking pla=
ce on a local submit gateway on the same machine.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">If someone =
was to write a new client or plug in that was aware of this stuff, they wou=
ld hopefully take the opportunity to do a better job.<br clear=3D"all"><div=
>
<br>
</div>-- <br>Website: <a href=3D"http://hallambaker.com/" target=3D"_blank"=
>http://hallambaker.com/</a><br>
</div></div>
--001a1133b2d051e16604e8f5d56c--
--===============5387550533349836130==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5387550533349836130==--
