Subject: [perpass] Encoding email security policy into email addresses.

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Oct 2013 11:22:39 -0400

One of the reasons that SSL works is that there is a convention that a
https: url is resolved over SSL transport. I have been thinking about
something similar for email.

Where I am at with the code at the moment is that I can generate keys and
throw them at a gateway to some PKI which is currently TBS. This allows
someone to configure their email client to accept encrypted email.

The hard part is how to decide whether the email should be encrypted and if
so under which key. As a pro-tem solution I plan to code up a simple
SMTP/SUBMIT proxy which the user points their outbound email at (using TLS
of course). This allows all the 'research stuff' to be isolated from the
email client.

One problem with this approach is that there is no way for the sender to
force use of encryption or to force encryption to a key validated under a
particular trust anchor.

Which had me thinking about a convention similar to https for email.

It turns out that the question mark is actually a valid RFC822 address and
is actually supported by a few MUAs. It is however rejected by plenty of
MTAs. Which is actually perfect for my purposes.

What I propose is the following:

?<user>@<domain>   : Force encryption of the email message

<key-identifier>?<user>@<domain>   : Force encryption of the email message
under a key that is chained under the specified <key-identifier>

The <key-identifier> here would be a base32 encoded one of the following:

* If it is 20 bytes, a PGP v4 sha1 fingerprint

* Otherwise, it a key identifier computed as a hash over the ASN.1 public
key info block that uses new, stronger hashes.

Note that this still requires the gateway to convert from either the email
address or the key identifier to a public key for encryption. But it does
place control in the hands of the user in a reasonably intelligible fashion
without needing to rewrite the email client.

An aware email client would of course have a handy button for this. But I
rather prefer it when the handy button is connected to something I can
relate to under the hood.

The key-identifier might specify the encryption key itself or there might
be a personal or enterprise hierarchy.

Consider the case that alice works for example.com.

Example Inc. has a corporate PKI and a key fingerprint X

[email-masked] has a personal key fingerprint Y which she has used to
endorse her email encryption key issued under the example.com PKI.

Depending on how well I know Alice and the nature of my message, I might
want to specify X or Y.

[I guess people might even want to allow for requiring the key to be
endorsed under X and Y]

Note that this approach still leaves open some research questions:

If the Key-Identifier is specified then we have a trust path Discovery
problem.

If the Key-Identifier is not specified then we have a trust path discovery
and validation problem.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Oct 2013 13:26:46 -0400

This is how the scheme works in practice.

Private Key Example

Alice uses a key generation tool to generate a public keypair. The public
parameters in hexadecimal are:

Modulus  :
 a4 11 df 43 4a 6b a1 3e 29 78 5e 65 3c 3e 77 71
 78 e5 be bf 1e aa cd 4b 07 94 78 05 c6 c8 06 52
 a6 32 ce 8d 31 88 43 f5 78 b4 17 03 99 b1 1b a4
 fc e9 82 ec d7 10 f2 56 f4 dc b8 0e e4 d2 e9 e8
 ad 90 41 e6 9a 65 ad 97 c3 a6 f4 49 51 b2 cb 98
 4c d9 19 ba b4 b6 06 7c 87 79 3f 30 01 fa 1d d9
 5c ad 94 f6 5e 09 2d 32 5f 1d f7 ce d2 f5 d1 68
 05 c6 95 2b 9a c3 f5 f4 8a f2 a1 a6 9d 7a de 93
Exponent :
 01 00 01

The Key Identifier is calculated using SHA512 and truncated to 224 bits to
produce the Key Identifier value. The Key Identifier in Base32 encoding is:

KeyIdentifier: ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA

An email sender may send email to Alice through a compliant gateway as
follows: [email-masked] Send email to Alice using encryption if and only
if an encryption key for Alice can be found and Alice has published the
email encryption policy 'encryption preferred' or stronger. ?
[email-masked] Send email to Alice using encryption if and only if an
encryption key for Alice can be found, otherwise report an error.
ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA?[email-masked] 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. ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA??
[email-masked] 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.

The key identifiers are 224 bits long plus an 8 bit prefix to specify the
algorithm. It might well be desirable to trim them back to 160 bits but
certainly no less than 128 bits.

Here is 160 bits:
AAAMDA-GF5JAP-IAH7P3A-DSAEYB-IAHMAFB?[email-masked]

Here is 128 bits:
ADAHSA-CSZLAG-AAHTZ2A-IFAF3PF?[email-masked]

The 128 bit key identifier might be strong enough for a personal key
identifier since the difficulty of finding a key that would match by brute
force would be 128 bits.

For an organizational key, there is a risk of the key being formed
maliciously so as to evade transparency requirements and so the longer
identifier is 'probably' necessary.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 16 Oct 2013 10:43:39 -0400

I can't tell you how many conversations I've had lately with laypeople
and journalists who have tried to get up to speed with PGP and just
can't manage it... they inevitably ask me if there is a way to encrypt
email such that they have to know nothing or little to us it. I have
to tell them, not really. This seems to be getting in that direction!
So, thank you, for working on this... I do wish the delimiter were
something other than "?", but I'm not sure if there are any other
design choices.

best, Joe

