[147713] in cryptography@c2.net mail archive
Re: [Cryptography] Encoding Key Identifiers in email addresses
daemon@ATHENA.MIT.EDU (David Mercer)
Thu Oct 17 17:13:56 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAMm+Lwiw=8KUf-15JUn4HXsn-j2gAVQfGjb8Zak3a6u0oophLw@mail.gmail.com>
Date: Fri, 18 Oct 2013 03:26:59 +0800
From: David Mercer <radix42@gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8446879591648856878==
Content-Type: multipart/alternative; boundary=089e0163548c33ee2c04e8f4cdd7
--089e0163548c33ee2c04e8f4cdd7
Content-Type: text/plain; charset=UTF-8
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.
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).
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.
--
David Mercer
PGP Public Key: http://davidmercer.nfshost.com/radix42.pubkey.txt
Fingerprint: A24F 5816 2B08 5B37 5096 9F52 B182 3349 0F23 225B
--089e0163548c33ee2c04e8f4cdd7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 16, 2013 at 1:43 AM, Phillip Hallam-Baker <spa=
n dir=3D"ltr"><<a href=3D"mailto:hallam@gmail.com" target=3D"_blank">hal=
lam@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<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.=C2=A0</div>
</div></blockquote><div>=C2=A0</div><div>*snip*</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth: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>*snip*=C2=A0</div><blockquot=
e 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-lef=
t: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>=C2=A0</div></div><div>This reminds me a lot of RFC 5233 email address =
local-part tagging, e.g. having a client convert one of the above to=C2=A0<=
/div>
<div><a href=3D"mailto:alice%2BACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-=
DPZJAJ-KAA@exmple.com">alice+ACACEA-H7MBAA-LAA2RMA-FUAAFQ-AADHAHS-KNAL3A-DP=
ZJAJ-KAA@exmple.com</a> when it has the key.</div><div><br></div><div>The p=
ity 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 a=
n easily un-commentable default).</div>
<div><br></div><div>Having the key identifier to the left of the untagged l=
ocal-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 co=
uld easy auto-mated client and/or gateway processing of the encryption at e=
ither or both ends.=C2=A0</div>
<div><br></div>-- <br><div dir=3D"ltr">David Mercer=C2=A0<div>PGP Public Ke=
y:=C2=A0<a href=3D"http://davidmercer.nfshost.com/radix42.pubkey.txt" targe=
t=3D"_blank">http://davidmercer.nfshost.com/radix42.pubkey.txt</a></div><di=
v>Fingerprint:=C2=A0A24F 5816 2B08 5B37 5096 =C2=A09F52 B182 3349 0F23 225B=
</div>
</div>
</div></div>
--089e0163548c33ee2c04e8f4cdd7--
--===============8446879591648856878==
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
--===============8446879591648856878==--
