OpenSSL 1.0.1c以降はCMSサポートを提供しているようです。 smime
とpkcs7
の違いを理解できません。 S/MIME仕様はPKCS#7に階層化されています(つまり Wikipedia )。
openssl
には、次のコマンドがあります。
openssl smime
openssl cms
これらの同等のコマンドはありますか?なぜ2つの実装があるのですか?どちらを使用すべきですか?
PKCS#7 は、後に「情報RFC」として公開されたRSA Labsの古い標準です。その後、「インターネット標準」として、つまりIETFの権力者の承認を得た新しいバージョンが作成されました。そのために新しい名前が考案されました: [〜#〜] cms [〜#〜] 。その後、新しいバージョンが定義されました: RFC 3369 、 RFC 3852 、 RFC 5652 。 CMSとPKCS#7の両方で、いくつかのバージョンを持つ同じ規格を指定することを検討できます。
CMS(PKCS#7)は、任意のバイナリメッセージ(サイズが大きくなる可能性がある)に暗号化、署名、および/または整合性チェックを適用するためのフォーマットです。入れ子にすることができます。 タイムスタンプ などの一部のプロトコルの基本です。また、X.509証明書のコンテナーとしても頻繁に(ab)使用されます。SignedData
タイプには、一連の署名のフィールドが含まれます(そのセットは空でもかまいません)。also =オブジェクトを処理するすべての人にとって「潜在的に役立つ」と見なされる任意のX.509証明書を格納するフィールド。
CMSは名目上下位互換性があります。さまざまな場所にバージョンフィールドがあり、CMSのバージョンを理解するライブラリすべき古いバージョンからのメッセージを処理できます。さらに、そのようなライブラリはalsoでなければなりませんが、メッセージの内容が与えられれば、他のバージョンと互換性のあるメッセージを生成できます。例については セクション5.1 を参照してください。「バージョン」フィールドは最小値に設定されますが、構造体に他に何があるかを考慮しても、それでも意味があります。
S/MIME は「安全なメール」を行うためのプロトコルです。 S/MIME 使用暗号化パーツのCMS。 S/MIMEがCMSに追加するものは次のとおりです。
CMSオブジェクト(バイナリ)を電子メール(テキストベース)で無傷で移動できるものにエンコードするためのルール。これらのルールは [〜#〜] mime [〜#〜] に基づいて構築されているため、基本的にいくつかのヘッダーを持つBase64です。
署名されたが暗号化されていない電子メールの正規化ルール。電子メールが署名されているだけで、受信者がS/MIMEに対応していない可能性がある場合、not電子メールデータを含むCMS SignedData
オブジェクトとして署名を送信すると便利です自体;署名は添付ファイルとしてメールに添付されます。次に、署名の検証のために、電子メールのコンテンツをバイトシーケンスにエンコードする方法を正確に定義することが重要です(1つの誤ってエンコードされたビットは検証の失敗を意味します)。
実際のCMSオブジェクトの制限と使用方法:ネストの許容量、表示されるタイプ...
送信者が署名されたメッセージで、サポートする暗号化アルゴリズムの種類と同様のメタデータを公開できるように、いくつかの追加属性。
ある意味では、S/MIMEはCMSと電子メールの間の接着剤と考えることができます。
OpenSSL は、PKCS#7の一部のバージョン、CMS、S/MIMEなど、一部のプロトコルを実装するライブラリです。 libraryにはcommand-line toolsも付属しており、コマンドラインインターフェイスとしてsomeライブラリの機能を公開しています。ツールは、ライブラリが実装していないものは何もサポートしません(逆に、控えめに言っても意外です)が、ライブラリはコマンドラインツールが簡単にアクセスできない機能を実装している可能性があります。またはまったくアクセスできません。
一般的に言って、コマンドラインツールはそれほど「深刻」ではありません。いくつかの手動操作やいくつかのスクリプトには便利ですが、堅牢なapplicationsにはライブラリを直接使用する必要があります(Cライブラリですが、バインディングは多くのプログラミング言語に存在します)。
コマンドラインツールには、サブコマンドpkcs7
、cms
、smime
があります。紛らわしいことに、cms
コマンドはS/MIMEで使用するためのものであり、S/MIMEをサポートしており、副産物としてのみ「汎用」CMSサポートツールとして使用できることが判明しています。 OpenSSL開発者は、S/MIME(およびCMS)の最近のバージョンをサポートするために、インターフェースの互換性を壊さずにcms
コマンドを更新できないと感じたため、新しいコマンドsmime
を作成しました。 openssl smime
を使用するパーティースクリプトは、そのコマンドのパラメーターが新しいS/MIMEバージョンに対応するように調整されている場合、無効になります。そのため、彼らはcms
という新しいコマンドを作成しました。
理論的には、S/MIMEに関連するすべてのものに対してopenssl cms
を使用する必要があります。しかし、このコマンドはS/MIMEおよびCMSの「新しい」バージョンのOpenSSLサポートコードへのアクセスを提供するため、完全に有効であるが、S/MIMEの古い実装では使用できない機能を使用するS/MIMEメッセージを生成できます。サポート。これについては、要約的に manページ で説明しています。他のS/MIME実装(Thunderbird、Outlookなど)を使用した広範なテストは、他の人がメールを読めなくすることなく、S/MIMEで何ができるかを正確に知るために必要です。
OpenSSLのsmime
アプリは、PKCS#7 CMSを使用して古いS/MIME形式をサポートしていると思います(一部はstandards.txt
OpenSSLで配布)これはS/MIMEバージョン3です。新しいバージョンのcms
アプリは、新しいCMS仕様を使用するS/MIME v3.1形式のメッセージをサポートしているため、S/MIMEのままです。 pkcs7
アプリはonlyPKCS#7 v1.5データのみを処理し、新しいCMSバージョンは処理しません。
命名法は明確ではないと思います。cms
アプリがpkcs#7
アプリ。
S/MIMEバージョン3.1の仕様は RFC 3851 にあります。 S/MIME v3.2の現在のバージョンは RFC 5751 で定義されています。
S/MIMEは、安全なMIMEデータを送受信するための一貫した方法を提供します。
「PKCS#7暗号メッセージ構文」は、暗号データのフォーマット(署名、ダイジェスト、暗号化)に関係しています。 「CMS」は、この現在の形式の名前です。これは CMS仕様(RFC 5652)のセクションPKCS#7 v1.5 を含む以前のバージョンからの変更点の詳細です。 CMSは自分自身を
CMSは、データ保護のためのカプセル化構文を記述します。デジタル署名と暗号化をサポートしています。構文では、複数のカプセル化が可能です。 1つのカプセル化エンベロープを別のカプセル化エンベロープ内にネストできます。
PKCS#7 v1.5に関連するCMSの重要な変更点の1つは、CMSが特定の暗号化アルゴリズムまたはキー管理スキーム(相互運用性の要件以外)に関連付けられていないため、拡張性が高いことです( RFC 3370を参照)。 たとえば)。
スタンドアロンのcms
アプリがopenssl-1.0.0に登場しました(とにかくCHANGES
によると)。私が理解している限り、CMSデータ構造のさまざまな部分には独自の独立したバージョンの詳細があります。単純な「1.0」バージョン管理システムはなく、RFC番号はおそらくインスタンスを識別するための最良の方法です。繰り返しますが、standards.txt
、OpenSSLのCMSサポートは RFC336 インスタンスであるように見えます。
最も互換性のあるS/MIMEメッセージを作成する必要がある場合は、おそらくsmime
アプリが最適です。新しいバージョンを作成または処理する場合は、cms
の方が適しています(cms
で新しい/より強力な暗号化およびダイジェストアルゴリズムを正常に使用できる可能性も高いでしょう)。 RFCは、バージョン間のS/MIME署名の非互換性、およびCMSとPKCS#7間の非互換性についても言及しています。