Written by Sebastian K Glas, 08/2014
The idea of "E-Mail Transport Layer Security (M-TLS)" is a by-product of my work on a commercial, hardware- and Lisp-based automatic local E-Mail Encryption Mail Relay (which may be compared to "GPGrelay".) After finishing Analysis and Design and iterating through some Versions of implementation, these abstractions emerged. As they are the public side of a possible specification, I decided to publish them here.
I called these ideas "Mail Transport Layer Security" for an architectural reason: the encryption layer is not part of the E-Mail Client functionality but is moved to the Tranpsort Layer (or a special pre/post-processing step of the Transport Layer). Encryption and Decryption is invisible to the E-Mail Client, just as a HTML page is not affected by a SSL/TLS Layer. It may be ssen as a counterproposal to PGP/MIME, in which the object of encryption, the E-Mail, is structurally modified for encryption/decryption.
My solution implements these concepts. Of course, there are many interesting situations and conditions to be handled in these High-Level Use Cases. They will be described at a later time in Detail.
If you are interested in updates, you may follow my Twitter on @skglas_en
Please note: this proposal has nothing to do with the Web-“TLS”/ “SSL” Secure Socket Layer
This Document describes a way of transporting e-mails in PGP (GnuPG) encrypted form and a way of communication between an e-mail Client and a Crypto-Mail-Transport-Subsystem with the goal of simplicity and a medium level of security. In this architectural proposal, the Crypto-Mail-Transport-Subsystem is seen as a Step of Transport Pre- / Post-Processing. It may be part of an e-Mail Client or an external Program or Device or a combination of it.
The key points are:
1) Encryption
Receive the e-Mail from the Mail Client. Encrypt the complete e-Mail, including e-Mail headers (definition: all SMTP “DATA” Lines) and create a new Transport-e-Mail Header; set the Subject in the Transport Header e-Mail to [PGP]. Forward this Mail to the remote Mail Server. May require user interaction (password) for signing.
2) Decryption
Receive mail and, when Subject is [PGP], decrypt the e-Mail (may require user interaction, password or PIN); save the Transport Header as “X-TRANSPORT-HEADER” in a “folded” way. Return the restored e-Mail including original Headers and original Subject in Plaintext to the Mail Client.
3) Requesting a new Public Key
Send an e-Mail with Subject [PGP-KEY-REQUEST] to the Communication Partner.
4) Processing a Key Request
Receive mail and, if Subject is [PGP-KEY-REQUEST], send the ASCII-armored Public Key with Subject [PGP-KEY-OFFER] to the Communication Partner. May be automatically triggered when an e-Mail with [PGP-KEY-REQUEST] is received. A Key Offer may be sent without a prior Key Request.
5) Importing a new Public Key to the Key Ring
Receive mail, and when Subject is [PGP-KEY-OFFER], import it to the local Keyring. Set the Status of the key to “not usable” until validity/trust is assigned manually. Create a local Plaintext e-Mail Notification including information for the End-User about Sender, Key ID and Key Fingerprint. Include Instructions on how to Check the Fingerprint in an appropriate way (alternate Communications way, meeting person face to face, checking a key base, using a mobile app). Include instructions on how to set validity in a Keyring GUI.
6) To be discussed: Revocation of a public key
Send a broadcast e-Mail to a list of all relevant recipients with Subject [KEY-REVOCATION] and include a Revocation key in the e-Mail Body. Recipient-Systems revocate Key after receiving and create a local notification e-Mail. A confirmation E-Mail may be sent back about successful revocation. Systems may automatically trigger a new “Key Request” to the sender to obtain a new Key.
7) Current assumption: There is no “web of trust”. Every communication partner is responsible for his validity-assignments to keys.
8) To be discussed: Send regularly (eg. once a month) a [KEY-REFRESH] mail to a list of all relevant communication partners. Expect a [PGP-KEY-OFFER] reply. If not received for a period (of eg 3 months), set the public key in local key ring to Status “unusable” (eg. “disabled”).