![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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==--
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
home | help | back | first | fref | pref | prev | next | nref | lref | last | post |