[要約] RFC 6030は、ワンタイムパスワード（OTP）トークンなどの「対称鍵」情報を、異なるメーカーのデバイスや管理サーバー間で安全に転送するためのXMLデータ形式「PSKC（Portable Symmetric Key Container）」を定義しています。暗号化された鍵データ、シリアル番号、および有効期限などの情報を構造化し、セキュリティトークンのプロビジョニングや鍵のインポート・エクスポートにおける相互運用性を保証します。
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
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.
この文書では、さまざまな種類の暗号モジュールに対称鍵を輸送およびプロビジョニングするための形式を規定します。例えば、ワンタイムパスワード（OTP）用の共有シークレットや、強固な認証デバイス用の対称暗号鍵を扱います。標準的な鍵輸送形式により、企業は複数のベンダーの最適なコンポーネントを組み合わせ、同じインフラストラクチャ上にソリューションを展開できます。
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.
この文書はInternet Engineering Task Force（IETF）の成果であり、IETFコミュニティの合意を示しています。公開レビューを経て、Internet Engineering Steering Group（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.
この文書の現在の状態、正誤表、およびフィードバックの送付方法については、http://www.rfc-editor.org/info/rfc6030 を参照してください。
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書には、発行日時点で有効なBCP 78およびIETF文書に関するIETF Trustの法的規定（http://trustee.ietf.org/license-info）が適用されます。これらの文書には、本書に関する権利と制限が記載されているため、注意深く確認してください。本書から抜粋したコードコンポーネントには、Trustの法的規定のセクション4.eに記載されたSimplified BSD Licenseの文面を含める必要があります。また、Simplified BSD Licenseに記載されているとおり、保証なしで提供されます。
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
1. Introduction ....................................................4
1. はじめに ........................................................4
1.1. Key Words ..................................................4
1.1. キーワード .................................................4
1.2. Version Support ............................................4
1.2. バージョンのサポート .......................................4
1.3. Namespace Identifiers ......................................5
1.3. 名前空間識別子 .............................................5
1.3.1. Defined Identifiers .................................5
1.3.1. 定義済み識別子 ......................................5
1.3.2. Referenced Identifiers ..............................5
1.3.2. 参照先の識別子 ......................................5
2. Terminology .....................................................6
2. 用語 ............................................................6
3. Portable Key Container Entities Overview and Relationships ......6
3. ポータブル鍵コンテナの構成要素と関係の概要 ......................6
4. <KeyContainer> Element: The Basics ..............................8
4. <KeyContainer>要素：基本構造 ....................................8
4.1. <Key>: Embedding Keying Material and Key-Related
Information ................................................8
4.1. <Key>要素：鍵素材と鍵関連情報の埋め込み ....................8
4.2. Key Value Encoding ........................................10
4.2. 鍵値のエンコーディング ....................................10
4.2.1. AES Key Value Encoding .............................11
4.2.1. AES鍵値のエンコーディング ..........................11
4.2.2. Triple-DES Key Value Encoding ......................11
4.2.2. Triple-DES鍵値のエンコーディング ...................11
4.3. Transmission of Supplementary Information .................12
4.3. 補足情報の伝送 ............................................12
4.3.1. <DeviceInfo> Element: Unique Device
Identification .....................................13
4.3.1. <DeviceInfo>要素：デバイスの一意な識別 .............13
4.3.2. <CryptoModuleInfo> Element: CryptoModule
Identification .....................................15
4.3.2. <CryptoModuleInfo>要素：暗号モジュールの識別 .......15
4.3.3. <UserId> Element: User Identification ..............15
4.3.3. <UserId>要素：ユーザーの識別 .......................15
4.3.4. <AlgorithmParameters> Element:
Supplementary Information for OTP and CR Algorithms 15
4.3.4. <AlgorithmParameters>要素：OTPおよびCRアルゴリズムの補足情報
4.4. Transmission of Key Derivation Values .....................17
4.4. 鍵導出値の伝送 ............................................17
5. Key Policy .....................................................19
5. 鍵ポリシー .....................................................19
5.1. PIN Algorithm Definition ..................................23
5.1. PINアルゴリズムの定義 .....................................23
6. Key Protection Methods .........................................23
6. 鍵の保護方式 ...................................................23
6.1. Encryption Based on Pre-Shared Keys .......................24
6.1. 事前共有鍵による暗号化 ....................................24
6.1.1. MAC Method .........................................26
6.1.1. MAC方式 ............................................26
6.2. Encryption Based on Passphrase-Based Keys .................27
6.2. パスフレーズベースの鍵による暗号化 ........................27
6.3. Encryption Based on Asymmetric Keys .......................29
6.3. 非対称鍵による暗号化 ......................................29
6.4. Padding of Encrypted Values for Non-Padded
Encryption Algorithms .....................................31
6.4. パディング機能を持たない暗号化アルゴリズムでの暗号化値のパディング ..31
7. Digital Signature ..............................................31
7. デジタル署名 ...................................................31
8. Bulk Provisioning ..............................................33
8. 一括プロビジョニング ...........................................33
9. Extensibility ..................................................35
9. 拡張性 .........................................................35
10. PSKC Algorithm Profile ........................................36
10. PSKCアルゴリズムプロファイル ..................................36
10.1. HOTP .....................................................36
10.1. HOTP .....................................................36
10.2. PIN ......................................................37
10.2. PIN ......................................................37
11. XML Schema ....................................................38
11. XMLスキーマ ...................................................38
12. IANA Considerations ...........................................44
12. IANAに関する考慮事項 ..........................................44
12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.1. application/pskc+xmlのContent-Type登録 ...................44
12.2. XML Schema Registration ..................................45
12.2. XMLスキーマの登録 ........................................45
12.3. URN Sub-Namespace Registration ...........................46
12.3. URNサブネームスペースの登録 ..............................46
12.4. PSKC Algorithm Profile Registry ..........................46
12.4. PSKCアルゴリズムプロファイルレジストリ ...................46
12.5. PSKC Version Registry ....................................47
12.5. PSKCバージョンレジストリ .................................47
12.6. Key Usage Registry .......................................47
12.6. 鍵用途レジストリ .........................................47
13. Security Considerations .......................................48
13. セキュリティに関する考慮事項 ..................................48
13.1. PSKC Confidentiality .....................................49
13.1. PSKCの機密性 .............................................49
13.2. PSKC Integrity ...........................................50
13.2. PSKCの完全性 .............................................50
13.3. PSKC Authenticity ........................................50
13.3. PSKCの真正性 .............................................50
14. Contributors ..................................................50
14. 貢献者 ........................................................50
15. Acknowledgements ..............................................50
15. 謝辞 ..........................................................50
16. References ....................................................51
16. 参考文献 ......................................................51
16.1. Normative References .....................................51
16.1. 規範的参考文献 ...........................................51
16.2. Informative References ...................................52
16.2. 参考情報文献 .............................................52
Appendix A. Use Cases ............................................54
Appendix A. 使用例 ...............................................54
A.1. Online Use Cases ..........................................54
A.1. オンラインでの使用例 ......................................54
A.1.1. Transport of Keys from Server to Cryptographic
Module ................................................54
A.1.1. サーバーから暗号モジュールへの鍵の転送 ................54
A.1.2. Transport of Keys from Cryptographic Module to
Cryptographic Module ..................................54
A.1.2. 暗号モジュールから別の暗号モジュールへの鍵の転送 ......54
A.1.3. Transport of Keys from Cryptographic Module to
Server ................................................55
A.1.3. 暗号モジュールからサーバーへの鍵の転送 ................55
A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.1.4. サーバー間での鍵の一括インポート／エクスポート ........55
A.2. Offline Use Cases .........................................55
A.2. オフラインでの使用例 ......................................55
A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
A.2.1. サーバー間での鍵の一括インポート／エクスポート ........55
Appendix B. Requirements .........................................56
Appendix B. 要件 .................................................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.
保存データの暗号化や、ワンタイムパスワード（OTP）およびチャレンジ／レスポンス（CR）方式を用いる強固な認証など、対称鍵を用いるシステムが普及するにつれて、ベンダー間の相互運用性と、対称鍵をインポートおよびエクスポート（プロビジョニング）するための標準形式が必要になっています。例えば、従来、認証サーバーやサービスプロバイダーのベンダーは、鍵をシステムに取り込んだり書き出したりするために独自形式を使用しており、そのため異なるベンダーのトークンを併用しにくくなっていました。
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].
この文書で使う「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、[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>」の形式です。major番号とminor番号は別々の整数として扱わなければなりません (MUST)。それぞれの番号は、1桁を超える値まで増分してもかまいません (MAY)。したがって、「PSKC 2.4」は「PSKC 2.13」より古いバージョンであり、「PSKC 2.13」は「PSKC 12.3」より古いバージョンです。先行ゼロ（例えば「PSKC 6.01」）は受信側で無視しなければならず (MUST)、送信してはなりません (MUST NOT)。
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.
メジャーバージョン番号は、メッセージ形式（例えば要素構造）が大幅に変更され、旧バージョンの実装が新バージョンと相互運用できなくなる場合にのみ増分すべきです。マイナーバージョン番号は新機能を示します。マイナーバージョン番号が小さいエンティティはこれを無視しなければなりません (MUST) が、番号が大きいエンティティは情報提供の目的で使用します。
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to identify resources, algorithms, and semantics.
この文書では、リソース、アルゴリズム、および意味を識別するためにUniform Resource Identifier（URI）[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" と定義）。実装ではこの名前空間を使用することを推奨します (SHOULD)。
The PSKC syntax presented in this document relies on algorithm identifiers and elements defined in the XML Signature [XMLDSIG] namespace:
この文書に示すPSKC構文は、XML Signature [XMLDSIG]名前空間で定義されたアルゴリズム識別子と要素を使用します。
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to the XML Signature namespace are represented by the prefix "ds".
XML Signature名前空間の参照には、接頭辞「ds」を使用します。
PSKC also relies on algorithm identifiers and elements defined in the XML Encryption [XMLENC] namespace:
PSKCでは、XML Encryption [XMLENC]名前空間で定義されたアルゴリズム識別子と要素も使用します。
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the prefix "xenc".
XML Encryption名前空間の参照には、接頭辞「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:
パスフレーズベースの鍵を使って転送中の鍵を保護する場合、PSKCではXML Encryption Version 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 Encryption Version 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エンティティ：複数のKeyPackageエンティティを格納するコンテナを表します。有効なコンテナには、少なくとも1つのKeyPackageエンティティを含めなければなりません (MUST)。
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. KeyPackageエンティティ：最大1つの鍵と、その鍵に関連するプロビジョニング先または現在の使用先（物理デバイス、仮想デバイス、特定のCryptoModuleなど）をまとめたパッケージを表します。
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、または鍵のプロビジョニング先となるCryptoModuleに関する情報を表します。
5. Key entity - representing the key transported or provisioned.
5. Keyエンティティ：転送またはプロビジョニングされる鍵を表します。
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エンティティ：鍵に関連するメタデータの一覧を表します。要素名がメタデータの名前で、その値は暗号化された形式（例えば、<Data>要素内の<Secret>）または平文形式（例えば、<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>要素と1つの<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.
Version：この属性はPSKCスキーマのバージョンを識別します。この仕様では、PSKCスキーマの初期バージョン「1.0」を定義します。この属性は必ず含めなければなりません (MUST)。
'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：この属性には、コンテナを一意に識別する値を格納します。そのため、大きなXML文書に複数のコンテナが含まれる場合に、特定の鍵コンテナを識別できます。
The following attributes of the <Key> element MUST be included at a minimum:
<Key>要素には、少なくとも次の属性を含めなければなりません (MUST)。
'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属性には毎回同じ値を設定しなければなりません (MUST)。例えば、初回のプロビジョニング後に一方のシステムで鍵メタデータを更新する場合、更新対象のメタデータを含む<Key>のId属性には、プロビジョニング時のId属性と同じ値を設定しなければなりません (MUST)。識別子は英数字からなる文字列です。
'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].
Algorithm：この属性には、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.'.
<Issuer>：この要素は、鍵を発行した当事者の名前を表します。例えば、小売銀行の利用者にハードウェアトークンを発行する銀行「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>：秘密鍵を参照しやすくするための、人が読める名前です。この要素は情報提供だけを目的とします。この要素の文字列は言語に依存するため、[RFC5646]で規定される言語識別子を値とするxml:lang="xx"属性を付けるべきです (SHOULD)。xml:lang属性がない場合、実装は属性値を「en」としたときに指定される英語を言語と見なさなければなりません (MUST)（例えば、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として記録すべきです (SHOULD)。
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:
上記のすべての要素と今後定義される要素は、データ値を平文または暗号化形式で伝える子要素をサポートしなければなりません (MUST)。
Plaintext: The <PlainValue> element carries a plaintext value that is typed, for example, to xs:integer.
平文：<PlainValue>要素には、例えばxs:integer型の平文値を格納します。
Encrypted: The <EncryptedValue> element carries an encrypted value.
暗号文：<EncryptedValue>要素には、暗号化された値を格納します。
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の例では、<Secret>と<Counter>の2つの子要素を持つ<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.
<PlainValue>要素または<EncryptedValue>要素内のxs:base64Binaryをデコードした結果、同じ鍵値のOCTET STRINGを受け取る2者は、相互運用のためにその鍵をまったく同じ方法で使用する必要があります。そのためには、OCTET STRINGと、鍵の使用方法を定める標準アルゴリズムの記述における表記との対応関係を定義する必要があります。次のセクションでは、AESアルゴリズム[FIPS197]とTriple Data Encryption Algorithm（TDEAまたはTriple DES）[SP800-67]について、その対応関係を定めます。特定のアルゴリズムについて別途指定がない限り、OCTET STRINGのエンコーディングはAES鍵値エンコーディングに従わなければなりません (MUST)。
[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]の「Key Expansion」と題されたセクション5.2では、入力鍵を0から始まるインデックスを持つバイト配列として扱います。OCTET STRINGの最初のオクテットは、[FIPS197]でインデックス0とされるAES鍵バイトになります (MUST)。後続のオクテットは、インデックスの昇順でAES鍵バイトになります (MUST)。
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用のOCTET STRINGの内容を適切に解析して鍵として読み込めたかどうかは、次のbinaryBase64エンコード値を<PlainValue>要素に設定し、AESについて[FIPS197]の付録Aにある鍵拡張テストベクトルを生成して照合することで確認します (MUST)。
Cipher Key: 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鍵は、暗号エンジン用の3つの鍵（Key1、Key2、Key3）からなり、それぞれ64ビット（鍵ビット56個とパリティビット8個）です。この3つの鍵をまとめて鍵束と呼びます [SP800-67]。鍵束には、2個または3個の独立した鍵を使用できます。独立した鍵を2個だけ使う方式（2-key Triple DES）では、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まで番号付けし、最左端のビット、すなわち最上位ビット（MSB）を1とします。OCTET STRINGの最初のオクテットはKey1のビット1～8であり、ビット1がMSBです (MUST)。2番目のオクテットはKey1のビット9～16であり、以降も同様に続きます (MUST)。したがって、OCTET STRINGの最後のオクテットはKey3のビット57～64（2-key Triple DESの場合はKey2のビット57～64）です (MUST)。
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:
Triple DES用OCTET STRINGの内容を適切に解析して鍵として読み込めたかどうかは、次のbinaryBase64エンコード値を<PlainValue>要素に設定し、鍵束について[SP800-67]の付録Bにある鍵拡張テストベクトルを生成して照合することで確認します (MUST)。
Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123
... <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など、さまざまな形態があります。この要素では、複数の子要素をさまざまに組み合わせて使用できます。子要素の値を組み合わせたとき、デバイスを一意に識別しなければなりません (MUST)。例えば、ハードウェアトークンでは<SerialNo>と<Manufacturer>の組み合わせでデバイスを一意に識別できますが、異なるトークンメーカーが同じシリアル番号のデバイスを発行する可能性があるため、<SerialNo>だけでは不十分です（証明書におけるIssuer Distinguished Nameとシリアル番号の場合と同様です）。
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]>").
<Manufacturer>：この要素はデバイスのメーカーを示します。<Manufacturer>の値には、[OATHMAN]のprefix（左列）またはIANA Private Enterprise Number Registry [IANAPENREG]のOrganization値を使用しなければなりません (MUST)。[OATHMAN]の値を使う場合は、値の前に「oath.」を付けなければなりません (MUST)（例えば「oath.<prefix value from [OATHMAN]>」）。[IANAPENREG]の値を使う場合は、値の前に「iana.」を付けなければなりません (MUST)（例えば「iana.<Organization value 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>：この要素はデバイスのモデルを示します（例えば、one-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>：この要素を使うと、プロビジョニングサーバーは、鍵プロビジョニング要求が承認されたデバイスに鍵が読み込まれることを保証できます。デバイスはデバイス識別子を使って要求にひも付けます。例えば、電話のInternational Mobile Equipment Identity（IMEI）や、識別子のクラスを表す識別子（例えば、鍵がTrusted Platform Module（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-2-20041028]のdateTime値で表さなければなりません (MUST)。実装はミリ秒より細かい時間分解能に依存すべきではなく (SHOULD NOT)、うるう秒を指定する時刻を生成してはなりません (MUST NOT)。デバイスに格納された鍵は、現在の日付が<StartDate>より後で、<ExpiryDate>より前の場合にのみ使用すべきです (SHOULD)。スマートカードなど内部時計を持たないデバイスもあるため、日付に関する鍵の使用制限は検証サーバーだけで実施してもかまわない場合があります (MAY)。したがって、システムは鍵の使用日制限をデバイスが実施することに依存すべきではありません (SHOULD NOT)。
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>の特定の子要素を含めなければなりません (MUST)。この文書ではデバイスの種類を列挙していないため、種類ごとの必須要素も列挙しません。
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と接続されたトークン）を個別に識別できます (MAY)。
The <CryptoModuleInfo> element has a single child element that MUST be included:
<CryptoModuleInfo>要素には、必ず含める子要素が1つあります (MUST)。
<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>：この要素にはCryptoModuleを一意に識別する値を格納します。値の形式は実装に依存します。この要素により、鍵のプロビジョニング先またはプロビジョニング済みの特定のCryptoModuleを識別できます。
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>、<ChallengeFormat>、<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:
Encoding：この属性は必ず含めなければならず (MUST)、デバイスが受け入れるチャレンジのエンコーディングを定義します。また、値は次のいずれかでなければなりません (MUST)。
DECIMAL: Only numerical digits
DECIMAL：数字のみ
HEXADECIMAL: Hexadecimal response
HEXADECIMAL：16進数表記
ALPHANUMERIC: All letters and numbers (case sensitive)
ALPHANUMERIC：英字と数字（大文字と小文字を区別）
BASE64: Base-64 encoded, as defined in Section 4 of [RFC4648]
BASE64：[RFC4648]のセクション4で定義されるBase64エンコーディング
BINARY: Binary data
BINARY：バイナリデータ
'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]で定義されたLuhnチェックディジットをデバイスが検査するかどうかを示します。この属性が有効なのは、Encoding属性がDECIMALに設定されている場合だけです。値がTRUEなら、デバイスは受け取ったチャレンジに付加されたLuhnチェックディジットを検査します。値がFALSEなら検査しません。
'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モードでデバイスが受け入れるチャレンジの最小サイズを定義し、必ず含めなければなりません (MUST)。Encoding属性がDECIMAL、HEXADECIMAL、またはALPHANUMERICの場合、この値は最小の桁数または文字数を示します。Encoding属性がBASE64またはBINARYの場合、この値はエンコード前の値の最小バイト数を示します。
'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モードでデバイスが受け入れるチャレンジの最大サイズを定義し、必ず含めなければなりません (MUST)。Encoding属性がDECIMAL、HEXADECIMAL、またはALPHANUMERICの場合、この値は最大の桁数または文字数を示します。Encoding属性がBASE64またはBINARYの場合、この値はエンコード前の値の最大バイト数を示します。
<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:
<ResponseFormat>要素は、計算結果の特性と、OTPまたはチャレンジへの応答の形式を定義します。鍵がPIN値の場合、この要素にはPIN自体の形式を指定します（例えば、4桁のPINならDECIMAL、長さ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.
Encoding：この属性はデバイスが生成する応答のエンコーディングを定義します。必ず含めなければならず (MUST)、値はDECIMAL、HEXADECIMAL、ALPHANUMERIC、BASE64、BINARYのいずれかでなければなりません (MUST)。
'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チェックディジットをデバイスが付加するかどうかを示します。この属性が有効なのはEncoding属性がDECIMALに設定されている場合だけです。値がTRUEならデバイスは応答にLuhnチェックディジットを付加し、FALSEなら付加しません。
'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.
Length：この属性はデバイスが生成する応答の長さを定義し、必ず含めなければなりません (MUST)。Encoding属性がDECIMAL、HEXADECIMAL、またはALPHANUMERICの場合、この値は桁数または文字数を示します。Encoding属性がBASE64またはBINARYの場合、この値はエンコード前の値のバイト数を示します。
<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).
<Key>要素の子要素である<KeyProfileId>要素は、コンテナ内では伝送されず、両者間で帯域外に合意された鍵属性値の集合を確立するために、送信側と受信側の間で使用する一意の識別子を格納します。この要素は、その鍵属性値の集合を一意に参照します（例えば、応答計算に影響するスマートカードアプリケーション上の特定の属性値に関連付けられた、スマートカードアプリケーション個別化プロファイル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>要素には、鍵値（シークレット）を伝送するための<Data>の子要素<Secret>は含まれず、外部マスター鍵への参照だけを伝送します（例えば、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の<Policy>要素の機能を説明します。この要素を使うと、鍵の使用ポリシーとPIN保護ポリシーを特定の鍵および関連メタデータに関連付けられます。この要素は<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.
<Policy>要素に、PSKC文書の受信側が理解できない子要素や要素／属性値が含まれる場合、受信側はその鍵の使用を許可されていないものとして扱わなければなりません (MUST)。これにより、特定の拡張を理解できないことが、意図しない鍵の使用につながるのを防ぎます。
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：PINで保護された、暗号化されていないHOTPシークレット鍵
This document defines the following <Policy> child elements:
この文書では、<Policy>の子要素として次の要素を定義します。
<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つの要素は鍵の有効期間を示します。鍵が開始日から終了日まで（両端を含む）に限って使用されることを保証しなければなりません (MUST)。日付は「標準表現」[W3C.REC-xmlschema-2-20041028]のdateTime値で表さなければなりません (MUST)。実装はミリ秒より細かい時間分解能に依存すべきではなく (SHOULD NOT)、うるう秒を指定する時刻を生成してはなりません (MUST NOT)。この要素がない場合、現在時刻を開始時刻と見なします。
<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文書の受信側は、鍵の用途を強制しなければなりません (MUST)。現時点で、この文書では次のトークンを登録しています。
OTP: The key MUST only be used for OTP generation.
OTP：鍵はOTPの生成にのみ使用しなければなりません (MUST)。
CR: The key MUST only be used for Challenge/Response purposes.
CR：鍵はチャレンジ／レスポンスの目的にのみ使用しなければなりません (MUST)。
Encrypt: The key MUST only be used for data encryption purposes.
Encrypt：鍵はデータの暗号化にのみ使用しなければなりません (MUST)。
Integrity: The key MUST only be used to generate a keyed message digest for data integrity or authentication purposes.
Integrity：鍵はデータの完全性確認または認証のための鍵付きメッセージダイジェストの生成にのみ使用しなければなりません (MUST)。
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').
Verify：鍵はデータの完全性確認または認証のための鍵付きメッセージダイジェストの検証にのみ使用しなければなりません (MUST)（これは「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).
Unlock：利用者が誤ったPINを何度も入力してデバイスをロックした場合に、逆方向のチャレンジ／レスポンスにのみ使用しなければなりません (MUST)（PIN入力機能を持つデバイスの場合）。
Decrypt: The key MUST only be used for data decryption purposes.
Decrypt：鍵はデータの復号にのみ使用しなければなりません (MUST)。
KeyWrap: The key MUST only be used for key wrap purposes.
KeyWrap：鍵は鍵ラップにのみ使用しなければなりません (MUST)。
Unwrap: The key MUST only be used for key unwrap purposes.
Unwrap：鍵は鍵のアンラップにのみ使用しなければなりません (MUST)。
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]).
Derive：鍵は鍵導出関数を使って新しい鍵を導出する目的にのみ使用しなければなりません (MUST)（[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]).
Generate：鍵は乱数と鍵の以前の値に基づいて新しい鍵を生成する目的にのみ使用しなければなりません (MUST)（[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.
複数の鍵用途を表すため、この要素を繰り返してもかまいません (MAY)。この要素がない場合、鍵の用途に制約はないものと見なします。つまり、鍵をあらゆる用途に使ってもかまいません (MAY)。
<PINPolicy>: The <PINPolicy> element allows policy about the PIN usage to be associated with the key. The following attributes are specified:
<PINPolicy>：<PINPolicy>要素を使うと、PINの使用に関するポリシーを鍵に関連付けられます。次の属性を規定します。
'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：この属性には、PIN値を含み、そのPINで鍵を保護する<Key>要素のId属性値を指定します。その<Key>要素は、この<KeyContainer>内にあります。
'PINUsageMode': This mandatory attribute indicates the way the PIN is used during the usage of the key. The following values are defined:
PINUsageMode：この必須属性は、鍵の使用時にPINをどのように使うかを示します。次の値を定義します。
Local: This value indicates that the PIN is checked locally on the device before allowing the key to be used in executing the algorithm.
Local：この値は、鍵をアルゴリズムの実行に使用する前に、デバイス内でPINを検査することを示します。
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：この値は、PINをアルゴリズムの応答の先頭に付加することを示します。そのため、応答を検証する側がPINを検査しなければなりません (MUST)。
Append: This value indicates that the PIN is appended to the algorithm response; hence, it MUST be checked by the party validating the response.
Append：この値は、PINをアルゴリズムの応答の末尾に付加することを示します。そのため、応答を検証する側がPINを検査しなければなりません (MUST)。
Algorithmic: This value indicates that the PIN is used as part of the algorithm computation.
Algorithmic：この値は、PINをアルゴリズム計算の一部として使用することを示します。
'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：この属性は、鍵を使用できなくなるまでにPINの誤入力が許される最大回数を示します。この回数を超えると、その鍵は使用できてはなりません (MUST NOT)。通常、妥当な値は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：この属性は、関連する鍵を保護するPINに設定できる最小長を示します。この値より短いPINを設定できてはなりません (MUST NOT)。PINFormat属性がDECIMAL、HEXADECIMAL、またはALPHANUMERICの場合、この値は桁数または文字数を示します。PINFormat属性がBASE64またはBINARYの場合、この値はエンコード前の値のバイト数を示します。
'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：この属性は、この鍵を保護するPINに設定できる最大長を示します。この値より長いPINを設定できてはなりません (MUST NOT)。PINFormat属性がDECIMAL、HEXADECIMAL、またはALPHANUMERICの場合、この値は桁数または文字数を示します。PINFormat属性がBASE64またはBINARYの場合、この値はエンコード前の値のバイト数を示します。
'PINEncoding': This attribute indicates the encoding of the PIN and MUST be one of the values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
PINEncoding：この属性はPINのエンコーディングを示し、値はDECIMAL、HEXADECIMAL、ALPHANUMERIC、BASE64、BINARYのいずれかでなければなりません (MUST)。
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属性がLocalの場合、デバイスはMaxFailedAttempts、MinLength、MaxLength、PINEncodingの各属性が示す制限を実施しなければなりません (MUST)。それ以外の場合は、サーバー側でこれらの制限を実施しなければなりません (MUST)。
The PIN algorithm is defined as:
PINアルゴリズムを次のように定義します。
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は、比較対象となるPINをバイナリ形式で表したものです。
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.
comparePIN関数は、KとPをオクテット単位で直接比較します。KとPのオクテット長が同じで、Kを構成するすべてのオクテットがPの対応するオクテットと同じ場合、この比較はTRUE（資格情報が一致）を返さなければなりません (MUST)。
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].
前のセクションで説明した機能では、鍵に関連する情報を平文で伝送していました。<KeyContainer>の子要素である<EncryptionKey>を使うと、鍵と関連情報を暗号化できます。暗号化は各要素の値に適用し、暗号化に使用するアルゴリズムは、暗号化するすべての要素で同じでなければなりません (MUST)。鍵は、事前共有鍵、パスフレーズベースの鍵、または非対称鍵を使って保護します。AES-128-CBCなど、初期化ベクトル（IV）を使用する暗号化アルゴリズムでは、暗号化する値ごとにランダムなIVを生成しなければなりません (MUST)。また、[XMLENC]の規定に従い、そのIVを暗号化後の値の先頭に付加しなければなりません (MUST)。
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など完全性検査を備えないアルゴリズムを使用する場合、鍵付きMAC値を<Data>要素の<ValueMAC>要素に格納しなければなりません (MUST)。この場合、MACアルゴリズムの種類を<KeyContainer>要素の<MACMethod>要素に設定しなければなりません (MUST)。MAC鍵は、送信側がランダムに生成した鍵、送信側と受信側が事前に合意した鍵、またはPSKC文書を運ぶアプリケーションプロトコルで設定した鍵でなければなりません (MUST)。送信側がランダムなMAC鍵を生成することを推奨します (SHOULD)。送信側がランダムなMAC鍵を生成する場合、その鍵素材を<KeyContainer>の<EncryptionKey>要素で指定したものと同じ暗号鍵で暗号化しなければなりません (MUST)。<MACMethod>要素内の<MACKey>要素には、暗号化方式と暗号化値をそれぞれ<EncryptionMethod>要素と<CipherData>要素に設定しなければなりません (MUST)。<MACMethod>の<MACKeyReference>要素を使って、事前共有MAC鍵またはプロビジョニングプロトコルから導出したMAC鍵を示してもかまいません (MAY)。PSKCを実装するシステムには、HMAC-SHA1（URI：http://www.w3.org/2000/09/xmldsig#hmac-sha1）の実装を推奨します (SHOULD)。任意で実装できる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]で定義されたパスフレーズベースの鍵導出（PBKDF2）を使って暗号鍵を導出し、<Secret>要素の内容を暗号化する例を示します。パスフレーズベースの鍵導出を使う場合、パスフレーズベースの鍵を指定するため、XML Encryption Version 1.1 [XMLENC11]で定義された<DerivedKey>要素を使用しなければなりません (MUST)。<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>要素は、鍵導出関数と関連パラメーターを指定するために使用します。この例では、暗号化データ要素内で使用する<EncryptionMethod>要素のAlgorithm属性に、暗号化アルゴリズムAES-128-CBC（URI：http://www.w3.org/2001/04/xmlenc#aes128-cbc）を設定しなければなりません (MUST)。
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>要素のAlgorithm属性をURI「http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2」に設定しなければなりません (MUST)。また、PBKDF2のsaltや反復回数などのパラメーターを示すため、<xenc11:KeyDerivationMethod>要素に子要素<PBKDF2-params>を含めなければなりません (MUST)。
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を付加して渡さなければなりません (MUST)。
In the example below, the following data is used.
以下の例では、次のデータを使用します。
Password: qwerty
Salt: 0x123eff3c4a72129c
Iteration Count: 1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
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鍵の暗号化にも使用します。この例では、別のIV「0xd864d39cbc0cdc8e1ee483b9164b9fa0」も使用できます。「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>要素の子要素を暗号化する場合、使用する証明書の情報を、<EncryptionKey>の子要素である<X509Data>要素に記載しなければなりません (MUST)。暗号化アルゴリズムを<EncryptionMethod>要素のAlgorithm属性に指定しなければなりません (MUST)。図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アルゴリズムを実装することを推奨します (SHOULD)。
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パディングを値に適用することを推奨します (SHOULD)。
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文書にデジタル署名を追加できます。次の例では<KeyContainer>の署名にXML Signatureを使用しています。署名要素には、署名対象となるすべての子要素を含めます。
<?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).
<KeyContainer>要素内で<KeyPackage>要素を複数回繰り返すと、異なるデバイスまたは暗号モジュールに複数の鍵を提供する一括プロビジョニングを実現できます。<EncryptionKey>要素は、すべての<KeyPackage>要素に適用されます。同じデバイスに複数の鍵をプロビジョニングする場合も<KeyPackage>要素を繰り返しますが、その中の<DeviceInfo>要素には、そのデバイスを一意に識別する同じ子要素を含めます（例えば、以下の例で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で説明するVersion属性に格納します。番号付け方式はセクション1.2に従わなければなりません (MUST)。拡張に関する規則はセクション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要素を追加できます。要素の種類に応じて、異なる拡張方法を用意しています。一部では<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属性：セクション11の「<xs:anyAttribute namespace="##other"/>」を参照してください。XMLスキーマでは、XML拡張ポイントが定義された箇所に新しいXML属性を追加できます。
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-ALGORITHM-PROFILES]。セクション12.4で説明する方法に従って、PSKCアルゴリズムプロファイルをさらに登録できます。
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.
アルゴリズムURI：セクション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の用途に限る」など、実装者が鍵の用途を制限できます。セクション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:
廃止：FALSE プロファイル：
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>要素を含めなければなりません (MUST)。また、<AlgorithmParameters>要素の子要素である<ResponseFormat>要素を使って、OTPの長さと値の形式を示さなければなりません (MUST)。
The <Counter> element (see Section 4.1) MUST be provided as metadata for the key.
<Counter>要素（セクション4.1を参照）を鍵のメタデータとして指定しなければなりません (MUST)。
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ビット）の鍵素材を含めなければなりません (MUST)。
+ 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).
+ <ResponseFormat>要素のFormat属性を「DECIMAL」に設定しなければなりません (MUST)。Length属性には6～9（両端を含む）の値を指定しなければなりません (MUST)。
+ The <PINPolicy> element MAY be present, but the 'PINUsageMode' attribute cannot be set to "Algorithmic".
+ <PINPolicy>要素を含めてもかまいません (MAY)。ただし、PINUsageMode属性を「Algorithmic」に設定することはできません。
An example can be found in Figure 3.
例を図3に示します。
Common Name: PIN
一般名：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
廃止：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.
<Usage>要素を含めてもかまいません (MAY)。ただし、<Usage>要素の属性はいずれも必須ではありません。<ResponseFormat>要素を使ってPIN値の形式を示してもかまいません (MAY)。
The <Secret> element (see Section 4.1) MUST be provided.
<Secret>要素（セクション4.1を参照）を指定しなければなりません (MUST)。
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>
MIME media type name: application
MIMEメディアタイプ名：application
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.
charsetは、含まれるXMLの文字エンコーディングを示します。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2.
エンコーディングに関する考慮事項：XMLを使用します。使用する文字エンコーディングによっては、8ビット文字を使用できます。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.
このメディアタイプを使用するアプリケーション：このメディアタイプは、さまざまな種類の強固な認証デバイスに対称鍵（ワンタイムパスワード（OTP）用の共有シークレットや対称暗号鍵）を輸送およびプロビジョニングするための、対称鍵コンテナ形式として使用します。そのため、鍵プロビジョニングシステムで使用します。
Additional information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .pskcxml
ファイル拡張子：.pskcxml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード：'TEXT'
Personal and email address to contact for further information: Philip Hoyer, Philip.Hoyer@actividentity.com
Personal and email address to contact for further information: Philip Hoyer, Philip.Hoyer@actividentity.com
Intended usage: LIMITED USE
意図された使用法：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).
Registrant Contact: IETF KEYPROV Working Group, 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:params:xml:ns:keyprov:pskc」を登録します。
URI: urn:ietf:params:xml:ns:keyprov:pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com).
Registrant Contact: IETF KEYPROV Working Group, 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.
廃止：専門家の承認に基づいてこの項目が廃止され、新しい実装では使用すべきではない場合 (SHOULD NOT) はTRUEです。それ以外はFALSEです。
PSKC Profiling: Information about PSKC XML elements and attributes being used (or not) with this specific profile of 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]に従いSpecification Requiredポリシーを適用します。更新は専門家の承認に基づく場合に限り行えます。専門家の承認に基づいて、項目を「deprecated」と指定できます。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.
Key Usage：鍵用途の識別子。
Specification: IANA will add a pointer to the specification containing information about the semantics of a new Key Usage registration.
仕様：IANAは、新しいKey Usageの登録について意味を説明する仕様への参照を追加します。
Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE.
廃止：専門家の承認に基づいてこの項目が廃止され、新しい実装では使用すべきではない場合 (SHOULD NOT) はTRUEです。それ以外は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.
Key Usageレジストリへの登録には、RFC 5226 [RFC5226]に従いSpecification Requiredポリシーを適用します。新しいKey Usage値を定義するにはExpert Reviewが必要です。更新は専門家の承認に基づく場合に限り行えます。専門家の承認に基づいて、項目を「deprecated」と指定できます。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）には、暗号鍵などの機密情報が含まれ、あるセキュリティ境界から別の境界へ移動することがあります。例えば、安全な部屋に置かれたバックエンドプロビジョニングサーバーのセキュリティ境界内にあるコンテナを、インターネット経由でパーソナルコンピューターに接続されたエンドユーザーデバイスへ送る場合があります。そのため、コンテナ内の情報の機密性、完全性、および真正性を確保するため、特別な注意を払わなければなりません (MUST)。
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.
1つ目は、コンテナ内の鍵データペイロードを暗号化する方法です。
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.
この場合、トランスポート層セキュリティは必要ありません。ただし、鍵データペイロードの暗号化に使う暗号アルゴリズムの強度を選択する際は、標準的なセキュリティのベストプラクティスに従います。対称鍵暗号を使用すべきです (SHOULD)。鍵が長いほど保護は強固になります。対称鍵暗号による鍵データペイロードの保護については、セクション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を使用することを強く推奨します (SHOULD)。最も強く保護するには、PSKCごとに異なるPBESaltを使用すべきです (SHOULD)。
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.
平文のPSKCはトランスポート層セキュリティだけで保護されるため、実用的な実装では中間者攻撃から確実に保護しなければなりません (MUST)。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全体を対象とすることを推奨します (SHOULD)。これにより、すべての属性の完全性を保証できます。また、コンテナを通信路経由で宛先側のセキュリティ境界に届けた後、通信路でメッセージの完全性を検査できなくなっても、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の真正性を示す主な手段はデジタル署名です。コンテナの受信者は、署名に関連付けられた公開鍵を使い、その鍵を事前に読み込まれた公開鍵または証明書までたどって、送信者の真正性を確認すべきです (SHOULD)。コンテナを安全な通信路で届けた後でも、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.
著者らは、次の方々から寄せられたフィードバックに感謝します：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、特に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.
この作業は、技術コミュニティに自由に配布できる形式を規定するため、OATH（Initiative for Open AuTHentication）のメンバーが先に行った作業に基づいています。[OATH]を参照してください。
[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced Encryption Standard (AES)", November 2001.
[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced Encryption Standard (AES)", November 2001.
[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., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[IANAPENREG] IANA, "Private Enterprise Numbers", <http://www.iana.org>.
[IANAPENREG] IANA, "Private Enterprise Numbers", <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 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>.
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April 2009, <http://www.openauthentication.org/oath-id/prefixes/>.
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April 2009, <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: Password-Based Cryptography Standard", Version 2.0, March 1999, <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., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[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): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[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] 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.
[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. 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>.
[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., 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>.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", W3C Recommendation, December 2002, <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 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>.
[CAP] MasterCard International, "Chip Authentication Program Functional Architecture", September 2004.
[CAP] MasterCard International, "Chip Authentication Program Functional Architecture", September 2004.
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[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., and M. Smid, "NIST Special Publication 800-57, Recommendation for Key Management Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[OATH] "Initiative for Open AuTHentication", <http://www.openauthentication.org>.
[OATH] "Initiative for Open AuTHentication", <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., and A. Doherty, "Additional Portable Symmetric Key Container (PSKC) Algorithm Profiles", Work in Progress, May 2010.
[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., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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., 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>.
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上のソフトトークンアプリケーションに鍵をプロビジョニングします。前述と同様に、プロビジョニングシステムは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.
例えば、利用者が鍵をある暗号モジュールから別の暗号モジュールへ移したい場合があります。一方がコンピューター、もう一方が携帯電話にある場合、利用者はコンピューターから携帯電話へ鍵を移します。利用者は、もう一方の暗号モジュールに取り込める標準形式で、鍵と関連データをエクスポートできます。
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.
例えば、利用者が、ある鍵を認識していない検証システムで新しい鍵と関連データを有効にし、使用したい場合があります。その鍵は、利用者が近所の電器店で購入した暗号モジュール（例えばSecure Digital（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.
例えば、前述の変形例として、携帯電話に鍵をプロビジョニングするOver-The-Air（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）で鍵と関連データを提供します。トークンメーカーと検証システムのベンダーは、同一の場合も異なる場合もあります。一部の暗号モジュールではデバイス上のPINパッドを使ったPIN管理が可能です。その場合、製造時に設定するランダムな初期PINは、それぞれが保護する鍵とともに送信することが望まれます。
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、チャレンジ／レスポンスなどのアルゴリズムで使用する複数種類の対称鍵と関連属性の転送に対応しなければなりません (MUST)。
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：この形式は、対称鍵そのものに加え、対称鍵に通常関連付けられる属性も扱わなければなりません (MUST)。これらの属性には、例えば次のものがあります。
* 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：この形式はオフラインとオンラインの両方のシナリオに対応すべきです (SHOULD)。つまり、ファイルにシリアライズでき、オンラインプロビジョニングプロトコルでも利用できる形式です。
R4: The format SHOULD allow bulk representation of symmetric keys.
R4：この形式は、対称鍵を一括して表現できるようにすべきです (SHOULD)。
R5: The format SHOULD allow bulk representation of PINs related to specific keys.
R5：この形式は、特定の鍵に関連付けられたPINを一括して表現できるようにすべきです (SHOULD)。
R6: The format SHOULD be portable to various platforms. Furthermore, it SHOULD be computationally efficient to process.
R6：この形式はさまざまなプラットフォームに移植可能であるべきです (SHOULD)。さらに、処理の計算効率も高くすべきです (SHOULD)。
R7: The format MUST provide an appropriate level of security in terms of data encryption and data integrity.
R7：この形式は、データ暗号化とデータ完全性について適切な水準のセキュリティを提供しなければなりません (MUST)。
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：オンラインシナリオでは、この形式は中核的なセキュリティ要件を満たすためにトランスポート層セキュリティ（例えばSecure Socket Layer／Transport Layer Security（SSL/TLS））に依存すべきではありません (SHOULD NOT)。
R9: The format SHOULD be extensible. It SHOULD enable extension points allowing vendors to specify additional attributes in the future.
R9：この形式は拡張可能であるべきです (SHOULD)。また、ベンダーが将来追加属性を指定できるように拡張ポイントを設けるべきです (SHOULD)。
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：この形式は、対称鍵自体を含めずに鍵導出データを配布できるようにすべきです (SHOULD)。これは、事前に配置したマスター鍵に基づく鍵導出アルゴリズムを使用する対称鍵管理方式に対応するためです。鍵導出データは通常、鍵値自体ではなく、鍵への参照で構成されます。
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：この形式は、カウンターの再同期など、追加のライフサイクル管理操作に対応すべきです (SHOULD)。このような処理にはクライアントとサーバー間の機密性が必要です。そのため、鍵素材を転送せずに共通のセキュアコンテナ形式を使用できます。
R12: The format MUST support the use of pre-shared symmetric keys to ensure confidentiality of sensitive data elements.
R12：この形式は、機密データ要素の機密性を確保するため、事前共有対称鍵の使用に対応しなければなりません (MUST)。
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]方式に対応しなければなりません (MUST)。これは、さまざまなプロビジョニングシナリオで広く使われている方式です。
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などの非対称暗号化アルゴリズムに対応すべきです (SHOULD)。これは、事前に共有鍵暗号鍵を設定することが難しいシナリオに対応するためです。
Philip Hoyer ActivIdentity, Inc. 117 Waterloo Road London, SE1 8UL UK
Philip Hoyer ActivIdentity, 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 Canada
Phone: +1 416 756 2324 Ext. 321
EMail: smachani@diversinet.com