[要約] RFC 6030は、ポータブル対称鍵コンテナ（PSKC）の仕様を定義しています。その目的は、異なるシステム間で対称鍵を安全に共有するための標準化された形式を提供することです。
Internet Engineering Task Force (IETF) P. Hoyer
Request for Comments: 6030 ActivIdentity
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign
S. Machani
Diversinet
October 2010
Portable Symmetric Key Container (PSKC)
ポータブル対称キーコンテナ（PSKC）
Abstract
概要
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure.
このドキュメントは、さまざまなタイプの暗号モジュールへの対称キーの輸送とプロビジョニングの対称キー形式を指定します。たとえば、1回限りのパスワード（OTP）は、強力な認証デバイスに対してシークレットまたは対称暗号化キーを共有しました。標準の主要な輸送形式により、企業はさまざまなベンダーからコンポーネントを同じインフラストラクチャに組み合わせたベストブリードソリューションを展開できます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc6030.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6030で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Key Words ..................................................4
1.2. Version Support ............................................4
1.3. Namespace Identifiers ......................................5
1.3.1. Defined Identifiers .................................5
1.3.2. Referenced Identifiers ..............................5
2. Terminology .....................................................6
3. Portable Key Container Entities Overview and Relationships ......6
4. <KeyContainer> Element: The Basics ..............................8
4.1. <Key>: Embedding Keying Material and Key-Related
Information ................................................8
4.2. Key Value Encoding ........................................10
4.2.1. AES Key Value Encoding .............................11
4.2.2. Triple-DES Key Value Encoding ......................11
4.3. Transmission of Supplementary Information .................12
4.3.1. <DeviceInfo> Element: Unique Device
Identification .....................................13
4.3.2. <CryptoModuleInfo> Element: CryptoModule
Identification .....................................15
4.3.3. <UserId> Element: User Identification ..............15
4.3.4. <AlgorithmParameters> Element:
Supplementary Information for OTP and CR Algorithms 15
4.4. Transmission of Key Derivation Values .....................17
5. Key Policy .....................................................19
5.1. PIN Algorithm Definition ..................................23
6. Key Protection Methods .........................................23
6.1. Encryption Based on Pre-Shared Keys .......................24
6.1.1. MAC Method .........................................26
6.2. Encryption Based on Passphrase-Based Keys .................27
6.3. Encryption Based on Asymmetric Keys .......................29
6.4. Padding of Encrypted Values for Non-Padded
Encryption Algorithms .....................................31
7. Digital Signature ..............................................31
8. Bulk Provisioning ..............................................33
9. Extensibility ..................................................35
10. PSKC Algorithm Profile ........................................36
10.1. HOTP .....................................................36
10.2. PIN ......................................................37
11. XML Schema ....................................................38
12. IANA Considerations ...........................................44
12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.2. XML Schema Registration ..................................45
12.3. URN Sub-Namespace Registration ...........................46
12.4. PSKC Algorithm Profile Registry ..........................46
12.5. PSKC Version Registry ....................................47
12.6. Key Usage Registry .......................................47
13. Security Considerations .......................................48
13.1. PSKC Confidentiality .....................................49
13.2. PSKC Integrity ...........................................50
13.3. PSKC Authenticity ........................................50
14. Contributors ..................................................50
15. Acknowledgements ..............................................50
16. References ....................................................51
16.1. Normative References .....................................51
16.2. Informative References ...................................52
Appendix A. Use Cases ............................................54
A.1. Online Use Cases ..........................................54
A.1.1. Transport of Keys from Server to Cryptographic
Module ................................................54
A.1.2. Transport of Keys from Cryptographic Module to
Cryptographic Module ..................................54
A.1.3. Transport of Keys from Cryptographic Module to
Server ................................................55
A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.2. Offline Use Cases .........................................55
A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
Appendix B. Requirements .........................................56
With the increasing use of symmetric-key-based systems, such as encryption of data at rest or systems used for strong authentication, such as those based on One-Time Password (OTP) and Challenge/Response (CR) mechanisms, there is a need for vendor interoperability and a standard format for importing and exporting (provisioning) symmetric keys. For instance, traditionally, vendors of authentication servers and service providers have used proprietary formats for importing and exporting these keys into their systems, thus making it hard to use tokens from two different vendors.
安静時のデータの暗号化や、1回限りのパスワード（OTP）やチャレンジ/応答（CR）メカニズムに基づくものなど、強力な認証に使用されるシステムの暗号化など、対称キーベースのシステムの使用が増えているため、ベンダーの相互運用性と、インポートおよびエクスポート（プロビジョニング）対称キーの標準形式の必要性。たとえば、従来、認証サーバーとサービスプロバイダーのベンダーは、これらのキーをシステムにインポートおよびエクスポートするために独自の形式を使用しているため、2つの異なるベンダーからのトークンを使用するのが難しくなりました。
This document defines a standardized XML-based key container, called Portable Symmetric Key Container (PSKC), for transporting symmetric keys and key-related metadata. The document also specifies the information elements that are required when the symmetric key is utilized for specific purposes, such as the initial counter in the HMAC-Based One-Time Password (HOTP) [HOTP] algorithm. It also creates an IANA registry for algorithm profiles where algorithms, their metadata and PSKC transmission profile can be recorded for a centralized, standardized reference.
このドキュメントは、対称キーとキー関連のメタデータを輸送するために、ポータブル対称キーコンテナ（PSKC）と呼ばれる標準化されたXMLベースのキーコンテナを定義します。また、このドキュメントは、HMACベースのワンタイムパスワード（HOTP）[HOTP]アルゴリズムの初期カウンターなど、特定の目的で対称キーが使用される場合に必要な情報要素を指定します。また、アルゴリズム、メタデータ、およびPSKC伝送プロファイルを集中標準化された参照のために記録できるアルゴリズムプロファイルのIANAレジストリも作成します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
There is a provision made in the syntax for an explicit version number. Only version "1.0" is currently specified.
明示的なバージョン番号の構文で作成された規定があります。現在、バージョン「1.0」のみが指定されています。
The numbering scheme for PSKC versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "PSKC 2.4" would be a lower version than "PSKC 2.13", which in turn would be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be ignored by recipients and MUST NOT be sent.
PSKCバージョンの番号付けスキームは「<major>。<minor>」です。主要な数字とマイナー数は、個別の整数として扱う必要があり、各数値は1桁よりも高く増加することができます。したがって、「PSKC 2.4」は「PSKC 2.13」よりも低いバージョンであり、「PSKC 12.3」よりも低くなります。主要なゼロ（例：「PSKC 6.01」）は、受信者が無視する必要があり、送信してはなりません。
The major version number should be incremented only if the message format (e.g., element structure) has changed so dramatically that an older version implementation would not be able to interoperate with a newer version. The minor version number indicates new capabilities, and it MUST be ignored by an entity with a smaller minor version number but used for informational purposes by the entity with the larger minor version number.
メジャーバージョン番号は、メッセージ形式（要素構造など）が非常に劇的に変更されているため、古いバージョンの実装が新しいバージョンと相互運用できない場合にのみインクリメントする必要があります。マイナーバージョン番号は新しい機能を示しており、マイナーバージョン番号が小さいエンティティでは無視する必要がありますが、より大きなマイナーバージョン番号を持つエンティティが情報目的で使用する必要があります。
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to identify resources, algorithms, and semantics.
このドキュメントでは、均一なリソース識別子（URIS）[RFC3986]を使用して、リソース、アルゴリズム、およびセマンティクスを識別します。
The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
PSKCのバージョン1.0のXML名前空間[XMLNS] URIは次のとおりです。
"urn:ietf:params:xml:ns:keyprov:pskc"
References to qualified elements in the PSKC schema defined in this specification and used in the example use the prefix "pskc" (defined as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"). It is RECOMMENDED to use this namespace in implementations.
この仕様で定義され、例で使用されているPSKCスキーマの適格要素への参照は、プレフィックス「pskc」（xmlns：pskc = "urn：ietf：params：xml：ns：keyprov：pskc"）を使用します。この名前空間を実装で使用することをお勧めします。
The PSKC syntax presented in this document relies on algorithm identifiers and elements defined in the XML Signature [XMLDSIG] namespace:
このドキュメントに示されているPSKC構文は、XML署名[XMLDSIG]名前空間で定義されているアルゴリズム識別子と要素に依存しています。
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to the XML Signature namespace are represented by the prefix "ds".
XML署名名空間への参照は、プレフィックス「DS」で表されます。
PSKC also relies on algorithm identifiers and elements defined in the XML Encryption [XMLENC] namespace:
PSKCは、XML暗号化[XMLENC]名前空間で定義されているアルゴリズム識別子と要素にも依存しています。
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the prefix "xenc".
XML暗号化名前空間への参照は、プレフィックス「XENC」で表されます。
When protecting keys in transport with passphrase-based keys, PSKC also relies on the derived key element defined in the XML Encryption Version 1.1 [XMLENC11] namespace:
PassPhraseベースのキーを使用してトランスポートのキーを保護する場合、PSKCはXML暗号化バージョン1.1 [XMLENC11]名前空間で定義されている派生キー要素にも依存しています。
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
References to the XML Encryption Version 1.1 namespace are represented by the prefix "xenc11".
XML暗号化バージョン1.1名前空間への参照は、プレフィックス「XENC11」で表されます。
When protecting keys in transport with passphrase-based keys, PSKC
also relies on algorithm identifiers and elements defined in the PKCS
#5 [PKCS5] namespace:
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
References to the PKCS #5 namespace are represented by the prefix "pkcs5".
PKCS＃5ネームスペースへの参照は、プレフィックス「PKCS5」で表されます。
NOTE: In subsequent sections of the document, we highlight **mandatory** XML elements and attributes. Optional elements and attributes are not explicitly indicated, i.e., if it does not say mandatory, it is optional.
注：ドキュメントの後続セクションでは、**必須** XML要素と属性を強調します。オプションの要素と属性は明示的に示されていません。つまり、必須と言わない場合、オプションです。
The portable key container is based on an XML schema definition and contains the following main conceptual entities:
ポータブルキーコンテナはXMLスキーマ定義に基づいており、次の主要な概念エンティティが含まれています。
1. KeyContainer entity - representing the container that carries a number of KeyPackage entities. A valid container MUST carry at least one KeyPackage entity.
1. KeyContainerエンティティ - 多くのキーパッケージエンティティを搭載したコンテナを表す。有効なコンテナは、少なくとも1つのキーパッケージエンティティを運ぶ必要があります。
2. KeyPackage entity - representing the package of at most one key and its related provisioning endpoint or current usage endpoint, such as a physical or virtual device and a specific CryptoModule.
2. キーパッケージエンティティ - 最大1つのキーのパッケージと、その関連するプロビジョニングエンドポイントまたは物理的または仮想デバイスや特定の暗号化などの現在の使用エンドポイントを表します。
3. DeviceInfo entity - representing the information about the device and criteria to identify uniquely the device.
3. DeviceInfoエンティティ - デバイスと基準に関する情報を表して、デバイスを一意に識別します。
4. CryptoModuleInfo entity - representing the information about the CryptoModule where the keys reside or to which they are provisioned.
4. cryptomoduleinfoエンティティ - キーが存在するか、それらがプロビジョニングされているcryptoModuleに関する情報を表します。
5. Key entity - representing the key transported or provisioned.
5. 主要エンティティ - 輸送またはプロビジョニングされた主要なものを表す。
6. Data entity - representing a list of metadata related to the key, where the element name is the name of the metadata and its associated value is either in encrypted (for example, for <Data> element <Secret>) or plaintext (for example, the <Data> element <Counter>) form.
6. データエンティティ - キーに関連するメタデータのリストを表します。要素名はメタデータの名前であり、関連する値は暗号化（<data> element <secret>の場合）またはPlantext（たとえば、例えば、<data>要素<Counter>）フォーム。
Figure 1 shows the high-level structure of the PSKC data elements.
図1は、PSKCデータ要素の高レベル構造を示しています。
-----------------
| KeyContainer |
|---------------|
| EncryptionKey |
| Signature |
| ... |
-----------------
|
|
/|\ 1..n
---------------- ----------------
| KeyPackage | 0..1| DeviceInfo |
|--------------|--------|--------------|
| |-- | SerialNumber |
---------------- | | Manufacturer |
| | | .... |
| | ----------------
/|\ 0..1 |
---------------- | --------------------
| Key | | 0..1| CryptoModuleInfo |
|--------------| -----|------------------|
| Id | | Id |
| Algorithm | |.... |
| UserId | --------------------
| Policy |
| .... |
----------------
|
|
/|\ 0..n
--------------------------------------- - -
| | |
------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue |
| ValueMAC | ----------------
------------------
Figure 1: PSKC Data Elements Relationship Diagram
図1：PSKCデータ要素関係図
The following sections describe in detail all the entities and related XML schema elements and attributes.
次のセクションでは、すべてのエンティティと関連するXMLスキーマ要素と属性について詳しく説明しています。
In its most basic form, a PSKC document uses the top-level element <KeyContainer> and a single <KeyPackage> element to carry key information.
最も基本的な形式では、PSKCドキュメントでは、トップレベルの要素<keyContainer>と単一の<keypackage>要素を使用して、キー情報を伝達します。
The following example shows a simple PSKC document. We will use it to describe the structure of the <KeyContainer> element and its child elements.
次の例は、単純なPSKCドキュメントを示しています。<keyContainer>要素の構造とその子要素を説明するために使用します。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer-A</Issuer>
<Data>
<Secret>
<PlainValue>MTIzNA==
</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 2: Basic PSKC Key Container Example
図2：基本的なPSKCキーコンテナの例
The attributes of the <KeyContainer> element have the following semantics:
<keyContainer>要素の属性には、次のセマンティクスがあります。
'Version': The 'Version' attribute is used to identify the version of the PSKC schema version. This specification defines the initial version ("1.0") of the PSKC schema. This attribute MUST be included.
「バージョン」：「バージョン」属性は、PSKCスキーマバージョンのバージョンを識別するために使用されます。この仕様では、PSKCスキーマの初期バージョン（ "1.0"）を定義します。この属性を含める必要があります。
'Id': The 'Id' attribute carries a unique identifier for the container. As such, it helps to identify a specific key container in cases in which multiple containers are embedded in larger XML documents.
「ID」：「ID」属性には、コンテナの一意の識別子が含まれます。そのため、複数の容器がより大きなXMLドキュメントに埋め込まれている場合に、特定の重要なコンテナを識別するのに役立ちます。
The following attributes of the <Key> element MUST be included at a minimum:
<key>要素の次の属性は、少なくとも含む必要があります。
'Id': This attribute carries a unique identifier for the symmetric key in the context of key provisioning exchanges between two parties. This means that if PSKC is used in multiple interactions between a sending and receiving party, using different containers referencing the same keys, the 'Id' attribute of <Key> MUST use the same value (e.g., after initial provisioning, if a system wants to update key metadata values in the other system, the value of the 'Id' attribute of the <Key> where the metadata is to be updated MUST be the same of the original 'Id' attribute value provisioned). The identifier is defined as a string of alphanumeric characters.
「ID」：この属性には、2つの当事者間のキープロビジョニング交換のコンテキストで、対称キーの一意の識別子が含まれます。これは、同じキーを参照する異なるコンテナを使用して、送信および受信者間の複数の相互作用でPSKCが使用されている場合、<key>の「ID」属性は同じ値を使用する必要があることを意味します（例：最初のプロビジョニング後、システムが必要な場合は、他のシステムのキーメタデータ値を更新するには、メタデータが更新される<キー>の「ID」属性の値は、元の「ID」属性値と同じである必要があります。識別子は、英数字の文字列として定義されます。
'Algorithm': This attribute contains a unique identifier for the PSKC algorithm profile. This profile associates specific semantics to the elements and attributes contained in the <Key> element. This document describes profiles for open standards algorithms in Section 10. Additional profiles are defined in the following informative document: [PSKC-ALGORITHM-PROFILES].
「アルゴリズム」：この属性には、PSKCアルゴリズムプロファイルの一意の識別子が含まれています。このプロファイルは、特定のセマンティクスを、<key>要素に含まれる要素と属性に関連付けます。このドキュメントでは、セクション10のオープン標準アルゴリズムのプロファイルについて説明します。追加のプロファイルは、次の有益なドキュメントで定義されています。[PSKC-Algorithm-Profiles]。
The <Key> element has a number of optional child elements. An initial set is described below:
<key>要素には、多くのオプションの子要素があります。初期セットを以下に説明します。
<Issuer>: This element represents the name of the party that issued the key. For example, a bank "Foobar Bank, Inc." issuing hardware tokens to their retail banking users may set this element to 'Foobar Bank, Inc.'.
<発行者>：この要素は、キーを発行した当事者の名前を表します。たとえば、銀行「Foobar Bank、Inc。」小売銀行のユーザーにハードウェアトークンを発行すると、この要素を「Foobar Bank、Inc。」に設定する場合があります。
<FriendlyName>: A human-readable name for the secret key for easier reference. This element serves informational purposes only. This element is a language-dependent string; hence, it SHOULD have an attribute xml:lang="xx" where xx is the language identifier as specified in [RFC5646]. If no xml:lang attribute is present, implementations MUST assume the language to be English as defined by setting the attribute value to 'en' (e.g., xml:lang="en").
<FriendlyName>：参照を容易にするためのシークレットキーの人間の読み取り可能な名前。この要素は、情報提供のみを提供します。この要素は言語依存の文字列です。したがって、属性xml：lang = "xx"が必要です。ここで、xxは[rfc5646]で指定されている言語識別子です。XML：LANG属性が存在しない場合、実装は、属性値を「EN」に設定することによって定義されている言語を英語であると想定する必要があります（例：XML：Lang = "en"）。
<AlgorithmParameters>: This element carries parameters that influence the result of the algorithmic computation, for example, response truncation and format in OTP and CR algorithms. A more detailed discussion of the element can be found in Section 4.3.4.
<algorithmparameters>：この要素には、アルゴリズム計算の結果に影響するパラメーターが含まれています。たとえば、OTPおよびCRアルゴリズムの応答の切り捨てと形式です。要素のより詳細な説明は、セクション4.3.4に記載されています。
<Data>: This element carries data about and related to the key. The following child elements are defined for the <Data> element:
<data>：この要素は、キーに関するデータを伝達し、キーに関連しています。次の子要素は、<data>要素に対して定義されています。
<Secret>: This element carries the value of the key itself in a binary representation. Please see Section 4.2 for more details on Key Value Encoding.
<secret>：この要素は、バイナリ表現にキー自体の値を運びます。キー値エンコーディングの詳細については、セクション4.2を参照してください。
<Counter>: This element contains the event counter for event-based OTP algorithms.
<Counter>：この要素には、イベントベースのOTPアルゴリズムのイベントカウンターが含まれています。
<Time>: This element contains the time for time-based OTP algorithms. (If time intervals are used, this element carries the number of time intervals passed from a specific start point, normally it is algorithm dependent).
<time>：この要素には、時間ベースのOTPアルゴリズムの時間が含まれています。（時間間隔が使用される場合、この要素は特定の開始点から渡される時間間隔数、通常はアルゴリズムに依存します）。
<TimeInterval>: This element carries the time interval value for time-based OTP algorithms in seconds (a typical value for this would be 30, indicating a time interval of 30 seconds).
<TimeInterval>：この要素は、時間ベースのOTPアルゴリズムの時間間隔値を秒単位で運びます（これの典型的な値は30で、30秒の時間間隔を示します）。
<TimeDrift>: This element contains the device clock drift value for time-based OTP algorithms. The integer value (positive or negative drift) that indicates the number of time intervals that a validation server has established the device clock drifted after the last successful authentication. So, for example, if the last successful authentication established a device time value of 8 intervals from a specific start date but the validation server determines the time value at 9 intervals, the server SHOULD record the drift as -1.
<TimeDrift>：この要素には、時間ベースのOTPアルゴリズムのデバイスクロックドリフト値が含まれています。検証サーバーが最後に成功した認証の後にドリフトしたデバイスクロックを確立した時間間隔数を示す整数値（正または負のドリフト）。したがって、たとえば、最後の成功した認証が特定の開始日から8つの間隔のデバイス時間値を確立したが、検証サーバーが9間隔で時間値を決定する場合、サーバーはドリフトを-1として記録する必要があります。
All the elements listed above (and those defined in the future) obey a simple structure in that they MUST support child elements to convey the data value in either plaintext or encrypted format:
上記のすべての要素（および将来定義されている要素）は、プレーンテキストまたは暗号化された形式でデータ値を伝えるために子要素をサポートする必要があるという単純な構造に従います。
Plaintext: The <PlainValue> element carries a plaintext value that is typed, for example, to xs:integer.
プレーンテキスト：<sablavalue>要素は、たとえばXS：Integerに入力されるプレーンテキスト値を搭載しています。
Encrypted: The <EncryptedValue> element carries an encrypted value.
暗号化：<necryptedValue>要素には、暗号化された値があります。
ValueMAC: The <ValueMAC> element is populated with a Message Authentication Code (MAC) generated from the encrypted value in case the encryption algorithm does not support integrity checks. The example shown in Figure 2 illustrates the usage of the <Data> element with two child elements, namely <Secret> and <Counter>. Both elements carry a plaintext value within the <PlainValue> child element.
ValueMac：<valueMac>要素には、暗号化アルゴリズムが整合性チェックをサポートしていない場合に、暗号化された値から生成されたメッセージ認証コード（MAC）が入力されます。図2に示す例は、2つの子要素、つまり<secret>と<counter>を備えた<data>要素の使用法を示しています。どちらの要素も、<PlainValue>子要素内に平文値を保持します。
Two parties receiving the same key value OCTET STRING, resulting in decoding the xs:base64Binary, inside the <PlainValue> or <EncryptedValue> elements, must make use of the key in exactly the same way in order to interoperate. To ensure that, it is necessary to define a correspondence between the OCTET STRING and the notation in the standard algorithm description that defines how the key is used. The next sections establish that correspondence for the AES algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or Triple DES) [SP800-67]. Unless otherwise specified for a specific algorithm, the OCTET STRING encoding MUST follow the AES Key Value Encoding.
同じキー値のOctet文字列を受け取る2つのパーティがXS：base64Binaryをデコードし、<PlainValue>または<ncryptedValue>要素内で、相互運用するためにまったく同じ方法でキーを利用する必要があります。それを確実にするには、キーの使用方法を定義する標準アルゴリズムの説明のオクテット文字列と表記の間の対応を定義する必要があります。次のセクションでは、AESアルゴリズム[FIPS197]およびトリプルデータ暗号化アルゴリズム（TDEAまたはトリプルDES）[SP800-67]の対応を確立します。特定のアルゴリズムに特に指定されていない限り、Octet文字列エンコードはAESキー値エンコーディングに従う必要があります。
[FIPS197], Section 5.2, titled "Key Expansion", uses the input key as an array of bytes indexed starting at 0. The first octet of the OCTET STRING SHALL become the key byte in the AES, labeled index 0 in [FIPS197]; the succeeding octets of the OCTET STRING SHALL become key bytes in AES, in increasing index order.
[FIPS197]、「キー拡張」というタイトルのセクション5.2は、0からインデックス付けされたバイトの配列として入力キーを使用します。オクテット文字列の最初のオクテットは、AESのキーバイトになり、[FIPS197]のインデックス0とラベル付けされます。;Octet Stringの後続のオクテットは、インデックス順序の増加において、AESのキーバイトになります。
Proper parsing and key load of the contents of the OCTET STRING for AES SHALL be determined by using the following value for the <PlainValue> element (binaryBase64-encoded) to generate and match the key expansion test vectors in [FIPS197], Appendix A, for AES
AESのオクテット文字列の内容の適切な解析とキーロードは、[FIPS197]、付録Aの主要な拡張テストベクトルを生成および一致させるために、<PlainValue>要素（BinaryBase64-Encoded）の次の値を使用して決定するものとします。AESの場合
Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
暗号キー：2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C
...
<PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue>
...
A Triple-DES key consists of three keys for the cryptographic engine (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 parity bits); the three keys are also collectively referred to as a key bundle [SP800-67]. A key bundle may employ either two or three independent keys. When only two independent keys are employed (called two-key Triple DES), the same value is used for Key1 and Key3.
Triple-DESキーは、それぞれ64ビット（56キービットと8パリティビット）である暗号エンジン（key1、key2、およびkey3）の3つのキーで構成されています。3つのキーは、キーバンドル[SP800-67]とも集合的に呼ばれます。キーバンドルは、2つまたは3つの独立したキーを使用する場合があります。2つの独立したキーのみが使用されている場合（2キートリプルDEと呼ばれる）、Key1とKey3に同じ値が使用されます。
Each key in a Triple-DES key bundle is expanded into a key schedule according to a procedure defined in [SP800-67], Appendix A. That procedure numbers the bits in the key from 1 to 64, with number 1 being the leftmost, or most significant bit (MSB). The first octet of the OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. The second octet of the OCTET STRING SHALL be bits 9 through 16 of Key1, and so forth, so that the trailing octet of the OCTET STRING SHALL be bits 57 through 64 of Key3 (or Key2 for two-key Triple DES).
Triple-DESキーバンドルの各キーは、[SP800-67]で定義されている手順に従ってキースケジュールに拡張されます。付録Aは、1〜64のキーのビットを数字で、ナンバー1が左端で、または最も重要なビット（MSB）。オクテット文字列の最初のオクテットは、key1のビット1〜8で、ビット1はMSBです。オクテット弦の2番目のオクテットは、key1のビット9〜16などでなければならないため、オクテット弦の後続のオクテットは、key3のビット57〜64（または2キートリプルデスの場合はkey2）になります。
Proper parsing and key load of the contents of the OCTET STRING for Triple DES SHALL be determined by using the following <PlainValue> element (binaryBase64-encoded) to generate and match the key expansion test vectors in [SP800-67], Appendix B, for the key bundle:
トリプルDESのオクテット文字列の内容の適切な解析とキーロードは、次の<PlainBalue>要素（binaryBase64エンコード）を使用して決定して、[SP800-67]、付録Bのキー拡張テストベクターを生成および一致させるものとします。キーバンドルの場合：
Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123
... <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue> ...
... <plainValue> asnfz4mrze8jrwejq83vauvniavn7wej </plainValue> ...
A PSKC document can contain a number of additional information regarding device identification, cryptographic module identification, user identification, and parameters for usage with OTP and CR algorithms. The following example, see Figure 3, is used as a reference for the subsequent sub-sections.
PSKCドキュメントには、OTPおよびCRアルゴリズムで使用するためのデバイス識別、暗号化モジュールの識別、ユーザー識別、およびパラメーターに関する多くの追加情報を含めることができます。次の例、図3を参照してください。後続のサブセクションの参照として使用されます。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
<UserId>DC=example-bank,DC=net</UserId>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
</Key>
</KeyPackage>
</KeyContainer>
Figure 3: PSKC Key Container Example with Supplementary Data
図3：補足データを備えたPSKCキーコンテナの例
The <DeviceInfo> element uniquely identifies the device to which the <KeyPackage> is provisioned. Since devices can come in different form factors, such as hardware tokens, smart-cards, soft tokens in a mobile phone, or as a PC, this element allows different child element combinations to be used. When combined, the values of the child elements MUST uniquely identify the device. For example, for hardware tokens, the combination of <SerialNo> and <Manufacturer> elements uniquely identifies a device, but the <SerialNo> element alone is insufficient since two different token manufacturers might issue devices with the same serial number (similar to the Issuer Distinguished Name and serial number of a certificate).
<deviceInfo>要素は、<keypackage>がプロビジョニングされているデバイスを一意に識別します。デバイスには、ハードウェアトークン、スマートカード、携帯電話のソフトトークン、またはPCとしてのさまざまなフォームファクターが付属する可能性があるため、この要素により、異なる子要素の組み合わせを使用できます。結合すると、子要素の値はデバイスを一意に識別する必要があります。たとえば、ハードウェアトークンの場合、<serialno>と<メーカー>要素の組み合わせはデバイスを一意に識別しますが、2つの異なるトークンメーカーが同じシリアル番号を持つデバイスを発行する可能性があるため、<serialno>要素だけでは不十分です（発行者に類似しています。証明書の著名な名前とシリアル番号）。
The <DeviceInfo> element has the following child elements:
<deviceInfo>要素には、次の子要素があります。
<Manufacturer>: This element indicates the manufacturer of the device. Values for the <Manufacturer> element MUST be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN], "oath." MUST be prepended to the value (e.g., "oath.<prefix value from [OATHMAN]>"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.<Organization value from [IANAPENREG]>").
<メーカー>：この要素は、デバイスのメーカーを示しています。<メーカー>要素の値は、[左列）またはIANAプライベートエンタープライズ番号レジストリ[Ianapenreg]のいずれかから、組織値を使用して取得する必要があります。[Oathman]、「Oath」から価値が取られたとき。値に加えなければなりません（たとえば、 "oath。<[oathman]>" from [oathman]> "）。値が[Ianapenreg]から取られたとき、「Iana」。値に加えなければなりません（たとえば、「iana。<[ianapenreg]> "from [ianapenreg]>"）。
<SerialNo>: This element contains the serial number of the device.
<Serialno>：この要素には、デバイスのシリアル番号が含まれています。
<Model>: This element describes the model of the device (e.g., one-button-HOTP-token-V1).
<model>：この要素は、デバイスのモデル（たとえば、1-Button-hotp-token-v1）を説明しています。
<IssueNo>: This element contains the issue number in case there are devices with the same serial number so that they can be distinguished by different issue numbers.
<issueno>：この要素には、同じシリアル番号があるデバイスがある場合に備えて問題番号が含まれているため、異なる発行番号で区別できます。
<DeviceBinding>: This element allows a provisioning server to ensure that the key is going to be loaded into the device for which the key provisioning request was approved. The device is bound to the request using a device identifier, e.g., an International Mobile Equipment Identity (IMEI) for the phone, or an identifier for a class of identifiers, e.g., those for which the keys are protected by a Trusted Platform Module (TPM).
<devicebinding>：この要素により、プロビジョニングサーバーがキーが承認されたデバイスにキーがロードされるようにすることができます。デバイスは、デバイス識別子を使用して要求にバインドされています。たとえば、電話用の国際モバイル機器ID（IMEI）、または識別子のクラスの識別子、たとえば、キーが信頼できるプラットフォームモジュールによって保護されている識別子（例：TPM）。
<StartDate> and <ExpiryDate>: These two elements indicate the start and end date of a device (such as the one on a payment card, used when issue numbers are not printed on cards). The date MUST be expressed as a dateTime value in "canonical representation" [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. Keys that reside on the device SHOULD only be used when the current date is after the <StartDate> and before the <ExpiryDate>. Note that usage enforcement of the keys with respect to the dates MAY only happen on the validation server, as some devices such as smart cards do not have an internal clock. Systems thus SHOULD NOT rely upon the device to enforce key usage date restrictions.
<StartDate>および<ExpiryDate>：これらの2つの要素は、デバイスの開始日と終了日（問題番号がカードに印刷されていない場合に使用される支払いカードのものなど）を示します。日付は、「標準表現」[W3C.REC-XMLSCHEMA-20041028]の日付値として表現する必要があります。実装は、ミリ秒よりも細かい時間解像度に依存してはならず、左秒を指定する時間インスタントを生成してはなりません。デバイスに存在するキーは、現在の日付が<StartDate>の後、<ExpiryDate>の前である場合にのみ使用する必要があります。スマートカードなどの一部のデバイスには内部クロックがないため、日付に関するキーの使用の使用が検証サーバーでのみ発生する可能性があることに注意してください。したがって、システムは、主要な使用日制限を実施するためにデバイスに依存してはなりません。
Depending on the device type, certain child elements of the <DeviceInfo> element MUST be included in order to uniquely identify a device. This document does not enumerate the different device types and therefore does not list the elements that are mandatory for each type of device.
デバイスの種類に応じて、デバイスを一意に識別するには、<deviceInfo>要素の特定の子要素を含める必要があります。このドキュメントは、異なるデバイスタイプを列挙せず、したがって、各タイプのデバイスに必須の要素をリストしません。
The <CryptoModuleInfo> element identifies the cryptographic module to which the symmetric keys are or have been provisioned. This allows the identification of the specific cases where a device MAY contain more than one crypto module (e.g., a PC hosting a TPM and a connected token).
<cryptomoduleinfo>要素は、対称キーがプロビジョニングされている、またはプロビジョニングされている暗号化モジュールを識別します。これにより、デバイスに複数の暗号モジュール（TPMをホストするPCや接続されたトークンなど）を含む特定のケースを識別できます。
The <CryptoModuleInfo> element has a single child element that MUST be included:
<cryptomoduleinfo>要素には、含める必要がある単一の子供要素があります。
<Id>: This element carries a unique identifier for the CryptoModule and is implementation specific. As such, it helps to identify a specific CryptoModule to which the key is being or was provisioned.
<id>：この要素には、暗号化の一意の識別子が搭載されており、実装固有です。そのため、キーが存在している、またはプロビジョニングされている特定の暗号径を識別するのに役立ちます。
The <UserId> element identifies the user of a distinguished name, as defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net.
<userid>要素は、[rfc4514]で定義されているように、著名な名前のユーザーを識別します。たとえば、uid = jsmith、dc = example、dc = net。
Although the syntax of the user identifier is defined, there are no semantics associated with this element, i.e., there are no checks enforcing that only a specific user can use this key. As such, this element is for informational purposes only.
ユーザー識別子の構文は定義されていますが、この要素に関連するセマンティクスはありません。つまり、特定のユーザーのみがこのキーを使用できることを強制するチェックはありません。そのため、この要素は情報提供のみを目的としています。
This element may appear in two places, namely as a child element of the <Key> element, where it indicates the user with whom the key is associated, and as a child element of the <DeviceInfo> element, where it indicates the user with whom the device is associated.
この要素は、2つの場所、つまり<key>要素の子要素として表示される場合があります。ここでは、キーが関連付けられているユーザーを示し、<deviceInfo>要素の子要素として、ユーザーを示します。デバイスが関連付けられている人。
The <AlgorithmParameters> element is a child element of the <Key> element, and this document defines three child elements: <Suite>, <ChallengeFormat>, and <ResponseFormat>.
<algorithmparameters>要素は<key>要素の子要素であり、このドキュメントでは、<suite>、<saglewerformat>、および<ResponseFormat>の3つの子要素を定義します。
<Suite>:
<Suite>：
The optional <Suite> element defines additional characteristics of the algorithm used, which are algorithm specific. For example, in an HMAC-based (Hashed MAC) OTP algorithm, it could designate the strength of the hash algorithm used (SHA1, SHA256, etc.). Please refer to the algorithm profile section, Section 10, for the exact semantics of the value for each algorithm profile.
オプションの<suite>要素は、使用されるアルゴリズムの追加特性を定義します。これはアルゴリズム固有です。たとえば、HMACベースの（Hashed Mac）OTPアルゴリズムでは、使用されるハッシュアルゴリズムの強度（SHA1、SHA256など）を指定できます。各アルゴリズムプロファイルの値の正確なセマンティクスについては、アルゴリズムプロファイルセクション10を参照してください。
<ChallengeFormat>:
<ChallengeFormat>：
The <ChallengeFormat> element defines the characteristics of the challenge in a CR usage scenario whereby the following attributes are defined:
<ChallengeFormat>要素は、次の属性が定義されているCR使用シナリオでチャレンジの特性を定義します。
'Encoding': This attribute, which MUST be included, defines the encoding of the challenge accepted by the device and MUST be one of the following values:
「エンコード」：この属性を含める必要があるため、デバイスが受け入れたチャレンジのエンコードを定義し、次の値のいずれかでなければなりません。
DECIMAL: Only numerical digits
小数：数値のみ
HEXADECIMAL: Hexadecimal response
16進数：16進応答
ALPHANUMERIC: All letters and numbers (case sensitive)
英数字：すべての文字と数字（ケースに敏感）
BASE64: Base-64 encoded, as defined in Section 4 of [RFC4648]
base64：[RFC4648]のセクション4で定義されているように、ベース64エンコード
BINARY: Binary data
バイナリ：バイナリデータ
'CheckDigit': This attribute indicates whether a device needs to check the appended Luhn check digit, as defined in [ISOIEC7812], contained in a challenge. This is only valid if the 'Encoding' attribute is set to 'DECIMAL'. A value of TRUE indicates that the device will check the appended Luhn check digit in a provided challenge. A value of FALSE indicates that the device will not check the appended Luhn check digit in the challenge.
'CheckDigit'：この属性は、[ISOIEC7812]で定義されているように、デバイスが課題に含まれる[ISOIEC7812]で定義されているように、追加されたLuhn Check Digitをチェックする必要があるかどうかを示します。これは、「エンコード」属性が「小数」に設定されている場合にのみ有効です。Trueの値は、デバイスが提供されたチャレンジでAppled Luhn Check Digitをチェックすることを示します。falseの値は、デバイスがチャレンジでAppled Luhnチェックディジットをチェックしないことを示します。
'Min': This attribute defines the minimum size of the challenge accepted by the device for CR mode and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the minimum number of digits/characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the minimum number of bytes of the unencoded value.
'min'：この属性は、CRモード用にデバイスで受け入れられたチャレンジの最小サイズを定義し、含める必要があります。「エンコード」属性が「小数」、「16進数」、または「英数字」に設定されている場合、この値は数字/文字の最小数を示します。「エンコーディング」属性が「base64」または「バイナリ」に設定されている場合、この値は、非エンコード値の最小バイト数を示します。
'Max': This attribute defines the maximum size of the challenge accepted by the device for CR mode and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the maximum number of digits/characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the maximum number of bytes of the unencoded value.
'max'：この属性は、CRモードのためにデバイスで受け入れられたチャレンジの最大サイズを定義し、含める必要があります。「エンコード」属性が「小数」、「16進数」、または「英数字」に設定されている場合、この値は数字/文字の最大数を示します。「エンコーディング」属性が「base64」または「バイナリ」に設定されている場合、この値は、非エンコード値の最大バイト数を示します。
<ResponseFormat>:
<ResponseFormat>：
The <ResponseFormat> element defines the characteristics of the result of a computation and defines the format of the OTP or the response to a challenge. For cases in which the key is a PIN value, this element contains the format of the PIN itself (e.g., DECIMAL, length 4 for a 4-digit PIN). The following attributes are defined:
<応答Format>要素は、計算の結果の特性を定義し、OTPの形式またはチャレンジへの応答を定義します。キーがピン値である場合、この要素にはピン自体の形式が含まれています（例：小数、4桁のピンの長さ4）。次の属性が定義されています。
'Encoding': This attribute defines the encoding of the response generated by the device, it MUST be included and MUST be one of the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
「エンコーディング」：この属性は、デバイスによって生成された応答のエンコードを定義します。これは含めて、次の値のいずれかでなければなりません：10進、六文字、英数字、Base64、またはバイナリ。
'CheckDigit': This attribute indicates whether the device needs to append a Luhn check digit, as defined in [ISOIEC7812], to the response. This is only valid if the 'Encoding' attribute is set to 'DECIMAL'. If the value is TRUE, then the device will append a Luhn check digit to the response. If the value is FALSE, then the device will not append a Luhn check digit to the response.
'CheckDigit'：この属性は、[ISOIEC7812]で定義されているように、デバイスがLuhn Check Digitを追加する必要があるかどうかを示します。これは、「エンコード」属性が「小数」に設定されている場合にのみ有効です。値が真の場合、デバイスはluhnのチェック桁を応答に追加します。値がfalseの場合、デバイスはluhnのチェック桁を応答に追加しません。
'Length': This attribute defines the length of the response generated by the device and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or ALPHANUMERIC, this value indicates the number of digits/ characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
「長さ」：この属性は、デバイスによって生成された応答の長さを定義し、含める必要があります。「エンコード」属性が「小数」、「16進数」、または英数字に設定されている場合、この値は数字/文字の数を示します。「エンコーディング」属性が「base64」または「バイナリ」に設定されている場合、この値はエンコードされていない値のバイト数を示します。
<KeyProfileId> element, which is a child element of the <Key> element, carries a unique identifier used between the sending and receiving parties to establish a set of key attribute values that are not transmitted within the container but are agreed upon between the two parties out of band. This element will then represent the unique reference to a set of key attribute values. (For example, a smart card application personalization profile id related to specific attribute values present on a smart card application that have influence when computing a response).
<KeyProfileID>要素は、<key>要素の子要素であり、送信者と受信者の間に使用される一意の識別子を持ち、コンテナ内に送信されないが2つの間に合意されている一連のキー属性値を確立します。バンドからのパーティー。この要素は、キー属性値のセットへの一意の参照を表します。（たとえば、応答の計算時に影響を与えるスマートカードアプリケーションに存在する特定の属性値に関連するスマートカードアプリケーションパーソナライズプロファイルID）。
For example, in the case of MasterCard's Chip Authentication Program [CAP], the sending and the receiving party would agree that KeyProfileId='1' represents a certain set of values (e.g., Internet Authentication Flag (IAF) set to a specific value). During transmission of the <KeyContainer>, these values would not be transmitted as key attributes but would only be referred to via the
たとえば、MasterCardのChip認証プログラム[CAP]の場合、送信者と受信者は、KeyProfileID = '1'が特定の値のセットを表すことに同意します（たとえば、特定の値に設定されたインターネット認証フラグ（IAF））。<keyContainer>の送信中、これらの値は重要な属性として送信されるのではなく、
<KeyProfileId> element set to the specific agreed-upon profile (in this case '1'). The receiving party can then associate all relevant key attributes contained in the profile that was agreed upon out of band with the imported keys. Often, this methodology is used between a manufacturing service, run by company A, and the validation service, run by company B, to avoid repeated transmission of the same set of key attribute values.
<KeyProfileID>特定の合意されたプロファイル（この場合は '1'）に設定されています。受信者は、インポートされたキーとバンドから合意されたプロファイルに含まれるすべての関連するキー属性を関連付けることができます。多くの場合、この方法論は、企業Aが運営する製造サービスと、同じキー属性値のセットの繰り返し送信を避けるために、会社Bが運営する検証サービスの間で使用されます。
The <KeyReference> element contains a reference to an external key to be used with a key derivation scheme. In this case, the parent <Key> element will not contain the <Secret> subelement of <Data>, in which the key value (secret) is transported; only the reference to the external master key is transported (e.g., a PKCS #11 key label).
<keyReference>要素には、キー派生スキームで使用される外部キーへの参照が含まれています。この場合、親<key>要素には<secret> <secret> subelement of <data>が含まれていません。キー値（秘密）が輸送されます。外部マスターキーへの参照のみが輸送されます（例：PKCS＃11キーラベル）。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<KeyProfileId>keyProfile1</KeyProfileId>
<KeyReference>MasterKeyLabel
</KeyReference>
<Data>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
Figure 4: Example of a PSKC Document Transmitting an HOTP Key via Key Derivation Values
図4：キー派生値を介してHOTPキーを送信するPSKCドキュメントの例
The key value will be derived using the value of the <SerialNo> element, values agreed upon between the sending and the receiving parties and identified by the <KeyProfile> 'keyProfile1', and an externally agreed-upon key referenced by the label 'MasterKeyLabel'.
キー値は、<serialno>要素の値、送信者と受信者の間で合意され、<keyprofile> 'keyprofile1'によって識別される値、およびラベル「masterkeylabel」によって参照される外部から合意されたキーを使用して導出されます。'。
This section illustrates the functionality of the <Policy> element within PSKC, which allows a key usage and key PIN protection policy to be attached to a specific key and its related metadata. This element is a child element of the <Key> element.
このセクションでは、PSKC内の<ポリシー>要素の機能を示します。これにより、キー使用とキーピン保護ポリシーを特定のキーとその関連メタデータに添付することができます。この要素は、<key>要素の子要素です。
If the <Policy> element contains child elements or values within elements/attributes that are not understood by the recipient of the PSKC document, then the recipient MUST assume that key usage is not permitted. This statement ensures that the lack of understanding of certain extensions does not lead to unintended key usage.
<ポリシー>要素に、PSKCドキュメントの受信者が理解していない要素/属性内の子要素または値が含まれている場合、受信者は重要な使用法が許可されていないと想定する必要があります。このステートメントは、特定の拡張機能の理解の欠如が意図しない主要な使用につながらないことを保証します。
We will start our description with an example that expands the example shown in Figure 3.
図3に示す例を展開する例を使用して説明を開始します。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<PINPolicy MinLength="4" MaxLength="4"
PINKeyId="123456781" PINEncoding="DECIMAL"
PINUsageMode="Local"/>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="123456781"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:pin">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="4" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNA==</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 5: Non-Encrypted HOTP Secret Key Protected by PIN
図5：ピンで保護されている非暗号化HOTPシークレットキー
This document defines the following <Policy> child elements:
このドキュメントは、次の<ポリシー>子要素を定義します。
<StartDate> and <ExpiryDate>: These two elements denote the validity period of a key. It MUST be ensured that the key is only used between the start and the end date (inclusive). The date MUST be expressed as a dateTime value in "canonical representation" [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. When this element is absent, the current time is assumed as the start time.
<StartDate>および<ExpiryDate>：これらの2つの要素は、キーの有効期間を示しています。キーが開始日と終了日の間にのみ使用されることを確認する必要があります（包括的）。日付は、「標準表現」[W3C.REC-XMLSCHEMA-20041028]の日付値として表現する必要があります。実装は、ミリ秒よりも細かい時間解像度に依存してはならず、左秒を指定する時間インスタントを生成してはなりません。この要素が存在しない場合、現在の時刻は開始時間として想定されます。
<NumberOfTransactions>: The value in this element indicates the maximum number of times a key carried within the PSKC document can be used by an application after having received it. When this element is omitted, there is no restriction regarding the number of times a key can be used.
<NumberofTransactions>：この要素の値は、PSKCドキュメント内で運ばれるキーがそれを受け取った後に使用できる最大回数を示します。この要素が省略されている場合、キーを使用できる回数に関する制限はありません。
<KeyUsage>: The <KeyUsage> element puts constraints on the intended usage of the key. The recipient of the PSKC document MUST enforce the key usage. Currently, the following tokens are registered by this document:
<keyUsage>：<keyUsage>要素は、キーの意図した使用法に制約を付けます。PSKCドキュメントの受信者は、重要な使用法を実施する必要があります。現在、次のトークンはこのドキュメントで登録されています。
OTP: The key MUST only be used for OTP generation.
OTP：キーはOTP生成にのみ使用する必要があります。
CR: The key MUST only be used for Challenge/Response purposes.
CR：キーは、チャレンジ/応答の目的でのみ使用する必要があります。
Encrypt: The key MUST only be used for data encryption purposes.
暗号化：キーは、データ暗号化の目的でのみ使用する必要があります。
Integrity: The key MUST only be used to generate a keyed message digest for data integrity or authentication purposes.
整合性：キーは、データの整合性または認証の目的でキー付きメッセージダイジェストを生成するためにのみ使用する必要があります。
Verify: The key MUST only be used to verify a keyed message digest for data integrity or authentication purposes (this is the opposite key usage of 'Integrity').
検証：キーは、データの整合性または認証の目的でキー付きメッセージダイジェストを検証するためにのみ使用する必要があります（これは「整合性」の逆のキー使用です）。
Unlock: The key MUST only be used for an inverse Challenge/ Response in the case where a user has locked the device by entering a wrong PIN too many times (for devices with PIN-input capability).
ロック解除：キーは、ユーザーが間違ったピンを何度も入力することでデバイスをロックした場合（ピン入力機能を備えたデバイスの場合）、逆の挑戦/応答にのみ使用する必要があります。
Decrypt: The key MUST only be used for data decryption purposes.
復号化：キーは、データの復号化の目的でのみ使用する必要があります。
KeyWrap: The key MUST only be used for key wrap purposes.
KeyWrap：キーは、キーラップの目的でのみ使用する必要があります。
Unwrap: The key MUST only be used for key unwrap purposes.
アンラップ：キーは、キーアンラップの目的でのみ使用する必要があります。
Derive: The key MUST only be used with a key derivation function to derive a new key (see also Section 8.2.4 of [NIST800-57]).
派生：キーは、新しいキーを導出するためにキー導入関数でのみ使用する必要があります（[NIST800-57]のセクション8.2.4も参照）。
Generate: The key MUST only be used to generate a new key based on a random number and the previous value of the key (see also Section 8.1.5.2.1 of [NIST800-57]).
生成：キーは、乱数とキーの以前の値に基づいて新しいキーを生成するためにのみ使用する必要があります（[nist800-57]のセクション8.1.5.2.1も参照）。
The element MAY also be repeated to allow several key usages to be expressed. When this element is absent, no key usage constraint is assumed, i.e., the key MAY be utilized for every usage.
要素を繰り返して、いくつかの重要な使用法を表現できるようにすることもできます。この要素がない場合、キー使用量の制約は想定されていません。つまり、使用ごとにキーを使用できます。
<PINPolicy>: The <PINPolicy> element allows policy about the PIN usage to be associated with the key. The following attributes are specified:
<Pinpolicy>：<Pinpolicy>要素により、ピンの使用に関するポリシーがキーに関連付けられています。次の属性が指定されています。
'PINKeyId': This attribute carries the unique 'Id' attribute vale of the <Key> element held within this <KeyContainer> that contains the value of the PIN that protects the key.
'pinkeyid'：この属性には、キーを保護するピンの値を含むこの<keyContainer>内に保持されている<key>要素の一意の「ID」属性属性が含まれます。
'PINUsageMode': This mandatory attribute indicates the way the PIN is used during the usage of the key. The following values are defined:
「PinusageMode」：この必須属性は、キーの使用中にピンを使用する方法を示します。次の値が定義されています。
Local: This value indicates that the PIN is checked locally on the device before allowing the key to be used in executing the algorithm.
ローカル：この値は、アルゴリズムの実行にキーを使用できるようにする前に、ピンがデバイス上でローカルでチェックされていることを示しています。
Prepend: This value indicates that the PIN is prepended to the algorithm response; hence, it MUST be checked by the party validating the response.
PREPEND：この値は、ピンがアルゴリズム応答に加えられていることを示しています。したがって、応答を検証する当事者が確認する必要があります。
Append: This value indicates that the PIN is appended to the algorithm response; hence, it MUST be checked by the party validating the response.
追加：この値は、ピンがアルゴリズム応答に追加されていることを示します。したがって、応答を検証する当事者が確認する必要があります。
Algorithmic: This value indicates that the PIN is used as part of the algorithm computation.
アルゴリズム：この値は、ピンがアルゴリズム計算の一部として使用されていることを示しています。
'MaxFailedAttempts': This attribute indicates the maximum number of times the PIN may be entered wrongly before it MUST NOT be possible to use the key anymore (typical reasonable values are in the positive integer range of at least 2 and no more than 10).
「maxfailedattempts」：この属性は、キーを使用することができなくなる前に、ピンが間違って入力できる最大回数を示します（典型的な合理的な値は、少なくとも2の正の整数範囲にあり、10以下です）。
'MinLength': This attribute indicates the minimum length of a PIN that can be set to protect the associated key. It MUST NOT be possible to set a PIN shorter than this value. If the 'PINFormat' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/ characters. If the 'PINFormat' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
'minlength'：この属性は、関連するキーを保護するように設定できるピンの最小長を示します。この値よりも短いピンを設定することはできないはずです。「Pinformat」属性が「小数」、「16進数」、または「英数字」に設定されている場合、この値は数字/文字の数を示します。「Pinformat」属性が「base64」または「バイナリ」に設定されている場合、この値はエンコードされていない値のバイト数を示します。
'MaxLength': This attribute indicates the maximum length of a PIN that can be set to protect this key. It MUST NOT be possible to set a PIN longer than this value. If the 'PINFormat' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/ characters. If the 'PINFormat' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
'maxlength'：この属性は、このキーを保護するために設定できるピンの最大長を示します。この値よりも長くピンを設定することはできないはずです。「Pinformat」属性が「小数」、「16進数」、または「英数字」に設定されている場合、この値は数字/文字の数を示します。「Pinformat」属性が「base64」または「バイナリ」に設定されている場合、この値はエンコードされていない値のバイト数を示します。
'PINEncoding': This attribute indicates the encoding of the PIN and MUST be one of the values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
「ピンコード」：この属性は、ピンのエンコードを示し、値の1つでなければなりません：10進、六文字、英数字、base64、またはバイナリ。
If the 'PinUsageMode' attribute is set to 'Local', then the device MUST enforce the restriction indicated in the 'MaxFailedAttempts', 'MinLength', 'MaxLength', and 'PINEncoding' attributes; otherwise, it MUST be enforced on the server side.
「pinusagemode」属性が「ローカル」に設定されている場合、デバイスは「maxfailedattempts」、「minlength」、「maxlength」、および「Pinencoding」属性に示されている制限を実施する必要があります。それ以外の場合は、サーバー側で実施する必要があります。
The PIN algorithm is defined as:
ピンアルゴリズムは次のように定義されます。
boolean = comparePIN(K,P)
boolean = comparepin（k、p）
Where:
ただし：
'K' is the stored symmetric credential (PIN) in binary format.
「K」は、バイナリ形式の保存された対称資格（PIN）です。
'P' is the proposed PIN to be compared in binary format.
「P」は、バイナリ形式で比較される提案されたピンです。
The function comparePIN is a straight octet comparison of K and P. Such a comparison MUST yield a value of TRUE (credentials matched) when the octet length of K is the same as the octet length of P and all octets comprising K are the same as the octets comprising P.
関数比較は、KとPのまっすぐなオクテットの比較です。このような比較は、kのオクテットの長さがpのオクテット長と同じであり、kを含むすべてのオクテットが同じである場合、真の（資格情報の値（一致した資格）を生成する必要があります。Pを含むオクテット
With the functionality described in the previous sections, information related to keys had to be transmitted in cleartext. With the help of the <EncryptionKey> element, which is a child element of the <KeyContainer> element, it is possible to encrypt keys and associated information. The level of encryption is applied to the value of individual elements and the applied encryption algorithm MUST be the same for all encrypted elements. Keys are protected using the following methods: pre-shared keys, passphrase-based keys, and asymmetric keys. When encryption algorithms are used that make use of Initialization Vectors (IVs), for example, AES-128-CBC, a random IV value MUST be generated for each value to be encrypted and it MUST be prepended to the resulting encrypted value as specified in [XMLENC].
前のセクションで説明されている機能により、キーに関連する情報をClearTextで送信する必要がありました。<keyContainer>要素の子要素である<encryptionkey>要素の助けを借りて、キーと関連情報を暗号化することができます。暗号化のレベルは個々の要素の値に適用され、適用された暗号化アルゴリズムはすべての暗号化された要素で同じでなければなりません。キーは、以下の方法を使用して保護されています：事前共有キー、パスフレーズベースのキー、および非対称キー。初期化ベクトル（IVS）、たとえばAES-128-CBCなどの暗号化アルゴリズムが使用される場合、暗号化する各値に対してランダムIV値を生成する必要があり、で指定された結果の暗号化値に準備する必要があります。[xmlenc]。
Figure 6 shows an example that illustrates the encryption of the content of the <Secret> element using AES-128-CBC and PKCS #5 Padding. The plaintext value of <Secret> is '3132333435363738393031323334353637383930'. The name of the pre-shared secret is "Pre-shared-key", as set in the <KeyName> element (which is a child element of the <EncryptionKey> element). The value of the encryption key used is '12345678901234567890123456789012'.
図6は、AES-128-CBCおよびPKCS＃5パディングを使用した<secret>要素の含有量の暗号化を示す例を示しています。<secret>の平文値は '3132333435363738393031323334353637383930'です。事前に共有された秘密の名前は、<keyname>要素（<encryptionkey>要素の子要素である要素です）に設定されている「pre-shared-key」です。使用される暗号化キーの値は '12345678901234567890123456789012'です。
The IV for the MAC key is '11223344556677889900112233445566', and the IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
MACキーのIVは「11223455667888990011223345566」、HotPキーのIVは '0001020304050607088090A0B0C0D0E0F'です。
As AES-128-CBC does not provide integrity checks, a keyed MAC is applied to the encrypted value using a MAC key and a MAC algorithm as declared in the <MACMethod> element (in our example, "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the algorithm and the value of the MAC key is randomly generated, in our case '1122334455667788990011223344556677889900', and encrypted with the above encryption key). The result of the keyed-MAC computation is placed in the <ValueMAC> child element of <Secret>.
AES-128-CBCは整合性チェックを提供していないため、<MacMethod>要素で宣言されているMACキーとMACアルゴリズムを使用して、キー付きMACが暗号化された値に適用されます（この例では、 "http：//www.w3.org/2000/09/xmldsig＃hmac-sha1 "はアルゴリズムとして使用され、Macキーの値はランダムに生成されます。Keyed-MAC計算の結果は、<secret>の<valueMac>子要素に配置されます。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey>
<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX
</xenc:CipherValue>
</xenc:CipherData>
</MACKey>
</MACMethod>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc=
</ValueMAC>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1
図6：HMAC-SHA1を使用したAES-128-CBC暗号化された事前共有シークレットキー
When protecting the payload with pre-shared keys, implementations MUST set the name of the specific pre-shared key in the <KeyName> element inside the <EncryptionKey> element. When the encryption method uses a CBC mode that requires an explicit initialization vector (IV), the IV MUST be passed by prepending it to the encrypted value.
プレッシャーキーを使用してペイロードを保護する場合、実装は<encryptionkey>要素内の<keyname>要素の特定の事前共有キーの名前を設定する必要があります。暗号化方法が明示的な初期化ベクトル（IV）を必要とするCBCモードを使用する場合、暗号化された値に準備することにより、IVを渡す必要があります。
For systems implementing PSKC, it is RECOMMENDED to support AES-128-CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-AES128 requires that the key to be protected must be a multiple of 8 bytes in length. Hence, if keys of a different length have to be protected, then the usage of the key-wrap algorithm with padding, as described in [RFC5649] is RECOMMENDED. Some of the encryption algorithms that can optionally be implemented are:
PSKCを実装するシステムの場合、AES-128-CBC（http://www.w3.org/2001/04/xmlenc#aes128-cbc）およびkw-aes128（httpのURIとともに）をサポートすることをお勧めします：//www.w3.org/2001/04/xmlenc#kw-aes128）。KW-AES128では、保護されるキーが長さ8バイトの倍数でなければならないことに注意してください。したがって、[RFC5649]で説明されているように、異なる長さのキーを保護する必要がある場合、パディングを使用したキーWRAPアルゴリズムの使用が推奨されます。オプションで実装できる暗号化アルゴリズムの一部は次のとおりです。
Algorithm | Uniform Resource Locator (URL)
---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
When algorithms without integrity checks are used, such as AES-128- CBC, a keyed-MAC value MUST be placed in the <ValueMAC> element of the <Data> element. In this case, the MAC algorithm type MUST be set in the <MACMethod> element of the <KeyContainer> element. The MAC key MUST be a randomly generated key by the sender, be pre-agreed upon between the receiver and the sender, or be set by the application protocol that carries the PSKC document. It is RECOMMENDED that the sender generate a random MAC key. When the sender generates such a random MAC key, the MAC key material MUST be encrypted with the same encryption key specified in <EncryptionKey> element of the key container. The encryption method and encrypted value MUST be set in the <EncryptionMethod> element and the <CipherData> element, respectively, of the <MACKey> element in the <MACMethod> element. The <MACKeyReference> element of the <MACMethod> element MAY be used to indicate a pre-shared MAC key or a provisioning protocol derived MAC key. For systems implementing PSKC, it is RECOMMENDED to implement the HMAC-SHA1 (with the URI of 'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC algorithms that can optionally be implemented are:
AES-128-CBCなど、整合性チェックのないアルゴリズムが使用される場合、<data>要素の<valuemac>要素にキードマック値を配置する必要があります。この場合、Macアルゴリズムタイプは、<keyContainer>要素の<MacMethod>要素に設定する必要があります。MACキーは、送信者によってランダムに生成されたキーであるか、受信者と送信者の間で事前に合わせて、またはPSKCドキュメントを運ぶアプリケーションプロトコルによって設定する必要があります。送信者がランダムMACキーを生成することをお勧めします。送信者がこのようなランダムMACキーを生成する場合、MACキーマテリアルは、キーコンテナの<encryptionKey>要素で指定された同じ暗号化キーで暗号化する必要があります。暗号化方法と暗号化された値は、<macmethod>要素の<マッキー>要素の<cryptionmethod>要素と<cipherdata>要素にそれぞれ設定する必要があります。<macmethod>要素の<mackeyReference>要素を使用して、事前に共有MACキーまたはプロビジョニングプロトコル派生MACキーを示すことができます。PSKCを実装するシステムの場合、HMAC-Sha1（ 'http://www.w3.org/2000/09/xmldsig#hmac-sha1のURIを実装することをお勧めします。オプションで実装できるMACアルゴリズムの一部は次のとおりです。
Algorithm | Uniform Resource Locator (URL)
---------------+-----------------------------------------------------
HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
Figure 7 shows an example that illustrates the encryption of the content of the <Secret> element using passphrase-based key derivation (PBKDF2) to derive the encryption key as defined in [PKCS5]. When using passphrase-based key derivation, the <DerivedKey> element defined in XML Encryption Version 1.1 [XMLENC11] MUST be used to specify the passphrased-based key. A <DerivedKey> element is set as the child element of <EncryptionKey> element of the key container.
図7は、[PKCS5]で定義されているように暗号化キーを導出するPassPhraseベースのキー派生（PBKDF2）を使用して<secret>要素の含有量の暗号化を示す例を示しています。PassPhraseベースのキー導入を使用する場合、XML暗号化バージョン1.1 [XMLENC11]で定義されている<derivedKey>要素を使用して、PassPhrasedベースのキーを指定する必要があります。<derivedKey>要素は、キーコンテナの<encryptionkey>要素の子要素として設定されています。
The <DerivedKey> element is used to specify the key derivation function and related parameters. The encryption algorithm, in this example, AES-128-CBC (URI 'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the 'Algorithm' attribute of <EncryptionMethod> element used inside the encrypted data elements.
<derivedKey>要素は、キー派生関数と関連パラメーターを指定するために使用されます。暗号化アルゴリズム、この例では、AES-128-CBC（URI 'http://www.w3.org/2001/04/xmlenc#aes128-cbc'）は、<engryptingmethodの属性の「アルゴリズム」に設定する必要があります。>暗号化されたデータ要素内で使用される要素。
When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11: KeyDerivationMethod> element MUST be set to the URI 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The <xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params> child element to indicate the PBKDF2 parameters, such as salt and iteration count.
pbkdf2を使用する場合、<xenc11：keyderivationmethod>要素の「アルゴリズム」属性をuri 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'に設定する必要があります。<xenc11：keyderivationmethod>要素には、塩や反復カウントなどのPBKDF2パラメーターを示すために、<PBKDF2-PARAMS>子要素を含める必要があります。
When the encryption method uses a CBC mode that uses an explicit initialization vector (IV) other than a derived one, the IV MUST be passed by prepending it to the encrypted value.
暗号化方法が、派生したもの以外の明示的な初期化ベクトル（IV）を使用するCBCモードを使用する場合、暗号化された値にプリデュースすることにより、IVを渡す必要があります。
In the example below, the following data is used.
以下の例では、次のデータが使用されています。
Password: qwerty
パスワード：Qwerty
Salt: 0x123eff3c4a72129c
塩：0x123EFF3C4A72129C
Iteration Count: 1000
反復数：1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
OTP Secret: 12345678901234567890
OTP Secret：12345678901234567890
The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41". The initialization vector (IV) is "0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to encrypt the randomly chosen MAC key. A different IV can be used, say "0xd864d39cbc0cdc8e1ee483b9164b9fa0", in the example. The encryption with algorithm "AES-128-CBC" follows the specification defined in [XMLENC].
派生キーは「0x651E63CD57008476AF1FF6422CD02E41」です。初期化ベクトル（IV）は「0xA13BE8F92DB69EC992D99FD1B5CA05F0」です。このキーは、ランダムに選択したMacキーを暗号化するためにも使用されます。例では、「0xD864D39CBC0CDC8E1EE483B9164B9FA0」という別のIVを使用できます。アルゴリズム「AES-128-CBC」を使用した暗号化は、[XMLENC]で定義されている仕様に従います。
<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
<pskc:EncryptionKey>
<xenc11:DerivedKey>
<xenc11:KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params>
<Salt>
<Specified>Ej7/PEpyEpw=</Specified>
</Salt>
<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</pkcs5:PBKDF2-params>
</xenc11:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>
</xenc11:DerivedKey>
</pskc:EncryptionKey>
<pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp" Id="123456">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
</pskc:ValueMAC>
</pskc:Secret>
</pskc:Data>
</pskc:Key>
</pskc:KeyPackage>
</pskc:KeyContainer>
Figure 7: Example of a PSKC Document Using Encryption Based on Passphrase-Based Keys
図7：パスフレーズベースのキーに基づいた暗号化を使用したPSKCドキュメントの例
When using asymmetric keys to encrypt child elements of the <Data> element, information about the certificate being used MUST be stated in the <X509Data> element, which is a child element of the <EncryptionKey> element. The encryption algorithm MUST be indicated in the 'Algorithm' attribute of the <EncryptionMethod> element. In the example shown in Figure 8, the algorithm is set to 'http://www.w3.org/2001/04/xmlenc#rsa_1_5'.
非対称キーを使用して<data>要素の子要素を暗号化する場合、使用されている証明書に関する情報は、<x509data>要素である<x509data>要素で記載する必要があります。暗号化アルゴリズムは、<encryptionmethod>要素の「アルゴリズム」属性に示す必要があります。図8に示す例では、アルゴリズムは「http://www.w3.org/2001/04/xmlenc#rsa_1_5」に設定されています。
<?xml version="1.0" encoding="UTF-8" ?>
<KeyContainer
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
id="KC0001"
Version="1.0">
<EncryptionKey>
<ds:X509Data>
<ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M
Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF
Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR
GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data>
</EncryptionKey>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key
Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData>
<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 8: Example of a PSKC Document Using Encryption Based on Asymmetric Keys
図8：非対称キーに基づく暗号化を使用したPSKCドキュメントの例
For systems implementing PSKC, it is RECOMMENDED to implement the RSA-1.5 algorithm, identified by the URI 'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
PSKCを実装するシステムの場合、URI 'http://www.w3.org/2001/04/xmlenc#rsa-1_5'によって識別されるRSA-1.5アルゴリズムを実装することをお勧めします。
Some of the asymmetric encryption algorithms that can optionally be implemented are:
オプションで実装できる非対称暗号化アルゴリズムの一部は次のとおりです。
Algorithm | Uniform Resource Locator (URL)
------------------+-------------------------------------------------
RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
Padding of encrypted values (for example, the key secret value) is required when key protection algorithms are used that do not support embedded padding and the value to be encrypted is not a multiple of the encryption algorithm cipher block length.
暗号化された値のパディング（たとえば、重要な秘密値）が必要であり、暗号化されたパディングをサポートせず、暗号化される値が暗号化アルゴリズムの倍数の暗号ブロック長の倍数ではありません。
For example, when transmitting an HOTP key (20 bytes long) protected with the AES algorithm in CBC mode (8-byte block cipher), padding is required since its length is not a multiple of the 8-byte block length.
たとえば、CBCモード（8バイトブロック暗号）でAESアルゴリズムで保護されているHOTPキー（20バイト）を送信する場合、その長さは8バイトブロックの長さの倍数ではないため、パディングが必要です。
In these cases, for systems implementing PSKC, it is RECOMMENDED to pad the value before encryption using PKCS #5 padding as described in [PKCS5].
これらの場合、PSKCを実装するシステムの場合、[PKCS5]に記載されているように、PKCS＃5パディングを使用して暗号化前に値を埋めることをお勧めします。
PSKC allows a digital signature to be added to the XML document, as a child element of the <KeyContainer> element. The description of the XML digital signature can be found in [XMLDSIG].
PSKCを使用すると、<keyContainer>要素の子要素として、デジタル署名をXMLドキュメントに追加できます。XMLデジタル署名の説明は[XMLDSIG]にあります。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo>
</DeviceInfo>
<Key Id="123"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
<Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#Device">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>
CN=Example.com,C=US
</ds:X509IssuerName>
<ds:X509SerialNumber>
12345678
</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</ds:KeyInfo>
</Signature>
</KeyContainer>
Figure 9: Digital Signature Example
図9：デジタル署名の例
The functionality of bulk provisioning can be accomplished by repeating the <KeyPackage> element multiple times within the <KeyContainer> element, indicating that multiple keys are provided to different devices or cryptographic modules. The <EncryptionKey> element then applies to all <KeyPackage> elements. When provisioning multiple keys to the same device, the <KeyPackage> element is repeated, but the enclosed <DeviceInfo> element will contain the same sub-elements that uniquely identify the single device (for example, the keys for the device identified by SerialNo='9999999' in the example below).
バルクプロビジョニングの機能は、<keypackage>要素を<keyContainer>要素内で複数回繰り返すことで実現できます。これは、異なるデバイスまたは暗号化モジュールに複数のキーが提供されていることを示します。<encryptionkey>要素は、すべての<keypackage>要素に適用されます。同じデバイスに複数のキーをプロビジョニングすると、<keypackage>要素が繰り返されますが、囲まれた<deviceInfo>要素には、単一のデバイスを一意に識別する同じサブエレメントが含まれます（たとえば、Serialno = serialno =識別されるデバイスのキーは'9999999'以下の例）。
Figure 10 shows an example utilizing these capabilities.
図10は、これらの機能を利用する例を示しています。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>654321</SerialNo>
</DeviceInfo>
<Key Id="1"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>123456</SerialNo>
</DeviceInfo>
<Key Id="2"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="3"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-03-01T00:00:00Z</StartDate>
<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="4"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-04-01T00:00:00Z</StartDate>
<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
Figure 10: Bulk Provisioning Example
図10：バルクプロビジョニングの例
This section lists a few common extension points provided by PSKC:
このセクションには、PSKCが提供するいくつかの一般的な拡張ポイントをリストします。
New PSKC Version: Whenever it is necessary to define a new version of this document, a new version number has to be allocated to refer to the new specification. The version number is carried inside the 'Version' attribute, as described in Section 4, the numbering scheme MUST follow Section 1.2, and rules for extensibility are defined in Section 12.
新しいPSKCバージョン：このドキュメントの新しいバージョンを定義する必要があるときはいつでも、新しい仕様を参照するために新しいバージョン番号を割り当てる必要があります。セクション4で説明されているように、バージョン番号は「バージョン」属性内に配置されます。番号付けスキームはセクション1.2に従う必要があり、拡張性のルールはセクション12で定義されています。
New XML Elements: The usage of the XML schema and the available extension points allows new XML elements to be added. Depending on the type of XML element, different ways for extensibility are offered. In some places, the <Extensions> element can be used and elsewhere the "<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>" XML extension point is utilized.
新しいXML要素：XMLスキーマと使用可能な拡張ポイントの使用により、新しいXML要素を追加できます。XML要素のタイプに応じて、拡張性のためのさまざまな方法が提供されます。一部の場所では、<extensions>要素を使用でき、他の場所では "<xs：any namespace =" ## other "processcontents =" lax "minoccurs =" 0 "maxoccurs =" unbounded "/>" xml拡張ポイントが使用されています。
New XML Attributes: The XML schema allows new XML attributes to be added where XML extension points have been defined (see "<xs: anyAttribute namespace="##other"/>" in Section 11).
新しいXML属性：XMLスキーマを使用すると、XML拡張ポイントが定義されている場合に新しいXML属性を追加できます（ "<xs：anyattribute namespace =" ## other "/>"を参照）。
New PSKC Algorithm Profiles: This document defines two PSKC algorithm profiles, see Section 10. The following informational document describes additional profiles [PSKC-ALGORITHM-PROFILES]. Further PSKC algorithm profiles can be registered as described in Section 12.4.
新しいPSKCアルゴリズムプロファイル：このドキュメントでは、2つのPSKCアルゴリズムプロファイルを定義しています。セクション10を参照してください。さらにPSKCアルゴリズムプロファイルは、セクション12.4で説明されているように登録できます。
Algorithm URIs: Section 6 defines how keys and related data can be protected. A number of algorithms can be used. New algorithms can be used by pointing to a new algorithm URI.
アルゴリズムURIS：セクション6では、キーと関連データの保護方法を定義します。多くのアルゴリズムを使用できます。新しいアルゴリズムURIを指すことにより、新しいアルゴリズムを使用できます。
Policy: Section 5 defines policies that can be attached to a key and keying-related data. The <Policy> element is one such item that allows implementers to restrict the use of the key to certain functions, such as "OTP usage only". Further values may be registered as described in Section 12.
ポリシー：セクション5では、キーおよびキーリング関連のデータに添付できるポリシーを定義します。<policy>要素は、「OTP使用のみ」など、特定の関数へのキーの使用を実装者が制限できるようにする項目の1つです。セクション12で説明されているように、さらなる値を登録できます。
Common Name: HOTP
一般名：HOTP
Class: OTP
クラス：OTP
URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp
Algorithm Definition: [HOTP]
アルゴリズム定義：[hotp]
Identifier Definition: (this RFC)
識別子定義：（このRFC）
Registrant Contact: IESG
登録者の連絡先：IESG
Deprecated: FALSE Profiling:
非推奨：誤プロファイリング：
The <KeyPackage> element MUST be present and the <ResponseFormat> element, which is a child element of the <AlgorithmParameters> element, MUST be used to indicate the OTP length and the value format.
<keypackage>要素が存在する必要があり、<algorithmparameters>要素の子要素である<応答Format>要素を使用して、OTPの長さと値形式を示す必要があります。
The <Counter> element (see Section 4.1) MUST be provided as metadata for the key.
<カウンター>要素（セクション4.1を参照）は、キーのメタデータとして提供する必要があります。
The following additional constraints apply:
次の追加の制約が適用されます。
+ The value of the <Secret> element MUST contain key material with a length of at least 16 octets (128 bits), if it is present.
+ <secret>要素の値には、存在する場合は、少なくとも16オクテット（128ビット）の長さの重要な材料を含める必要があります。
+ The <ResponseFormat> element MUST have the 'Format' attribute set to "DECIMAL", and the 'Length' attribute MUST indicate a length value between 6 and 9 (inclusive).
+ <syponessFormat>要素には「形式」属性が「小数」に設定されている必要があり、「長さ」属性は6〜9（包括的）の長さ値を示す必要があります。
+ The <PINPolicy> element MAY be present, but the 'PINUsageMode' attribute cannot be set to "Algorithmic".
+ <pinpolicy>要素が存在する場合がありますが、「pinusagemode」属性を「アルゴリズム」に設定することはできません。
An example can be found in Figure 3.
例を図3に示します。
Common Name: PIN
一般名：ピン
Class: Symmetric static credential comparison
クラス：対称静的資格的比較
URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
Algorithm Definition: (this RFC) Section 5.1
アルゴリズム定義：（このRFC）セクション5.1
Identifier Definition (this RFC)
識別子定義（このRFC）
Registrant Contact: IESG
登録者の連絡先：IESG
Deprecated: FALSE
非推奨：偽
Profiling:
プロファイリング：
The <Usage> element MAY be present, but no attribute of the <Usage> element is required. The <ResponseFormat> element MAY be used to indicate the PIN value format.
<uesage>要素が存在する場合がありますが、<uesage>要素の属性は必要ありません。<s ResponseFormat>要素を使用して、PIN値形式を示すことができます。
The <Secret> element (see Section 4.1) MUST be provided.
<secret>要素（セクション4.1を参照）を提供する必要があります。
See the example in Figure 5
図5の例を参照してください
This section defines the XML schema for PSKC.
このセクションでは、PSKCのXMLスキーマを定義します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:complexType name="KeyContainerType">
<xs:sequence>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="MACMethod"
type="pskc:MACMethodType" minOccurs="0"/>
<xs:element name="KeyPackage"
type="pskc:KeyPackageType" maxOccurs="unbounded"/>
<xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version"
type="pskc:VersionType" use="required"/>
<xs:attribute name="Id"
type="xs:ID" use="optional"/>
</xs:complexType>
<xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="KeyType">
<xs:sequence>
<xs:element name="Issuer"
type="xs:string" minOccurs="0"/>
<xs:element name="AlgorithmParameters"
type="pskc:AlgorithmParametersType"
minOccurs="0"/>
<xs:element name="KeyProfileId"
type="xs:string" minOccurs="0"/>
<xs:element name="KeyReference"
type="xs:string" minOccurs="0"/>
<xs:element name="FriendlyName"
type="xs:string" minOccurs="0"/>
<xs:element name="Data"
type="pskc:KeyDataType" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Policy"
type="pskc:PolicyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Id"
type="xs:string" use="required"/>
<xs:attribute name="Algorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="KeyUsage"
type="pskc:KeyUsageType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="NumberOfTransactions"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyDataType">
<xs:sequence>
<xs:element name="Secret"
type="pskc:binaryDataType" minOccurs="0"/>
<xs:element name="Counter"
type="pskc:longDataType" minOccurs="0"/>
<xs:element name="Time"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeInterval"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeDrift"
type="pskc:intDataType" minOccurs="0"/>
<xs:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="binaryDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:base64Binary"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="intDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:int"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="stringDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:string"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="longDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:long"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PINPolicyType">
<xs:attribute name="PINKeyId"
type="xs:string" use="optional"/>
<xs:attribute name="PINUsageMode"
type="pskc:PINUsageModeType"/>
<xs:attribute name="MaxFailedAttempts"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MinLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MaxLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="PINEncoding"
type="pskc:ValueFormatType" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<xs:simpleType name="PINUsageModeType">
<xs:restriction base="xs:string">
<xs:enumeration value="Local"/>
<xs:enumeration value="Prepend"/>
<xs:enumeration value="Append"/>
<xs:enumeration value="Algorithmic"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="KeyUsageType">
<xs:restriction base="xs:string">
<xs:enumeration value="OTP"/>
<xs:enumeration value="CR"/>
<xs:enumeration value="Encrypt"/>
<xs:enumeration value="Integrity"/>
<xs:enumeration value="Verify"/>
<xs:enumeration value="Unlock"/>
<xs:enumeration value="Decrypt"/>
<xs:enumeration value="KeyWrap"/>
<xs:enumeration value="Unwrap"/>
<xs:enumeration value="Derive"/>
<xs:enumeration value="Generate"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeviceInfoType">
<xs:sequence>
<xs:element name="Manufacturer"
type="xs:string" minOccurs="0"/>
<xs:element name="SerialNo"
type="xs:string" minOccurs="0"/>
<xs:element name="Model"
type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo"
type="xs:string" minOccurs="0"/>
<xs:element name="DeviceBinding"
type="xs:string" minOccurs="0"/>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptoModuleInfoType">
<xs:sequence>
<xs:element name="Id" type="xs:string"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyPackageType">
<xs:sequence>
<xs:element name="DeviceInfo"
type="pskc:DeviceInfoType" minOccurs="0"/>
<xs:element name="CryptoModuleInfo"
type="pskc:CryptoModuleInfoType" minOccurs="0"/>
<xs:element name="Key"
type="pskc:KeyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AlgorithmParametersType">
<xs:choice>
<xs:element name="Suite" type="xs:string" minOccurs="0"/>
<xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Min"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="Max"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="ResponseFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Length"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="ExtensionsType">
<xs:sequence>
<xs:any namespace="##other"
processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="definition"
type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:simpleType name="KeyAlgorithmType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="ValueFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="DECIMAL"/>
<xs:enumeration value="HEXADECIMAL"/>
<xs:enumeration value="ALPHANUMERIC"/>
<xs:enumeration value="BASE64"/>
<xs:enumeration value="BINARY"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="MACMethodType">
<xs:sequence>
<xs:choice>
<xs:element name="MACKey"
type="xenc:EncryptedDataType" minOccurs="0"/>
<xs:element name="MACKeyReference"
type="xs:string" minOccurs="0"/>
</xs:choice>
<xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>
</xs:schema>
This specification contains the registration of a new media type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].
この仕様には、RFC 4288 [RFC4288]の手順に従って新しいメディアタイプの登録と、RFC 3023 [RFC3023]のガイドラインが含まれています。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: pskc+xml
MIMEサブタイプ名：PSKC XML
Required parameters: There is no required parameter.
必須パラメーター：必須パラメーターはありません。
Optional parameters: charset
オプションのパラメーター：charset
Indicates the character encoding of enclosed XML.
囲まれたXMLの文字エンコードを示します。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2.
考慮事項のエンコーディング：使用する文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。RFC 3023 [RFC3023]、セクション3.2を参照してください。
Security considerations: Please refer to Section 13 of RFC 6030.
セキュリティ上の考慮事項：RFC 6030のセクション13を参照してください。
Interoperability considerations: None Published specification: RFC 6030.
相互運用性の考慮事項：公開されていない仕様：RFC 6030。
Applications which use this media type: This media type is being used as a symmetric key container format for transport and provisioning of symmetric keys (One-Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. As such, it is used for key provisioning systems.
このメディアタイプを使用するアプリケーション：このメディアタイプは、さまざまなタイプの強力な認証デバイスに対して、対称キー（1回限りのパスワード（OTP）共有秘密または対称的な暗号化キー）の輸送とプロビジョニングのための対称キーコンテナ形式として使用されています。そのため、主要なプロビジョニングシステムに使用されます。
Additional information:
追加情報：
Magic Number: None
マジック番号：なし
File Extension: .pskcxml
ファイル拡張子：.pskcxml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード：「テキスト」
Personal and email address to contact for further information: Philip Hoyer, Philip.Hoyer@actividentity.com
詳細については、個人および電子メールアドレスをお問い合わせ：Philip Hoyer、Philip.hoyer@actividentity.com
Intended usage: LIMITED USE
意図された使用法：使用されています
Restrictions on usage: None
使用に関する制限：なし
Author: This specification is a work item of the IETF KEYPROV working group, with mailing list address <keyprov@ietf.org>.
著者：この仕様は、メーリングリストアドレス<keyprov@ietf.org>を備えたIETF keyprovワーキンググループの作業項目です。
Change controller: The IESG <iesg@ietf.org>
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:keyprov:pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com).
登録者の連絡先：IETF Keyprovワーキンググループ、Philip Hoyer（Philip.hoyer@actividentity.com）。
XML Schema: The XML schema to be registered is contained in Section 11. Its first line is
XMLスキーマ：登録するXMLスキーマはセクション11に含まれています。その最初の行は
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
そしてその最後の行はです
</xs:schema>
This section registers a new XML namespace, "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXMLネームスペース「urn：ietf：xml：xml：ns：keyprov：pskc」を登録します。
URI: urn:ietf:params:xml:ns:keyprov:pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com).
登録者の連絡先：IETF Keyprovワーキンググループ、Philip Hoyer（Philip.hoyer@actividentity.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>PSKC Namespace</title>
</head>
<body>
<h1>Namespace for PSKC</h1>
<h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6030.txt">
RFC 6030</a>.</p>
</body>
</html>
END
IANA has created a registry for PSKC algorithm profiles in accordance with the principles set out in RFC 5226 [RFC5226].
IANAは、RFC 5226 [RFC5226]に定められた原則に従って、PSKCアルゴリズムプロファイルのレジストリを作成しました。
As part of this registry, IANA maintains the following information:
このレジストリの一部として、IANAは次の情報を維持しています。
Common Name: The name by which the PSKC algorithm profile is generally referred.
一般名：PSKCアルゴリズムプロファイルが一般的に参照される名前。
Class: The type of PSKC algorithm profile registry entry being created, such as encryption, Message Authentication Code (MAC), One-Time Password (OTP), Digest.
クラス：暗号化、メッセージ認証コード（MAC）、ワンタイムパスワード（OTP）、ダイジェストなど、作成されるPSKCアルゴリズムプロファイルレジストリエントリのタイプ。
URI: The URI to be used to identify the profile.
URI：プロファイルを識別するために使用されるURI。
Identifier Definition: IANA will add a pointer to the specification containing information about the PSKC algorithm profile registration.
識別子定義：IANAは、PSKCアルゴリズムプロファイル登録に関する情報を含む仕様へのポインターを追加します。
Algorithm Definition: A reference to the stable document in which the algorithm being used with the PSKC is defined.
アルゴリズム定義：PSKCで使用されているアルゴリズムが定義されている安定したドキュメントへの参照。
Registrant Contact: Contact information about the party submitting the registration request.
登録者の連絡先：登録要求を提出する当事者に関する連絡先情報。
Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE.
非推奨：このエントリが専門家の承認に基づいて廃止され、新しい実装で使用されるべきではない場合は真実です。それ以外の場合、false。
PSKC Profiling: Information about PSKC XML elements and attributes being used (or not) with this specific profile of PSKC.
PSKCプロファイリング：PSKCのこの特定のプロファイルで使用されている（または使用しない）PSKC XML要素と属性に関する情報。
PSKC algorithm profile identifier registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
PSKCアルゴリズム識別子登録は、RFC 5226 [RFC5226]に従って、必要な仕様の対象となります。更新は、専門家の承認のみに基づいて提供できます。専門家の承認に基づいて、エントリを「非推奨」とマークすることができます。指定された専門家がIESGによって任命されます。
IANA has added two initial values to the registry based on the algorithm profiles described in Section 10.
IANAは、セクション10で説明したアルゴリズムプロファイルに基づいて、レジストリに2つの初期値を追加しました。
IANA has created a registry for PSKC version numbers. The registry has the following structure:
IANAは、PSKCバージョン番号のレジストリを作成しました。レジストリには次の構造があります。
PSKC Version | Specification
+---------------------------+----------------
| 1.0 | RFC 6030
Standards action is required to define new versions of PSKC. It is not envisioned to deprecate, delete, or modify existing PSKC versions.
PSKCの新しいバージョンを定義するには、標準アクションが必要です。既存のPSKCバージョンを非難、削除、または変更することは想定されていません。
IANA has created a registry for key usage. A description of the <KeyUsage> element can be found in Section 5.
IANAは、主要な使用法のレジストリを作成しました。<keyUsage>要素の説明は、セクション5にあります。
As part of this registry IANA will maintain the following information:
このレジストリの一部として、IANAは次の情報を維持します。
Key Usage: The identifier of the Key Usage.
主要な使用法：主要な使用法の識別子。
Specification: IANA will add a pointer to the specification containing information about the semantics of a new Key Usage registration.
仕様：IANAは、新しいキー使用登録のセマンティクスに関する情報を含む仕様へのポインタを追加します。
Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE.
非推奨：このエントリが専門家の承認に基づいて廃止され、新しい実装で使用されるべきではない場合は真実です。それ以外の場合、false。
IANA has added these initial values to the registry:
IANAはこれらの初期値をレジストリに追加しました。
Key Usage | Specification | Deprecated
+---------------+------------------------------+-----------
| OTP | [Section 5 of this document] | FALSE
| CR | [Section 5 of this document] | FALSE
| Encrypt | [Section 5 of this document] | FALSE
| Integrity | [Section 5 of this document] | FALSE
| Verify | [Section 5 of this document] | FALSE
| Unlock | [Section 5 of this document] | FALSE
| Decrypt | [Section 5 of this document] | FALSE
| KeyWrap | [Section 5 of this document] | FALSE
| Unwrap | [Section 5 of this document] | FALSE
| Derive | [Section 5 of this document] | FALSE
| Generate | [Section 5 of this document] | FALSE
+---------------+------------------------------+-----------
Key Usage Registry registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Expert Review is required to define new Key Usage values. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
主要な使用量レジストリ登録は、RFC 5226 [RFC5226]に従って、必要な仕様の対象となります。新しい主要な使用値を定義するには、専門家のレビューが必要です。更新は、専門家の承認のみに基づいて提供できます。専門家の承認に基づいて、エントリを「非推奨」とマークすることができます。指定された専門家がIESGによって任命されます。
The portable symmetric key container (PSKC) carries sensitive information (e.g., cryptographic keys) and may be transported across the boundaries of one secure perimeter to another. For example, a container residing within the secure perimeter of a back-end provisioning server in a secure room may be transported across the Internet to an end-user device attached to a personal computer. This means that special care MUST be taken to ensure the confidentiality, integrity, and authenticity of the information contained within.
ポータブル対称キーコンテナ（PSKC）には、機密情報（たとえば、暗号化キー）が搭載されており、1つの安全な境界を越えて別の境界線に輸送できます。たとえば、安全な部屋にあるバックエンドプロビジョニングサーバーの安全な周囲にあるコンテナは、インターネットを越えてパーソナルコンピューターに接続されたエンドユーザーデバイスに輸送できます。これは、内部に含まれる情報の機密性、完全性、および信頼性を確保するために特別な注意を払わなければならないことを意味します。
By design, the container allows two main approaches to guaranteeing the confidentiality of the information it contains while transported.
設計上、コンテナは、輸送中に含まれる情報の機密性を保証する2つの主要なアプローチを許可します。
First, the container key data payload may be encrypted.
まず、コンテナキーデータペイロードを暗号化できます。
In this case, no transport layer security is required. However, standard security best practices apply when selecting the strength of the cryptographic algorithm for key data payload encryption. A symmetric cryptographic cipher SHOULD be used -- the longer the cryptographic key, the stronger the protection. Please see Section 6.1 for recommendations of key data payload protection using symmetric cryptographic ciphers. In cases where the exchange of key encryption keys between the sender and the receiver is not possible, asymmetric encryption of the key data payload may be employed, see Section 6.3. Similar to symmetric key cryptography, the stronger the asymmetric key, the more secure the protection.
この場合、輸送層のセキュリティは必要ありません。ただし、キーデータペイロード暗号化の暗号化アルゴリズムの強度を選択するときに、標準のセキュリティベストプラクティスが適用されます。対称的な暗号性暗号を使用する必要があります - 暗号化キーが長くなるほど、保護が強くなります。対称暗号化暗号を使用した主要なデータペイロード保護の推奨については、セクション6.1を参照してください。送信者と受信機の間のキー暗号化キーの交換が不可能な場合、キーデータペイロードの非対称暗号化が使用される場合があります。セクション6.3を参照してください。対称キー暗号化と同様に、非対称キーが強くなるほど、保護が安全になります。
If the key data payload is encrypted with a method that uses one of the password-based encryption methods (PBE methods) detailed in Section 6.2, the key data payload may be subjected to password dictionary attacks to break the encryption password and recover the information. Standard security best practices for selection of strong encryption passwords apply.
キーデータペイロードが、セクション6.2で詳述されているパスワードベースの暗号化メソッド（PBEメソッド）のいずれかを使用するメソッドで暗号化されている場合、キーデータペイロードはパスワード辞書攻撃を受けて、暗号化パスワードを破り、情報を回復することができます。強力な暗号化パスワードを選択するための標準的なセキュリティベストプラクティスが適用されます。
Additionally, it is strongly RECOMMENDED that practical implementations use PBESalt and PBEIterationCount when PBE encryption is used. A different PBESalt value per PSKC SHOULD be used for best protection.
さらに、PBE暗号化を使用する場合、実際の実装ではPbesaltおよびPbeiterationCountを使用することを強くお勧めします。PSKCあたりの異なるPbesalt値を最良の保護に使用する必要があります。
The second approach to protecting the confidentiality of the key data is based on using lower-layer security mechanisms (e.g., [TLS], [IPsec]). The secure connection established between the source secure perimeter (the provisioning server from the example above) and the target perimeter (the device attached to the end-user computer) utilizes encryption to protect the messages that travel across that connection. No key data payload encryption is required in this mode. Secure connections that encrypt and digest each message provide an extra measure of security.
重要なデータの機密性を保護する2番目のアプローチは、低層セキュリティメカニズム（[TLS]、[IPSEC]など）の使用に基づいています。ソースセキュアー周辺（上記の例からのプロビジョニングサーバー）とターゲット周辺（エンドユーザーコンピューターに接続されたデバイス）との間に確立された安全な接続は、暗号化を使用して、その接続を越えて移動するメッセージを保護します。このモードでは、キーデータペイロード暗号化は必要ありません。各メッセージを暗号化して消化する接続を保護します。
Because of the fact that the plaintext PSKC is protected only by the transport layer security, practical implementation MUST ensure protection against man-in-the-middle attacks. Authenticating the secure channel endpoints is critically important for eliminating intruders that may compromise the confidentiality of the PSKC.
Plantext PSKCは輸送層のセキュリティによってのみ保護されているという事実のため、実用的な実装は、中間の攻撃に対する保護を確保する必要があります。安全なチャネルエンドポイントを認証することは、PSKCの機密性を損なう可能性のある侵入者を排除するために非常に重要です。
The PSKC provides means to guarantee the integrity of the information it contains through the use of digital signatures. It is RECOMMENDED that for best security practices, the digital signature of the container encompasses the entire PSKC. This provides assurances for the integrity of all attributes. It also allows verification of the integrity of a given PSKC even after the container is delivered through the communication channel to the target perimeter and channel message integrity check is no longer possible.
PSKCは、デジタル署名を使用して含まれる情報の完全性を保証する手段を提供します。最良のセキュリティ慣行の場合、コンテナのデジタル署名にはPSKC全体が含まれることをお勧めします。これは、すべての属性の完全性を保証します。また、コンテナが通信チャネルを介してターゲット周辺に配信された後でも、特定のPSKCの整合性の検証が可能になり、チャネルメッセージの整合性チェックは不可能になります。
The digital signature of the PSKC is the primary way of showing its authenticity. The recipient of the container SHOULD use the public key associated with the signature to assert the authenticity of the sender by tracing it back to a pre-loaded public key or certificate. Note that the digital signature of the PSKC can be checked even after the container has been delivered through the secure channel of communication.
PSKCのデジタル署名は、その信頼性を示す主要な方法です。コンテナの受信者は、署名に関連付けられた公開鍵を使用して、事前に搭載された公開キーまたは証明書にトレースすることにより、送信者の信ity性を主張する必要があります。PSKCのデジタル署名は、安全な通信チャネルを通じてコンテナが配信された後でもチェックできることに注意してください。
Authenticity guarantee may be provided by [TLS] or [IPsec]. However, no authenticity verification is possible once the container is delivered at the recipient end. Since the TLS endpoints could differ from the key provisioning endpoints, this solution is weaker than the previous solution that relies on a digital signature of the PSKC.
信頼性保証は、[TLS]または[IPSEC]によって提供される場合があります。ただし、受信者の端でコンテナが配信されると、信頼性の検証は不可能です。TLSエンドポイントは主要なプロビジョニングエンドポイントと異なる可能性があるため、このソリューションはPSKCのデジタル署名に依存する以前のソリューションよりも弱いです。
We would like Hannes Tschofenig for his text contributions to this document.
この文書へのテキストの貢献については、Hannes Tschofenigが欲しいです。
The authors of this document would like to thank the following people for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart Bajaj, Stu Vaeth, Kevin Lewis, Philip Hallam-Baker, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner, and especially Robert Philpott.
この文書の著者は、アポストール・ヴァシレフ、シュ・チャン、ジョン・マーティンソン、シッダート・バジャジ、スゥ・ヴァース、ケビン・ルイス、フィリップ・ハラム・ベーカー、アンドレア・ドハティ、マグナス・ニセストロム、ティム・モーゼス、ランドグレンのランドグレンのアンド・ヴァース、シッダート・バジャジ、シッドハート・バジャジ、彼らのフィードバックについて、次の人々に感謝したいと思います。、ショーン・ターナー、特にロバート・フィルポット。
We would like to thank Sean Turner for his review in January 2009. We would also like to thank Anders Rundgren for triggering the discussion regarding to the selection of encryption algorithms (KW-AES-128 vs. AES-128-CBC) and his input on the keyed message digest computation.
2009年1月のレビューについてSean Turnerに感謝します。また、暗号化アルゴリズム（KW-AES-128対AES-128-CBC）の選択に関する議論をトリガーしてくれたAnders Rundgrenにも感謝したいと思います。キー付きメッセージダイジェスト計算。
This work is based on earlier work by the members of OATH (Initiative for Open AuTHentication), see [OATH], to specify a format that can be freely distributed to the technical community.
この作業は、技術コミュニティに自由に配布できる形式を指定するために、[宣言のためのOpen認証のイニシアチブ）を参照してください。
[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced Encryption Standard (AES)", November 2001.
[FIPS197]国立標準研究所、「FIPS Pub 197：Advanced Encryption Standard（AES）」、2001年11月。
[HOTP] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[HOTP] M'Raihi、D.、Bellare、M.、Hoornaert、F.、Naccache、D。、およびO. Ranen、「Hotp：HMACベースのワンタイムパスワードアルゴリズム」、RFC 4226、2005年12月。
[IANAPENREG] IANA, "Private Enterprise Numbers", <http://www.iana.org>.
[ianapenreg] iana、「プライベートエンタープライズ番号」、<http://www.iana.org>。
[ISOIEC7812] ISO, "ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system", October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812] ISO、「ISO/IEC 7812-1：2006識別カード - 発行者の識別 - パート1：番号付けシステム」、2006年10月、<http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm？csnumber = 39698>。
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April 2009, <http://www.openauthentication.org/oath-id/prefixes/>.
[Oathman] Oath、「Oath Manufacturer Prefixes（OMP）のリスト」、2009年4月、<http://www.openauthentication.org/oath-id/prefixes/>。
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography Standard", Version 2.0, March 1999, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS5] RSA Laboratories、「PKCS＃5：パスワードベースの暗号標準」、バージョン2.0、1999年3月、<http://www.rsasecurity.com/rsalabs/pkcs/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[RFC5649] Housley、R。およびM. Dworkin、「Advanced Encryption Standard（AES）パディングアルゴリズム付きキーラップ」、RFC 5649、2009年9月。
[SP800-67] National Institute of Standards, "NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", NIST Special Publication 800-67, May 2008.
[SP800-67]国立標準研究所、「NIST Special Publication 800-67バージョン1.1：トリプルデータ暗号化アルゴリズム（TDEA）ブロックCipherの推奨」、NIST Special Publication 800-67、2008年5月。
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2-20041028] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-20041028、2004年10月、<http：//www.w3.org/tr/2004/rec-xmlschema-2-20041028>。
[XMLDSIG] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[Xmldsig] Solo、D.、Reagle、J。、およびD. Eastlake、「XML-Signature Syntax and Processing」、World Wide Web Consortium Firstedition Rec-Xmldsig-Core-20020212、2002年2月、<http：// www。w3.org/tr/2002/rec-xmldsig-core-20020212>。
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLENC] EastLake、D。、「XML暗号化構文と処理」、W3C推奨、2002年12月、<http://www.w3.org/tr/xmlenc-core/>。
[XMLENC11] Reagle, J. and D. Eastlake, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium WD WD-xmlenc-core1-20090730, July 2009, <http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>.
[XMLENC11] Reagle、J。and D. Eastlake、 "XML暗号化構文および処理バージョン1.1"、World Wide Web Consortium WD-XMLENC-CORE1-20090730、2009年7月、<http://www.w3.org/tr/2009/WD-XMLENC-CORE1-20090730>。
[CAP] MasterCard International, "Chip Authentication Program Functional Architecture", September 2004.
[CAP] MasterCard International、「チップ認証プログラム機能アーキテクチャ」、2004年9月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "NIST Special Publication 800-57, Recommendation for Key Management Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[Nist800-57] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「Nist Special Publication 800-57、主要管理の推奨パート1：一般（改訂）」、NIST Special Publication 800-57、2007年3月。
[OATH] "Initiative for Open AuTHentication", <http://www.openauthentication.org>.
[OATH]「オープン認証のためのイニシアチブ」、<http://www.openauthentication.org>。
[PSKC-ALGORITHM-PROFILES] Hoyer, P., Pei, M., Machani, S., and A. Doherty, "Additional Portable Symmetric Key Container (PSKC) Algorithm Profiles", Work in Progress, May 2010.
[PSKC-Algorithm-Profiles] Hoyer、P.、Pei、M.、Machani、S.、およびA. Doherty、「追加のポータブル対称キーコンテナ（PSKC）アルゴリズムプロファイル」、2010年5月の作業。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[XMLNS] Hollander、D.、Bray、T。、およびA. Layman、「XMLの名前空間」、World Wide Web Consortium Firstedition Rec-XML-Names-1990114、1999年1月、<http://www.w3.org/TR/1999/REC-XML-NAMES-1990114>。
This section describes a comprehensive list of use cases that inspired the development of this specification. These requirements were used to derive the primary requirement that drove the design. These requirements are covered in the next section.
このセクションでは、この仕様の開発に影響を与えたユースケースの包括的なリストについて説明します。これらの要件は、設計を推進する主要な要件を導き出すために使用されました。これらの要件については、次のセクションで説明します。
These use cases also help in understanding the applicability of this specification to real-world situations.
これらのユースケースは、この仕様の現実世界の状況への適用性を理解するのにも役立ちます。
This section describes the use cases related to provisioning the keys using an online provisioning protocol.
このセクションでは、オンラインプロビジョニングプロトコルを使用してキーのプロビジョニングに関連するユースケースについて説明します。
For example, a mobile device user wants to obtain a symmetric key for use with a cryptographic module on the device. The cryptographic module from vendor A initiates the provisioning process against a provisioning system from vendor B using a standards-based provisioning protocol. The provisioning entity delivers one or more keys in a standard format that can be processed by the mobile device.
たとえば、モバイルデバイスユーザーは、デバイス上の暗号化モジュールで使用する対称キーを取得したいと考えています。ベンダーAの暗号化モジュールは、標準ベースのプロビジョニングプロトコルを使用して、ベンダーBのプロビジョニングシステムに対するプロビジョニングプロセスを開始します。プロビジョニングエンティティは、モバイルデバイスで処理できる標準形式で1つ以上のキーを配信します。
For example, in a variation of the above, instead of the user's mobile phone, a key is provisioned in the user's soft token application on a laptop using a network-based online protocol. As before, the provisioning system delivers a key in a standard format that can be processed by the soft token on the PC.
たとえば、上記のバリエーションでは、ユーザーの携帯電話の代わりに、ネットワークベースのオンラインプロトコルを使用してラップトップ上のユーザーのソフトトークンアプリケーションにキーがプロビジョニングされます。前と同様に、プロビジョニングシステムは、PC上のソフトトークンによって処理できる標準形式のキーを提供します。
For example, the end user or the key issuer wants to update or configure an existing key in the cryptographic module and requests a replacement key container. The container may or may not include a new key and may include new or updated key attributes such as a new counter value in HOTP key case, a modified response format or length, a new friendly name, etc.
たとえば、エンドユーザーまたはキー発行者は、暗号化モジュールの既存のキーを更新または構成し、交換用キーコンテナを要求したいと考えています。コンテナには、新しいキーが含まれる場合と含まない場合があり、HOTPキーケースの新しいカウンター値、変更された応答形式または長さ、新しいフレンドリー名などの新しいまたは更新されたキー属性を含めることができます。
For example, a user wants to transport a key from one cryptographic module to another. There may be two cryptographic modules, one on a computer and one on a mobile phone, and the user wants to transport a key from the computer to the mobile phone. The user can export the key and related data in a standard format for input into the other cryptographic module.
たとえば、ユーザーは、ある暗号化モジュールから別のモジュールにキーを輸送したいと考えています。コンピューターに1つと携帯電話に1つは、2つの暗号化モジュールがあり、ユーザーはコンピューターから携帯電話にキーを輸送したいと考えています。ユーザーは、他の暗号化モジュールに入力するために、標準形式でキーおよび関連データをエクスポートできます。
For example, a user wants to activate and use a new key and related data against a validation system that is not aware of this key. This key may be embedded in the cryptographic module (e.g., a Secure Digital (SD) card, USB drive) that the user has purchased at the local electronics retailer. Along with the cryptographic module, the user may get the key on a CD or a floppy in a standard format. The user can now upload via a secure online channel or import this key and related data into the new validation system and start using the key.
たとえば、ユーザーは、このキーを認識していない検証システムに対して、新しいキーおよび関連データをアクティブ化して使用したいと考えています。このキーは、ユーザーがローカルエレクトロニクス小売業者で購入した暗号化モジュール（たとえば、安全なデジタル（SD）カード、USBドライブ）に埋め込まれる場合があります。暗号化モジュールに加えて、ユーザーは標準形式でCDまたはフロッピーのキーを取得できます。ユーザーは、安全なオンラインチャネルを介してアップロードするか、このキーと関連データを新しい検証システムにインポートして、キーの使用を開始できます。
From time to time, a key management system may be required to import or export keys in bulk from one entity to another.
あるエンティティから別のエンティティへの大量のキーをインポートまたはエクスポートするには、随時、キー管理システムが必要になる場合があります。
For example, instead of importing keys from a manufacturer using a file, a validation server may download the keys using an online protocol. The keys can be downloaded in a standard format that can be processed by a validation system.
たとえば、ファイルを使用してメーカーからキーをインポートする代わりに、検証サーバーはオンラインプロトコルを使用してキーをダウンロードできます。キーは、検証システムで処理できる標準形式でダウンロードできます。
For example, in a variation of the above, an Over-The-Air (OTA) key provisioning gateway that provisions keys to mobile phones may obtain key material from a key issuer using an online protocol. The keys are delivered in a standard format that can be processed by the key provisioning gateway and subsequently sent to the mobile phone of the end user.
たとえば、上記のバリエーションでは、携帯電話へのキーを提供するキーを提供する可能性があるオーバーザエア（OTA）キープロビジョニングゲートウェイは、オンラインプロトコルを使用してキー発行者からキー資料を取得できます。キーは、キープロビジョニングゲートウェイによって処理され、その後エンドユーザーの携帯電話に送信される標準形式で配信されます。
This section describes the use cases relating to offline transport of keys from one system to another, using some form of export and import model.
このセクションでは、何らかの形のエクスポートおよびインポートモデルを使用して、あるシステムから別のシステムへのキーのオフライン輸送に関するユースケースについて説明します。
For example, cryptographic modules, such as OTP authentication tokens, may have their symmetric keys initialized during the manufacturing process in bulk, requiring copies of the keys and algorithm data to be loaded into the authentication system through a file on portable media. The manufacturer provides the keys and related data in the form of a file containing records in standard format, typically on a CD. Note that the token manufacturer and the vendor for the validation system may be the same or different. Some crypto modules will allow local PIN management (the device will have a PIN pad); hence, random initial PINs set at manufacturing should be transmitted together with the respective keys they protect.
たとえば、OTP認証トークンなどの暗号化モジュールには、製造プロセス中に対称キーが初期化され、キーのコピーとアルゴリズムデータをポータブルメディア上のファイルを介して認証システムにロードする必要があります。メーカーは、通常はCDに標準形式のレコードを含むファイルの形式でキーと関連データを提供します。検証システムのトークンメーカーとベンダーは同じまたは異なる場合があることに注意してください。一部の暗号モジュールでは、ローカルピン管理が可能になります（デバイスにはピンパッドがあります）。したがって、製造に設定されたランダムな初期ピンは、保護するそれぞれのキーと一緒に送信する必要があります。
For example, an enterprise wants to port keys and related data from an existing validation system A into a different validation system B. The existing validation system provides the enterprise with a functionality that enables export of keys and related data (e.g., for OTP authentication tokens) in a standard format. Since the OTP tokens are in the standard format, the enterprise can import the token records into the new validation system B and start using the existing tokens. Note that the vendors for the two validation systems may be the same or different.
たとえば、エンタープライズは、既存の検証システムAからキーと関連データを別の検証システムBに移植することを望んでいます。既存の検証システムは、エンタープライズにキーと関連データのエクスポートを可能にする機能を提供します（例：OTP認証トークン用）標準形式。OTPトークンは標準形式であるため、エンタープライズはトークンレコードを新しい検証システムBにインポートし、既存のトークンの使用を開始できます。2つの検証システムのベンダーは同じまたは異なる場合があることに注意してください。
This section outlines the most relevant requirements that are the basis of this work. Several of the requirements were derived from use cases described above.
このセクションでは、この作業の基礎となる最も関連性の高い要件の概要を説明します。いくつかの要件は、上記のユースケースから導き出されました。
R1: The format MUST support the transport of multiple types of symmetric keys and related attributes for algorithms including HOTP, other OTP, Challenge/Response, etc.
R1：この形式は、HOTP、その他のOTP、課題/応答などを含むアルゴリズムの複数のタイプの対称キーと関連属性の輸送をサポートする必要があります。
R2: The format MUST handle the symmetric key itself as well of attributes that are typically associated with symmetric keys. Some of these attributes may be
R2：この形式は、対称キーに通常関連付けられている属性の対称キー自体を処理する必要があります。これらの属性のいくつかはそうかもしれません
* Unique Key Identifier
* 一意のキー識別子
* Issuer information
* 発行者情報
* Algorithm ID
* アルゴリズムID
* Algorithm mode
* アルゴリズムモード
* Issuer Name
* 発行者名
* Key friendly name
* キーフレンドリーな名前
* Event counter value (moving factor for OTP algorithms)
* イベントカウンター値（OTPアルゴリズムの移動係数）
* Time value
* 時間値
R3: The format SHOULD support both offline and online scenarios. That is, it should be serializable to a file as well as it should be possible to use this format in online provisioning protocols.
R3：フォーマットは、オフラインシナリオとオンラインシナリオの両方をサポートする必要があります。つまり、ファイルにシリアル化可能である必要があり、オンラインプロビジョニングプロトコルでこの形式を使用することができるはずです。
R4: The format SHOULD allow bulk representation of symmetric keys.
R4：この形式では、対称キーのバルク表現を可能にする必要があります。
R5: The format SHOULD allow bulk representation of PINs related to specific keys.
R5：フォーマットでは、特定のキーに関連するピンのバルク表現を可能にする必要があります。
R6: The format SHOULD be portable to various platforms. Furthermore, it SHOULD be computationally efficient to process.
R6：フォーマットは、さまざまなプラットフォームに移植可能である必要があります。さらに、処理するのに計算的に効率的でなければなりません。
R7: The format MUST provide an appropriate level of security in terms of data encryption and data integrity.
R7：形式は、データ暗号化とデータの整合性に関して、適切なレベルのセキュリティを提供する必要があります。
R8: For online scenarios, the format SHOULD NOT rely on transport layer security (e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS)) for core security requirements.
R8：オンラインシナリオの場合、フォーマットは、コアセキュリティ要件のためにトランスポートレイヤーセキュリティ（たとえば、セキュアソケットレイヤー/トランスポートレイヤーセキュリティ（SSL/TLS））に依存しないでください。
R9: The format SHOULD be extensible. It SHOULD enable extension points allowing vendors to specify additional attributes in the future.
R9：形式は拡張可能である必要があります。ベンダーが将来追加の属性を指定できるようにする拡張ポイントを可能にするはずです。
R10: The format SHOULD allow for distribution of key derivation data without the actual symmetric key itself. This is to support symmetric key management schemes that rely on key derivation algorithms based on a pre-placed master key. The key derivation data typically consists of a reference to the key, rather than the key value itself.
R10：この形式では、実際の対称キー自体なしでキー派生データの配布を可能にする必要があります。これは、事前に配置されたマスターキーに基づいてキー派生アルゴリズムに依存する対称キー管理スキームをサポートするためです。キー派生データは通常、キー値自体ではなく、キーへの参照で構成されています。
R11: The format SHOULD allow for additional life cycle management operations such as counter resynchronization. Such processes require confidentiality between client and server, thus could use a common secure container format, without the transfer of key material.
R11：この形式では、カウンター再同期などの追加のライフサイクル管理操作が可能になります。このようなプロセスには、クライアントとサーバー間の機密性が必要であるため、重要な資料を転送せずに、一般的なセキュリティコンテナ形式を使用できます。
R12: The format MUST support the use of pre-shared symmetric keys to ensure confidentiality of sensitive data elements.
R12：この形式は、敏感なデータ要素の機密性を確保するために、事前に共有対称キーの使用をサポートする必要があります。
R13: The format MUST support a password-based encryption (PBE) [PKCS5] scheme to ensure security of sensitive data elements. This is a widely used method for various provisioning scenarios.
R13：フォーマットは、感受性データ要素のセキュリティを確保するために、パスワードベースの暗号化（PBE）[PKCS5]スキームをサポートする必要があります。これは、さまざまなプロビジョニングシナリオに広く使用されている方法です。
R14: The format SHOULD support asymmetric encryption algorithms such as RSA to ensure end-to-end security of sensitive data elements. This is to support scenarios where a pre-set shared key encryption key is difficult to use.
R14：この形式は、RSAなどの非対称暗号化アルゴリズムをサポートして、機密データ要素のエンドツーエンドのセキュリティを確保する必要があります。これは、事前にセットの共有キー暗号化キーを使用するのが難しいシナリオをサポートするためです。
Authors' Addresses
著者のアドレス
Philip Hoyer ActivIdentity, Inc. 117 Waterloo Road London, SE1 8UL UK
Philip Hoyer ActiveIdentity、Inc。117 Waterloo Road London、SE1 8UL UK
Phone: +44 (0) 20 7960 0220
EMail: phoyer@actividentity.com
Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Mingliang Pei Verisign、Inc。487 E. Middlefield Road Mountain View、CA 94043 USA
Phone: +1 650 426 5173
EMail: mpei@verisign.com
Salah Machani Diversinet, Inc. 2225 Sheppard Avenue East Suite 1801 Toronto, Ontario M2J 5C2 Canada
Salah Machani Diversinet、Inc。2225 Sheppard Avenue East Suite 1801 Toronto、Ontario M2J 5C2カナダ
Phone: +1 416 756 2324 Ext. 321
EMail: smachani@diversinet.com