[要約] RFC 7292は、PKCS #12のバージョン1.1に関する仕様であり、個人情報の交換構文を定義しています。このRFCの目的は、異なるシステム間で個人情報を安全に交換するための標準化を提供することです。
Internet Engineering Task Force (IETF) K. Moriarty, Ed.
Request for Comments: 7292 EMC
Category: Informational M. Nystrom
ISSN: 2070-1721 Microsoft Corporation
S. Parkinson
A. Rusch
M. Scott
RSA
July 2014
PKCS #12: Personal Information Exchange Syntax v1.1
PKCS＃12：個人情報交換構文v1.1
Abstract
概要
PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.
PKCS＃12 v1.1は、秘密鍵、証明書、その他の秘密、拡張機能など、個人のID情報の転送構文について説明しています。この標準をサポートするマシン、アプリケーション、ブラウザ、インターネットキオスクなどを使用すると、ユーザーは単一の個人識別情報のセットをインポート、エクスポート、および実行できます。この標準は、いくつかのプライバシーおよび整合性モードでの個人情報の直接転送をサポートしています。
This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
このドキュメントは、RSA Laboratoriesの公開鍵暗号化標準（PKCS）シリーズからのPKCS＃12 v1.1の再版を表しています。このRFCを公開することにより、変更管理がIETFに移されます。
IESG Note
IESG Note
The IESG thanks RSA Laboratories for transferring change control to the IETF. Enhancements to this specification that preserve backward compatibility are expected in an upcoming IETF Standards Track document.
IESGは、変更管理をIETFに移行してくれたRSA Laboratoriesに感謝します。下位互換性を維持するこの仕様の拡張は、今後のIETF標準トラックドキュメントで期待されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7292.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7292で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes from PKCS #12 Version 1 . . . . . . . . . . . . . 4
2. Definitions and Notation . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Exchange Modes . . . . . . . . . . . . . . . . . . . . . 7
3.2. Mode Choice Policies . . . . . . . . . . . . . . . . . . 8
3.3. Trusted Public Keys . . . . . . . . . . . . . . . . . . . 8
3.4. The AuthenticatedSafe . . . . . . . . . . . . . . . . . . 9
4. PFX PDU Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. The AuthenticatedSafe Type . . . . . . . . . . . . . . . 11
4.2. The SafeBag Type . . . . . . . . . . . . . . . . . . . . 12
4.2.1. The KeyBag Type . . . . . . . . . . . . . . . . . . . 13
4.2.2. The PKCS8ShroudedKeyBag Type . . . . . . . . . . . . 13
4.2.3. The CertBag Type . . . . . . . . . . . . . . . . . . 13
4.2.4. The CRLBag Type . . . . . . . . . . . . . . . . . . . 14
4.2.5. The SecretBag Type . . . . . . . . . . . . . . . . . 14
4.2.6. The SafeContents Type . . . . . . . . . . . . . . . . 14
5. Using PFX PDUs . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating PFX PDUs . . . . . . . . . . . . . . . . . . . . 15
5.2. Importing Keys, etc., from a PFX PDU . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Normative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Message Authentication Codes (MACs) . . . . . . . . 19
Appendix B. Deriving Keys and IVs from Passwords and Salt . . . 19
B.1. Password Formatting . . . . . . . . . . . . . . . . . . . 19
B.2. General Method . . . . . . . . . . . . . . . . . . . . . 20
B.3. More on the ID Byte . . . . . . . . . . . . . . . . . . . 22
B.4. Keys for Password Integrity Mode . . . . . . . . . . . . 22
Appendix C. Keys and IVs for Password Privacy Mode . . . . . . . 22
Appendix D. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 24
Appendix E. Intellectual Property Considerations . . . . . . . . 28
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 28
Appendix G. About PKCS . . . . . . . . . . . . . . . . . . . . . 28
This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. RSA and its parent company EMC reserve the right to continue publishing and distributing PKCS #12 v1.1 and its predecessors.
このドキュメントは、RSA Laboratoriesの公開鍵暗号化標準（PKCS）シリーズからのPKCS＃12 v1.1の再版を表しています。このRFCを公開することにより、変更管理がIETFに移されます。 RSAおよびその親会社であるEMCは、PKCS＃12 v1.1およびその先行製品を引き続き公開および配布する権利を留保します。
The body of this document, except for the Security Considerations section, is taken directly from the PKCS #12 v1.1 specification. The list of references and the in-line cites have been updated or added where appropriate to cite the most current documents in addition to those current at the original publication of PKCS #12 v1.1.
このドキュメントの本文は、「セキュリティに関する考慮事項」セクションを除き、PKCS＃12 v1.1仕様から直接引用しています。参照のリストとインライン引用は、PKCS＃12 v1.1の最初の出版物にある最新のドキュメントに加えて、最新のドキュメントを引用するために適切に更新または追加されています。
This standard describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information.
この規格は、秘密鍵、証明書、その他の秘密、拡張機能など、個人のアイデンティティ情報の転送構文について説明しています。この標準をサポートするマシン、アプリケーション、ブラウザ、インターネットキオスクなどを使用すると、ユーザーは単一の個人識別情報のセットをインポート、エクスポート、および実行できます。
This standard supports direct transfer of personal information under several privacy and integrity modes. The most secure of the privacy and integrity modes require the source and destination platforms to have trusted public/private key pairs usable for digital signatures and encryption, respectively. The standard also supports lower-security, password-based privacy and integrity modes for those cases where trusted public/private key pairs are not available.
この標準は、いくつかのプライバシーおよび整合性モードでの個人情報の直接転送をサポートしています。最も安全なプライバシーモードと整合性モードでは、送信元プラットフォームと宛先プラットフォームに、それぞれデジタル署名と暗号化に使用できる信頼できる公開キーと秘密キーのペアが必要です。この規格は、信頼性の高い公開鍵と秘密鍵のペアが利用できない場合のために、セキュリティの低いパスワードベースのプライバシーモードと整合性モードもサポートしています。
This standard should be amenable to both software and hardware implementations. Hardware implementations offer physical security in tamper-resistant tokens such as smart cards and Personal Computer Memory Card International Association (PCMCIA) devices.
この標準は、ソフトウェアとハードウェアの両方の実装に対応できる必要があります。ハードウェアの実装により、スマートカードやPCMCIA（Personal Computer Memory Card International Association）デバイスなどの改ざん防止トークンに物理的なセキュリティが提供されます。
This standard can be viewed as building on PKCS #8 [15] [24] by including essential but ancillary identity information along with private keys and by instituting higher security through public-key privacy and integrity modes.
この標準は、PKCS＃8 [15] [24]に基づいて構築されていると見なすことができます。必須ではありますが補助的なID情報を秘密鍵とともに含めることと、公開鍵のプライバシーおよび整合性モードを通じてより高いセキュリティを導入することによって。
This document transfers PKCS #12 [16] into the IETF and includes some minor changes from the authors for this submission.
このドキュメントは、PKCS＃12 [16]をIETFに転送し、この提出に関する著者からのいくつかのマイナーな変更を含みます。
o Addition of hash algorithms.
o ハッシュアルゴリズムの追加。
o Incorporation of Technical Corrigendum #1, which makes some minor corrections to the ASN.1 syntax.
o ASN.1構文にいくつかのマイナーな修正を行うTechnical Corrigendum＃1の組み込み。
o Removed (from the ASN.1 syntax) 1024 as an example of the iteration count.
o 反復カウントの例として（ASN.1構文から）1024を削除しました。
o Addition of a recommendation that the technique in Appendix B no longer be used for a specific mode (password privacy mode) and that techniques from PKCS#5 v2.1 be used instead.
o 付録Bの手法を特定のモード（パスワードプライバシーモード）に使用せず、代わりにPKCS＃5 v2.1の手法を使用するという推奨事項を追加。
o Addition of comments and minor corrections to the ASN.1 module in Appendix C.
o 付録CのASN.1モジュールへのコメントの追加とマイナーな修正。
o Removal of the export regulations discussion in the former Appendix D.
o 以前の付録Dの輸出規制に関する議論の削除。
o Replacement of RSA with EMC in the "Intellectual Property Considerations".
o 「知的財産に関する考慮事項」のRSAからEMCへの置き換え。
o Many changes and additions to the references.
o 参照への多くの変更と追加。
o A reference was added to NIST SP 800-132 for its recommendations on selection of the iteration count value for password integrity (part of dictionary-attack resistance).
o パスワードの整合性（辞書攻撃に対する耐性の一部）の反復カウント値の選択に関する推奨事項について、NIST SP 800-132に参照が追加されました。
o Comment included on acronym expansion of PFX: The acronym is sometimes expanded as Personal Information Exchange.
o PFXの頭字語の拡張に関するコメント：頭字語は、Personal Information Exchangeとして拡張される場合があります。
o In Appendix B, the phrase "no longer recommended" was changed to "not recommended" in the following sentence to address a question and make it clear the method was not recommended: "Note that this method for password privacy mode is no longer recommended."
o 付録Bでは、質問に対処し、方法が推奨されていないことを明確にするために、次の文で「推奨されなくなりました」というフレーズが「推奨されません」に変更されました。「パスワードプライバシーモードのこの方法は推奨されなくなりました。 」
AlgorithmIdentifier: An ASN.1 type that identifies an algorithm (by an object identifier) and any associated parameters. This type is defined in [8].
AlgorithmIdentifier：（オブジェクト識別子によって）アルゴリズムと関連するパラメーターを識別するASN.1タイプ。このタイプは[8]で定義されています。
ASN.1: Abstract Syntax Notation One, as defined in [2], [3], [4], and [5].
ASN.1：[2]、[3]、[4]、および[5]で定義されている抽象構文記法1。
Attribute: An ASN.1 type that identifies an attribute type (by an object identifier) and an associated attribute value. The ASN.1 type Attribute is defined in [7].
属性：（オブジェクト識別子によって）属性タイプと関連する属性値を識別するASN.1タイプ。 ASN.1タイプの属性は[7]で定義されています。
Certificate: A digitally signed data unit binding a public key to identity information. A specific format for identity certificates is defined in [8]. Another format is described in [17].
証明書：公開鍵を識別情報にバインドするデジタル署名されたデータ単位。 ID証明書の特定の形式は、[8]で定義されています。別のフォーマットは[17]で説明されています。
Certificate Revocation List (CRL): A digitally signed list of certificates that should no longer be honored, having been revoked by the issuers or a higher authority. One format for CRLs is defined in [8].
証明書失効リスト（CRL）：デジタル署名された証明書のリストで、発行者または上位の機関によって失効したために、もはや尊重されるべきではありません。 CRLの1つの形式は、[8]で定義されています。
ContentInfo: An ASN.1 type used to hold data that may have been cryptographically protected. This type is defined in [21] and [14].
ContentInfo：暗号で保護されたデータを保持するために使用されるASN.1タイプ。このタイプは、[21]と[14]で定義されています。
DER: Distinguished Encoding Rules, as defined in [6].
DER：[6]で定義されているDistinguished Encoding Rules。
Destination platform: The ultimate, final target platform for the personal information originating from the source platform. Even though certain information may be transported from the destination platform to the source platform, the ultimate target for personal information is always called the destination platform.
宛先プラットフォーム：ソースプラットフォームから発信された個人情報の最終的な最終ターゲットプラットフォーム。特定の情報が宛先プラットフォームからソースプラットフォームに転送される場合でも、個人情報の最終的なターゲットは常に宛先プラットフォームと呼ばれます。
DigestInfo: An ASN.1 type used to hold a message digest. This type is defined in [21] and [14].
DigestInfo：メッセージダイジェストを保持するために使用されるASN.1タイプ。このタイプは、[21]と[14]で定義されています。
Encryption Key Pair (DestEncK): A public/private key pair used for the public-key privacy mode of this standard. The public half is called PDestEncK (TPDestEncK when emphasizing that the public key is "trusted"), and the private half is called VDestEncK.
暗号化キーペア（DestEncK）：この標準の公開キープライバシーモードに使用される公開/秘密キーペア。公開の半分はPDestEncK（公開鍵が「信頼できる」ことを強調する場合はTPDestEncK）と呼ばれ、秘密の半分はVDestEncKと呼ばれます。
Export time: The time that a user reads personal information from a source platform and transforms the information into an interoperable, secure Protocol Data Unit (PDU).
エクスポート時間：ユーザーがソースプラットフォームから個人情報を読み取り、その情報を相互運用可能な安全なプロトコルデータユニット（PDU）に変換する時間。
Import time: The time that a user writes personal information from a Safe PDU to a destination platform.
インポート時間：ユーザーがSafe PDUから宛先プラットフォームに個人情報を書き込む時間。
Message Authentication Code (MAC): A type of collision-resistant, "unpredictable" function of a message and a secret key. MACs are used for data authentication and are akin to secret-key digital signatures in many respects.
メッセージ認証コード（MAC）：メッセージと秘密鍵の衝突耐性があり、「予測できない」機能の一種。 MACはデータ認証に使用され、多くの点で秘密鍵のデジタル署名に似ています。
Object Identifier: A sequence of integers that uniquely identifies an associated data object in a global name space administrated by a hierarchy of naming authorities. This is a primitive data type in ASN.1.
オブジェクト識別子：ネーミングオーソリティの階層によって管理されるグローバルネームスペース内の関連データオブジェクトを一意に識別する一連の整数。これはASN.1のプリミティブデータ型です。
PFX: The top-level exchange PDU defined in this standard. The acronym is sometimes expanded as Personal Information Exchange.
PFX：この規格で定義されている最上位の交換PDU。頭字語は、Personal Information Exchangeとして拡張されることがあります。
Platform: A combination of machine, operating system, and applications software within which the user exercises personal identity. An application, in this context, is software that uses personal information. Two platforms differ if their machine types differ or if their applications software differs. There is at least one platform per user in multi-user systems.
プラットフォーム：ユーザーが個人のアイデンティティを行使するマシン、オペレーティングシステム、およびアプリケーションソフトウェアの組み合わせ。この文脈でのアプリケーションは、個人情報を使用するソフトウェアです。 2つのプラットフォームは、マシンタイプが異なる場合、またはアプリケーションソフトウェアが異なる場合に異なります。マルチユーザーシステムでは、ユーザーごとに少なくとも1つのプラットフォームがあります。
Protocol Data Unit (PDU): A sequence of bits in machine-independent format constituting a message in a protocol.
プロトコルデータユニット（PDU）：プロトコルのメッセージを構成する、マシンに依存しない形式の一連のビット。
Shrouding: Encryption as applied to private keys, possibly in concert with a policy that prevents the plaintext of the key from ever being visible beyond a certain, well-defined interface.
シュラウド：秘密キーに適用される暗号化。おそらく、特定の明確に定義されたインターフェイスを越えてキーのプレーンテキストが表示されないようにするポリシーと連携しています。
Signature Key Pair (SrcSigK): A platform-specific signature key pair used for the public-key integrity mode of this standard. The public half is called PSrcSigK (TPSrcSigK when emphasizing that the public key is "trusted"), and the private half is called VSrcSigK.
署名鍵ペア（SrcSigK）：この標準の公開鍵整合性モードに使用されるプラットフォーム固有の署名鍵ペア。パブリックハーフはPSrcSigK（パブリックキーが「信頼できる」ことを強調する場合はTPSrcSigK）と呼ばれ、プライベートハーフはVSrcSigKと呼ばれます。
Source platform: The origin platform of the personal information ultimately intended for the destination platform. Even though certain information may be transported from the destination platform to the source platform, the platform that is the origin of personal information is always called the source platform.
ソースプラットフォーム：最終的に宛先プラットフォームを対象とした個人情報の発信元プラットフォーム。特定の情報が宛先プラットフォームからソースプラットフォームに転送される場合でも、個人情報の発信元であるプラットフォームは常にソースプラットフォームと呼ばれます。
There are four combinations of privacy modes and integrity modes. The privacy modes use encryption to protect personal information from exposure, and the integrity modes protect personal information from tampering. Without protection from tampering, an adversary could conceivably substitute invalid information for the user's personal information without the user being aware of the substitution.
プライバシーモードと整合性モードの4つの組み合わせがあります。プライバシーモードは暗号化を使用して個人情報を公開から保護し、整合性モードは個人情報を改ざんから保護します。改ざんからの保護がなければ、攻撃者はユーザーの個人情報をユーザーが気付かないうちに無効な情報に置き換える可能性があります。
The following are the privacy modes:
プライバシーモードは次のとおりです。
o Public-key privacy mode: Personal information is enveloped on the source platform using a trusted encryption public key of a known destination platform (see Section 3.3). The envelope is opened with the corresponding private key.
o 公開キープライバシーモード：既知の宛先プラットフォームの信頼できる暗号化公開キーを使用して、個人情報がソースプラットフォームに埋め込まれます（セクション3.3を参照）。エンベロープは、対応する秘密鍵で開かれます。
o Password privacy mode: Personal information is encrypted with a symmetric key derived from a user name and a privacy password, as in [22] and [13]. If password integrity mode is used as well, the privacy password and the integrity password may or may not be the same.
o パスワードプライバシーモード：個人情報は、[22]や[13]のように、ユーザー名とプライバシーパスワードから派生した対称キーで暗号化されます。パスワード整合性モードも使用されている場合、プライバシーパスワードと整合性パスワードは同じ場合と同じでない場合があります。
The following are the integrity modes:
整合性モードは次のとおりです。
o Public-key integrity mode: Integrity is guaranteed through a digital signature on the contents of the PFX PDU, which is produced using the source platform's private signature key. The signature is verified on the destination platform by using the corresponding public key (see Section 3.4).
o 公開鍵整合性モード：整合性は、ソースプラットフォームの秘密署名鍵を使用して生成されるPFX PDUのコンテンツのデジタル署名によって保証されます。署名は、対応する公開鍵を使用して宛先プラットフォームで検証されます（セクション3.4を参照）。
o Password integrity mode: Integrity is guaranteed through a Message Authentication Code (MAC) derived from a secret integrity password. If password privacy mode is used as well, the privacy password and the integrity password may or may not be the same.
o パスワード整合性モード：整合性は、秘密の整合性パスワードから派生したメッセージ認証コード（MAC）によって保証されます。パスワードプライバシーモードも使用する場合、プライバシーパスワードと整合性パスワードは同じ場合と同じでない場合があります。
All combinations of the privacy and integrity modes are permitted in this standard. Of course, good security policy suggests that certain practices be avoided, e.g., it can be unwise to transport private keys without physical protection when using password privacy mode or when using public-key privacy mode with weak symmetric encryption.
この標準では、プライバシーモードと整合性モードのすべての組み合わせが許可されています。もちろん、適切なセキュリティポリシーは、特定のプラクティスを回避することを推奨しています。たとえば、パスワードプライバシーモードを使用する場合、または弱い対称暗号化で公開キープライバシーモードを使用する場合、物理的な保護なしに秘密キーを転送することは賢明ではありません。
In general, the public-key modes for both privacy and integrity are preferable to the password modes (from a security viewpoint). However, it is not always possible to use the public-key modes. For example, it may not be known at export time what the destination platform is; if this is the case, then the use of the public-key privacy mode is precluded.
一般に、プライバシーと整合性の両方の公開鍵モードは、（セキュリティの観点から）パスワードモードよりも望ましい方法です。ただし、公開鍵モードを常に使用できるとは限りません。たとえば、エクスポート時に宛先プラットフォームが何であるかがわからない場合があります。この場合、公開キープライバシーモードの使用は禁止されます。
Asymmetric key pairs may be used in this standard in two ways: public-key privacy mode and public-key integrity mode. For public-key privacy mode, an encryption key pair is required; for public-key integrity mode, a signature key pair is required.
この標準では、非対称キーペアを2つの方法で使用できます。公開キープライバシーモードと公開キー整合性モードです。公開鍵プライバシーモードの場合、暗号化鍵のペアが必要です。公開鍵整合性モードでは、署名鍵のペアが必要です。
It may be appropriate for the keys discussed in this section to be platform-specific keys dedicated solely for the purpose of transporting a user's personal information. Whether or not that is the case, though, the keys discussed here should not be confused with the user's personal keys that the user wishes to transport from one platform to another. (These latter keys are stored within the PDU.) For public-key privacy mode, the private key from the encryption key pair is kept on the destination platform, where it is ultimately used to open a private envelope. The corresponding trusted public key is called TPDestEncK.
このセクションで説明するキーは、ユーザーの個人情報の転送のみを目的としたプラットフォーム固有のキーであることが適切な場合があります。ただし、そうであろうとなかろうと、ここで説明するキーは、ユーザーがあるプラットフォームから別のプラットフォームに転送したいユーザーの個人キーと混同しないようにしてください。 （これらの後者の鍵はPDU内に格納されます。）公開鍵プライバシーモードの場合、暗号化鍵ペアの秘密鍵は宛先プラットフォームに保持され、最終的には秘密エンベロープを開くために使用されます。対応する信頼できる公開鍵はTPDestEncKと呼ばれます。
For public-key integrity mode, the private key from the signature pair is kept on the source platform, where it is used to sign personal information. The corresponding trusted public key is called TPSrcSigK.
公開鍵整合性モードの場合、署名ペアの秘密鍵はソースプラットフォームに保持され、個人情報の署名に使用されます。対応する信頼できる公開鍵はTPSrcSigKと呼ばれます。
For both uses of public/private key pairs, the public key from the key pair must be transported to the other platform such that it is trusted to have originated at the correct platform. Judging whether or not a public key is trusted in this sense must ultimately be left to the user. There are a variety of methods for ensuring that a public key is trusted.
公開鍵と秘密鍵のペアを両方使用する場合、正しいペアで発信されたと信頼されるように、鍵ペアからの公開鍵を他のプラットフォームに転送する必要があります。この意味で公開鍵が信頼できるかどうかの判断は、最終的にはユーザーに任せる必要があります。公開鍵が信頼できることを確認するには、さまざまな方法があります。
The processes of imbuing keys with trust and of verifying trustworthiness of keys are not discussed further in this document. Whenever asymmetric keys are discussed in what follows, the public keys are assumed to be trusted.
このドキュメントでは、信頼にキーを埋め込むプロセス、およびキーの信頼性を検証するプロセスについては、これ以上説明しません。以下で非対称鍵について説明する場合は常に、公開鍵は信頼されていると見なされます。
Each compliant platform shall be able to import and export AuthenticatedSafe PDUs wrapped in PFX PDUs.
各準拠プラットフォームは、PFX PDUでラップされたAuthenticatedSafe PDUをインポートおよびエクスポートできる必要があります。
For integrity, the AuthenticatedSafe is either signed (if public-key integrity mode is used) or MACed (if password integrity mode is used) to produce a PFX PDU. If the AuthenticatedSafe is signed, then it is accompanied by a digital signature, which was produced on the source platform with a private signature key, VSrcSigK, corresponding to a trusted public signature key, TPSrcSigK. TPSrcSigK must accompany the PFX to the destination platform, where the user can verify the trust in the key and can verify the signature on the AuthenticatedSafe. If the AuthenticatedSafe is MACed, then it is accompanied by a MAC computed from a secret integrity password, salt bits, an iteration count, and the contents of the AuthenticatedSafe.
完全性のために、AuthenticatedSafeは署名されているか（公開鍵完全性モードが使用されている場合）、MACされているか（パスワード完全性モードが使用されている場合）、PFX PDUを生成します。 AuthenticatedSafeが署名されている場合は、信頼できる公開署名鍵TPSrcSigKに対応する秘密署名鍵VSrcSigKを使用してソースプラットフォームで作成されたデジタル署名が付随しています。 TPSrcSigKは、PFXを宛先プラットフォームに添付する必要があります。宛先プラットフォームでは、ユーザーはキーの信頼を確認でき、AuthenticatedSafeの署名を確認できます。 AuthenticatedSafeがMACedの場合、秘密の整合性パスワード、ソルトビット、反復回数、およびAuthenticatedSafeの内容から計算されたMACが付随します。
The AuthenticatedSafe itself consists of a sequence of ContentInfo values, some of which may consist of plaintext (data), and others that may either be enveloped (if public-key privacy mode is used) or encrypted (if password privacy mode is used). If the contents are enveloped, then they are encrypted with a symmetric cipher under a freshly generated key, which is in turn encrypted with RSA asymmetric encryption. The RSA public key used to encrypt the symmetric key is called TPDestEncK and corresponds to an RSA private key, VDestEncK, on the destination platform. TPDestEncK needs to be trusted by the user when it is used at export time. If the contents are encrypted, then they are encrypted with a symmetric cipher under a key derived from a secret privacy password, salt bits, and an iteration counter.
AuthenticatedSafe自体は、一連のContentInfo値で構成され、その一部はプレーンテキスト（データ）で構成され、その他はエンベロープ（公開鍵プライバシーモードが使用されている場合）または暗号化（パスワードプライバシーモードが使用されている場合）の可能性があります。コンテンツがエンベロープされている場合、新しく生成された鍵の下で対称暗号で暗号化され、次にRSA非対称暗号で暗号化されます。対称鍵の暗号化に使用されるRSA公開鍵はTPDestEncKと呼ばれ、宛先プラットフォームのRSA秘密鍵VDestEncKに対応します。 TPDestEncKは、エクスポート時に使用される場合、ユーザーが信頼する必要があります。コンテンツが暗号化されている場合、秘密のプライバシーパスワード、ソルトビット、および反復カウンターから派生したキーの下で対称暗号で暗号化されます。
Each ContentInfo contains an arbitrary collection of private keys, PKCS #8-shrouded private keys, certificates, CRLs, or opaque data objects, at the user's discretion, stored in values of type SafeContents.
各ContentInfoには、プライベートコンテンツの任意のコレクション、PKCS＃8で覆われたプライベートキー、証明書、CRL、または不透明なデータオブジェクトが、ユーザーの裁量で、SafeContentsタイプの値に格納されて含まれています。
The raison d'etre for the unencrypted option is that some governments restrict certain uses of cryptography. Having several parts in an AuthenticatedSafe keeps implementers' options open. For example, it may be the case that strong cryptography can be used to make PKCS #8-shrouded keys, but then these shrouded keys should not be further encrypted, because super-encryption can limit a product's exportability. The multi-part AuthenticatedSafe design permits this possibility.
暗号化されていないオプションの存在理由は、一部の政府が暗号化の特定の使用を制限することです。 AuthenticatedSafeにいくつかの部分があると、実装者のオプションが開いたままになります。たとえば、強力な暗号化を使用してPKCS＃8で覆われた鍵を作成できる場合がありますが、スーパー暗号化は製品の輸出可能性を制限する可能性があるため、これらの覆われた鍵をさらに暗号化しないでください。マルチパートのAuthenticatedSafeデザインは、この可能性を可能にします。
Around the AuthenticatedSafe is the integrity-mode wrapper, which protects the entire contents of the AuthenticatedSafe (including unencrypted parts, if they are present). This is the reverse of the wrapping order in many protocols, in which privacy is the outermost protection. This latter, more-common wrapping order avoids signatures on encrypted data, which are undesirable under certain circumstances; however, these circumstances do not apply to this document, and it is therefore preferable to protect the integrity of as much information as possible.
AuthenticatedSafeの周囲には整合性モードラッパーがあり、AuthenticatedSafeの内容全体（存在する場合は暗号化されていない部分を含む）を保護します。これは、プライバシーが最も外側の保護である多くのプロトコルのラッピング順序の逆です。この後者のより一般的なラッピング順序は、特定の状況では望ましくない暗号化データの署名を回避します。ただし、これらの状況はこのドキュメントには適用されないため、できるだけ多くの情報の整合性を保護することが推奨されます。
This format corresponds to the data model presented above, with wrappers for privacy and integrity. This section makes free reference to PKCS #7 [14] [21] and assumes the reader is familiar with terms defined in that document.
このフォーマットは、プライバシーと整合性のためのラッパーを使用して、上記のデータモデルに対応しています。このセクションでは、PKCS＃7 [14] [21]を無料で参照し、読者がそのドキュメントで定義されている用語に精通していることを前提としています。
All modes of direct exchange use the same PDU format. ASN.1 and BER-encoding ensure platform independence.
直接交換のすべてのモードは、同じPDUフォーマットを使用します。 ASN.1およびBERエンコードにより、プラットフォームの独立性が保証されます。
This standard has one ASN.1 export: PFX. This is the outer integrity wrapper. Instances of PFX contain:
この標準には、1つのASN.1エクスポート（PFX）があります。これは、外部整合性ラッパーです。 PFXのインスタンスには以下が含まれます。
1. A version indicator. The version shall be v3 for this version of this document.
1. バージョンインジケーター。このドキュメントのこのバージョンのバージョンはv3です。
2. A PKCS #7 ContentInfo, whose contentType is signedData in public-key integrity mode and data in password integrity mode.
2. PKCS＃7 ContentInfo。そのcontentTypeは、公開鍵整合性モードではsignedDataであり、パスワード整合性モードではデータです。
3. An optional instance of MacData, present only in password integrity. This object, if present, contains a PKCS #7 DigestInfo, which holds the MAC value, a macSalt, and an iterationCount. As described in Appendix B, the MAC key is derived from the password, the macSalt, and the iterationCount; as described in Section 5, the MAC is computed from the authSafe value and the MAC key via HMAC [11] [20]. The password and the MAC key are not actually present anywhere in the PFX. The salt and (to a certain extent) the iteration count thwarts dictionary attacks against the integrity password. See NIST Special Publication 800-132 [12] about how to choose a reasonable value for the iteration count.
3. MacDataのオプションのインスタンス。パスワードの整合性でのみ存在します。このオブジェクトが存在する場合、PKCS＃7 DigestInfoが含まれます。これには、MAC値、macSalt、およびiterationCountが保持されます。付録Bで説明されているように、MACキーはパスワード、macSalt、およびiterationCountから導出されます。セクション5で説明されているように、MACはauthSafe値とMACキーからHMAC [11] [20]を介して計算されます。パスワードとMACキーは、実際にはPFXのどこにも存在しません。ソルトと（ある程度）反復回数は、整合性パスワードに対する辞書攻撃を阻止します。反復回数の妥当な値を選択する方法については、NIST Special Publication 800-132 [12]を参照してください。
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
MacData ::= SEQUENCE {
mac DigestInfo,
macSalt OCTET STRING,
iterations INTEGER DEFAULT 1
-- Note: The default is for historical reasons and its
-- use is deprecated.
}
As mentioned, the contentType field of authSafe shall be of type data or signedData. The content field of the authSafe shall, either directly (data case) or indirectly (signedData case), contain a BER-encoded value of type AuthenticatedSafe.
前述のように、authSafeのcontentTypeフィールドは、データ型またはsignedData型でなければなりません。 authSafeのcontentフィールドには、直接的（データの場合）または間接的（signedDataの場合）に、タイプAuthenticatedSafeのBERエンコード値が含まれます。
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
An AuthenticatedSafe contains a sequence of ContentInfo values. The content field of these ContentInfo values contains either plaintext, encrypted, or enveloped data. In the case of encrypted or enveloped data, the plaintext of the data holds the BER-encoding of an instance of SafeContents. Section 5.1 of this document describes the construction of values of type AuthenticatedSafe in more detail.
AuthenticatedSafeには、ContentInfo値のシーケンスが含まれています。これらのContentInfo値のコンテンツフィールドには、プレーンテキスト、暗号化、またはエンベロープデータのいずれかが含まれています。暗号化またはエンベロープされたデータの場合、データの平文はSafeContentsのインスタンスのBERエンコードを保持します。このドキュメントのセクション5.1では、AuthenticatedSafeタイプの値の構成について詳しく説明しています。
The SafeContents type is made up of SafeBags. Each SafeBag holds one piece of information -- a key, a certificate, etc. -- which is identified by an object identifier.
SafeContentsタイプはSafeBagsで構成されています。各SafeBagは、オブジェクト識別子によって識別される1つの情報（キー、証明書など）を保持します。
SafeContents ::= SEQUENCE OF SafeBag
SafeBag ::= SEQUENCE {
bagId BAG-TYPE.&id ({PKCS12BagSet})
bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
bagAttributes SET OF PKCS12Attribute OPTIONAL
}
PKCS12Attribute ::= SEQUENCE {
attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type 'Attribute'
PKCS12AttrSet ATTRIBUTE ::= {
friendlyName | -- from PKCS #9 [23]
localKeyId, -- from PKCS #9
... -- Other attributes are allowed
}
The optional bagAttributes field allows users to assign nicknames and identifiers to keys, etc., and permits visual tools to display meaningful strings of some sort to the user.
オプションのbagAttributesフィールドを使用すると、ニックネームや識別子をキーなどに割り当てることができ、視覚的なツールで何らかの意味のある文字列をユーザーに表示できます。
Six types of SafeBags are defined in this version of this document:
このドキュメントのこのバージョンでは、6種類のSafeBagが定義されています。
bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
BAG-TYPE ::= TYPE-IDENTIFIER
keyBag BAG-TYPE ::=
{KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE ::=
{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=
{CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=
{CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=
{SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=
{SafeContents IDENTIFIED BY {bagtypes 6}}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
... -- For future extensions
}
As new bag types become recognized in future versions of this standard, the PKCS12BagSet may be extended.
この規格の将来のバージョンで新しいバッグタイプが認識されるようになると、PKCS12BagSetが拡張される可能性があります。
A KeyBag is a PKCS #8 PrivateKeyInfo. Note that a KeyBag contains only one private key.
KeyBagはPKCS＃8 PrivateKeyInfoです。 KeyBagには秘密鍵が1つだけ含まれていることに注意してください。
KeyBag ::= PrivateKeyInfo
A PKCS8ShroudedKeyBag holds a private key, which has been shrouded in accordance with PKCS #8. Note that a PKCS8ShroudedKeyBag holds only one shrouded private key.
PKCS8ShroudedKeyBagは、PKCS＃8に従ってシュラウド化された秘密鍵を保持します。 PKCS8ShroudedKeyBagが保持する秘密鍵は1つだけであることに注意してください。
PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo
A CertBag contains a certificate of a certain type. Object identifiers are used to distinguish between different certificate types.
CertBagには、特定のタイプの証明書が含まれています。オブジェクト識別子は、異なる証明書タイプを区別するために使用されます。
CertBag ::= SEQUENCE {
certId BAG-TYPE.&id ({CertTypes}),
certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}
x509Certificate BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING
sdsiCertificate BAG-TYPE ::=
{IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String
CertTypes BAG-TYPE ::= {
x509Certificate |
sdsiCertificate,
... -- For future extensions
}
A CRLBag contains a Certificate Revocation List (CRL) of a certain type. Object identifiers are used to distinguish between different CRL types.
CRLBagには、特定のタイプの証明書失効リスト（CRL）が含まれています。オブジェクト識別子は、異なるCRLタイプを区別するために使用されます。
CRLBag ::= SEQUENCE {
crlId BAG-TYPE.&id ({CRLTypes}),
crlValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}
x509CRL BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {crlTypes 1}}
-- DER-encoded X.509 CRL stored in OCTET STRING
CRLTypes BAG-TYPE ::= {
x509CRL,
... -- For future extensions
}
Each of the user's miscellaneous personal secrets is contained in an instance of SecretBag, which holds an object identifier-dependent value. Note that a SecretBag contains only one secret.
ユーザーのその他の個人的な秘密はそれぞれ、オブジェクト識別子に依存する値を保持するSecretBagのインスタンスに含まれています。 SecretBagに含まれる秘密は1つだけであることに注意してください。
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
SecretTypes BAG-TYPE ::= {
... -- For future extensions
}
Implementers can add values to this set at their own discretion.
実装者は、独自の裁量でこのセットに値を追加できます。
The sixth type of bag that can be held in a SafeBag is a SafeContents. This recursive structure allows for arbitrary nesting of multiple KeyBags, PKCS8ShroudedKeyBags, CertBags, CRLBags, and SecretBags within the top-level SafeContents.
SafeBagに保持できる6番目のタイプのバッグはSafeContentsです。この再帰的な構造により、最上位のSafeContents内で複数のKeyBag、PKCS8ShroudedKeyBags、CertBags、CRLBags、およびSecretBagsを任意にネストできます。
This section describes the creation and usage of PFX PDUs.
このセクションでは、PFX PDUの作成と使用法について説明します。
The steps for creating PFX PDUs are as follows.
PFX PDUを作成する手順は次のとおりです。
1. It is somewhat clear from the ASN.1 how to make a number of instances of SafeContents, each containing a number of (possibly nested) instances of SafeBag. Let us assume, therefore, a number of instances SC_1, SC_2,..., SC_n of SafeContents. Note that there can be a more or less arbitrary number of instances of SafeContents in a PFX PDU. As will be seen in step 2, each instance can be encrypted (or not) separately.
1. ASN.1から、いくつものSafeBagのインスタンス（入れ子になっている可能性がある）を含むSafeContentsのインスタンスを作成する方法がいくらか明らかになっています。したがって、SafeContentsのインスタンスSC_1、SC_2、...、SC_nの数を想定します。 PFX PDUには、任意の数のSafeContentsのインスタンスが存在する可能性があることに注意してください。ステップ2でわかるように、各インスタンスは個別に暗号化できます（暗号化できません）。
2. For each SCI, depending on the chosen encryption option,
2. SCIごとに、選択した暗号化オプションに応じて、
A. If SC_i is not to be encrypted, make a ContentInfo CI_i holding content type Data. The contents of the Data OCTET STRING shall be a BER-encoding of SC_i (including tag, length, and value octets).
A. SC_iを暗号化しない場合は、コンテンツタイプデータを保持するContentInfo CI_iを作成します。 Data OCTET STRINGの内容は、SC_iのBERエンコード（タグ、長さ、値のオクテットを含む）でなければなりません。
B. If SC_i is to be encrypted with a password, make a ContentInfo CI_i of type EncryptedData. The encryptedContentInfo field of CI_i has its contentType field set to data and its encryptedContent field set to the encryption of the BER-encoding of SC_i (note that the tag and length octets shall be present).
B. SC_iをパスワードで暗号化する場合は、EncryptedDataタイプのContentInfo CI_iを作成します。 CI_iのencryptedContentInfoフィールドのcontentTypeフィールドはdataに設定され、encryptedContentフィールドはSC_iのBERエンコードの暗号化に設定されます（タグと長さのオクテットが存在することに注意してください）。
C. If SC_i is to be encrypted with a public key, make a ContentInfo CI_i of type EnvelopedData in essentially the same fashion as the EncryptedData ContentInfo was made in B.
C. SC_iを公開鍵で暗号化する場合は、Bで作成されたEncryptedData ContentInfoと基本的に同じ方法で、EnvelopedDataタイプのContentInfo CI_iを作成します。
3. Make an instance of AuthenticatedSafe by stringing together the CI_i's in a SEQUENCE.
3. シーケンス内のCI_iをつなぎ合わせて、AuthenticatedSafeのインスタンスを作成します。
4. Make a ContentInfo T holding content type Data. The contents of the Data OCTET STRING shall be a BER-encoding of the AuthenticatedSafe value (including tag, length, and value octets).
4. コンテンツタイプDataを保持するContentInfo Tを作成します。 Data OCTET STRINGの内容は、AuthenticatedSafe値（タグ、長さ、および値のオクテットを含む）のBERエンコードです。
5. For integrity protection,
5. 完全性保護のために、
A. If the PFX PDU is to be authenticated with a digital signature, make a ContentInfo C of type SignedData. The contentInfo field of the SignedData in C has T in it. C is the ContentInfo in the top-level PFX structure.
A. PFX PDUがデジタル署名で認証される場合、タイプSignedDataのContentInfo Cを作成します。 CのSignedDataのcontentInfoフィールドには、Tが含まれています。 Cは、最上位のPFX構造のContentInfoです。
B. If the PFX PDU is to be authenticated with HMAC, then an HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 is computed on the contents of the Data in T (i.e., excluding the OCTET STRING tag and length bytes). This is exactly what would be initially digested in step 5A if public-key authentication were being used.
B. PFX PDUがHMACで認証される場合、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512 / 224、またはSHA-512 / 256のHMACはTのデータの内容に基づいて計算されます（つまり、OCTET STRINGタグと長さバイトを除外します）。これは、公開鍵認証が使用されている場合、ステップ5Aで最初に要約されるものとまったく同じです。
Importation from a PFX is accomplished essentially by reversing the procedure for creating a PFX. In general, when an application imports keys, etc., from a PFX, it should ignore any object identifiers that it is not familiar with. At times, it may be appropriate to alert the user to the presence of such object identifiers.
PFXからのインポートは、基本的にPFXを作成する手順を逆にすることで実現されます。一般に、アプリケーションがPFXからキーなどをインポートするときは、慣れていないオブジェクト識別子を無視する必要があります。時には、そのようなオブジェクト識別子の存在をユーザーに警告することが適切な場合があります。
Special care may be taken by the application when importing an item in the PFX would require overwriting an item that already exists locally. The behavior of the application when such an item is encountered may depend on what the item is (i.e., it may be that a PKCS #8-shrouded private key and a CRL should be treated differently here). Appropriate behavior may be to ask the user what action should be taken for this item.
PFXにアイテムをインポートするときに、ローカルに既に存在するアイテムを上書きする必要がある場合、アプリケーションは特別な注意を払うことがあります。このようなアイテムが検出されたときのアプリケーションの動作は、アイテムが何であるかによって異なります（つまり、PKCS＃8で覆われた秘密鍵とCRLは、ここでは異なる方法で処理する必要がある場合があります）。適切な動作は、このアイテムに対して実行する必要があるアクションをユーザーに尋ねることです。
When using passwords in privacy or integrity mode, it needs to be considered that password-based cryptography is generally limited in the security that it can provide, particularly for methods such as those defined in this document where off-line password search is possible. While the use of salt and iteration count can increase the complexity of attack, it is essential that passwords are selected well and that relevant guidelines (e.g., NIST SP 800-61-1) are taken into account. It is also important that passwords be protected well if stored.
プライバシーモードまたは整合性モードでパスワードを使用する場合、パスワードベースの暗号化は、特にオフラインパスワード検索が可能なこのドキュメントで定義されている方法など、提供できるセキュリティが一般的に制限されていることを考慮する必要があります。ソルトと反復回数を使用すると攻撃が複雑になる可能性がありますが、パスワードを適切に選択し、関連するガイドライン（NIST SP 800-61-1など）を考慮することが不可欠です。保管する場合は、パスワードを適切に保護することも重要です。
When choosing a salt value in password privacy or integrity mode, the recommendations in Section 4 of PKCS #5 2.1 [13] [22] should be taken into account. Ideally, the salt is as long as the output of the hash function being used and consists of randomly generated data.
パスワードプライバシーモードまたは整合性モードでソルト値を選択する場合は、PKCS＃5 2.1 [13] [22]のセクション4の推奨事項を考慮する必要があります。理想的には、ソルトは使用されているハッシュ関数の出力と同じ長さであり、ランダムに生成されたデータで構成されます。
[1] Dobbertin, H., "The status of MD5 after a recent attack.", CryptoBytes Vol. 2, #2, 1996.
[1] Dobbertin、H.、「最近の攻撃後のMD5のステータス」、CryptoBytes Vol。 2、＃2、1996。
[2] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Specification of basic notation", ISO/IEC 8824-1:2008, 2008.
[2] ISO / IEC、「情報技術-抽象構文記法1（ASN.1）-基本記法の仕様」、ISO / IEC 8824-1：2008、2008。
[3] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Information object specification", ISO/IEC 8824-2:2008, 2008.
[3] ISO / IEC、「情報技術-抽象構文記法1（ASN.1）-情報オブジェクト仕様」、ISO / IEC 8824-2：2008、2008。
[4] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Constraint specification", ISO/IEC 88247-3:2008, 2008.
[4] ISO / IEC、「情報技術-抽象構文記法1（ASN.1）-制約仕様」、ISO / IEC 88247-3：2008、2008。
[5] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Parameterization of ASN.1 specifications", ISO/IEC 8824-4:2008, 2008.
[5] ISO / IEC、「情報技術-抽象構文記法1（ASN.1）-ASN.1仕様のパラメーター化」、ISO / IEC 8824-4：2008、2008。
[6] ISO/IEC, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules", ISO/IEC 8825-1:2008, 2008.
[6] ISO / IEC、「情報技術-ASN.1エンコーディングルール：Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）、Distinguished Encoding Rules」、ISO / IEC 8825-1：2008、2008。
[7] ISO/IEC, "Information technology -- Open Systems Interconnection -- The Directory: Models", ISO/IEC 9594-2:1997, 1997.
[7] ISO / IEC、「情報技術-オープンシステムインターコネクション-ディレクトリ：モデル」、ISO / IEC 9594-2：1997、1997。
[8] ISO/IEC, "Information technology -- Open Systems Interconnection -- The Directory: Authentication Framework", ISO/IEC 9594-8:1997, 1997.
[8] ISO / IEC、「情報技術-オープンシステム相互接続-ディレクトリ：認証フレームワーク」、ISO / IEC 9594-8：1997、1997。
[9] Microsoft, "PFX: Personal Exchange Syntax and Protocol Standard", ISO/IEC Version 0.020, January 1997.
[9] Microsoft、「PFX：Personal Exchange Syntax and Protocol Standard」、ISO / IECバージョン0.020、1997年1月。
[10] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS Publication 180-4, March 2012.
[10] 国立標準技術研究所（NIST）、「Secure Hash Standard」、FIPS Publication 180-4、2012年3月。
[11] National Institute of Standards and Technology (NIST), "The Keyed-Hash Message Authentication Code (HMAC)", FIPS Publication 198-1, July 2008.
[11] 米国連邦情報・技術局（NIST）、「Keyed-Hash Message Authentication Code（HMAC）」、FIPS Publication 198-1、2008年7月。
[12] National Institute of Standards and Technology (NIST), "The Recommendation for Password-Based Key Derivation, Part 1: Storage Applications", NIST Special Publication 800-132, December 2010.
[12] 米国連邦情報・技術局（NIST）、「パスワードベースのキー導出に関する推奨事項、パート1：ストレージアプリケーション」、NIST Special Publication 800-132、2010年12月。
[13] RSA Laboratories, "PKCS #5: Password-Based Encryption Standard", PKCS Version 2.1, October 2012.
[13] RSA Laboratories、「PKCS＃5：Password-Based Encryption Standard」、PKCSバージョン2.1、2012年10月。
[14] RSA Laboratories, "PKCS #7: Cryptographic Message Syntax Standard", PKCS Version 1.5, November 1993.
[14] RSA Laboratories、「PKCS＃7：Cryptographic Message Syntax Standard」、PKCSバージョン1.5、1993年11月。
[15] RSA Laboratories, "PKCS #8: Private-Key Information Syntax Standard", PKCS Version 1.2, November 1993.
[15] RSA Laboratories、「PKCS＃8：Private-Key Information Syntax Standard」、PKCSバージョン1.2、1993年11月。
[16] RSA Laboratories, "PKCS #12: Personal Information Exchange Syntax", PKCS Version 1.1, December 2012.
[16] RSA Laboratories、「PKCS＃12：Personal Information Exchange Syntax」、PKCSバージョン1.1、2012年12月。
[17] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed Security Infrastructure", 1996, <http://people.csail.mit.edu/rivest/sdsi10.html>.
[17] Rivest、R.およびB. Lampson、「SDSI-A Simple Distributed Security Infrastructure」、1996、<http://people.csail.mit.edu/rivest/sdsi10.html>。
[18] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, March 2011.
[18] ターナー、S。およびL.チェン、「MD2 to Historic Status」、RFC 6149、2011年3月。
[19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[19] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[20] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[20] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[21] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[21] Kaliski、B。、「PKCS＃7：Cryptographic Message Syntax Version 1.5」、RFC 2315、1998年3月。
[22] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[22] Kaliski、B。、「PKCS＃5：Password-Based Cryptography Specification Version 2.0」、RFC 2898、2000年9月。
[23] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[23] Nystrom、M.およびB. Kaliski、「PKCS＃9：Selected Object Classes and Attribute Types Version 2.0」、RFC 2985、2000年11月。
[24] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[24] ターナー、S。、「非対称キーパッケージ」、RFC 5958、2010年8月。
[25] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[25] ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
Appendix A. Message Authentication Codes (MACs)
付録A.メッセージ認証コード（MAC）
A MAC is a special type of function of a message (data bits) and an integrity key. It can be computed or checked only by someone possessing both the message and the integrity key. Its security follows from the secrecy of the integrity key. In this standard, MACing is used in password integrity mode.
MACは、メッセージ（データビット）と整合性キーの特別なタイプの機能です。メッセージと整合性キーの両方を所有しているユーザーだけが計算またはチェックできます。そのセキュリティは、整合性キーの機密性に基づいています。この標準では、MACはパスワード整合性モードで使用されます。
This document uses a particular type of MAC called HMAC [11] [20], which can be constructed from any of a variety of hash functions. Note that the specifications in [20] and [11] differ somewhat from the specification in [9]. The hash function HMAC is based on is identified in the MacData, which holds the MAC; for this version of this standard, the hash function can be one of the following: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 [10]. As indicated in Appendix B.4, this structure implies that the same hash algorithm must be used to derive the MAC key itself in password integrity mode and that the MAC key has either 160, 224, 256, 384, or 512 bits.
このドキュメントでは、HMAC [11] [20]と呼ばれる特定のタイプのMACを使用しています。これは、さまざまなハッシュ関数のいずれかから構築できます。 [20]と[11]の仕様は、[9]の仕様とは多少異なることに注意してください。 HMACが基づいているハッシュ関数は、MACを保持するMacDataで識別されます。この規格のこのバージョンでは、ハッシュ関数は次のいずれかになります。SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512 / 224、またはSHA-512 / 256 [ 10]。付録B.4に示すように、この構造は、パスワード整合性モードでMACキー自体を導出するために同じハッシュアルゴリズムを使用する必要があり、MACキーが160、224、256、384、または512ビットのいずれかであることを意味します。
When password integrity mode is used to secure a PFX PDU, an HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 is computed on the BER-encoding of the contents of the content field of the authSafe field in the PFX PDU (see Section 5.1).
パスワード完全性モードを使用してPFX PDUを保護すると、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512 / 224、またはSHA-512 / 256を備えたHMACが計算されます。 PFX PDUのauthSafeフィールドのcontentフィールドの内容のBERエンコード（セクション5.1を参照）。
Note that this method for password privacy mode is not recommended and is deprecated for new usage. The procedures and algorithms defined in PKCS #5 v2.1 [13] [22] should be used instead. Specifically, PBES2 should be used as encryption scheme, with PBKDF2 as the key derivation function.
パスワードプライバシーモードのこのメソッドは推奨されておらず、新しい使用法では非推奨であることに注意してください。代わりに、PKCS＃5 v2.1 [13] [22]で定義されている手順とアルゴリズムを使用する必要があります。具体的には、PBES2を暗号化スキームとして使用し、PBKDF2を鍵導出関数として使用する必要があります。
The method presented here is still used to generate the key in password integrity mode.
ここに示す方法は、パスワード整合性モードでキーを生成するために引き続き使用されます。
We present here a general method for using a hash function to produce various types of pseudorandom bits from a password and a string of salt bits. This method is used for password privacy mode and password integrity mode in the present standard.
ここでは、ハッシュ関数を使用して、パスワードとソルトビットの文字列からさまざまなタイプの擬似ランダムビットを生成する一般的な方法を紹介します。この方法は、現在の規格ではパスワードプライバシーモードとパスワード整合性モードに使用されます。
The underlying password-based encryption methods in PKCS #5 v2.1 view passwords (and salt) as being simple byte strings. The underlying password-based encryption methods and the underlying password-based authentication methods in this version of this document are similar.
PKCS＃5 v2.1の基本的なパスワードベースの暗号化方式では、パスワード（およびソルト）を単純なバイト文字列と見なします。このドキュメントのこのバージョンの基本的なパスワードベースの暗号化方法と基本的なパスワードベースの認証方法は類似しています。
What's left unspecified in the above paragraph is precisely where the byte string representing a password comes from. (This is not an issue with salt strings, since they are supplied as a password-based encryption (or authentication) parameter.) PKCS #5 v2.1 says: "[...] a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 are two possibilities."
上記の段落で指定されていないのは、パスワードを表すバイト文字列が正確にどこから来たかです。 （ソルト文字列はパスワードベースの暗号化（または認証）パラメータとして提供されるため、これは問題ではありません。）PKCS＃5 v2.1は、「[...]パスワードはオクテット文字列と見なされます。テキスト文字列としての解釈が指定されていない任意の長さ。ただし、相互運用性のために、アプリケーションはいくつかの一般的なテキストエンコーディングルールに従うことをお勧めします。ASCIIとUTF-8の2つの可能性があります。
In this specification, however, all passwords are created from BMPStrings with a NULL terminator. This means that each character in the original BMPString is encoded in 2 bytes in big-endian format (most-significant byte first). There are no Unicode byte order marks. The 2 bytes produced from the last character in the BMPString are followed by 2 additional bytes with the value 0x00.
ただし、この仕様では、すべてのパスワードはNULLターミネータを使用してBMPStringsから作成されます。つまり、元のBMPStringの各文字は、ビッグエンディアン形式（最上位バイトが最初）で2バイトにエンコードされます。 Unicodeバイトオーダーマークはありません。 BMPStringの最後の文字から生成された2バイトの後に、値0x00の2バイトが追加されます。
To illustrate with a simple example, if a user enters the 6-character password "Beavis", the string that PKCS #12 implementations should treat as the password is the following string of 14 bytes:
簡単な例で説明すると、ユーザーが6文字のパスワード「Beavis」を入力した場合、PKCS＃12実装がパスワードとして処理する必要がある文字列は、次の14バイトの文字列です。
0x00 0x42 0x00 0x65 0x00 0x61 0x00 0x76 0x00 0x69 0x00 0x73 0x00 0x00
0x00 0x42 0x00 0x65 0x00 0x61 0x00 0x76 0x00 0x69 0x00 0x73 0x00 0x00
Let H be a hash function built around a compression function f:
Hを圧縮関数fを中心に構築されたハッシュ関数とする：
Z_2^u x Z_2^v -> Z_2^u
(that is, H has a chaining variable and output of length u bits, and the message input to the compression function of H is v bits). The values for u and v are as follows:
（つまり、Hにはチェーン変数と長さuビットの出力があり、Hの圧縮関数へのメッセージ入力はvビットです）。 uとvの値は次のとおりです。
HASH FUNCTION VALUE u VALUE v MD2, MD5 128 512 SHA-1 160 512 SHA-224 224 512 SHA-256 256 512 SHA-384 384 1024 SHA-512 512 1024 SHA-512/224 224 1024 SHA-512/256 256 1024
ハッシュ関数値u値v MD2、MD5 128512 SHA-1 160512 SHA-224 224512 SHA-256 256512 SHA-384 384 1024 SHA-512 512 1024 SHA-512 / 224 224 1024 SHA-512 / 256 256 1024
Furthermore, let r be the iteration count.
さらに、rを反復回数とする。
We assume here that u and v are both multiples of 8, as are the lengths of the password and salt strings (which we denote by p and s, respectively) and the number n of pseudorandom bits required. In addition, u and v are of course non-zero.
ここでは、uとvはどちらも8の倍数であり、パスワードとソルト文字列（それぞれpとsで表します）と必要な疑似ランダムビットの数nと仮定します。さらに、uとvはもちろん非ゼロです。
For information on security considerations for MD5 [19], see [25] and [1], and on those for MD2, see [18].
MD5 [19]のセキュリティに関する考慮事項については、[25]および[1]を参照してください。MD2のセキュリティに関する考慮事項については、[18]を参照してください。
The following procedure can be used to produce pseudorandom bits for a particular "purpose" that is identified by a byte called "ID". The meaning of this ID byte will be discussed later.
次の手順を使用して、「ID」と呼ばれるバイトで識別される特定の「目的」の疑似ランダムビットを生成できます。このIDバイトの意味については、後で説明します。
1. Construct a string, D (the "diversifier"), by concatenating v/8 copies of ID.
1. IDのv / 8コピーを連結して、文字列D（「ダイバーシファイア」）を作成します。
2. Concatenate copies of the salt together to create a string S of length v(ceiling(s/v)) bits (the final copy of the salt may be truncated to create S). Note that if the salt is the empty string, then so is S.
2. ソルトのコピーを連結して、長さv（ceiling（s / v））ビットの文字列Sを作成します（ソルトの最終コピーは、Sを作成するために切り捨てられる場合があります）。 saltが空の文字列の場合、Sもそうであることに注意してください。
3. Concatenate copies of the password together to create a string P of length v(ceiling(p/v)) bits (the final copy of the password may be truncated to create P). Note that if the password is the empty string, then so is P.
3. パスワードのコピーを連結して、長さv（ceiling（p / v））ビットの文字列Pを作成します（パスワードの最終コピーは、Pを作成するために切り捨てられる場合があります）。パスワードが空の文字列の場合、Pも同様であることに注意してください。
4. Set I=S||P to be the concatenation of S and P.
4. I = S || PをSとPの連結になるように設定します。
5. Set c=ceiling(n/u).
5. c = ceiling（n / u）を設定します。
6. For i=1, 2, ..., c, do the following:
6. i = 1、2、...、cの場合、次のようにします。
A. Set A2=H^r(D||I). (i.e., the r-th hash of D||1,
H(H(H(... H(D||I))))
B. Concatenate copies of Ai to create a string B of length v bits (the final copy of Ai may be truncated to create B).
B. Aiのコピーを連結して、長さvビットの文字列Bを作成します（Aiの最後のコピーは、Bを作成するために切り捨てられる場合があります）。
C. Treating I as a concatenation I_0, I_1, ..., I_(k-1) of v-bit blocks, where k=ceiling(s/v)+ceiling(p/v), modify I by setting I_j=(I_j+B+1) mod 2^v for each j.
C. Iをvビットブロックの連結I_0、I_1、...、I_（k-1）として扱う。ここで、k = ceiling（s / v）+ ceiling（p / v）、I_j =を設定してIを変更する（I_j + B + 1）各jのmod 2 ^ v。
7. Concatenate A_1, A_2, ..., A_c together to form a pseudorandom bit string, A.
7. A_1、A_2、...、A_cを連結して、疑似ランダムビット文字列Aを形成します。
8. Use the first n bits of A as the output of this entire process.
8. このプロセス全体の出力として、Aの最初のnビットを使用します。
If the above process is being used to generate a DES key, the process should be used to create 64 random bits, and the key's parity bits should be set after the 64 bits have been produced. Similar concerns hold for 2-key and 3-key triple-DES keys, for CDMF keys, and for any similar keys with parity bits "built into them".
上記のプロセスを使用してDES鍵を生成する場合は、このプロセスを使用して64個のランダムビットを作成し、64ビットの生成後に鍵のパリティビットを設定する必要があります。 2キーおよび3キーのTriple-DESキー、CDMFキー、および「それらに組み込まれた」パリティビットを持つ同様のキーについても、同様の懸念が保持されます。
This standard specifies 3 different values for the ID byte mentioned above:
この規格では、上記のIDバイトに3つの異なる値を指定しています。
1. If ID=1, then the pseudorandom bits being produced are to be used as key material for performing encryption or decryption.
1. ID = 1の場合、生成される疑似ランダムビットは、暗号化または復号化を実行するためのキーマテリアルとして使用されます。
2. If ID=2, then the pseudorandom bits being produced are to be used as an IV (Initial Value) for encryption or decryption.
2. ID = 2の場合、生成される疑似ランダムビットは、暗号化または復号化のIV（初期値）として使用されます。
3. If ID=3, then the pseudorandom bits being produced are to be used as an integrity key for MACing.
3. ID = 3の場合、生成される疑似ランダムビットはMACingの整合性キーとして使用されます。
When password integrity mode is used to protect a PFX PDU, a password and salt are used to derive a MAC key. As with password privacy mode, the password is a Unicode string, and the salt is a byte string. No particular lengths are prescribed in this standard for either the password or the salt, but the general advice about passwords and salt that is given in Appendix C applies here, as well.
パスワード整合性モードを使用してPFX PDUを保護する場合、パスワードとソルトを使用してMACキーを派生させます。パスワードプライバシーモードと同様に、パスワードはUnicode文字列で、saltはバイト文字列です。この標準では、パスワードとソルトのどちらにも特定の長さは規定されていませんが、付録Cに記載されているパスワードとソルトに関する一般的なアドバイスがここでも適用されます。
The hash function used to derive MAC keys is whatever hash function is going to be used for MACing. The MAC keys that are derived have the same length as the hash function's output. In this version of this standard, SHA-1, SHA-224, SHA-256, SHA384, SHA-512, SHA-512/224, or SHA/512/256 can be used to perform MACing, and so the MAC keys can be 160, 224, 256, 384, or 512 bits. See Appendix A for more information on MACing.
MACキーの導出に使用されるハッシュ関数は、MACingに使用されるハッシュ関数です。派生したMACキーは、ハッシュ関数の出力と同じ長さです。この標準のこのバージョンでは、SHA-1、SHA-224、SHA-256、SHA384、SHA-512、SHA-512 / 224、またはSHA / 512/256を使用してMACを実行できるため、MACキーで160、224、256、384、または512ビット。 MACingの詳細については、付録Aを参照してください。
As stated at the start of Appendix B, use of this method for password privacy mode is not recommended; this specification of keys and IVs for password privacy mode is retained for backwards compatibility with PKCS #12 v1.0 only.
付録Bの冒頭で述べたように、この方法をパスワードプライバシーモードに使用することはお勧めしません。パスワードプライバシーモードのキーとIVのこの仕様は、PKCS＃12 v1.0との下位互換性のためにのみ保持されています。
When password privacy mode is used to encrypt a PFX PDU, a password (typically entered by the user), a salt and an iteration parameter are used to derive a key (and an IV, if necessary). The password is a Unicode string, and as such, each character in it is represented by 2 bytes. The salt is a byte string and so can be represented directly as a sequence of bytes.
パスワードプライバシーモードを使用してPFX PDUを暗号化する場合、パスワード（通常はユーザーが入力）、ソルト、および反復パラメーターを使用してキー（および必要に応じてIV）を導出します。パスワードはUnicode文字列であるため、その中の各文字は2バイトで表されます。ソルトはバイト文字列なので、バイトのシーケンスとして直接表すことができます。
This standard does not prescribe a length for the password. As usual, however, too short a password might compromise privacy. A particular application might well require a user-entered privacy password for creating a PFX PDU to have a password exceeding some specific length.
この規格では、パスワードの長さは規定されていません。ただし、通常どおり、パスワードが短すぎるとプライバシーが侵害される可能性があります。特定のアプリケーションでは、PFX PDUを作成するためにユーザーが入力したプライバシーパスワードを必要とする場合があり、パスワードが特定の長さを超えるようにします。
This standard does not prescribe a length for the salt either. Ideally, the salt is as long as the output of the hash function being used and consists of completely random bits.
この規格は、塩の長さも規定していません。理想的には、ソルトは使用されているハッシュ関数の出力と同じ長さで、完全にランダムなビットで構成されています。
The iteration count is recommended to be 1024 or more. (See [22] and [13] for more information.)
反復回数は1024以上にすることをお勧めします。 （詳細については、[22]および[13]を参照してください。）
The PBES1 encryption scheme defined in PKCS #5 provides a number of algorithm identifiers for deriving keys and IVs; here, we specify a few more, all of which use the procedure detailed in Appendices B.2 and B.3 to construct keys (and IVs, where needed). As is implied by their names, all of the object identifiers below use the hash function SHA-1.
PKCS＃5で定義されているPBES1暗号化スキームは、鍵とIVを導出するためのいくつかのアルゴリズム識別子を提供します。ここでは、さらにいくつかを指定します。これらはすべて、付録B.2およびB.3に詳述されている手順を使用して、キー（および必要に応じてIV）を構築します。名前からわかるように、以下のすべてのオブジェクト識別子はハッシュ関数SHA-1を使用します。
pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
Each of the six PBE object identifiers above has the following ASN.1 type for parameters:
上記の6つのPBEオブジェクト識別子のそれぞれには、パラメーター用に次のASN.1タイプがあります。
pkcs-12PbeParams ::= SEQUENCE {
salt OCTET STRING,
iterations INTEGER
}
The pkcs-12PbeParams holds the salt that is used to generate the key (and IV, if necessary) and the number of iterations to carry out.
pkcs-12PbeParamsは、キー（および必要に応じてIV）の生成に使用されるソルトと、実行する反復回数を保持します。
Note that the first two algorithm identifiers above (the algorithm identifiers for RC4) only derive keys; it is unnecessary to derive an IV for RC4.
上記の最初の2つのアルゴリズム識別子（RC4のアルゴリズム識別子）は鍵のみを導出することに注意してください。 RC4のIVを派生させる必要はありません。
This section is here for two reasons: first, to enable backwards compatibility as described in the first paragraph of this section; second, because it is still used in password integrity mode. In order to not use it in password integrity mode, the ASN.1 definitions require updates. This document recommends that future definitions of the PFX structure replace the existing MacData object, optionally present in password integrity mode, with a new object definition that holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication scheme. This change would simplify the requirements for key derivation functions used across all parts of the PFX structure.
このセクションは、2つの理由でここにあります。最初に、このセクションの最初の段落で説明されているように、下位互換性を有効にします。 2つ目は、パスワード整合性モードで引き続き使用されるためです。パスワード整合性モードで使用しないようにするには、ASN.1定義を更新する必要があります。このドキュメントでは、PFX構造の将来の定義で、オプションでパスワード整合性モードで存在する既存のMacDataオブジェクトを、PKCS＃5 [13] [22] PBMAC1メッセージ認証方式に基づくMACを保持する新しいオブジェクト定義に置き換えることを推奨しています。この変更により、PFX構造のすべての部分で使用される主要な派生関数の要件が簡素化されます。
This appendix documents all ASN.1 types, values, and object sets defined in this specification. It does so by providing an ASN.1 module called PKCS-12.
この付録では、この仕様で定義されているすべてのASN.1タイプ、値、およびオブジェクトセットについて説明します。これは、PKCS-12と呼ばれるASN.1モジュールを提供することによって行われます。
PKCS-12 {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-12(12)
modules(0) pkcs-12(1)}
-- PKCS #12 v1.1 ASN.1 Module
-- Revised October 27, 2012
-- This module has been checked for conformance with the ASN.1 standard
-- by the OSS ASN.1 Tools
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL
-- All types and values defined in this module are exported for use
-- in other ASN.1 modules.
IMPORTS
輸入
informationFramework
FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
usefulDefinitions(0) 3}
ATTRIBUTE FROM InformationFramework informationFramework
ATTRIBUTE FROM InformationFramework informationFramework
ContentInfo, DigestInfo
FROM PKCS-7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-7(7) modules(0) pkcs-7(1)}
PrivateKeyInfo, EncryptedPrivateKeyInfo
FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-8(8) modules(1) pkcs-8(1)}
pkcs-9, friendlyName, localKeyId, certTypes, crlTypes
FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) modules(0) pkcs-9(1)};
-- ============================
-- Object identifiers
-- ============================
rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549)}
pkcs OBJECT IDENTIFIER ::= {rsadsi pkcs(1)}
pkcs-12 OBJECT IDENTIFIER ::= {pkcs 12}
pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
-- ============================
-- The PFX PDU
-- ============================
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
MacData ::= SEQUENCE {
mac DigestInfo,
macSalt OCTET STRING,
iterations INTEGER DEFAULT 1
-- Note: The default is for historical reasons and its use is
-- deprecated.
}
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
SafeContents ::= SEQUENCE OF SafeBag
SafeBag ::= SEQUENCE {
bagId BAG-TYPE.&id ({PKCS12BagSet}),
bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
bagAttributes SET OF PKCS12Attribute OPTIONAL
}
-- ============================
-- Bag types
-- ============================
keyBag BAG-TYPE ::=
{KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE ::=
{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=
{CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=
{CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=
{SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=
{SafeContents IDENTIFIED BY {bagtypes 6}}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
... -- For future extensions
}
BAG-TYPE ::= TYPE-IDENTIFIER
-- KeyBag
KeyBag ::= PrivateKeyInfo
-- Shrouded KeyBag
PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo
-- CertBag
CertBag ::= SEQUENCE {
certId BAG-TYPE.&id ({CertTypes}),
certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}
x509Certificate BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING
sdsiCertificate BAG-TYPE ::=
{IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String
CertTypes BAG-TYPE ::= {
x509Certificate |
sdsiCertificate,
... -- For future extensions
}
-- CRLBag
CRLBag ::= SEQUENCE {
crlId BAG-TYPE.&id ({CRLTypes}),
crltValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}
x509CRL BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {crlTypes 1}}
-- DER-encoded X.509 CRL stored in OCTET STRING
CRLTypes BAG-TYPE ::= {
x509CRL,
... -- For future extensions
}
-- Secret Bag
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
SecretTypes BAG-TYPE ::= {
... -- For future extensions
}
-- ============================
-- Attributes
-- ============================
PKCS12Attribute ::= SEQUENCE {
attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type 'Attribute'
PKCS12AttrSet ATTRIBUTE ::= {
friendlyName |
localKeyId,
... -- Other attributes are allowed
}
END
終わり
EMC Corporation makes no patent claims on the general constructions described in this document, although specific underlying techniques may be covered.
EMC Corporationは、このドキュメントに記載されている一般的な構造について特許を主張していませんが、特定の基礎となる技術がカバーされている場合があります。
RC2 and RC4 are trademarks of EMC Corporation.
RC2およびRC4はEMC Corporationの商標です。
EMC Corporation makes no representations regarding intellectual property claims by other parties. Such determination is the responsibility of the user.
EMC Corporationは、他の当事者による知的財産権の主張に関していかなる表明も行いません。そのような決定はユーザーの責任です。
Many thanks to Dan Simon of Microsoft Corporation and Jim Spring of Netscape Communications Corporation for their assistance in preparing early drafts of this document. Especial thanks to Brian Beckman of Microsoft Corporation for writing the specification that this document is based on.
このドキュメントの初期ドラフトを作成する際に支援してくれたMicrosoft CorporationのDan SimonとNetscape Communications CorporationのJim Springに感謝します。このドキュメントのベースとなっている仕様を書いてくれたMicrosoft CorporationのBrian Beckmanに特に感謝します。
Appendix G. About PKCS
付録G. PKCSについて
The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public-key cryptography. First published in 1991 as a result of meetings with a small group of early adopters of public-key technology, the PKCS documents have become widely referenced and implemented. Contributions from the PKCS series have become part of many formal and de facto standards, including ANSI X9 documents, PKIX, SET, S/ MIME, and SSL.
公開鍵暗号規格は、公開鍵暗号の展開を加速する目的で、世界中の安全なシステム開発者と協力してRSA研究所が作成した仕様です。 PKCS文書は、1991年に公開鍵技術の早期採用者の小さなグループとの会議の結果として最初に公開され、広く参照および実装されています。 PKCSシリーズからの貢献は、ANSI X9ドキュメント、PKIX、SET、S / MIME、SSLなど、多くの正式な事実上の標準の一部となっています。
Further development of PKCS occurs through the IETF. Suggestions for improvement are welcome.
PKCSのさらなる開発はIETFを通じて行われます。改善のための提案は大歓迎です。
Authors' Addresses
著者のアドレス
Kathleen M. Moriarty (editor) EMC Corporation 176 South Street Hopkinton, MA United States
Kathleen M. Moriarty（編集者）EMC Corporation 176 South Streetホプキントン、MAアメリカ合衆国
EMail: Kathleen.Moriarty@emc.com
Magnus Nystrom Microsoft Corporation 1 Microsoft Way Redmond, WA 98052 United States
まｇぬｓ Ｎｙｓｔろｍ みｃろそｆｔ こｒぽらちおん １ みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うにてｄ Ｓたてｓ
EMail: mnystrom@microsoft.com
Sean Parkinson RSA Security Inc. 345 Queen Street Brisbane, QLD, 4000 Australia
Sean Parkinson RSA Security Inc. 345 Queen StreetブリスベンQLD、オーストラリア
EMail: Sean.Parkinson@rsa.com
Andreas Rusch RSA Security Inc. 345 Queen Street Brisbane, QLD, 4000 Australia
Andreas Rusch RSA Security Inc. 345 Queen Street Brisbane、QLD、4000 Australia
EMail: Andreas.Rusch@rsa.com
Michael Scott RSA Security Inc. 345 Queen Street Brisbane, QLD, 4000 Australia
マイケルスコットRSA Security Inc.オーストラリア、QLD、ブリスベンクイーンズストリート345
EMail: Michael2.Scott@rsa.com