web-dev-qa-db-ja.com

X.509とPKCS＃7証明書の違いは何ですか？

  1. Windowsで「暗号化メッセージ構文標準-PKCS＃7証明書（.P7B）」として保存された.p7bファイル拡張子を持つ呼び出しファイル-「PKCS＃7証明書」は正しいですか？それとも、「PKCS＃7形式で保存されたX.509証明書」と呼ぶ方がよいでしょうか。

  2. いつ他の証明書形式よりも1つの証明書形式を選択しますか？これらの形式には、特定の長所または短所がありますか？

  3. 最初の2つの編集の後にこの質問を追加します。 PKCS＃7形式は、DER/PEMファイル形式とどのように異なりますか？

ありがとう

編集＃1：Linux上のFirefoxでは、一部のWebサイトの証明書を次のようにエクスポートできます。

  • X.509証明書（PEM）
  • X.509証明書（DER）
  • X.509証明書（PKCS＃7）

ここでのPKCS＃7は、DERと似ているがDERとは異なるバイナリファイル形式にすぎないということですかtrueの場合、.p7bファイルは（PEMまたはDER形式ではなく）PKCS＃7形式で保存されたX.509証明書です。

編集＃2：最初の編集までフォローアップします。このページ OpenSSL：Documents、pkcs7 は、PKCS＃7がDERまたはPEMで暗号化できることを示唆しています。そのことから、PKCS＃7は明確なバイナリファイル形式ではないと推測します。今、私は完全に混乱しています。

編集＃3：OK、PEMとDER形式の関係を理解し​​ました。 PEMファイルのBase64でエンコードされたペイロードは、実際にはDER形式のデータです。したがって、最初にX.509証明書はDER形式でエンコードされ、オプションで、結果の「DERエンコードされた証明書」を「PEMエンコードされた証明書」にエンコードできます。パズルのPKCS＃7部分をフィッティングするのがまだ困難です。

編集＃4：別の情報。 PKCS＃7は、DER形式にエンコードする前にいくつかのX.509証明書をバンドルできるコンテナーのようです（これは、証明書を1つずつ貼り付けるだけで同じファイルにバンドルできるPEM形式とは異なります）。 。

tlscertificatesx.509
56
golem

あなたはほぼ正しい方向に進化しましたが、いくつかのポイントを追加し、@ CoverosGene ' answer を編集で快適に感じるよりもさらに拡張しました。

X.509は、ASN.1で証明書（およびここでは関係のない他のいくつかのこと）を定義します。これは、いくつかの定義されたエンコーディングを持つ（非常に！）一般的なデータ構造化メソッドで、その[〜＃〜] der [〜＃〜]識別エンコーディング表現は非常に一般的であり、ここで使用されます。

[〜＃〜] pem [〜＃〜]形式-証明書が1つしかないいくつかのタイプのデータの場合-エンコードされたバイナリ（DER）データだけですbase64（edit）通常64文字ごとに行に分割されます（ただし、バリエーションがあります）。さらに、ダッシュ+ BEGINまたはEND +データのタイプ（この場合はCERTIFICATE +ダッシュ。これらの行は人間にとって冗長に見えますが、それらは予想され、ほとんどがソフトウェアで必要とされます。 PEM（Privacy Enhanced Mail）は実際には安全な電子メールの完全な標準でしたが、現在はほとんど忘れられています（以下を参照）exceptはそのエンコード形式です。（編集）2015年の時点で RFC 7468 が詳細に記述されていますmost「PEM」形式の使用最新の暗号化データ。

PKCS＃7は、RSA（アルゴリズムではなく会社）によって、暗号化または署名されたデータの多目的フォーマットとして定義されました。それはIETFに引き渡され、 RFC 26 、次に RFC 3369 、次に RFC 3852 のCMS暗号メッセージ構文に進化しました_、次に RFC 5652 、つまりWindows（inetopt）プロンプトの表現。 「PKCS＃7」は、元のRSA PKCS＃7とIETF後継CMSのbothを意味するためによく使用されます。同じように、「SSL」は元のNetscapeプロトコルとIETF後継TLSトランスポートレベルセキュリティ。

.p7bまたは.p7c形式は、PKCS＃7/CMSの特殊なケースです。「コンテンツ」がなく、SignerInfoがゼロであるが、1つ以上の証明書（通常）および/またはCRL（まれに）。これが（edit）chainを構成するために必要な証明書のセットを処理するための標準的な方法を提供したとき（必ずしも順不同）。

PKCS＃7/CMSも（ある？）ASN.1であり、状況に応じてDERまたは[〜＃〜] ber [〜＃〜]のいずれかになります。ほとんどのDERデコーダーが処理するいくつかの非常に小さな違い。

PKCS＃7/CMSは、他のDERオブジェクトやBERオブジェクトと同様に、canはPEM形式ですが、 Openssl以外の実装を見たことがない （編集）証明書ではまれです。 （Java CertificateFactoryは、DERまたはPEMからのみPKCS7/CMS-certs-onlyを読み取ることができますが、CertPath.getEncodedは、DERにのみ書き込みます。）対照的に、単一の証明書のDER形式とPEM形式の両方が一般的です。

PKCS＃7/CMSは、S/MIME安全な電子メール（5751から始まる複数のrfc）の基礎としても使用されます。基本的にPEMはPKCS＃7をASCII 1980年代の電子メールシステムで簡単に処理できるテキストにエンコードしましたが、S/MIMEはCMSをでエンコードされたMIMEエンティティとして表します最新の電子メールシステムが処理できるいくつかの方法。

OpenSSL次のように実装することで問題を混乱させます：pkcs7コマンドはcerts-CRLsのみのケースを処理し、完全なPKCS＃7ではありません。crl2pkcs7コマンドは実際にCRLと証明書を処理しますが、残りのPKCS＃7は処理しません。smimeコマンドは、暗号化および/または署名されたメッセージのほとんどの場合に、実際にS/MIMEとPKCS＃7/CMSの両方を処理しますcmsコマンドは、実際にはS/MIMEとPKCS＃7/CMSの両方を処理して、より完全なケースセットを作成します。

したがって、私はオプションを次のように説明します。PEMまたはDER形式の証明書。 PKCS＃7コンテナーまたは略してp7の（単一の）証明書。適用されるまれな場合にのみPEMについて言及します。または、PKCS＃7またはp7のcert chain。単一の証明書と証明書チェーンのセマンティックの違いは、証明書自体またはコンテナ内の証明書の形式の違いと少なくとも同じくらい重要です。

そして、これは、証明書自体（他のエンティティ、ほとんどの場合はCAルートまたはアンカー）と、自分の証明書を証明するために使用する秘密鍵PLUS証明書（通常はチェーン）の組み合わせとの間の広範な混乱にさえ至りませんたとえば、SSL/TLSサーバーとして、またはS/MIMEメールに署名するときのID。Thatは、元のMicrosoft PFX Personal Information Exchange形式、またはその標準化された形式PKCS＃12または "p12"を使用します。

60
dave_thompson_085

PKCS＃7は、DERまたはPEMでエンコードされた複数の証明書をバンドルできる形式と考えることができ、証明書と証明書失効リスト（CRL）を含めることができます。

RFC2315 ごとに、PKCS＃7は

a general syntax for data that may have
cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one
envelope can be nested inside another, or one party can sign some
previously enveloped digital data.
9
CoverosGene