RFC 1847を使用した暗号化および署名されたMIMEメッセージ

Question

Web転送用のクライアントサーバー暗号化ソリューションが必要です（つまり、署名および暗号化されたクライアント側、検証および復号化されたサーバー側）。

HTTPを使用していますが、共有ホスティングの制限のためにSSLは使用できません（サーバーは共有ホスト環境です）。 代替ソリューションを検討し、 GnuPG を使用してOpenPGPを決定しました。その理由の1つは、さまざまなPEARおよびPECLモジュールを介してPHPでサポートされていることです（PHPは、クライアントスクリプトとサーバースクリプトの両方で両方に使用する予定の言語ですが、Perlは最後の手段）。

現在、データを送信する最適な方法を決定しようとしています。暗号化および署名されたマルチパートMIMEメッセージを定義する RFC 1847 に出会いました。このプロトコルは、PGP専用に RFC 3156 で拡張されています。 （これらのプロトコルはS / MIME暗号化メールプロトコルに関連していると思います）。

私の質問は、これらの標準に従う理由はありますか？プロトコルに関しては、賢明なソリューションのように見えますが、実際にこのプロトコルを使用するクライアントはいますか？たとえば、Apache Webサーバーにmultipart / encryptedリクエストを行った場合、データを取得する簡単な方法はありますか？ PHPスクリプトを使用した私のテストでは、これらのようなリクエストを解読しようとしてもPHPは役に立たないと考えさせられました（$ _POSTデータは 'multipart / form-data' MIMEタイプデータから来ているようです）。

ホストがソケットを開くことを するので、PHPのソケットプログラミングAPIを使用してPHPスクリプトを記述し、サーバーとして機能することができます 「multipart / encrypted」および「multipart / signed」HTTPリクエストを受け入れますが、これはやり過ぎのようです。

提案はありますか

私の問題の詳細については、をご覧ください。この質問。

Answer 1

あなたは正しい-これらのプロトコルは暗号化されたメールプロトコルに関連しているので、それを使用するのは少しやり過ぎであり、OpenSSL php拡張を使用する必要があります。 OpenPGPを使用します。

クライアントはPHPで作成されるため、次のシナリオを検討してください。

シナリオ1：簡単なSOAP Webサービスの作成

サーバーとクライアントのメソッドは同じです：

• getPublicKey（）-公開鍵を返します
• sendMessage（msg）-回答を返します

シナリオ2：GET / POSTメッセージを使用する

• クライアント-<！> gt; HTTP GET（送信してください 公開鍵）-<！> gt;サーバー
• クライアント<！> lt;-（my 公開鍵はxxxx）<！> lt;-サーバー
• クライアント サーバーのパブリックでメッセージを暗号化します キークライアントは、自身の公開キーを メッセージ
• クライアント-<！> gt; HTTP POST（送信 暗号化されたメッセージ）-<！> gt;サーバー
• サーバー メッセージをデコードし、エンコードします クライアントの公開鍵で答える
• クライアント <！> lt;-（クライアントへのエンコードされた回答）<！> lt;- サーバー