[要約] RFC 8351は、PKCS #8 EncryptedPrivateKeyInfoメディアタイプに関する仕様です。このRFCの目的は、PKCS #8形式で暗号化されたプライベートキー情報を安全に伝送するためのメディアタイプを定義することです。
Independent Submission S. Leonard Request for Comments: 8351 Penango, Inc. Category: Informational June 2018 ISSN: 2070-1721
The PKCS #8 EncryptedPrivateKeyInfo Media Type
PKCS#8 EncryptedPrivateKeyInfoメディアタイプ
Abstract
概要
This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.
このドキュメントでは、PKCS#8のEncryptedPrivateKeyInfoタイプのapplication / pkcs8暗号化メディアタイプを登録します。このメディアタイプのインスタンスは、単一のEncryptedPrivateKeyInfo値としてBERエンコードされた単一の暗号化された秘密キーを伝送します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8351.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8351で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Registration Application . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
The private key is encrypted with an encryption algorithm, which could be a password-based encryption scheme as that term is used in PKCS #5: Password-Based Cryptography Specification Version 2.1 as published in [RFC2898] and updated by [RFC8018]. This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8 (as originally described in [RFC5208], which was obsoleted by [RFC5958]). An instance of this media type carries a single encrypted private key [RFC5958] BER-encoded as a single EncryptedPrivateKeyInfo value.
秘密鍵は暗号化アルゴリズムで暗号化されます。暗号化アルゴリズムは、[RFC2898]で公開され[RFC8018]によって更新されたPKCS#5:Password-Based Cryptography Specification Version 2.1で使用されているパスワードベースの暗号化スキームです。このドキュメントは、PKCS#8のEncryptedPrivateKeyInfoタイプのapplication / pkcs8-encryptedメディアタイプを登録します([RFC5958]で廃止された[RFC5208]で最初に説明されたとおり)。このメディアタイプのインスタンスは、単一の暗号化された秘密キー[RFC5958]を単一のEncryptedPrivateKeyInfo値としてBERエンコードされた状態で伝送します。
Type name: application
タイプ名:アプリケーション
Subtype name: pkcs8-encrypted
サブタイプ名:pkcs8-encrypted
Required parameters: None.
必須パラメーター:なし。
Optional parameters:
オプションのパラメーター:
password-mapping: The private key is encrypted with an encryption algorithm, which could be a password-based encryption scheme as that term is used in PKCS #5 ([RFC2898] and [RFC8018]). Such algorithms take a password as input. A "password" is a secret text value (see Section 3 of [RFC2898] and [RFC8018]), but for algorithmic purposes the term "password" refers to an octet string (see Section 2 of [RFC2898] and [RFC8018]). Therefore, there must be some mapping between the text value (which might be user input) and the octet string. Section 3 of [RFC2898] (which was replaced by [RFC8018]) recommends "that applications follow some common text encoding rules"; it then offers, but does not recommend, ASCII and UTF-8.
password-mapping:秘密鍵は暗号化アルゴリズムで暗号化されます。このアルゴリズムはPKCS#5([RFC2898]および[RFC8018])で使用されているため、パスワードベースの暗号化スキームである可能性があります。このようなアルゴリズムは、パスワードを入力として受け取ります。 「パスワード」は秘密のテキスト値です([RFC2898]および[RFC8018]のセクション3を参照)。ただし、アルゴリズムの目的では、「パスワード」という用語はオクテット文字列を指します([RFC2898]のセクション2および[RFC8018]を参照)。 。したがって、テキスト値(ユーザー入力である可能性があります)とオクテット文字列の間には何らかのマッピングが必要です。 [RFC2898]のセクション3(これは[RFC8018]に置き換えられました)は、「アプリケーションがいくつかの一般的なテキストエンコーディングルールに従うこと」を推奨しています。次に、ASCIIおよびUTF-8を提供しますが、お勧めしません。
While many modern applications support Unicode and Unicode-based encodings such as UTF-8 and UTF-16, interchange is still needed with private key artifacts that are encrypted with passwords in other encodings. Therefore, this parameter specifies the charset (see Section 1.3 of [RFC2978]) that a recipient should attempt first, in "reverse", when mapping from a sequence of characters to an octet string. This parameter is not cryptographically protected, so recipients cannot rely on it as the exclusive mapping possibility.
最近の多くのアプリケーションは、UTF-8やUTF-16などのUnicodeおよびUnicodeベースのエンコーディングをサポートしていますが、他のエンコーディングのパスワードで暗号化された秘密キーアーティファクトとの交換が依然として必要です。したがって、このパラメーターは、文字のシーケンスからオクテット文字列にマッピングするときに、受信者が最初に「リバース」で試行する必要がある文字セット([RFC2978]のセクション1.3を参照)を指定します。このパラメーターは暗号で保護されていないため、受信者は排他的なマッピングの可能性としてこれに依存できません。
This parameter has similar semantics to the charset parameter from text/plain, except that it only applies to the user's input (text value) of a password. There is no default value.
このパラメーターは、text / plainのcharsetパラメーターと同様のセマンティクスを持っていますが、パスワードのユーザー入力(テキスト値)にのみ適用される点が異なります。デフォルト値はありません。
The following special values, which all begin with "*" to distinguish them from registered charsets, are defined:
登録された文字セットと区別するために、すべて「*」で始まる次の特別な値が定義されています。
*pkcs12 UTF-16LE with U+0000 NULL terminator: PKCS #12 style, see [RFC7292].
* pkcs12 UTF-16LE、U + 0000 NULLターミネータ:PKCS#12スタイル、[RFC7292]を参照。
*precis Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) password profile, i.e., OpaqueString from Section 4 of [RFC7613], which was obsoleted by [RFC8265]: always UTF-8 in Normalization Form C (NFC).
* Preparation、Enforcement、and Comparison of Internationalized Strings(PRECIS)password profile、すなわち、OpaqueString from the Section 4 of [RFC7613]:Obsoleted for [RFC8265]:常にUTF-8で正規化フォームC(NFC)。
*precis-XXX Any profile from the IANA "PRECIS Profiles" registry where "XXX" is replaced by the profile name as shown in the registry.
* precis-XXX IXXX "PRECISプロファイル"レジストリからの任意のプロファイル。ここで、 "XXX"は、レジストリに表示されるプロファイル名に置き換えられます。
*hex hexadecimal input: the input is mapped to 0-9, A-F, and then converted directly to octets. If there are an odd number of hex digits, either the final digit 0 is appended or an error condition is raised. Compare with Annex M.4 of [IEEE.802.11-2012].
* hex hexadecimal input:入力は0-9、A-Fにマップされ、オクテットに直接変換されます。 16進数が奇数の場合、最後の数字0が追加されるか、エラー条件が発生します。 [IEEE.802.11-2012]のAnnex M.4と比較してください。
*dtmf The characters "0"-"9", "A"-"D", "*", and "#", which map to their corresponding ASCII codes. "A"-"D" map to the uppercase range 0x41 - 0x44. (This is to support restricted-input devices, i.e., telephones and telephone-like equipment.) User input outside of these values is either ignored or an error condition is raised.
* dtmf対応するASCIIコードにマップされる文字「0」〜「9」、「A」〜「D」、「*」、および「#」。 「A」-「D」は、大文字の範囲0x41-0x44にマップされます。 (これは、入力が制限されたデバイス、つまり電話や電話のような機器をサポートするためのものです。)これらの値以外のユーザー入力は無視されるか、エラー状態が発生します。
Otherwise, the value of this parameter is a charset, from the IANA "Character Sets" registry [CHARREG].
それ以外の場合、このパラメータの値は、IANAの「文字セット」レジストリ[CHARREG]の文字セットです。
This parameter is case insensitive.
このパラメーターは大文字と小文字を区別しません。
Encoding considerations: Binary.
エンコーディングに関する考慮事項:バイナリ。
Security considerations:
セキュリティに関する考慮事項:
Carries a cryptographic private key. See Section 6 of [RFC5958].
暗号化秘密鍵を保持します。 [RFC5958]のセクション6をご覧ください。
EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the confidential payloads much easier to compromise.
EncryptedPrivateKeyInfo PKCS#8データには、秘密鍵が1つだけ含まれています。不十分なパスワードの選択、弱いアルゴリズム、または不適切なパラメーターの選択(たとえば、不十分なソルティングラウンド)は、機密のペイロードの侵害をはるかに容易にします。
Interoperability considerations:
相互運用性に関する考慮事項:
PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The contents are exactly one private key (with optional key attributes), so there is no possibility for hidden "Easter eggs" in the payload such as unexpected certificates or miscellaneous secrets.
PKCS#8は、最新のすべての暗号化スタックの秘密鍵情報で広く認識されている形式です。内容は1つの秘密鍵(オプションのキー属性付き)なので、予期しない証明書やその他の秘密など、ペイロードに「イースターエッグ」が隠されている可能性はありません。
The encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, "Encrypted Private Key Info", of [RFC5958], and Section 6 of PKCS #8 as originally described in [RFC5208], which was obsoleted by [RFC5958]), is less widely used for exchange than PKCS #12, but it is much simpler to implement. Actually, PKCS #12 incorporates the PKCS #8 types, so a PKCS #12 processor ought to be able to process PKCS #8 data by embedding the PKCS #8 data in PKCS #12 "scaffolding".
この登録の暗号化されたバリエーションであるEncryptedPrivateKeyInfo([RFC5958]のセクション3、「Encrypted Private Key Info」、および[RFC5208]で廃止された[RFC5208]で最初に説明されたPKCS#8のセクション6)は、以下です。 PKCS#12よりも交換に広く使用されていますが、実装ははるかに簡単です。実際、PKCS#12にはPKCS#8タイプが組み込まれているため、PKCS#12プロセッサはPKCS#8データをPKCS#12の「足場」に埋め込むことによってPKCS#8データを処理できるはずです。
The password-mapping parameter aids in interoperability when the creator (who encrypted the keying material) and the user (who is attempting to decrypt the keying material) are not operating in the same character-encoding environment. An anticipated scenario is that the creator may have created the keying material with a password in a Shift-JIS environment a long time ago, while the user is in a UTF-8 environment. There are potentially many Unicode sequences that code for the same abstract character, such as precomposed and decomposed forms; yet, such an abstract character (however coded in Unicode) will tend to map to one coding in the legacy charset, if it can be represented at all. Therefore, the password-mapping parameter will almost never be ambiguous when mapping to legacy encodings. When mapping from one Unicode form to another (such as an internal Unicode representation to *pkcs12), code sequences are either preserved or folded deterministically to common Unicode code points or sequences, producing the same holistic result as mapping to legacy encodings.
パスワードマッピングパラメーターは、作成者(キー情報を暗号化したユーザー)とユーザー(キー情報を解読しようとしているユーザー)が同じ文字エンコード環境で動作していない場合の相互運用性を支援します。予想されるシナリオは、ユーザーがUTF-8環境にいるときに、作成者がかなり前にShift-JIS環境でパスワード付きの鍵素材を作成した可能性があることです。事前に合成されたフォームや分解されたフォームなど、同じ抽象文字をコード化する多くのUnicodeシーケンスが潜在的に存在します。しかし、そのような抽象文字(ただし、Unicodeでコーディングされている)は、レガシー文字セットで表すことができる場合、1つのコーディングにマッピングされる傾向があります。したがって、レガシーエンコーディングにマッピングする場合、パスワードマッピングパラメーターがあいまいになることはほとんどありません。 1つのUnicodeフォームから別のUnicodeフォーム(* pkcs12への内部Unicode表現など)にマッピングする場合、コードシーケンスは保存されるか、一般的なUnicodeコードポイントまたはシーケンスに確定的に折りたたまれ、従来のエンコーディングへのマッピングと同じ全体的な結果が生成されます。
It is possible that an abstract character might map to multiple legacy encodings under the same charset. However, the possibility is sufficiently remote as to be ignored in this media type registration. One possible workaround is to set the user's (decrypting party's) local operating environment to the password-mapping legacy encoding parameter for the purpose of generating the password octet string from user input. Another possibility is to generate all possible legacy encoding combinations from the abstract text (i.e., Unicode text), attempting decryption with them. Customized behavior can be defined by updating this media type registration with a new password-mapping special value, prefixed with *.
抽象文字が同じ文字セットで複数のレガシーエンコーディングにマッピングされる可能性があります。ただし、このメディアタイプの登録で無視される可能性は十分にありません。考えられる回避策の1つは、ユーザーの入力からパスワードオクテット文字列を生成する目的で、ユーザー(復号化当事者)のローカル操作環境をパスワードマッピングレガシーエンコーディングパラメーターに設定することです。別の可能性は、抽象テキスト(つまり、Unicodeテキスト)から可能なすべてのレガシーエンコーディングの組み合わせを生成し、それらを使用して復号化を試みることです。カスタマイズされた動作は、このメディアタイプ登録を、プレフィックスが*である新しいパスワードマッピング特殊値で更新することによって定義できます。
Published specification:
公開された仕様:
RSA Laboratories PKCS #8 v1.2 RSA Encryption Standard, November 1993 (republished as [RFC5208], May 2008, and updated as [RFC5958], August 2010); RFC 5958, August 2010
RSA Laboratories PKCS#8 v1.2 RSA暗号化標準、1993年11月([RFC5208]として再発行、2008年5月、[RFC5958]、2010年8月として更新)。 RFC 5958、2010年8月
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to import, export, and exercise a single private key.
この標準をサポートするマシン、アプリケーション、ブラウザ、インターネットキオスクなどにより、ユーザーは単一の秘密鍵をインポート、エクスポート、および行使することができます。
Fragment identifier considerations: None.
フラグメント識別子の考慮事項:なし。
Additional information:
追加情報:
Deprecated alias names for this type: N/A Magic number(s): None. File extension(s): .p8e Macintosh file type code(s): None. A uniform type identifier (UTI) of "com.rsa.pkcs-8-encrypted" is recommended.
このタイプの非推奨のエイリアス名:N / Aマジック番号:なし。ファイル拡張子:.p8e Macintoshファイルタイプコード:なし。 「com.rsa.pkcs-8-encrypted」のUniform Type Identifier(UTI)をお勧めします。
Object Identifiers: 1.2.840.113549.1.12.10.1.2 (when in PKCS #12)
オブジェクト識別子:1.2.840.113549.1.12.10.1.2(PKCS#12の場合)
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス:
Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON
使用目的:COMMON
Restrictions on usage: None.
使用制限:なし。
Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Provisional registration? No
仮登録?番号
IANA has registered the media type application/pkcs8-encrypted in the Standards tree using the information provided in Section 2 of this document.
IANAは、このドキュメントのセクション2で提供される情報を使用して、標準ツリーにメディアタイプapplication / pkcs8-encryptedを登録しました。
See the registration template.
登録テンプレートをご覧ください。
[CHARREG] IANA, "Character Sets", December 2013, <http://www.iana.org/assignments/character-sets>.
[CHARREG] IANA、「Character Sets」、2013年12月、<http://www.iana.org/assignments/character-sets>。
[IEEE.802.11-2012] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, <http://ieeexplore.ieee.org/document/6178212/>.
[IEEE.802.11-2012] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network--Specific requirements Part 11:Wireless LAN Medium Access Control(MAC)and Physical Layer(PHY)Specifications "、IEEE 802.11-2012、DOI 10.1109 / ieeestd.2012.6178212、<http://ieeexplore.ieee.org/document/6178212/>。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, <https://www.rfc-editor.org/info/rfc2898>.
[RFC2898] Kaliski、B。、「PKCS#5:Password-Based Cryptography Specification Version 2.0」、RFC 2898、DOI 10.17487 / RFC2898、2000年9月、<https://www.rfc-editor.org/info/rfc2898> 。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC2978] Freed、N。およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2978、DOI 10.17487 / RFC2978、2000年10月、<https://www.rfc-editor.org/info/rfc2978> 。
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", RFC 5208, DOI 10.17487/RFC5208, May 2008, <https://www.rfc-editor.org/info/rfc5208>.
[RFC5208] Kaliski、B。、「公開鍵暗号化標準(PKCS)#8:秘密鍵情報構文仕様バージョン1.2」、RFC 5208、DOI 10.17487 / RFC5208、2008年5月、<https://www.rfc- editor.org/info/rfc5208>。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、DOI 10.17487 / RFC5958、2010年8月、<https://www.rfc-editor.org/info/rfc5958>。
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.
[RFC7292] Moriarty、K。、編、Nystrom、M.、Parkinson、S.、Rusch、A。、およびM. Scott、「PKCS#12:Personal Information Exchange Syntax v1.1」、RFC 7292、DOI 10.17487 / RFC7292、2014年7月、<https://www.rfc-editor.org/info/rfc7292>。
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <https://www.rfc-editor.org/info/rfc7613>.
[RFC7613] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 7613、DOI 10.17487 / RFC7613、2015年8月、<https://www.rfc- editor.org/info/rfc7613>。
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <https://www.rfc-editor.org/info/rfc8018>.
[RFC8018] Moriarty、K.、Ed。、Kaliski、B。、およびA. Rusch、「PKCS#5:Password-Based Cryptography Specification Version 2.1」、RFC 8018、DOI 10.17487 / RFC8018、2017年1月、<https:/ /www.rfc-editor.org/info/rfc8018>。
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>.
[RFC8265] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 8265、DOI 10.17487 / RFC8265、2017年10月、<https://www.rfc- editor.org/info/rfc8265>。
Author's Address
著者のアドレス
Sean Leonard Penango, Inc. 5900 Wilshire Blvd Ste 2600 Los Angeles, CA 90036 United States of America
Sean Leonard Penango、Inc. 5900 Wilshire Blvd Ste 2600 Los Angeles、CA 90036アメリカ合衆国
Email: dev+ietf@seantek.com URI: http://www.penango.com/