Hi Bryce, What you propose is very similar to the Plasma work. The Plasma server functions like a EKG as you describe. We generalized the model more so we made authentication to the Plasma server via user tokens so it is possible to support a broader set of authentication mechanisms and authentication levels e.g. Facebook or Google+, as well as PIV cards. Since we support user tokes we can also do Attribute Based Access Control if the message contents warrant e.g. if the message has ITAR material. There were a number of compares built a POC to show this works and interoperates.
Here is the requirements document if you are interested. Doing late key binging via an EKG does have a number of advantages over early key binding. It is generally much more forgiving. It does not requires everybody to have encryption keys at send time. It scales better if you have a large number of recipients. It also does not require recipient key escrow to prevent data loss if you lose your encryption key. This main issue is the security and scope of the EKG key or keys. Here is the draft if you want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/ Trevor From: Endymail [mailto:[email protected]] On Behalf Of Nordgren, Bryce L -FS Sent: Monday, June 01, 2015 10:42 AM To: [email protected] Subject: [Endymail] FW: Group/Enterprise encrypted email 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: [email protected] 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
_______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
