12月 26, 2020
Articles
コメントはまだありません

“ BEGIN RSA PRIVATE KEY ”形式の仕様はありますか？

これまで、BEGIN RSA PRIVATEKEYプレフィックスとENDRSA PRIVATE KEYサフィックスを使用するファイル形式の仕様（RFCなど）が見つかりませんでした。 。どこで定義されていますか？正式な名前はありますか？少なくとも一連のPEMRFCに関連しているようです。

ホワイトスペース処理の詳細、base64の詳細に関する参照情報を探しています。 、1つのファイルでの異なるキーの結合など。

この質問は、ペイロードのASNエンコーディングに関するものではありません。

コメント

  • OpenPGP仕様では、同様のASCII-Armor形式について説明しています。
  • tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
  • ほとんどのPEM形式（RSA秘密鍵以外）は、 RFC 7468：のテキストエンコーディングで文書化されています。 PKIX、PKCS、およびCMS構造。たとえば、ホワイトスペース処理のトピックに関するガイダンスがいくつかあります。RFCは基本的にその詳細はパーサーによって異なります。
  • user4982に感謝します：これは私が探している種類のソースです。ただし、RFC 7468には、ラベル" ENCRYPTED PRIVATE KEY "に関する情報が含まれていますが、' t。
  • PEMは RFC 1421 には、ヘッダーの全体的な形式などが記載されています。しかし、' " RSA秘密鍵"。 1997年のこの記事では、OpenSSLを使用したことについてすでに言及しています。

回答

私はここにいます。なぜなら、私はOPと同じ質問をしているからです。

PKCS＃1（RFC 3447）は、ASN.1構造を定義します：RSAPrivateKey、許可RSA秘密鍵のみの表現。

PKCS＃8（RFC 5208）は、ASN.1構造PrivateKeyInfoを定義し、任意の秘密鍵の表現を許可します。 （RSA秘密鍵の場合、PrivateKeyInfoはいくつかのパッケージ情報であり、PKCS＃1からのRSAPrivateKeyの再利用です。）

PEM（Privacy Enhanced Mail）は、安全な電子メールの廃止された方法です。ただし、そのコンテナ形式は暗号化アイテムをパッケージ化するために借用されました。

RFC 7468（はじめに）： “基本的に非調整または不注意に帰着する理由により、多くのPKIX、PKCS、およびCMSライブラリPEMエンコーディングに類似しているが同一ではないテキストベースのエンコーディングを実装する。 “

次のように読みます：ええと、人々は暗号ファイルをパッケージ化するためにPEMのビットを使用することにしました。ここでは、それを形式化するために非常に良い努力をしています…

残念ながら、RFC 7468はPKCS＃8 / PrivateKeyInfoパッケージを「BEGINPRIVATEKEY」として明確にしています。ただし、PKCS＃1 / RSAPrivateKeyを「BEGINRSAPRIVATEKEY」としてパッケージ化することはできません。

「BEGINRSAPRIVATE KEY」パッケージ化は、秘密鍵の場合は「SSLeay形式」または「従来の形式」と呼ばれることもあります。少なくとも、これは私たちにこのフォーマットの名前を与えますが、あなたのように、私はこのフォーマットの正式な説明に近づく何かを見つけることができず、歓迎します。これは存在しないと思われます。

コメント

  • I'm here, because, I'm asking myself the same question as the OP. – –明確にするために：これは上記の質問に対するあなたの答えですか、それとも実際に同じ質問をしているのですか？

答え

内部のbase64コンテンツの形式：

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

は RFC3447-付録A.1.2-RSA秘密鍵の構文：

RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }

DERを使用してエンコードする方法はすでに知っています。 ASN.1のフレーバー;問題は、そのDERバイナリデータを実際にファイルに書き込む方法についてです。

その次のステップは、 RFC1421-4.3.2.4ステップ4に記載されています。 ：印刷可能なエンコード

  • base64でバイナリデータをエンコードするドキュメント
  • 出力をテキスト行としてエンコード
  • 各行（正確に64個の印刷可能な文字を含む最後の行を除く
  • 64個以下の印刷可能な文字を含む最後の行

次に、使用される「カプセル化境界」（EB）があります。カプセル化されたPEMメッセージを区切る。

  • EB前の文字列は次のとおりです：-----BEGIN PRIVACY-ENHANCED MESSAGE-----
  • EB後の文字列は次のとおりです：-----END PRIVACY-ENHANCED MESSAGE-----

使用されたのは古い Privacy Enhanced Mail でした：

  • 5つのハイフン（-----）
  • BEGIN something
  • 5つのハイフン（-----）

その後に

  • 5つのハイフン（-----）
  • END something
  • 5つのハイフン（-----）

これらのPEM規則は、公開鍵、秘密鍵、および証明書に引き継がれましたが、適切なものがあります。表現の変更：

-----BEGIN RSA PUBLIC KEY----- ...base64 encoded DER ASN.1 RSAPublicKey... -----END RSA PUBLIC KEY-----

  

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

  

-----BEGIN PUBLIC KEY----- ...base64 encoded DER ASN.1 SubjectPublicKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN PRIVATE KEY----- ...base64 encoded DER ASN.1 PrivateKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN CERTIFICATE----- ...base64 encoded DER ASNl.1 Certificate... -----END CERTIFICATE-----

回答

はい。 RFC7468-PKIX、PKCS、およびCMS構造のテキストエンコーディング

このドキュメントは明確に表現しています既存の実装が動作し、将来の実装が相互運用できるようにそれらを定義する事実上のルール。

ここに関連する抜粋：

10. 1つの非対称キーとPKCS＃8秘密キー情報のテキストエンコーディング

暗号化されていないPKCS＃8秘密鍵情報構文構造（PrivateKeyInfo）は、非対称鍵パッケージ（OneAsymmetricKey）に名前が変更され、「PRIVATEKEY」ラベルを使用してエンコードされます。エンコードされるデータはBER（ DERを推奨。付録Bを参照）PKCS＃8 [RFC5208]で説明されているエンコードされたASN.1PrivateKeyInfo構造、または[RFC5958]で説明されているOneAsymmetricKey構造。2つは意味的に同一であり、バージョン番号で区別できます。

-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY-----

コメント

  • " RSA秘密鍵について質問しています"、"証明書リクエスト"についてではありません。ちなみに、PKCS＃10ではなく、PKCS＃8またはPKCS＃1を期待します。第10章はもっと近いでしょう。ただし、'ラベルでRSAを指定していないため、ここでPKCS＃8を使用するのは理にかなっています。キーアルゴリズムは冗長に指定されるため、PKCS＃1を" RSAプライベートキー"ファイル。
  • @すでに述べたように、" RSA秘密鍵"を探しています。 "秘密鍵"用ではありません。したがって、第10章でも適用できず、RFC7468は間違った答えです。
  • @Gustave I 'あなたが" RSA秘密鍵"ただし、ヘッダーで秘密鍵の形式を指定する必要はなく、仕様は適切です。
  • ABNFは< < textualmsg = preeb * WSP（…）> >および< < preeb = " —- -BEGIN "ラベル" —– "（…）> >。では、なぜヘッダーが不要だと思いますか？
  • PKCS＃1（ tools.ietf.org/html/rfc8017#appendix-A.1.2 ）'はASCIIbase64エンコーディングを指定しません。また、' ヘッダー。 PKCS＃8は、ASCIIbase64エンコーディングも'指定していません。第10章では、実際に-----BEGIN PRIVATE KEY-----を指定しています。 -----BEGIN RSA PRIVATE KEY-----ヘッダーを指定する標準へのリンクはありますか？

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です