web-dev-qa-db-ja.com

PEM証明書バンドルの公式の標準や名前はありますか？

これは、適切なセキュリティについての問題ではありません。セキュリティ/暗号の命名法についてです。それは私を少し悩ませているので、ここに行きます：

関連する証明書/キーを一緒にバンドルする2つの方法を知っています。

  • 重量級アプローチ：PFX。PKCS＃12ファイル形式があります。 Windowsはこれらを.PFXまたは.P12ファイルとして保存します。
  • 軽量アプローチ：Just-cat-everything（aka "PEM bundle"）。すべての証明書/キーでcatを実行するだけ（ご希望の順序で）、これを新しいテキストファイルにリダイレクトします。

質問

  • 「PEMバンドル」アプローチの実際の標準はありますか？それとも呼ばれるのですか、それとももっと正式な名前がありますか？ （引用してください！）

これは、OpenSSLが証明書/キーのバンドルを処理するために使用するアドホックな方法であり、事実上の標準として採用されているというのが私の印象でした。これは本当ですか？それとも、PEM標準の「すべてのことだけ」アプローチですか？

命名法調査

人々はこれらのPEMバンドルファイルを何と呼びますか？

certificatesopensslterminologypkcs12pem
8
StackzOfZtuff

「PEM」形式のものには実際の標準はありません。 「PEM」の頭字語が由来する Privacy-enhanced Electronic Mail と呼ばれる提案された標準がありました。ただし、その標準はその競合（PGPおよびS/MIME）に対抗する勢いを得ることはなく、誰もそれを実装していません。

OpenSSL PEMを取得し、実際の仕様やドキュメントにその名前に値するドキュメントなしで、追加の機能とヘッダーでPEM形式を「拡張」したため、現在、「PEM」は「OpenSSLが生成して解析できるもの」を意味するようになりました。 」他のベンダー、例えばMicrosoft、そのソフトウェアはPEMエンコードされた証明書をデコードできます。

PEMの原則（ '----- BEGIN XXX -----'ヘッダーと対応する '- --- END XXX ----- 'トレーラー）は他のものに使用されています。 PGPはこれを「ASCIIアーマー」と呼んでいます。物事を行うその方法のポイントは、テキストが転送されたときにそのテキストに与えられたさまざまな拷問（例：電子メールとして送信、コピー＆貼り付け、に含まれる）に関係なく、一連のテキストデータ内で興味深いデータを見つけることができることですWord文書、印刷およびスキャン...）。これは重要なポイントです。つまり、PEMの全体は、特定の手順に従う必要なく、証明書を一緒に無計画に保存できることを意味します。正確な基準。その意味で、「PEMバンドル」の標準は自己矛盾です。「PEMバンドル」は、標準がないときに行うことです。

これを「事実上の標準」と呼ぶことは誤りではありません。

証明書をエンコードして送信する場合、実際には2つ以上の方法があります。可能性は次のとおりです。

  • ASN.1 DERエンコーディング（is標準）を使用して、各証明書を個別にエンコードします。
  • PEMを使用して、これらの証明書をASCIIベースの転送に対してより回復力のあるものにします。これにより、それらのいくつかを1つのファイル（「PEMバンドル」と呼ぶ）に保存することもできます。
  • 証明書をPKCS＃7（別名 [〜＃〜] cms [〜＃〜] ）SignedDataオブジェクトに保存します。 SignedDataは、名目上、署名されたデータを埋め込むためのフォーマットです。ただし、データを省略して署名をまったく含めないこともできます。その場合、「追加の証明書」を埋め込むためのフィールドを含む何らかのシェルがあります（通常、これらの証明書は署名の検証に役立ちます）。これは、標準が意図していない何かのための既存の標準の再利用ですが、既存のソフトウェアはそれを行います。 Microsoftはこれを「PKCS＃7証明書」または「P7Bファイル」と呼んでいます。
  • PKCS＃7 SignedDataだけでなく、PEMエンコードも使用します（概念的には、それらのいくつかを単一のファイルに格納できます）。
  • PKCS＃12 （「PFX」とも呼ばれます）。この形式では、他の種類のオブジェクトを格納することもでき、パスワードベースの暗号化のプロビジョニングが含まれているため、証明書およびの秘密鍵の格納に一般的に使用されます。 （どうやら、PKCS＃12アーカイブをPEMエンコードすることは誰も考えたことがないようです。）

秘密鍵にも独自の形式があります。たとえば、 PKCS＃1 は、RSA秘密鍵のASN.1ベースのエンコードを定義します。OpenSSLはそれをうまく使用し、次に「BEGIN RSA PRIVATE KEY」ヘッダーでPEMエンコードします。そのフォーマットはさらに PKCS＃8 オブジェクトにラップすることができます。これには、アルゴリズムのASN.1ベースの識別子と、オプションでパスワードベースの暗号化のサポートが含まれます。そしてそして、OpenSSLはまたPKCS＃8ファイルをエンコードします、これパスワードベースの暗号化が使用されたかどうかに応じて、「BEGIN PRIVATE KEY」または「BEGIN ENCRYPTED PRIVATE KEY」（PEMヘッダーにアルゴリズムが示されていない）の時間。あるいは、OpenSSLが実装しているが文書化していないPEMの拡張機能を使用して、未加工のPKCS＃1形式をパスワードで暗号化することもできます（OpenSSLのソースコードは仕様であると想定されています）。

要約すると、それは混乱です。

6
Thomas Pornin