On Tue Oct 15 13:26:46 2013, Phillip Hallam-Baker wrote:
> Alice uses a key generation tool to generate a public keypair. The
> public parameters in hexadecimal are:
> 
> Modulus  : a4 11 df 43 4a 6b a1 3e 29 78 5e 65 3c 3e 77 71 78 e5 be
> bf 1e aa cd 4b 07 94 78 05 c6 c8 06 52 a6 32 ce 8d 31 88 43 f5 78
> b4 17 03 99 b1 1b a4 fc e9 82 ec d7 10 f2 56 f4 dc b8 0e e4 d2 e9
> e8 ad 90 41 e6 9a 65 ad 97 c3 a6 f4 49 51 b2 cb 98 4c d9 19 ba b4
> b6 06 7c 87 79 3f 30 01 fa 1d d9 5c ad 94 f6 5e 09 2d 32 5f 1d f7
> ce d2 f5 d1 68 05 c6 95 2b 9a c3 f5 f4 8a f2 a1 a6 9d 7a de 93 
> Exponent : 01 00 01
> 
> The Key Identifier is calculated using SHA512 and truncated to 224
> bits to produce the Key Identifier value. The Key Identifier in
> Base32 encoding is:
> 
> KeyIdentifier:
> ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA
> 
> An email sender may send email to Alice through a compliant gateway
> as follows: [email-masked] Send email to Alice using encryption
> if and only if an encryption key for Alice can be found and Alice
> has published the email encryption policy 'encryption preferred' or
> stronger. ? [email-masked] Send email to Alice using encryption
> if and only if an encryption key for Alice can be found, otherwise
> report an error. 
> ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA?[email-masked]
> 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.
> ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA?? 
> [email-masked] 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.
> 
> The key identifiers are 224 bits long plus an 8 bit prefix to
> specify the algorithm. It might well be desirable to trim them back
> to 160 bits but certainly no less than 128 bits.
> 
> Here is 160 bits: 
> Here is 128 bits: ADAHSA-CSZLAG-AAHTZ2A-IFAF3PF?[email-masked]
> 
> 
> The 128 bit key identifier might be strong enough for a personal
> key identifier since the difficulty of finding a key that would
> match by brute force would be 128 bits.
> 
> maliciously so as to evade transparency requirements and so the
> longer identifier is 'probably' necessary.
> 
> 
> 
> Alice uses a key generation tool to generate a public keypair. The 
> public parameters in hexadecimal are:
> 
> Modulus  : a4 11 df 43 4a 6b a1 3e 29 78 5e 65 3c 3e 77 71 78 e5 be
> bf 1e aa cd 4b 07 94 78 05 c6 c8 06 52 a6 32 ce 8d 31 88 43 f5 78
> b4 17 03 99 b1 1b a4 fc e9 82 ec d7 10 f2 56 f4 dc b8 0e e4 d2 e9
> e8 ad 90 41 e6 9a 65 ad 97 c3 a6 f4 49 51 b2 cb 98 4c d9 19 ba b4
> b6 06 7c 87 79 3f 30 01 fa 1d d9 5c ad 94 f6 5e 09 2d 32 5f 1d f7
> ce d2 f5 d1 68 05 c6 95 2b 9a c3 f5 f4 8a f2 a1 a6 9d 7a de 93 
> Exponent : 01 00 01 The Key Identifier is calculated using SHA512
> and truncated to 224 bits to produce the Key Identifier value. The
> Key Identifier in Base32 encoding is: KeyIdentifier:
> ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA An email
> sender may send email to Alice through a compliant gateway as 
> follows:
> 
> [email-masked] <mailto:[email-masked]> Send email to Alice
> using encryption if and only if an encryption key for Alice can be
> found and Alice has published the email encryption policy
> 'encryption preferred' or stronger. ?[email-masked]
> <mailto:[email-masked]> Send email to Alice using encryption if
> and only if an encryption key for Alice can be found, otherwise
> report an error. 
> ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA?[email-masked]
>
> 
<mailto:[email-masked]>
> 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. 
> ABAFYA-ATQBAB-UAG4VXA-MMACY7-4AMIAB4-NWALTA-GSHYAK-5AA??[email-masked]
>
> 
<mailto:[email-masked]>
> Send email to Alice using encryption if and only if an encryption 
> key for Alice can be found that is (directly or indierectly) 
> The key identifiers are 224 bits long plus an 8 bit prefix to
> specify the algorithm. It might well be desirable to trim them back
> to 160 bits but certainly no less than 128 bits.
> 
> Here is 160 bits: 
> <mailto:[email-masked]>
> 
> Here is 128 bits: ADAHSA-CSZLAG-AAHTZ2A-IFAF3PF?[email-masked]
> <mailto:[email-masked]>
> 
> 
> The 128 bit key identifier might be strong enough for a personal
> key identifier since the difficulty of finding a key that would
> match by brute force would be 128 bits.
> 
> maliciously so as to evade transparency requirements and so the
> longer identifier is 'probably' necessary.
> 
> -- Website: http://hallambaker.com/
> 
> 
> _______________________________________________ perpass mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/perpass
- -- 
Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: BE7E A889 7742 8773 301B 4FA1 C0E2 6D90 F257 77F8

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Oct 2013 13:37:05 -0400

We can use almost anything as the separator except for

It can't be @ (reserved for use as a separator)
It can't be ! (legacy of UUCP)
It can't be : or . (used in IP addresses)
It can't be - or _  (widely used already)
It can't be % (used as escaping in URIs)
It can't be < or > and probably not [({ })] either

That leaves very little. I dislike $.

I chose ? because it poses a problem for the NSA to decrypt which is a
reasonable mnemonic.

The other options I looked at were =, &, ^, *, +, #

Could do # I guess. But that will create issues with URI encoding (so will
?)

I think one big advantage of the approach is that it is easy to explain
that the gobbledygook in front of the name represents the encryption key.
Now it is really an index to the key rather than the key itself, just like
the DNS 'address' is actually an index not an address.