エンドツーエンドの暗号化がメールのデフォルトになっていないのはなぜですか？
私は暗号学者ではありません。たぶんそれが、PGPをSMTPに統合する際の問題を見ない理由です。
私の頭の中で：リーは、ルークのドメインjedi.comのサーバーに[email protected]の公開鍵を伝えるよう要求します（この要求には暗号化方式が含まれている可能性があります）。彼女は鍵PUBLICを受け取ります。それから彼女はメッセージを暗号化し、ルークはそれを簡単に解読できます。
それはそれほど難しくありません、なぜそれが何年もの間標準ではないのですか？
それはそれほど難しくありません、なぜそれが何年もの間標準ではないのですか？
それは、PGPが解決しようとしている問題を解決しなかったからです。
PGPはエンドツーエンドの暗号化であるため、SMTPサーバーが暗号化を無効にする方法がある場合、スキームは失敗します。
あなたが提案したスキームの場合、アリス（[email protected]）がボブ（[email protected]）にプライベートメッセージを送信したいとします。提案したスキームを使用して、AliceのメールクライアントまたはAliceのSMTPサーバーは、dave.comへのTLS接続を行うことにより、Bobの公開鍵をフェッチします。これは、dave.comが正直で、実際にボブの公開鍵を返す限り問題ありません。しかし、dave.comは、dave.comのオペレーターがEveによって作成された偽造された公開鍵を返すように構成されているか、またはEveがdave.comにハッキングしてこれを設定することができます。これで、公開鍵がボブのものであると考えて、アリスのメールクライアント/メールサーバーはイブの証明書を喜んで受け入れます。このモデルでは、dave.comのオペレーターがボブのメールを傍受できます。
現在、dave.comが正直である限り、これは依然としてサードパーティのなりすましから保護します。これが少なくともサードパーティのスヌーピングから保護されているのであれば、なぜこれを行わないのですか？主な理由は、SMTPSが同じレベルの保護を提供すると同時に、はるかに単純であるためです。メールサーバーオペレーターによるMITMが問題にならない場合は、両方がSMTPSを使用していることを確認することで、既に電子メールを非常に安全に保護できます。
エンドツーエンドの暗号化の難しさは、公開鍵を取得することではないことに注意してください。 PGPをサポートするほとんどの電子メールクライアントは、LDAPまたはHPKPからの公開鍵の自動フェッチもサポートしています。エンドツーエンドの暗号化の難しさは、公開鍵を検証することです。
ユーザーに対して完全に透過的で完全に安全な公開鍵を検証する既知の方法はありません。 Web of Trustまたは認証局モデルが最も近くなりますが、Web of Trustには多くの警告があり、認証局モデルは検証を行うためにサードパーティに依存しています。
pGPをSMTPに統合します。
PGPは、データ（メールに限定されない）などのコンテナー形式であり、データに暗号化や署名を追加します。 SMTPはトランスポートプロトコルです。
コンテナー形式をトランスポートプロトコルに統合しません。これは、Officeドキュメントを誰かに送信するためにOffice（テキスト、画像のコンテナ...）をSMTP（トランスポート）と統合する必要があると言っているのと同じです。
PGPは単なるコンテナーであるため、SMTP以外でも使用されます。また、SMTPは単なる転送プロトコルであるため、PGPコンテナとは異なるものを転送するためにも使用されます。
代わりに、PGPやS/MIMEのようなエンドツーエンドの暗号化をSMTPに統合することについて質問しても、SMTPはホップバイホップの配信であり、エンドツーエンドではないため、機能しません。そのSMTPは別として、最後のホップ、つまり最後のメールサーバーからクライアントへの配信もカバーしていません。これは、POPやIMAPなどのプロトコルで行われます。
Leaは、Lukeのドメインjedi.comのサーバーに[email protected]の公開鍵を伝えるように要求します...
これが、キーサーバーまたは他の種類の中央ディレクトリを持っているものです。しかし、リーはこれが実際にはルークの鍵であって、ルークであると主張する誰かの鍵ではないことをどのようにして知っているのでしょうか。したがって、たとえば信頼のWeb（PGP）またはより集中化された構造（S/MIME）の形式で、または特定の中央ディレクトリのすべてを信頼することによって、信頼の伝播が必要です。
したがって、タスクはPGPをSMTPと統合することではなく、メールクライアントでPGPをより適切にサポートして、受信者のPGPキーを自動的にフェッチするようにすることです。ただし、もちろん、最初に受信者の検証可能なPGP鍵が鍵サーバーまたは他のディレクトリのどこかにある必要があるため、他のタスクは、鍵の作成、公開、管理（更新、取り消し...）を簡単にすることです。これらはすべてメール配信（SMTP）自体の外にあるものです。
暗号化はメールの転送中に既に行われていますが（SMTPの場合はSTARTTLS）、MITMから保護できるほど高度ではありません。
PGPは、電子メールクライアント間のエンドユーザーエクスペリエンスのほうが多いと思います。これは、関係するサーバーに対する完全な信頼がない場合に役立ちます。
（ただし、SSHのように、PGPはMITMの影響を受けやすいユーザーに影響を受けやすい場合があります。正しいキー署名を確認すると、その問題は解決されます）
ただし、Gmailなどのクラウドベースのメールサービスの場合は、ユーザーエクスペリエンスを向上させるためにサーバーで利用できるようにする必要があるため、PGPが邪魔になります。
うまくいけば、いつの日かSMTPでMITMに対応した暗号化が行われることを期待していますが、メールサーバーが制御されたネットワーク上にあるため、それほど問題にはなりません。
標準を書くのは簡単です。私はこれだけの問題について10年ほど前に考えました。それは人間/コストの要因に帰着します。 10億人の技術的に文盲の人々にソフトウェアをアップデートして知覚されるメリットがないように説得し、数千の開発者にこのプロトコルを実装するよう説得し、何百万もの組織が新しいプロトコルに切り替えるよう説得するにはどうすればよいでしょう- 譲ってください。 2011年には、世界の一部の地域でIPv4アドレスを使い果たしましたが、インターネットはまだIPv6をグローバルに使用していません。文字通りインターネットの成長を抑制しているにもかかわらず、IPv6への切り替えを説得することもできません。今日標準を作成し、IETFに提出して正式に配布することができたとしても、今日実行されている無数の「クラシック」メールサーバーをシャットダウンするのに十分普及するまでには、2030年になるでしょう。
さて、上で読んだように、SMTPSとSTARTTLSを使用して、メールの送信中にSMTPサーバーのセキュリティを強化できます。 MITMはDKIMで軽減できます。
DomainKeys Identified Mail（DKIM）を使用すると、送信中のメッセージに対して組織が責任を持つことができます。組織は、その発信者または仲介者としてのメッセージのハンドラーです。彼らの評判は、配信などのさらなる処理のためにメッセージを信頼するかどうかを評価するための基礎です。技術的には、DKIMは、暗号化認証を通じてメッセージに関連付けられているドメイン名IDを検証する方法を提供します。
要するに、DKIMを使用すると、メールがOriginから送信されたものであるかどうか、メールヘッダーが送信元であると示しているかどうかを識別できます。サーバーがメッセージを信頼できるかどうかを信頼できる方法で決定できる場合（DKIM認証が失敗した場合は、メールをドロップして、偽造されたメッセージがスパムハウスリストのSMTPサーバーを取得するかどうか心配する必要はありません）。
そして、そのようなものは円を丸くします。安全な認証STARTTLSを使用すると、SMTPサーバーに確実に接続し、メールサーバーにメールを送信できます。 DKIMは、特定のSMTPサーバーが特定のアドレスからのメール送信を許可されているかどうかを識別できます。接続を暗号化するためにSMTPサーバーからメールサーバーにメールを配信するためのTLS。メールクライアントとメールサーバー間のSTARTTLS（Webメールクライアントでない場合、POPまたはIMAPを介したセキュアソケット接続で十分です）