[Endymail] FW: Group/Enterprise encrypted email

["Nordgren, Bryce L -FS" <[e-mail]>]

I was directed to this list because I posted the following to [kitten]. I looked at the archives here, and it seems that my proposed email key gatekeeper (run by the entity providing the email account) may solve the key distribution problem for transit, both for point to point ops as well as mailing lists.

No promises. It's not like I spend my life thinking about this stuff.

Bryce

From: Nordgren, Bryce L -FS
Sent: Friday, May 29, 2015 4:36 PM
To: [e-mail]
Subject: Group/Enterprise encrypted email

This is a "what if" message, centered around trying to make email encryption as painless as email signing. I want to be able to encrypt an email message once, no matter how many recipients there are. An enterprise should be able to decrypt employees' email to ensure there's no misbehavior. I want as little "extra" supporting infrastructure as possible. I also want to minimize the amount of inter-organizational coordination required.

What if sending an encrypted email required clients to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorized senders, and releases the decryption key once (only) to each recipient.

Detailed flow:

When encryption is desired, the sender's email client formats a key request to the EKG and signs it using the sender's email signing key. The key request includes the recipient's email addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an encryption key, encrypted with the sender's public email signing key; and 2] a plaintext copy of the key request, signed by the EKG itself. The sender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request. Poof. The message is sent. If the sender's client stores outgoing mail in a "sent mail" folder, the stored copy must be encrypted using some other means.

The EKG-signed key request includes: 1] a unique identifier for the encryption key; 2] contact info, so recipients can locate the EKG; and 3] of course, the list of recipients (part of the original key request).

The Sender's organization can decrypt the outbound email at a gateway by contacting the EKG and retrieving the decryption key (which could be the same as the encryption key if symmetric, or the other half of an asymmetric keypair if not.)

The recipient's organization (assuming different than sender's organization) cannot decrypt the inbound email at a gateway.

The recipient's email client detects the EKG's signed key request attached to the email. The EKG's signature is verified. The recipient's client uses the recipient's email signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided.

The EKG verifies the recipients' signature. The EKG verifies that the recipient's certificate contains an email address that is included as a recipient in the original key request. The EKG verifies its own signature. The EKG encrypts the email's decryption key using the recipient's public email signing key, and signs the response. The recipient verifies the signature (ensuring same EKG signed key request and decryption key request) and decrypts the message/attachments.

If the message is to be stored, it must be re-encrypted in a locally recoverable fashion, likely with the recipient's credentials. If the recipient's organization is concerned about decrypting inbound email, the "locally recoverable fashion" should allow authorized individuals/services access. The original ciphertext should not be stored after decryption, and the decryption key must not be stored. Probably best not to get too psycho over this: the recipient can always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients keep things encrypted when they're received encrypted is what we're after.

The EKG keeps track of which recipients have requested the decryption key. Recipients are allowed to request the key once and only once. When all recipients have requested the decryption key, that key must never be served out again. The EKG should not re-use encryption keys for subsequent messages.

Clearly, the EKG needs to be just as publicly available as the organization's mailserver. I do not believe there would need to be anything special in DNS (no "EKG" records, etc.) To summarize:  The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messages are one-time-use, and shared among sender and all recipients. Recipients get decryption keys by having a certificate with a matching email address. No extra coordination is involved over and above the configuration necessary to verify email signatures.

What do you think? Is there an obvious reason this hasn't been done before?

Bryce