[Cryptography] Encoding Key Identifiers in email addresses

[Phillip Hallam-Baker]

On Thu, Oct 17, 2013 at 3:26 PM, David Mercer <radix42 at gmail.com> wrote:

> On Wed, Oct 16, 2013 at 1:43 AM, Phillip Hallam-Baker <hallam at 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 at 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 at 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131017/06fd2635/attachment.html>