Internet Engineering Task Force (IETF) P. Hoyer
Request for Comments: 6030 ActivIdentity
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign
S. Machani
Diversinet
October 2010
Portable Symmetric Key Container (PSKC)
Abstract
抽象
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure.
この文書は、暗号モジュールの異なる種類の対称鍵の輸送およびプロビジョニングのための対称鍵の形式を指定します。例えば、ワンタイムパスワード（OTP）は、強力な認証デバイスに秘密または対称暗号鍵を共有しました。標準キートランスポート・フォーマットは、同じインフラストラクチャに異なるベンダーからの成分を混合最善のソリューションを展開する企業を可能にします。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6030.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6030で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Key Words ..................................................4
1.2. Version Support ............................................4
1.3. Namespace Identifiers ......................................5
1.3.1. Defined Identifiers .................................5
1.3.2. Referenced Identifiers ..............................5
2. Terminology .....................................................6
3. Portable Key Container Entities Overview and Relationships ......6
4. <KeyContainer> Element: The Basics ..............................8
4.1. <Key>: Embedding Keying Material and Key-Related
Information ................................................8
4.2. Key Value Encoding ........................................10
4.2.1. AES Key Value Encoding .............................11
4.2.2. Triple-DES Key Value Encoding ......................11
4.3. Transmission of Supplementary Information .................12
4.3.1. <DeviceInfo> Element: Unique Device
Identification .....................................13
4.3.2. <CryptoModuleInfo> Element: CryptoModule
Identification .....................................15
4.3.3. <UserId> Element: User Identification ..............15
4.3.4. <AlgorithmParameters> Element:
Supplementary Information for OTP and CR Algorithms 15
4.4. Transmission of Key Derivation Values .....................17
5. Key Policy .....................................................19
5.1. PIN Algorithm Definition ..................................23
6. Key Protection Methods .........................................23
6.1. Encryption Based on Pre-Shared Keys .......................24
6.1.1. MAC Method .........................................26
6.2. Encryption Based on Passphrase-Based Keys .................27
6.3. Encryption Based on Asymmetric Keys .......................29
6.4. Padding of Encrypted Values for Non-Padded
Encryption Algorithms .....................................31
7. Digital Signature ..............................................31
8. Bulk Provisioning ..............................................33
9. Extensibility ..................................................35
10. PSKC Algorithm Profile ........................................36
10.1. HOTP .....................................................36
10.2. PIN ......................................................37
11. XML Schema ....................................................38
12. IANA Considerations ...........................................44
12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.2. XML Schema Registration ..................................45
12.3. URN Sub-Namespace Registration ...........................46
12.4. PSKC Algorithm Profile Registry ..........................46
12.5. PSKC Version Registry ....................................47
12.6. Key Usage Registry .......................................47
13. Security Considerations .......................................48
13.1. PSKC Confidentiality .....................................49
13.2. PSKC Integrity ...........................................50
13.3. PSKC Authenticity ........................................50
14. Contributors ..................................................50
15. Acknowledgements ..............................................50
16. References ....................................................51
16.1. Normative References .....................................51
16.2. Informative References ...................................52
Appendix A. Use Cases ............................................54
A.1. Online Use Cases ..........................................54
A.1.1. Transport of Keys from Server to Cryptographic
Module ................................................54
A.1.2. Transport of Keys from Cryptographic Module to
Cryptographic Module ..................................54
A.1.3. Transport of Keys from Cryptographic Module to
Server ................................................55
A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.2. Offline Use Cases .........................................55
A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
Appendix B. Requirements .........................................56
With the increasing use of symmetric-key-based systems, such as encryption of data at rest or systems used for strong authentication, such as those based on One-Time Password (OTP) and Challenge/Response (CR) mechanisms, there is a need for vendor interoperability and a standard format for importing and exporting (provisioning) symmetric keys. For instance, traditionally, vendors of authentication servers and service providers have used proprietary formats for importing and exporting these keys into their systems, thus making it hard to use tokens from two different vendors.
例えば、このようなワンタイムパスワード（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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "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バージョンの番号付けスキームは、「<主要な>。<マイナー>」です。メジャー番号とマイナー番号は、別々の整数として扱わなければならないと、それぞれ番号が一桁以上高い増分することができます。このように、「PSKC 2.4は、」順番に「PSKC 12.3」よりも低くなると思われる、「PSKC 2.13」より低いバージョンになります。先頭のゼロ（例えば、「PSKC 6.01」）は、受信者によって無視されなければならないと送ってはいけません。
The major version number should be incremented only if the message format (e.g., element structure) has changed so dramatically that an older version implementation would not be able to interoperate with a newer version. The minor version number indicates new capabilities, and it MUST be ignored by an entity with a smaller minor version number but used for informational purposes by the entity with the larger minor version number.
メジャーバージョン番号は、メッセージ・フォーマット（例えば、素子構造）場合にインクリメントされなければならない古いバージョンの実装では、新しいバージョンと相互運用することができないように劇的に変化しました。マイナーバージョン番号は、新しい機能を示し、それは小さなマイナーバージョン番号を持つエンティティによって無視されますが、より大きなマイナーバージョン番号を持つエンティティによって情報の目的のために使用しなければなりません。
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to identify resources, algorithms, and semantics.
この文書では、リソース、アルゴリズム、およびセマンティクスを識別するために、ユニフォームリソース識別子（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"
"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 = "URN：IETF：paramsは：XML：NS：keyprov：pskc" のxmlnsとして定義される）修飾PSKCスキーマ本明細書で定義され、接頭辞 "pskc" を使用例で使用中の要素への参照。実装でこの名前空間を使用することをお勧めします。
The PSKC syntax presented in this document relies on algorithm identifiers and elements defined in the XML Signature [XMLDSIG] namespace:
この文書で提示PSKC構文はアルゴリズム識別子とXML署名[XMLDSIG]名前空間で定義された要素に依存しています：
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns：DS = "http://www.w3.org/2000/09/xmldsig#"
References to the XML Signature namespace are represented by the prefix "ds".
XML署名名前空間への参照は、接頭辞「DS」で表されます。
PSKC also relies on algorithm identifiers and elements defined in the XML Encryption [XMLENC] namespace:
PSKCまた、アルゴリズム識別子とXML暗号化[XMLENC]名前空間で定義された要素に依存しています：
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns：また、xenc = "http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the prefix "xenc".
XML暗号化名前空間への参照は、接頭辞「また、xenc」で表されます。
When protecting keys in transport with passphrase-based keys, PSKC also relies on the derived key element defined in the XML Encryption Version 1.1 [XMLENC11] namespace:
パスフレーズベースのキーを使用して輸送に鍵を保護する場合、PSKCもXML暗号化バージョン1.1 [XMLENC11]名前空間で定義された派生重要な要素に依存しています：
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
xmlns：xenc11 = "http://www.w3.org/2009/xmlenc11#"
References to the XML Encryption Version 1.1 namespace are represented by the prefix "xenc11".
XML暗号化バージョン1.1の名前空間への参照は、接頭辞「xenc11」で表されます。
When protecting keys in transport with passphrase-based keys, PSKC also relies on algorithm identifiers and elements defined in the PKCS #5 [PKCS5] namespace:
パスフレーズベースのキーを使用して輸送にキーを保護する場合、PSKCはまた、アルゴリズム識別子とPKCS＃5 [PKCS5]ネームスペースで定義された要素に依存しています。
xmlns:pkcs5= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
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エンティティの数を運ぶコンテナを表します。有効なコンテナは、少なくとも一つのKeyPackageエンティティを運ばなければなりません。
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エンティティ - せいぜい一つのキーとその関連プロビジョニングエンドポイントまたは現在の使用エンドポイントのパッケージを示す、そのような物理的または仮想デバイスおよび特定の暗号モジュールとして。
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エンティティ - キーが存在するか、それらがプロビジョニングされるために暗号モジュールに関する情報を表します。
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.
前記データエンティティ - 要素名は、メタデータの名称とその関連値であるキーに関連するメタデータのリストを表す（たとえば、ための<データ>要素<秘密>）または平文（暗号化のためのいずれかであります例えば、<データ>要素<カウンタ>）を形成します。
Figure 1 shows the high-level structure of the PSKC data elements.
図1は、PSKCデータ要素のハイレベル構造を示します。
-----------------
| KeyContainer |
|---------------|
| EncryptionKey |
| Signature |
| ... |
-----------------
|
|
/|\ 1..n
---------------- ----------------
| KeyPackage | 0..1| DeviceInfo |
|--------------|--------|--------------|
| |-- | SerialNumber |
---------------- | | Manufacturer |
| | | .... |
| | ----------------
/|\ 0..1 |
---------------- | --------------------
| Key | | 0..1| CryptoModuleInfo |
|--------------| -----|------------------|
| Id | | Id |
| Algorithm | |.... |
| UserId | --------------------
| Policy |
| .... |
----------------
|
|
/|\ 0..n
--------------------------------------- - -
| | |
------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue |
| ValueMAC | ----------------
------------------
Figure 1: PSKC Data Elements Relationship Diagram
図1：PSKCデータ要素関係図
The following sections describe in detail all the entities and related XML schema elements and attributes.
次のセクションでは、詳細にすべてのエンティティおよび関連XMLスキーマの要素と属性を記述します。
In its most basic form, a PSKC document uses the top-level element <KeyContainer> and a single <KeyPackage> element to carry key information.
その最も基本的な形では、PSKCドキュメントはトップレベル要素<KeyContainer>とキー情報を運ぶために、単一の<KeyPackage>要素を使用しています。
The following example shows a simple PSKC document. We will use it to describe the structure of the <KeyContainer> element and its child elements.
次の例は、単純なPSKCドキュメントを示しています。私たちは、<KeyContainer>要素とその子要素の構造を記述するためにそれを使用します。
<?xml version="1.0" encoding="UTF-8"?> <KeyContainer Version="1.0" Id="exampleID1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> <KeyPackage> <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <Issuer>Issuer-A</Issuer> <Data> <Secret> <PlainValue>MTIzNA== </PlainValue> </Secret> </Data> </Key> </KeyPackage> </KeyContainer>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerバージョン= "1.0" ID = "exampleID1" のxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskc"> <KeyPackage> <キーID = "12345678" アルゴリズム= "壷：IETF：のparams：XML：NS：keyprov：pskc：HOTP"> <発行>発行者-A </発行者> <データ> <シークレット> <PlainValue> MTIzNA == < / PlainValue> </シークレット> </データ> </キー> </ KeyPackage> </ KeyContainer>
Figure 2: Basic PSKC Key Container Example
図2：基本PSKCキーコンテナの例
The attributes of the <KeyContainer> element have the following semantics:
<KeyContainer>要素の属性は次の意味があります。
'Version': The 'Version' attribute is used to identify the version of the PSKC schema version. This specification defines the initial version ("1.0") of the PSKC schema. This attribute MUST be included.
「バージョン」：「バージョン」属性はPSKCスキーマのバージョンのバージョンを識別するために使用されます。この仕様はPSKCスキーマの最初のバージョン（「1.0」）を定義します。この属性を含まなければなりません。
'Id': The 'Id' attribute carries a unique identifier for the container. As such, it helps to identify a specific key container in cases in which multiple containers are embedded in larger XML documents.
「ID」は：「ID」属性は、コンテナの一意の識別子を運びます。このように、それは、複数のコンテナが大きなXML文書に埋め込まれている場合には、特定のキーコンテナを識別するのに役立ちます。
The following attributes of the <Key> element MUST be included at a minimum:
<キー>要素の次の属性を最小限に含まれている必要があります
'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」は：この属性は、二者間の鍵プロビジョニング・交換の文脈における対称鍵の一意の識別子を運びます。これは、システムが欲しい場合は、<キー>、初期プロビジョニング後に同じ値（例えば、使用しなければならないの「ID」属性、PSKCは同じキーを参照する別のコンテナを使用して、送信側と受信側との間に複数の相互作用で使用されている場合ことを意味し他のシステムで重要なメタデータの値を更新するために、メタデータが更新される<キー>の「ID」属性の値は、プロビジョニングされたオリジナルの「ID」属性値）と同じでなければなりません。識別子は、英数字の文字列として定義されています。
'Algorithm': This attribute contains a unique identifier for the PSKC algorithm profile. This profile associates specific semantics to the elements and attributes contained in the <Key> element. This document describes profiles for open standards algorithms in Section 10. Additional profiles are defined in the following informative document: [PSKC-ALGORITHM-PROFILES].
「アルゴリズム」：この属性は、PSKCアルゴリズムプロファイルの一意の識別子が含まれています。このプロファイルは、<キー>要素に含まれる要素や属性に特定のセマンティクスを関連付けます。 [PSKCアルゴリズム-PROFILES]：この文書では、10追加のプロファイルは、次の参考文書で定義されているセクションでのオープンな標準アルゴリズムのプロファイルを説明しています。
The <Key> element has a number of optional child elements. An initial set is described below:
<キー>要素には、オプションの子要素の数を持っています。最初のセットは、以下に記載されています。
<Issuer>: This element represents the name of the party that issued the key. For example, a bank "Foobar Bank, Inc." issuing hardware tokens to their retail banking users may set this element to 'Foobar Bank, Inc.'.
<発行者>：この要素は、キーを発行した当事者の名前を表します。例えば、銀行「FOOBAR銀行、株式会社」彼らのリテール・バンキングのユーザーにハードウェアトークンを発行することは「FOOBAR銀行株式会社」に、この要素を設定することができます。
<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").
<フレンドリ>：簡単に参照するための秘密鍵のための人間可読な名前。この要素は、情報提供のみの目的があります。この要素は、言語依存文字列です。 lang =「XX」xxは[RFC5646]で指定された言語識別子である：したがって、属性XMLを有するべきです。いいえXML場合：lang属性が存在している「EN」（：langは=「EN」例えば、XML）に属性値を設定することによって定義されるように、実装は英語であること言語を想定しなければなりません。
<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:
<データ>：この要素は、についてのデータとキーに関連を運びます。次の子要素は<データ>要素に定義されています。
<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.
<秘密>：この要素はバイナリ表現におけるキー自体の値を運びます。キー値の符号化の詳細については、セクション4.2を参照してください。
<Counter>: This element contains the event counter for event-based OTP algorithms.
<カウンタ>：この要素は、イベントベースの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).
<時間>：この要素は、時間ベースの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).
<時間間隔>：この要素は、秒単位の時間ベースのOTPアルゴリズムの時間間隔値（このための典型的な値は30秒の時間間隔を示し、30であろう）を運びます。
<TimeDrift>: This element contains the device clock drift value for time-based OTP algorithms. The integer value (positive or negative drift) that indicates the number of time intervals that a validation server has established the device clock drifted after the last successful authentication. So, for example, if the last successful authentication established a device time value of 8 intervals from a specific start date but the validation server determines the time value at 9 intervals, the server SHOULD record the drift as -1.
<TimeDrift>：この要素は、時間ベースのOTPアルゴリズムのためのデバイスのクロックドリフト値を含みます。検証サーバは、デバイスのクロックは、最後の成功した認証の後にドリフト確立した時間間隔の数を示す整数値（正または負のドリフト）。したがって、たとえば、最後に成功した認証は、特定の開始日から8時間間隔のデバイスの時間値を確立している場合が、検証サーバは、9時間間隔で値を決定し、サーバは-1としてドリフトを記録する必要があります。
All the elements listed above (and those defined in the future) obey a simple structure in that they MUST support child elements to convey the data value in either plaintext or encrypted format:
すべての要素は、上記の（および将来的に定義されたもの）は、彼らがいずれかの平文または暗号化された形式でデータ値を伝えるために子要素をサポートしなければならないという点で、シンプルな構造に従います。
Plaintext: The <PlainValue> element carries a plaintext value that is typed, for example, to xs:integer.
平文：整数<PlainValue>要素は、xsに、例えば、入力された平文の値を運びます。
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に示す例では、2つのつの子、すなわち<秘密>要素と<カウンタ>と<データ>要素の使用を示します。両方の要素は、<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.
XSをデコード結果として、同じキー値のオクテット文字列を受け取る二者：base64Binaryのは、<PlainValue>または<EncryptedValue>要素内で、相互運用するために、全く同じようにキーを利用する必要があります。それを確実にするために、オクテット文字列とキーが使用される方法を定義する標準的なアルゴリズム記述で表記との対応関係を定義する必要があります。次のセクションでは、AESアルゴリズム[FIPS197]トリプルデータ暗号化アルゴリズム（TDEAまたはトリプルDES）[SP800-67]のために、その対応関係を確立します。そうでない場合は、特定のアルゴリズムのために指定されない限り、オクテット文字列のエンコーディングは、AESキー値のエンコードに従わなければなりません。
[FIPS197], Section 5.2, titled "Key Expansion", uses the input key as an array of bytes indexed starting at 0. The first octet of the OCTET STRING SHALL become the key byte in the AES, labeled index 0 in [FIPS197]; the succeeding octets of the OCTET STRING SHALL become key bytes in AES, in increasing index order.
「鍵拡張」と題する[FIPS197]、セクション5.2は、[FIPS197]でインデックス0を標識し、バイトの配列は0から始まるインデックス付けとしてオクテット文字列の最初のオクテットは、AESにおける鍵バイトとなるものの入力キーを使用し;オクテット文字列の後続のオクテットは、インデックスの昇順に、AESでの鍵のバイトとなるもの。
Proper parsing and key load of the contents of the OCTET STRING for AES SHALL be determined by using the following value for the <PlainValue> element (binaryBase64-encoded) to generate and match the key expansion test vectors in [FIPS197], Appendix A, for AES
AESのためのオクテット文字列の内容の適切な解析およびキー荷重は、付録A、[FIPS197]における鍵拡張テストベクトルを生成し、一致する（binaryBase64エンコード）<PlainValue>要素は、次の値を使用して決定しなければなりません、 AESについて
Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
暗号鍵：2B 7E 15 16 28のAE D2 A6のAB F7 15 88 09のCF 4F 3cと
... <PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue> ...
... <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.
トリプルDES鍵は、各64ビット（56ビットキーと8パリティビット）は、暗号化エンジン（キー1、キー2、およびキー3）のための3つのキーで構成されています。 3つのキーをまとめ鍵束[SP800-67]と呼ばれます。キーのバンドルは、2つのまたは3つの独立したキーのいずれかを使用することができます。 2つだけの独立したキーが使用される場合、（2キートリプルDESと呼ばれる）同じ値をキー1とキー3のために使用されます。
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).
トリプルDES鍵束内の各キーは、[SP800-67]で定義された手順に従って鍵スケジュールに展開され、付録A.番号1の手順番号1〜64から鍵のビットは、左端であること、または、最上位ビット（MSB）。オクテット文字列の最初のオクテットはビット1がMSBであるとキー1の8を介してビット1でなければなりません。オクテット文字列の末尾オクテットが（2キートリプルDESまたはキー2）キー3の64からビット57なければならないようにオクテット文字列の2番目のオクテットは、等キー1の16を介してビット9であり、そしてSHALL。
Proper parsing and key load of the contents of the OCTET STRING for Triple DES SHALL be determined by using the following <PlainValue> element (binaryBase64-encoded) to generate and match the key expansion test vectors in [SP800-67], Appendix B, for the key bundle:
トリプルDESのためのOCTET STRINGの内容の適切な解析およびキー荷重は[SP800-67]に鍵拡張テストベクトルを生成し、一致するように次の<PlainValue>要素（binaryBase64エンコード）、付録Bを使用して決定しなければなりません、キーバンドル：
Key1 = 0123456789ABCDEF
キー1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01
嘔吐= 23456789 Absudaiv 01
Key3 = 456789ABCDEF0123
= 456789署名Absudaiv 0123
... <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue> ...
... <PlainValue> ASNFZ4mrze8jRWeJq83vAUVniavN7wEj </ PlainValue> ...
A PSKC document can contain a number of additional information regarding device identification, cryptographic module identification, user identification, and parameters for usage with OTP and CR algorithms. The following example, see Figure 3, is used as a reference for the subsequent sub-sections.
PSKC文書は、OTPおよびCRアルゴリズムでの使用のための装置識別に関する追加情報、暗号モジュールの識別、ユーザ識別、及びパラメータの数を含むことができます。次の例では、図3を参照してください、次のサブセクションのための基準として使用されます。
<?xml version="1.0" encoding="UTF-8"?> <KeyContainer Version="1.0" Id="exampleID1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> <KeyPackage> <DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>987654321</SerialNo> <UserId>DC=example-bank,DC=net</UserId> </DeviceInfo> <CryptoModuleInfo> <Id>CM_ID_001</Id> </CryptoModuleInfo> <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <Issuer>Issuer</Issuer> <AlgorithmParameters> <ResponseFormat Length="8" Encoding="DECIMAL"/> </AlgorithmParameters> <Data> <Secret> <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= </PlainValue> </Secret> <Counter> <PlainValue>0</PlainValue> </Counter> </Data> <UserId>UID=jsmith,DC=example-bank,DC=net</UserId> </Key> </KeyPackage> </KeyContainer>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerバージョン= "1.0" ID = "exampleID1" のxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskc"> <KeyPackage> <DEVICEINFO> <メーカー>メーカー</メーカー> <のSerialNo> 987654321 </のSerialNo> <ユーザーID> DC =たとえば、銀行、DC =ネット</ユーザーID> </ DEVICEINFO> <CryptoModuleInfo> <ID> CM_ID_001 </ ID> </ CryptoModuleInfo> <キーID = "12345678" アルゴリズム= "壷：IETF：のparams：XML：NS：keyprov：pskc：HOTP"> <発行>発行</発行者> <ない、AlgorithmParameters> <ResponseFormat長= "8" エンコーディング= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <シークレット> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA = </ PlainValue> </シークレット> <カウンタ> <PlainValue> 0 </ PlainValue> </カウンタ> </データ> <ユーザーID > UID = JSMITH、DC =例-銀行、DC =ネット</ユーザーID> </キー> </ KeyPackage> </ KeyContainer>
Figure 3: PSKC Key Container Example with Supplementary Data
図3：補足データとPSKCキーコンテナの例
The <DeviceInfo> element uniquely identifies the device to which the <KeyPackage> is provisioned. Since devices can come in different form factors, such as hardware tokens, smart-cards, soft tokens in a mobile phone, or as a PC, this element allows different child element combinations to be used. When combined, the values of the child elements MUST uniquely identify the device. For example, for hardware tokens, the combination of <SerialNo> and <Manufacturer> elements uniquely identifies a device, but the <SerialNo> element alone is insufficient since two different token manufacturers might issue devices with the same serial number (similar to the Issuer Distinguished Name and serial number of a certificate).
<DEVICEINFO>要素を一意<KeyPackage>プロビジョニングされたデバイスを識別する。装置は、ハードウェアトークン、スマートカード、携帯電話にソフトトークン、またはPCなどのような異なるフォームファクタ、に来ることができるので、この要素は、別の子要素の組み合わせが使用されることを可能にします。組み合わせた場合、子要素の値は、デバイスを一意に識別しなければなりません。例えば、ハードウェア・トークン、<のSerialNo>の組み合わせおよび<メーカー>要素がデバイスを一意に識別し、2つの異なるトークン製造業者が発行者に似て同じシリアル番号（持つデバイスを発行する可能性があるため、単独で<のSerialNo>要素が不十分です識別名と証明書のシリアル番号）。
The <DeviceInfo> element has the following child elements:
<DEVICEINFO>要素は、以下の子要素があります。
<Manufacturer>: This element indicates the manufacturer of the device. Values for the <Manufacturer> element MUST be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN], "oath." MUST be prepended to the value (e.g., "oath.<prefix value from [OATHMAN]>"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.<Organization value from [IANAPENREG]>").
<メーカー>：この要素は、デバイスの製造元を示します。 <メーカー>要素の値は、組織の値を使用して、[OATHMAN]プレフィックス（即ち、左の列）又はIANAプライベートエンタープライズ番号レジストリ[IANAPENREG]のいずれかから取らなければなりません。値は[OATHMAN]から取得されたときに「誓い。」値（例えば、「宣誓。<OATHMAN]からプレフィックス値>」）の先頭に追加されなければなりません。値は[IANAPENREG]から取得されたときに「IANA」。 （例えば、「IANA。<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).
<モデル>：この要素は、（例えば、ワンボタンHOTPトークン-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>：この要素は、プロビジョニング・サーバーは、キーは、キープロビジョニング要求が承認されたデバイスにロードされようとしていることを保証することができます。デバイスは、デバイス識別子、例えば、国際モバイル機器アイデンティティー（IMEI）電話用、またはキーがトラステッド・プラットフォーム・モジュールによって保護されているものの識別子のクラス、例えば、の識別子（使用要求にバインドされていますTPM）。
<StartDate> and <ExpiryDate>: These two elements indicate the start and end date of a device (such as the one on a payment card, used when issue numbers are not printed on cards). The date MUST be expressed as a dateTime value in "canonical representation" [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. Keys that reside on the device SHOULD only be used when the current date is after the <StartDate> and before the <ExpiryDate>. Note that usage enforcement of the keys with respect to the dates MAY only happen on the validation server, as some devices such as smart cards do not have an internal clock. Systems thus SHOULD NOT rely upon the device to enforce key usage date restrictions.
<開始日>と<ExpiryDate>：これら二つの要素は、（発行番号がカードに印刷されていないときに使用される支払いカード上の一つのような）デバイスの開始日と終了日を示します。日付は、「標準的な表現」[W3C.REC-XMLSCHEMA-2から20041028]の日時値として表現されなければなりません。実装はミリ秒よりも時間分解能の細かいに依存すべきではないとうるう秒を指定する時刻を生成してはなりません。現在の日付が<開始日>と<ExpiryDate>の前にした後であるとき、デバイス上に存在するキーにのみ使用してください。スマートカードなど、一部のデバイスは内部クロックを持っていないとして、日付に関しては、キーの使用法の施行にのみ、検証サーバ上で起こるかもしれないことに注意してください。システムは、このように鍵使用日付制限を適用するために、デバイスに依存しない（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>要素の特定の子要素は、デバイスを一意に識別するために含まれなければなりません。この文書は、異なるデバイスタイプを列挙していないため、デバイスの種類毎に必須の要素が表示されません。
The <CryptoModuleInfo> element identifies the cryptographic module to which the symmetric keys are or have been provisioned. This allows the identification of the specific cases where a device MAY contain more than one crypto module (e.g., a PC hosting a TPM and a connected token).
<CryptoModuleInfo>要素は、対称鍵があるか、またはプロビジョニングされていた暗号モジュールを特定します。これは、デバイスが複数の暗号モジュール（例えば、TPMと接続トークンをホストPC）を含んでいてもよい特定の症例の同定を可能にします。
The <CryptoModuleInfo> element has a single child element that MUST be included:
<CryptoModuleInfo>要素が含まれなければならない単一の子要素があります。
<Id>: This element carries a unique identifier for the CryptoModule and is implementation specific. As such, it helps to identify a specific CryptoModule to which the key is being or was provisioned.
<ID>：この要素は、暗号モジュールの一意の識別子を運び、実装固有です。このように、それはキーがされているか、プロビジョニングされたために、特定の暗号モジュールを識別するのに役立ちます。
The <UserId> element identifies the user of a distinguished name, as defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net.
[RFC4514]で定義されるように、<ユーザーID>要素には、識別名のユーザを識別し、例えば、UID = JSMITH、DCは、例えば、DC =ネット=。
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つの場所に表示され、それが持つユーザを示し、<DEVICEINFO>要素の子要素としても誰デバイスが関連付けられています。
4.3.4. <AlgorithmParameters> Element: Supplementary Information for OTP and CR Algorithms
4.3.4. <ない、AlgorithmParameters>要素：OTPおよびCRアルゴリズムのための補足情報
The <AlgorithmParameters> element is a child element of the <Key> element, and this document defines three child elements: <Suite>, <ChallengeFormat>, and <ResponseFormat>.
<ない、AlgorithmParameters>要素は、<キー>要素の子要素であり、この文書は3つのつの子要素を定義：<スイート>、<ChallengeFormat>、および<ResponseFormat>。
<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.
オプションの<スイート>要素は、アルゴリズム特異的であり、使用されるアルゴリズムの追加の特性を定義します。例えば、HMACベースの（ハッシュされたMAC）OTPアルゴリズムでは、（SHA1、SHA256など）使用されるハッシュアルゴリズムの強度を指定することができました。各アルゴリズムプロファイルの値の正確な意味については、アルゴリズム・プロファイル・セクション、セクション10を参照してください。
<ChallengeFormat>:
<ChallengeFormat>：
The <ChallengeFormat> element defines the characteristics of the challenge in a CR usage scenario whereby the following attributes are defined:
<ChallengeFormat>要素は以下の属性が定義されていることにより、CRの使用シナリオにおける課題の特性を定義します。
'Encoding': This attribute, which MUST be included, defines the encoding of the challenge accepted by the device and MUST be one of the following values:
「エンコーディング」を含まなければなりませんこの属性は、デバイスによって受け入れチャレンジの符号化を定義し、以下の値のいずれかである必要があります
DECIMAL: Only numerical digits
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：ベース64は、符号化された、[RFC4648]のセクション4で定義されるように
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.
「チェックデジット」は：この属性は、デバイスがチャレンジに含まれている、[ISOIEC7812]で定義されるように、数字をチェック添付のLuhnをチェックする必要があるかどうかを示します。 「エンコーディング」属性が「DECIMAL」に設定されている場合にのみ有効です。 TRUEの値は、デバイスが提供されるチャレンジに添付のLuhnチェックデジットをチェックすることを示しています。 FALSEの値は、デバイスがチャレンジに追加のLuhnチェックデジットをチェックしないであろうことを示しています。
'Min': This attribute defines the minimum size of the challenge accepted by the device for CR mode and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the minimum number of digits/characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the minimum number of bytes of the unencoded value.
「最小」：この属性は、CRモードのデバイスによって受け入れチャレンジの最小サイズを定義し、含まなければなりません。 「エンコーディング」属性が「DECIMAL」、「HEXADECIMAL」、または「ALPHANUMERIC」に設定されている場合は、この値は数字/文字の最小数を示します。 「エンコーディング」属性が「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.
「最大」：この属性は、CRモードのデバイスによって受け入れチャレンジの最大サイズを定義し、含まなければなりません。 「エンコーディング」属性が「DECIMAL」、「HEXADECIMAL」、または「ALPHANUMERIC」に設定されている場合は、この値は数字/文字の最大数を示します。 「エンコード」属性が「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自体（例えば、DECIMAL、4桁のPINの長4）のフォーマットを含んでいます。次の属性が定義されています。
'Encoding': This attribute defines the encoding of the response generated by the device, it MUST be included and MUST be one of the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
「エンコード」：この属性は、デバイスによって生成された応答のエンコーディングを定義し、それを含まなければなりません、次の値のいずれかである必要があります10進数、16進数の英数字、BASE64、又はBINARY。
'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.
「チェックデジット」は：この属性は、定義されたようISOIEC7812]にデバイスが応答するには、のLuhnチェックデジットを付加する必要があるかどうかを示します。 「エンコーディング」属性が「DECIMAL」に設定されている場合にのみ有効です。値がTRUEの場合、デバイスは、応答へのLuhnチェックデジットを追加します。値がFALSEの場合、デバイスは、応答へのLuhnチェックデジットを付加しません。
'Length': This attribute defines the length of the response generated by the device and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or ALPHANUMERIC, this value indicates the number of digits/ characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
「長さ」：この属性は、デバイスによって生成された応答の長さを定義し、含まなければなりません。 「エンコーディング」属性が「DECIMAL」、「HEXADECIMAL」、または英数字に設定されている場合、この値は数字/文字の数を示します。 「エンコーディング」属性が「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).
<キー>要素の子要素である<KeyProfileId>要素は、コンテナ内で送信されていないが、2つの間で合意されているキー属性値のセットを確立するために、送信側と受信側の関係者の間で使用される一意の識別子を運びますバンドのうち、当事者。この要素は、キー属性値のセットに一意の参照を表します。 （応答を計算するときに影響を与えるスマートカードアプリケーションに存在する特定の属性値に関連する。例えば、スマートカードアプリケーション個人化プロファイルID）。
For example, in the case of MasterCard's Chip Authentication Program [CAP], the sending and the receiving party would agree that KeyProfileId='1' represents a certain set of values (e.g., Internet Authentication Flag (IAF) set to a specific value). During transmission of the <KeyContainer>, these values would not be transmitted as key attributes but would only be referred to via the
例えば、MasterCardのチップ認証プログラム[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>要素は、鍵導出方式で使用する外部キーへの参照を含みます。この場合、親は、<キー>要素は、（秘密）鍵の値が搬送される<データ>の<秘密>サブ要素を、含まれません。外部マスタキーへの参照のみが搬送される（例えば、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>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerバージョン= "1.0" ID = "exampleID1" のxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskc"> <KeyPackage> <DEVICEINFO> <メーカー>メーカー</メーカー> <のSerialNo> 987654321 </のSerialNo> </ DEVICEINFO> <CryptoModuleInfo> <ID> CM_ID_001 </ ID> </ CryptoModuleInfo> <キーID = "12345678" アルゴリズム= "壷： IETF：paramsは：XML：NS：keyprov：pskc：HOTP "> <発行>発行</発行者> <ない、AlgorithmParameters> <ResponseFormat長=" 8" エンコーディング= "DECIMAL" /> </ない、AlgorithmParameters> <KeyProfileId> keyProfile1 </ KeyProfileId> <KeyReference> MasterKeyLabel </ KeyReference> <データ> <カウンタ> <PlainValue> 0 </ PlainValue> </カウンタ> </データ> <ポリシー> <のKeyUsage> OTP </のKeyUsage> </ポリシー> </キー> </ 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.
このセクションでは、キーの使用とキーPIN保護ポリシーが特定のキーとそれに関連するメタデータに取り付けることを可能にするPSKC内<ポリシー>要素の機能性を示します。この要素は、<キー>要素の子要素です。
If the <Policy> element contains child elements or values within elements/attributes that are not understood by the recipient of the PSKC document, then the recipient MUST assume that key usage is not permitted. This statement ensures that the lack of understanding of certain extensions does not lead to unintended key usage.
<ポリシー>要素はPSKC文書の受信者によって理解されていない要素/属性内の子要素または値が含まれている場合は、受信者は、キーの使用が許可されていないと仮定しなければなりません。この文は、特定の拡張子の理解の欠如が意図しないキーの使用にはつながらないことを保証します。
We will start our description with an example that expands the example shown in Figure 3.
我々は、図3に示した例を拡張する例を私たちの説明を開始します。
<?xml version="1.0" encoding="UTF-8"?> <KeyContainer Version="1.0" Id="exampleID1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> <KeyPackage> <DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>987654321</SerialNo> </DeviceInfo> <CryptoModuleInfo> <Id>CM_ID_001</Id> </CryptoModuleInfo> <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <Issuer>Issuer</Issuer> <AlgorithmParameters> <ResponseFormat Length="8" Encoding="DECIMAL"/> </AlgorithmParameters> <Data> <Secret> <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= </PlainValue> </Secret> <Counter> <PlainValue>0</PlainValue>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerバージョン= "1.0" ID = "exampleID1" のxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskc"> <KeyPackage> <DEVICEINFO> <メーカー>メーカー</メーカー> <のSerialNo> 987654321 </のSerialNo> </ DEVICEINFO> <CryptoModuleInfo> <ID> CM_ID_001 </ ID> </ CryptoModuleInfo> <キーID = "12345678" アルゴリズム= "壷： IETF：のparams：XML：NS：keyprov：pskc：HOTP "> <発行>発行</発行者> <ない、AlgorithmParameters> <ResponseFormat長=" 8" エンコーディング= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <秘密> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA = </ PlainValue> </シークレット> <カウンタ> <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>
</カウンタ> </データ> <ポリシー> <PINPolicy MINLENGTH = "4" のMaxLength = "4" PINKeyId = "123456781" PINEncoding = "DECIMAL" PINUsageMode = "ローカル" /> <のKeyUsage> OTP </のKeyUsage> </ポリシー> </キー> </ KeyPackage> <KeyPackage> <DEVICEINFO> <メーカー>メーカー</メーカー> <のSerialNo> 987654321 </のSerialNo> </ DEVICEINFO> <CryptoModuleInfo> <ID> CM_ID_001 </ ID> </ CryptoModuleInfo > <キーID = "123456781" アルゴリズム= "URN：IETF：paramsは：XML：NS：keyprov：pskc：ピン"> <発行>発行</発行者> <ない、AlgorithmParameters> <ResponseFormat長= "4" エンコード= "DECIMAL 「/> </ない、AlgorithmParameters> <データ> <シークレット> <PlainValue> MTIzNA == </ PlainValue> </シークレット> </データ> </キー> </ KeyPackage> </ KeyContainer>
Figure 5: Non-Encrypted HOTP Secret Key Protected by PIN
図5：非暗号化HOTP秘密鍵PINによって保護されました
This document defines the following <Policy> child elements:
このドキュメントでは、次の<ポリシー>子要素を定義します。
<StartDate> and <ExpiryDate>: These two elements denote the validity period of a key. It MUST be ensured that the key is only used between the start and the end date (inclusive). The date MUST be expressed as a dateTime value in "canonical representation" [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. When this element is absent, the current time is assumed as the start time.
<開始日>と<ExpiryDate>：これら二つの要素は、キーの有効期間を表します。キーのみ、開始日と終了日（含む）との間で使用されることが保証されなければなりません。日付は、「標準的な表現」[W3C.REC-XMLSCHEMA-2から20041028]の日時値として表現されなければなりません。実装はミリ秒よりも時間分解能の細かいに依存すべきではないとうるう秒を指定する時刻を生成してはなりません。この要素が存在しない場合、現在時刻が開始時刻とします。
<NumberOfTransactions>: The value in this element indicates the maximum number of times a key carried within the PSKC document can be used by an application after having received it. When this element is omitted, there is no restriction regarding the number of times a key can be used.
<NumberOfTransactions>：この要素の値はPSKC文書内で運ばキーがそれを受信した後にアプリケーションによって使用することができる最大回数を示しています。この要素が省略された場合、キーを使用することができる回数に関する制限はありません。
<KeyUsage>: The <KeyUsage> element puts constraints on the intended usage of the key. The recipient of the PSKC document MUST enforce the key usage. Currently, the following tokens are registered by this document:
<のKeyUsage>：<のKeyUsage>要素は、キーの使用目的に制約を置きます。 PSKC文書の受信者は、鍵の使用を強制しなければなりません。現在、以下のトークンは、この文書によって登録されています。
OTP: The key MUST only be used for OTP generation.
OTP：キーはOTP生成のために使用しなければなりません。
CR: The key MUST only be used for Challenge/Response purposes.
CR：キーはチャレンジ/レスポンスの目的のためにのみ使用しなければなりません。
Encrypt: The key MUST only be used for data encryption purposes.
暗号化：鍵は唯一のデータ暗号化の目的のために使用しなければなりません。
Integrity: The key MUST only be used to generate a keyed message digest for data integrity or authentication purposes.
整合性：キーは、データの整合性や認証のためのダイジェストキー付きメッセージを生成するために使用されなければなりません。
Verify: The key MUST only be used to verify a keyed message digest for data integrity or authentication purposes (this is the opposite key usage of 'Integrity').
検証：キーのみ（これは「完全性」の反対の主要な用法である）、データの整合性または認証のためにダイジェストキー付きメッセージを確認するために使用されなければなりません。
Unlock: The key MUST only be used for an inverse Challenge/ Response in the case where a user has locked the device by entering a wrong PIN too many times (for devices with PIN-input capability).
アンロック：キーは、ユーザが（PIN入力機能を持つデバイスの場合）間違ったPINあまりにも多くの時間を入力することにより、デバイスをロックしている場合には、逆チャレンジ/レスポンスのために使用されなければなりません。
Decrypt: The key MUST only be used for data decryption purposes.
解読：キーのみをデータ復号化の目的のために使用しなければなりません。
KeyWrap: The key MUST only be used for key wrap purposes.
KeyWrap：キーは、キーラップの目的のために使用しなければなりません。
Unwrap: The key MUST only be used for key unwrap purposes.
アンラップ：キーは、キーだけアンラップの目的のために使用しなければなりません。
Derive: The key MUST only be used with a key derivation function to derive a new key (see also Section 8.2.4 of [NIST800-57]).
派生：キーは、新しい鍵を導出するために鍵導出関数を使用する必要があります（また、[NIST800-57]の第8.2.4項を参照してください）。
Generate: The key MUST only be used to generate a new key based on a random number and the previous value of the key (see also Section 8.1.5.2.1 of [NIST800-57]).
生成：キーのみ（また、[NIST800-57]のセクション8.1.5.2.1を参照）乱数および鍵の以前の値に基づいて新たな鍵を生成するために使用されなければなりません。
The element MAY also be repeated to allow several key usages to be expressed. When this element is absent, no key usage constraint is assumed, i.e., the key MAY be utilized for every usage.
要素はまた、いくつかの重要な用途を表現することができるようにするために繰り返されてもよいです。この要素が存在しない場合、何のキーの使用制限が想定されていない、すなわち、鍵は、すべての使用のために利用することができます。
<PINPolicy>: The <PINPolicy> element allows policy about the PIN usage to be associated with the key. The following attributes are specified:
<PINPolicy>：<PINPolicy>要素は、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の値が含まれています。この<KeyContainer>内に保持された<キー>要素のユニークな「ID」属性の谷を運びます。
'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.
ローカル：この値は、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.
前に付加：この値は、PINは、アルゴリズム応答の前に付加されていることを示します。したがって、それは応答を検証する当事者がチェックしなければなりません。
Append: This value indicates that the PIN is appended to the algorithm response; hence, it MUST be checked by the party validating the response.
追加：この値は、PINアルゴリズム応答に添付されていることを示します。したがって、それは応答を検証する当事者がチェックしなければなりません。
Algorithmic: This value indicates that the PIN is used as part of the algorithm computation.
アルゴリズム：この値は、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が間違って入力することができる最大回数を示している（典型的な妥当な値は、少なくとも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を設定することが可能にすることはできません。 「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を設定することが可能にすることはできません。 「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の符号化を示し、値のいずれかである必要があります10進数、16進数の英数字、BASE64、又はBINARY。
If the 'PinUsageMode' attribute is set to 'Local', then the device MUST enforce the restriction indicated in the 'MaxFailedAttempts', 'MinLength', 'MaxLength', and 'PINEncoding' attributes; otherwise, it MUST be enforced on the server side.
「PinUsageMode」属性に設定されている場合は「ローカル」は、デバイスが「MaxFailedAttempts」に示された制限を強制しなければならない、「MINLENGTH」や「maxLength」、そして「PINEncoding」属性。それ以外の場合は、サーバーサイドで強制されなければなりません。
The PIN algorithm is defined as:
PINアルゴリズムは次のように定義されています。
boolean = comparePIN(K,P)
ブール= 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を含む全てのオクテットが同じである場合には、このような比較はTRUE（認証情報が一致した）の値を得なければなりませんKおよびPの直線オクテット比較でありますP.を備えオクテット
With the functionality described in the previous sections, information related to keys had to be transmitted in cleartext. With the help of the <EncryptionKey> element, which is a child element of the <KeyContainer> element, it is possible to encrypt keys and associated information. The level of encryption is applied to the value of individual elements and the applied encryption algorithm MUST be the same for all encrypted elements. Keys are protected using the following methods: pre-shared keys, passphrase-based keys, and asymmetric keys. When encryption algorithms are used that make use of Initialization Vectors (IVs), for example, AES-128-CBC, a random IV value MUST be generated for each value to be encrypted and it MUST be prepended to the resulting encrypted value as specified in [XMLENC].
前のセクションで説明した機能を用いて、キーに関連する情報は平文で送信されなければなりませんでした。 <KeyContainer>要素の子要素である<EncryptionKey>要素の助けを借りて、キーと関連する情報を暗号化することが可能です。暗号化のレベルは、個々の要素の値に適用され、適用される暗号化アルゴリズムは、全ての暗号化された要素で同じでなければなりません。事前共有鍵、パスフレーズベースキー、および非対称キー：キーは、以下の方法を使用して保護されています。暗号化アルゴリズムは、初期化ベクトル（IV）を使用することが使用される場合、それぞれの値を暗号化するとで指定されるように、それが得られた暗号化された値の前に付加されなければならないため、例えば、AES-128-CBC、ランダムIV値が生成されなければなりません【XMLENC]。
Figure 6 shows an example that illustrates the encryption of the content of the <Secret> element using AES-128-CBC and PKCS #5 Padding. The plaintext value of <Secret> is '3132333435363738393031323334353637383930'. The name of the pre-shared secret is "Pre-shared-key", as set in the <KeyName> element (which is a child element of the <EncryptionKey> element). The value of the encryption key used is '12345678901234567890123456789012'.
図6は、AES-128-CBCとPKCS＃5パディングを使用して<秘密>要素の内容の暗号化を示す例を示しています。 <シークレット>の平文値は「3132333435363738393031323334353637383930」です。事前共有秘密の名前が（<EncryptionKey>要素の子要素である）<キー名>要素に設定され、「事前共有キー」です。使用される暗号化キーの値は「12345678901234567890123456789012」です。
The IV for the MAC key is '11223344556677889900112233445566', and the IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
MACキーのIVは「11223344556677889900112233445566」であり、かつHOTPキーのIVは「000102030405060708090a0b0c0d0e0f」です。
As AES-128-CBC does not provide integrity checks, a keyed MAC is applied to the encrypted value using a MAC key and a MAC algorithm as declared in the <MACMethod> element (in our example, "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the algorithm and the value of the MAC key is randomly generated, in our case '1122334455667788990011223344556677889900', and encrypted with the above encryption key). The result of the keyed-MAC computation is placed in the <ValueMAC> child element of <Secret>.
//www.w3：AES-128-CBCは、整合性チェックを提供していませんので、<MACMethod>要素（この例では、「HTTPで宣言されたとして、鍵付きMACはMACキーとMACアルゴリズムを使用して暗号化された値に適用されます.ORG / 2000/09 / XMLDSIG＃HMAC-SHA1" アルゴリズムとMACキーの値はランダムに生成されたとして、我々の場合には、使用されている 『1122334455667788990011223344556677889900』、および上記暗号化キーで暗号化されました）。キー付き-MAC計算の結果は、<シークレット>の<ValueMAC>子要素に配置されます。
<?xml version="1.0" encoding="UTF-8"?> <KeyContainer Version="1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <EncryptionKey> <ds:KeyName>Pre-shared-key</ds:KeyName> </EncryptionKey> <MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> <MACKey> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <xenc:CipherData> <xenc:CipherValue> ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX </xenc:CipherValue> </xenc:CipherData> </MACKey> </MACMethod> <KeyPackage> <DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>987654321</SerialNo> </DeviceInfo> <CryptoModuleInfo>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerバージョン= "1.0" のxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskc" のxmlns：DS = "のhttp：// www.w3.org/2000/09/xmldsig#」のxmlns：また、xenc = "http://www.w3.org/2001/04/xmlenc#"> <EncryptionKey> <DS：キー名>事前共有キー< / DS：キー名> </ EncryptionKey> <MACMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"> <マッキー> <また、xenc：はEncryptionMethodアルゴリズム= "のhttp：// WWW .w3.org / 2001/04 / xmlenc＃AES128-CBC "/> <また、xenc：CipherData> <また、xenc：CipherValue> ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX </また、xenc：CipherValue> </また、xenc：CipherData> </マッキー> </ MACMethod> <KeyPackage > <DEVICEINFO> <メーカー>メーカー</メーカー> <のSerialNo> 987654321 </のSerialNo> </ DEVICEINFO> <CryptoModuleInfo>
<Id>CM_ID_001</Id> </CryptoModuleInfo> <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <Issuer>Issuer</Issuer> <AlgorithmParameters> <ResponseFormat Length="8" Encoding="DECIMAL"/> </AlgorithmParameters> <Data> <Secret> <EncryptedValue> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <xenc:CipherData> <xenc:CipherValue> AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv </xenc:CipherValue> </xenc:CipherData> </EncryptedValue> <ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc= </ValueMAC> </Secret> <Counter> <PlainValue>0</PlainValue> </Counter> </Data> </Key> </KeyPackage> </KeyContainer>
<ID> CM_ID_001 </ ID> </ CryptoModuleInfo> <キーID = "12345678" アルゴリズム= "壷：IETF：のparams：XML：NS：keyprov：pskc：HOTP"> <発行>発行</発行者> <ない、AlgorithmParameters> <ResponseFormat長= "8" エンコーディング= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <シークレット> <EncryptedValue> <また、xenc：はEncryptionMethodアルゴリズム= "http://www.w3.org/2001/04/xmlenc# AES128-CBC "/> <また、xenc：CipherData> <また、xenc：CipherValue> AAECAwQFBgcICQoLDA0OD + cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv </また、xenc：CipherValue> </また、xenc：CipherData> </ EncryptedValue> <ValueMAC>蘇+ NvtQfmvfJzF6bmQiJqoLRExc = </ ValueMAC> </シークレット> <カウンタ> <PlainValue> 0 </ PlainValue> </カウンタ> </データ> </キー> </ KeyPackage> </ KeyContainer>
Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1
図6：HMAC-SHA1とAES-128-CBC暗号化事前共有秘密鍵
When protecting the payload with pre-shared keys, implementations MUST set the name of the specific pre-shared key in the <KeyName> element inside the <EncryptionKey> element. When the encryption method uses a CBC mode that requires an explicit initialization vector (IV), the IV MUST be passed by prepending it to the encrypted value.
事前共有キーを使用してペイロードを保護する場合、実装は、<EncryptionKey>要素内の<キー名>要素の特定の事前共有キーの名前を設定しなければなりません。暗号化方式は、明示的な初期化ベクトル（IV）を必要とCBCモードを使用する場合、IVは暗号化された値にそれを付加することで渡さなければなりません。
For systems implementing PSKC, it is RECOMMENDED to support AES-128-CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-AES128 requires that the key to be protected must be a multiple of 8 bytes in length. Hence, if keys of a different length have to be protected, then the usage of the key-wrap algorithm with padding, as described in [RFC5649] is RECOMMENDED. Some of the encryption algorithms that can optionally be implemented are:
PSKCを実装するシステムのためには、AES128-CBC（http://www.w3.org/2001/04/xmlenc#aes128-cbcのURIを持つ）とHTTPのURIを持つKW-AES128を（サポートするために推奨されます：//www.w3.org/2001/04/xmlenc#kw-aes128）。 KW-AES128が保護されるキーの長さが8バイトの倍数でなければならないことを要求することに注意してください。したがって、[RFC5649]に記載されているように、異なる長さのキーは、保護されるパディングとキーラップアルゴリズムを次に使用している場合が推奨されます。必要に応じて実装することができ、暗号化アルゴリズムのいくつかは以下のとおりです。
Algorithm | Uniform Resource Locator (URL)
---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
When algorithms without integrity checks are used, such as AES-128- CBC, a keyed-MAC value MUST be placed in the <ValueMAC> element of the <Data> element. In this case, the MAC algorithm type MUST be set in the <MACMethod> element of the <KeyContainer> element. The MAC key MUST be a randomly generated key by the sender, be pre-agreed upon between the receiver and the sender, or be set by the application protocol that carries the PSKC document. It is RECOMMENDED that the sender generate a random MAC key. When the sender generates such a random MAC key, the MAC key material MUST be encrypted with the same encryption key specified in <EncryptionKey> element of the key container. The encryption method and encrypted value MUST be set in the <EncryptionMethod> element and the <CipherData> element, respectively, of the <MACKey> element in the <MACMethod> element. The <MACKeyReference> element of the <MACMethod> element MAY be used to indicate a pre-shared MAC key or a provisioning protocol derived MAC key. For systems implementing PSKC, it is RECOMMENDED to implement the HMAC-SHA1 (with the URI of 'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC algorithms that can optionally be implemented are:
整合性チェックなしのアルゴリズムは、例えばAES-CBC 128として使用される場合、キー付き-MAC値は、<データ>要素の<ValueMAC>要素内に配置されなければなりません。この場合、MACアルゴリズムの種類は<KeyContainer>要素の<MACMethod>要素に設定されなければなりません。 MACキーは、送信者によってランダムに生成された鍵は、受信側と送信側との間の時に事前合意され、又はPSKC文書を搬送するアプリケーションプロトコルにより設定することがなければなりません。送信者は、ランダムなMACキーを生成することが推奨されます。送信者は、ランダムMAC鍵を生成する際に、MAC鍵材料は、キーコンテナの<EncryptionKey>要素で指定された同一の暗号鍵で暗号化されなければなりません。暗号化方式と暗号化された値は、<MACMethod>要素内の<マッキー>要素の、それぞれ、<はEncryptionMethod>要素と<CipherData>要素に設定されなければなりません。 <MACMethod>要素の<MACKeyReference>要素は、事前共有MAC鍵またはMAC鍵導出さプロビジョニングプロトコルを示すために使用され得ます。 PSKCを実装するシステムの場合には、（「http://www.w3.org/2000/09/xmldsig#hmac-sha1」のURIを持つ）HMAC-SHA1を実装することが推奨されます。必要に応じて実装することができ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）を使用し、<秘密>要素の内容の暗号化を示す例を示しています。パスフレーズベースの鍵導出を使用する場合、XML暗号化バージョン1.1で定義された<DerivedKey>要素は[XMLENC11] passphrasedベースのキーを指定するために使用されなければなりません。 <DerivedKey>要素はキーコンテナの<EncryptionKey>要素の子要素として設定されています。
The <DerivedKey> element is used to specify the key derivation function and related parameters. The encryption algorithm, in this example, AES-128-CBC (URI 'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the 'Algorithm' attribute of <EncryptionMethod> element used inside the encrypted data elements.
<DerivedKey>要素は、鍵導出関数と関連するパラメータを指定するために使用されます。この例では、暗号化アルゴリズム、AES-128-CBCは、（URI「http://www.w3.org/2001/04/xmlenc#aes128-cbc」）、<はEncryptionMethodの「アルゴリズム」属性に設定しなければなりません>要素は、暗号化されたデータ要素内で使用されます。
When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11: KeyDerivationMethod> element MUST be set to the URI 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The <xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params> child element to indicate the PBKDF2 parameters, such as salt and iteration count.
PBKDF2を使用する場合は、の「アルゴリズム」属性<xenc11：KeyDerivationMethod>要素は、URI「http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2」に設定しなければなりません。 <xenc11：KeyDerivationMethod>要素は、そのような塩や反復回数などPBKDF2パラメータを、示すために、<PBKDF2-のparams>子要素を含まなければなりません。
When the encryption method uses a CBC mode that uses an explicit initialization vector (IV) other than a derived one, the IV MUST be passed by prepending it to the encrypted value.
暗号化方式が由来以外の明示的な初期化ベクトル（IV）を使用してCBCモードを使用する場合、IVが暗号化された値にそれを付加することによって通過しなければなりません。
In the example below, the following data is used.
以下の例では、以下のデータが使用されます。
Password: qwerty
パスワード：qwerty配列
Salt: 0x123eff3c4a72129c
塩：0x123eff3c4a72129c
Iteration Count: 1000
繰り返し数：1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
MACキー：0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
OTP Secret: 12345678901234567890
OTPシークレット：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=
<？xml version = "1.0" エンコード= "UTF-8"？> <pskc：KeyContainerののxmlns：pskc = "壷：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の＃ "バージョン= "1.0"> <pskc：EncryptionKey> <xenc11：DerivedKey> <xenc11：KeyDerivationMethodアルゴリズム=" http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs -5v2-0＃PBKDF2" > <PKCS5：PBKDF2-paramsは> <ソルト> <> Ej7 / PEpyEpw = </指定> </塩> <IterationCount、> 1000指定された</ IterationCount> <KEYLENGTH> 16 </ KEYLENGTH> < PRF /> </ PKCS5：PBKDF2-のparams> </ xenc11：KeyDerivationMethod> <また、xenc：ReferenceList> <また、xenc：DataReference URI = "＃ED" /> </また、xenc：ReferenceList> <xenc11：MasterKeyName>マイパスワード1 </ xenc11：MasterKeyName> </ xenc11：DerivedKey> </ pskc：EncryptionKey> <pskc：MACMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"> <pskc：マッキー> <また、xenc：はEncryptionMethodアルゴリズム= "http://www.w3.org/2001/04/xmlenc#aes128-cbc" /> <また、xenc：CipherData> <また、xenc：CipherValue> 2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx </また、xenc：CipherValue> </また、xenc：CipherData> </ pskc：マッキー> </ pskc：MACMethod> <pskc：KeyPackage> <pskc：DEVICEINFO> <pskc：メーカー> TokenVendorAcme </ pskc。メーカー> <pskc：のSerialNo> 987654321 </ pskc：のSerialNo> </ pskc：DEVICEINFO> <pskc：CryptoModuleInfo> <pskc：ID> CM_ID_001 </ pskc：ID> </ pskc：CryptoModuleInfo> <pskc：鍵アルゴリズム=
"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>
"URN：IETF：paramsは：XML：NS：keyprov：pskc：HOTP" ID = "123456"> <pskc：発行者>実施例-発行</ pskc：発行者> <pskc：ない、AlgorithmParameters> <pskc：ResponseFormat長= "8 "エンコーディング=" DECIMAL "/> </ pskc：ない、AlgorithmParameters> <pskc：データ> <pskc：シークレット> <pskc：EncryptedValue ID =" ED "> <また、xenc：はEncryptionMethodアルゴリズム=" 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：シークレット> </ pskc：データ> </ pskc：キー> </ pskc：KeyPackage> </ pskc：KeyContainer>
Figure 7: Example of a PSKC Document Using Encryption Based on
Passphrase-Based Keys
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'.
<データ>要素の子要素を暗号化するために非対称鍵を使用する場合、使用されている証明書に関する情報は、<EncryptionKey>要素の子要素である<X509Data>要素に記載しなければなりません。暗号化アルゴリズムは、<はEncryptionMethod>要素の「アルゴリズム」属性で示されなければなりません。図8に示す例では、アルゴリズムは、「http://www.w3.org/2001/04/xmlenc#rsa_1_5」に設定されています。
<?xml version="1.0" encoding="UTF-8" ?> <KeyContainer xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" id="KC0001" Version="1.0"> <EncryptionKey> <ds:X509Data>
<？xmlのバージョンは、= "1.0" エンコード= "UTF-8"？> <KeyContainerはのxmlns：DS = "http://www.w3.org/2000/09/xmldsig#" のxmlns = "壷：IETF：のparams： XML：NS：keyprov：pskc」のxmlns：また、xenc = "http://www.w3.org/2001/04/xmlenc#" ID = "KC0001" バージョン= "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>
<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> <メーカー> TokenVendorAcme </メーカー> <のSerialNo> 987654321 </のSerialNo> </ DEVICEINFO> <キーID = "MBK000000001" アルゴリズム= "壷：IETF：のparams： XML：NS：keyprov：pskc：HOTP "> <発行者>例 - 発行</発行者> <ない、AlgorithmParameters> <ResponseForm長さで= "6" エンコード= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <シークレット> <EncryptedValue> <また、xenc：はEncryptionMethodアルゴリズム= "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> </シークレット> <カウンタ> <PlainValue> 0 </ PlainValue> </カウンタ> </データ> </キー> </ KeyPackage> </ KeyContainer>
Figure 8: Example of a PSKC Document Using Encryption Based on Asymmetric Keys
図8：非対称キーに基づいて暗号化を使用しPSKC文書の例
For systems implementing PSKC, it is RECOMMENDED to implement the RSA-1.5 algorithm, identified by the URI 'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
PSKCを実装するシステムのためには、URI「http://www.w3.org/2001/04/xmlenc#rsa-1_5」によって識別されるRSA-1.5アルゴリズムを実装することをお勧めします。
Some of the asymmetric encryption algorithms that can optionally be implemented are:
必要に応じて実装することができ、非対称暗号化アルゴリズムのいくつかは以下のとおりです。
Algorithm | Uniform Resource Locator (URL)
------------------+-------------------------------------------------
RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
Padding of encrypted values (for example, the key secret value) is required when key protection algorithms are used that do not support embedded padding and the value to be encrypted is not a multiple of the encryption algorithm cipher block length.
（例えば、秘密鍵の値）暗号化された値のパディング鍵保護アルゴリズムが使用されるときに必要とされる埋め込みパディングをサポートしていないので、暗号化される値は、暗号化アルゴリズムの暗号ブロック長の倍数ではないん。
For example, when transmitting an HOTP key (20 bytes long) protected with the AES algorithm in CBC mode (8-byte block cipher), padding is required since its length is not a multiple of the 8-byte block length.
CBCモードのAESアルゴリズム（8バイトのブロック暗号）で保護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].
【PKCS5]に記載されているようにこれらのケースでは、PSKCを実現するシステムのためには、PKCS＃5のパディングを使用して値を暗号化する前に、パッドが推奨されます。
PSKC allows a digital signature to be added to the XML document, as a child element of the <KeyContainer> element. The description of the XML digital signature can be found in [XMLDSIG].
PSKCは、デジタル署名が<KeyContainer>要素の子要素として、XML文書に追加されることを可能にします。 XMLデジタル署名の説明は、[XMLDSIG]に見出すことができます。
<?xml version="1.0" encoding="UTF-8"?> <KeyContainer xmlns="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0"> <KeyPackage> <DeviceInfo> <Manufacturer>TokenVendorAcme</Manufacturer> <SerialNo>0755225266</SerialNo> </DeviceInfo> <Key Id="123" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <Issuer>Example-Issuer</Issuer> <AlgorithmParameters>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerのxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskc" のxmlns：DS = "http://www.w3.org / 2000/09 / XMLDSIG＃」のxmlns：また、xenc = "http://www.w3.org/2001/04/xmlenc#" バージョン= "1.0"> <KeyPackage> <DEVICEINFO> <メーカー> TokenVendorAcme </メーカー> <のSerialNo> 0755225266 </のSerialNo> </ DEVICEINFO> <キーID = "123" アルゴリズム= "URN：IETF：paramsは：XML：NS：keyprov：pskc：HOTP"> <発行>実施例-発行</発行者> <ない、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>
<ResponseFormat長= "6" エンコード= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <シークレット> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA = </ PlainValue> </シークレット> <カウンタ> <PlainValue> 0 </ PlainValue> </カウンター> </データ> </キー> </ KeyPackage> <署名> <DS：のSignedInfo> <DS：CanonicalizationMethodにアルゴリズム= "http://www.w3.org/2001/10/xml-exc-c14n#" /> <DS：のSignatureMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <DS：参考URI = "＃デバイス"> <DS：DigestMethodアルゴリズム= "HTTP ：//www.w3.org/2000/09/xmldsig#sha1" /> <DS：DigestValue> j6lwx3rvEPO0vKtMup4NbeVu8nk = </ DS：DigestValue> </ DS：リファレンス> </ 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> </署名> </ 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>
<？xml version = "1.0" エンコード= "UTF-8"？> <KeyContainerバージョン= "1.0" のxmlns = "壷：IETF：のparams：XML：NS：keyprov：pskcは"> <KeyPackage> <DEVICEINFO> <メーカー> TokenVendorAcme </メーカー> <のSerialNo> 654321 </のSerialNo> </ DEVICEINFO> <キーID = "1" アルゴリズム= "壷：IETF：のparams：XML：NS：keyprov：pskc：HOTP"> <発行>発行< /発行者> <ない、AlgorithmParameters> <ResponseFormat長= "8" エンコーディング= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <シークレット> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA = </ PlainValue> </シークレット> <カウンタ> <PlainValue> 0 </ PlainValue> </カウンタ> </データ> <ポリシー> <開始日> 2006-05-01T00：00：00Z </開始日> <ExpiryDate> 2006-05-31T00：00：00Z </ ExpiryDate> </ポリシー> </キー> </ 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>
<ポリシー> <開始日> 2006-03-01T00：00：00Z </開始日> <ExpiryDate> 2006-03-31T00：00：00Z </ ExpiryDate> </ポリシー> </キー> </ KeyPackage> <KeyPackage> <DEVICEINFO> <メーカー> TokenVendorAcme </製造> <のSerialNo> 9999999 </のSerialNo> </ DEVICEINFO> <キーID = "4" アルゴリズム= "URN：IETF：paramsは：XML：NS：keyprov：pskc：HOTP"> <発行>発行</発行者> <ない、AlgorithmParameters> <ResponseFormat長= "8" エンコーディング= "DECIMAL" /> </ない、AlgorithmParameters> <データ> <シークレット> <PlainValue> MTIzNDU2Nzg5MDEyMzQ1Njc4OTA = </ PlainValue> </シークレット> <カウンター> <PlainValue> 0 </ PlainValue> </カウンタ> </データ> <ポリシー> <開始日> 2006-04-01T00：00：00Z </開始日> <ExpiryDate> 2006-04-30T00：00：00Z </ ExpiryDate> </ポリシー> </キー> </ KeyPackage> </ KeyContainer>
Figure 10: Bulk Provisioning Example
図10：バルクプロビジョニング例
This section lists a few common extension points provided by PSKC:
このセクションでは、PSKCが提供するいくつかの一般的な拡張ポイントを示しています。
New PSKC Version: Whenever it is necessary to define a new version of this document, a new version number has to be allocated to refer to the new specification. The version number is carried inside the 'Version' attribute, as described in Section 4, the numbering scheme MUST follow Section 1.2, and rules for extensibility are defined in Section 12.
新PSKCバージョン：それは、このドキュメントの新しいバージョンを定義する必要があるたびに、新しいバージョン番号は、新しい仕様を参照するために割り当てられることがあります。バージョン番号は、セクション4で説明したように、ナンバリングスキームは、セクション1.2に従わなければならない、および拡張のためのルールはセクション12で定義され、「バージョン」属性の内部に搬送されます。
New XML Elements: The usage of the XML schema and the available extension points allows new XML elements to be added. Depending on the type of XML element, different ways for extensibility are offered. In some places, the <Extensions> element can be used and elsewhere the "<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>" XML extension point is utilized.
新しいXML要素：XMLスキーマの使用方法と使用可能な拡張ポイントの新しいXML要素を追加することができます。 XML要素の種類に応じて、拡張のためのさまざまな方法が提供されています。いくつかの場所で、<拡張>要素を使用することができ、他の場所で「<XS：任意の名前空間=」##その他「のprocessContents = 『緩い』のminOccurs = 『0』のmaxOccurs = 『無制限』 />」のXML拡張ポイントが利用されます。
New XML Attributes: The XML schema allows new XML attributes to be added where XML extension points have been defined (see "<xs: anyAttribute namespace="##other"/>" in Section 11).
新しいXML属性：XMLスキーマは、新しいXMLは、XMLの拡張ポイントが定義されている場所を追加することができます属性（参照「<XS：anyAttributeは名前空間=」##他の「/>」第11節で）。
New PSKC Algorithm Profiles: This document defines two PSKC algorithm profiles, see Section 10. The following informational document describes additional profiles [PSKC-ALGORITHM-PROFILES]. Further PSKC algorithm profiles can be registered as described in Section 12.4.
新PSKCアルゴリズムプロファイル：この文書は、2つのPSKCアルゴリズムプロファイルを定義し、節参照10.以下の情報のドキュメントには、追加のプロファイル[PSKCアルゴリズム-プロファイル]について説明します。 12.4項で説明したようにさらに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節では、キーに取り付けられ、キーイング関連データできるポリシーを定義します。 <ポリシー>要素は、実装者は、「のみOTP使用」などの特定の機能へのキーの使用を制限することを可能にするそのような項目です。項12に記載のようにさらに値が登録されていてもよいです。
Common Name: HOTP
共通名：HOTP
Class: OTP
クラス：OTP
URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp
URI：URN：IETF：のparams：XML：NS：keyprov：pskc：HOTP
Algorithm Definition: [HOTP]
アルゴリズムの定義：[HOTP]
Identifier Definition: (this RFC)
識別子定義：（このRFC）
Registrant Contact: IESG
登録者連絡先：IESG
Deprecated: FALSE
非推奨：FALSE
Profiling:
プロファイリング：
The <KeyPackage> element MUST be present and the
<ResponseFormat> element, which is a child element of the
<AlgorithmParameters> element, MUST be used to indicate the OTP
length and the value format.
The <Counter> element (see Section 4.1) MUST be provided as metadata for the key.
<カウンタ>要素（セクション4.1を参照）は、キーのためのメタデータとして提供されなければなりません。
The following additional constraints apply:
以下の追加の制約が適用されます。
+ The value of the <Secret> element MUST contain key material with a length of at least 16 octets (128 bits), if it is present.
+が存在する場合、<シークレット>要素の値は、少なくとも16個のオクテット（128ビット）の長さを有する鍵材料を含まなければなりません。
+ The <ResponseFormat> element MUST have the 'Format' attribute set to "DECIMAL", and the 'Length' attribute MUST indicate a length value between 6 and 9 (inclusive).
+ <ResponseFormat>要素は、「DECIMAL」に設定「形式」属性を持たなければならない、と「長さ」属性は、6,9（両端を含む）の間の長さの値を指定する必要があります。
+ The <PINPolicy> element MAY be present, but the 'PINUsageMode' attribute cannot be set to "Algorithmic".
+ <PINPolicy>要素が存在しているかもしれなくて、しかし「PINUsageMode」属性は、「アルゴリズム」に設定することはできません。
An example can be found in Figure 3.
例を図3に見出すことができます。
Common Name: PIN
共通名：PIN
Class: Symmetric static credential comparison
クラス：対称静的資格の比較
URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
URI：URN：IETF：のparams：XML：NS：keyprov：pskc：ピン
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.
The <Secret> element (see Section 4.1) MUST be provided.
<シークレット>要素（セクション4.1を参照）が提供されなければなりません。
See the example in Figure 5
図5の例を参照してください
This section defines the XML schema for PSKC.
このセクションでは、PSKCのためのXMLスキーマを定義します。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation= "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ xmldsig-core-schema.xsd"/> <xs:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation= "http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace"/> <xs:complexType name="KeyContainerType"> <xs:sequence> <xs:element name="EncryptionKey" type="ds:KeyInfoType" minOccurs="0"/> <xs:element name="MACMethod" type="pskc:MACMethodType" minOccurs="0"/> <xs:element name="KeyPackage" type="pskc:KeyPackageType" maxOccurs="unbounded"/> <xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/> <xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Version" type="pskc:VersionType" use="required"/> <xs:attribute name="Id" type="xs:ID" use="optional"/> </xs:complexType> <xs:simpleType name="VersionType" final="restriction"> <xs:restriction base="xs:string"> <xs:pattern value="\d{1,2}\.\d{1,3}"/> </xs:restriction>
<XS <xmlのバージョン= "1.0" エンコード= "UTF-8"？>：スキーマのxmlns：XS = "http://www.w3.org/2001/XMLSchema" のxmlns：pskc = "壷：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 = "壷：IETF：のparams：XML：NS：keyprov：pskc" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS：インポートの名前空間=" http://www.w3.org/2000/ 09 / XMLDSIG＃ "のschemaLocation = "http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ XMLDSIG-コアschema.xsd"/> <XS：インポート名前空間=" のhttp：/ /www.w3.org/2001/04/xmlenc#」のschemaLocation = "http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd" /> <XS：インポート名前空間= "http://www.w3.org/XML/1998/namespace" /> <XS：complexTypeの名前= "KeyContainerType"> <XS：シーケンス> <XS：要素名= "EncryptionKey" タイプ=「DS ：KeyInfoType」のminOccurs = "0" /> <XS：要素名= "MACMethod" タイプ= "pskc：MACMethodType" のminOccurs = "0" /> <XS：要素名= "KeyPackage" タイプ= "pskc：KeyPackageType" のmaxOccurs = "無制限" /> <XS：要素名= "署名" タイプ= "DS：SignatureType" のminOccurs = "0" /> <XS：要素名= "拡張" タイプ= "pskc：ExtensionsType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "バージョン" タイプ= "pskc：VersionType" 使用= "必要" /> <XS：属性名= "ID" タイプ= "XS：ID" 使用= "オプション" /> </ XS：complexTypeの> <XS：単純型名= "VersionType" 最終= "制限"> <XS：制限ベース= "XS：文字列"> <XS：パターン値= "\ dの{1,2} \ \。 D {1,3} "/> </ XS：制限>
</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：要素名= "秘密" タイプ= "pskc：binaryDataType" のminOccurs = "0" /> <XS：要素名= "カウンター" タイプ= "pskc：longDataType" のminOccurs = "0" /> <XS：要素名前= "時間" タイプ= "pskc：intDataType" のminOccurs = "0" /> <XS：要素名= "時間間隔" タイプ= "pskc：intDataType" のminOccurs = "0" /> <XS：要素名= "TimeDrift "TYPE =" pskc：intDataType」のminOccurs = "0" /> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> < / XS：complexTypeの> <XS：complexTypeの名前= "binaryDataType"> <XS：シーケンス> <XS：選択> <XS：要素名= "PlainValue" タイプ= "XS：base64Binaryの" /> <XS：要素名=」 EncryptedValue」タイプ= "また、xenc：EncryptedDataType" /> </ XS：選択> <XS：要素名= "ValueMAC" タイプ= "XS：base64Binaryの" minOccurs属性= "0" /> </ XS：シーケンス> </ XS： complexTypeの> <XS：complexTypeの名前= "intDataType"> <XS：シーケンス> <XS：選択> <XS：要素名= "PlainValue" タイプ= "XS：int型" /> <XS：要素名= "EncryptedValue" タイプ= "また、xenc：EncryptedDataType" /> </ XS：選択> <XS：要素名= "ValueMAC" タイプ= "XS：base64Binaryの" minOccurs = "0" /> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名前= "stringDataType"> <XS：シーケンス> <XS：選択> <XS：要素名= "PlainValue" タイプ= "XS：文字列" /> <XS：要素名= "EncryptedValue" タイプ= "また、xenc：EncryptedDataType" /> </ XS：選択> <XS：要素名= "ValueMAC" タイプ= "XS：base64Binaryの" のminOccurs =」 0" /> </ XS：シーケンス>
</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：complexTypeの> <XS：complexTypeの名前= "longDataType"> <XS：シーケンス> <XS：選択> <XS：要素名= "PlainValue" タイプ= "XS：長い" /> <XS：要素名= "EncryptedValue" タイプ= "また、xenc：EncryptedDataType" /> </ XS：選択> <XS：要素名= "ValueMAC" タイプ= "XS：base64Binaryの" minOccurs属性= "0" /> </ XS：シーケンス> </ XS ：complexTypeの> <XS：complexTypeの名前= "PINPolicyType"> <XS：属性名= "PINKeyId" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "PINUsageMode" タイプ= "pskc： PINUsageModeType "/> <XS：属性名=" MaxFailedAttempts」タイプ= "XS：unsignedInt型" 使用= "オプション" /> <XS：属性名= "MINLENGTH" タイプ= "XS：unsignedInt型" 使用= "オプション" /> <XS：属性名= "のMaxLength" タイプ= "XS：unsignedInt型" 使用= "オプション" /> <XS：属性名= "PINEncoding" タイプ= "pskc：ValueFormatType" 使用= "オプション" /> <XS：anyAttributeを名前空間= "##他の" /> </ XS：complexTypeの> <XS：単純型名= "PINUsageModeType"> <XS：制限ベース= "XS：文字列"> <XS：列挙値/> <= "ローカル" XS ：列挙値= "先頭に追加" /> <XS：列挙値= "追加" /> <XS：列挙値= "アルゴリズム" /> </ XS：制限> </ XS：単純> <XS：単純型名= "KeyUsageType"> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "OTP" /> <XS：列挙値= "CR" /> <XS：列挙値= "暗号化" /> <XS：列挙値= "整合" /> <XS：列挙値= "確認" /> <XS：列挙値= "ロック解除" /> <XS：列挙値= "復号化" /> <XS：列挙値= "KeyWrap" /> <XS：列挙値= "アンラップ" /> <XS：列挙値= "派生" /> <XS：列挙値= "生成" />
</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：制限> </ XS：単純> <XS：complexTypeの名前= "DeviceInfoType"> <XS：配列> <XS：要素名= "メーカー" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "のSerialNo" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "モデル" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名前= "IssueNo" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "DeviceBinding" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "開始日"TYPE =" XS：dateTimeの "minOccurs属性= "0"/> <XS：要素名= "ExpiryDate" タイプ= "XS：dateTimeの" minOccurs属性= "0"/> <XS：要素名= "ユーザーID" タイプ=" XS：文字列」のminOccurs = "0" /> <XS：要素名= "拡張機能" タイプ= "pskc：ExtensionsType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名前= "CryptoModuleInfoType"> <XS：シーケンス> <XS：要素名= "ID" タイプ= "XS：文字列" /> <XS：要素名= "拡張機能" タイプ= "pskc：ExtensionsType" minOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名= "KeyPackageType"> <XS：シーケンス> <XS：E lement名= "DEVICEINFO" タイプ= "pskc：DeviceInfoType" のminOccurs = "0" /> <XS：要素名= "CryptoModuleInfo" タイプ= "pskc：CryptoModuleInfoType" のminOccurs = "0" /> <XS：要素名=」キー」タイプ= "pskc：ます。KeyType" のminOccurs = "0" /> <XS：要素名= "拡張機能" タイプ= "pskc：ExtensionsType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名= "AlgorithmParametersType"> <XS：選択>
<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：要素名= "スイート" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "ChallengeFormat" のminOccurs = "0"> <XS：complexTypeの> <XS：属性名=」エンコーディング」タイプ= "pskc：ValueFormatType" 使用= "必要" /> <XS：属性名= "分" タイプ= "XS：unsignedInt型" 使用= "必要" /> <XS：属性名= "マックス" タイプ= "XS：unsignedInt型" 使用= "必須" /> <XS：属性名= "CheckDigits" タイプ= "XS：ブール" デフォルト= "偽" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "ResponseFormat" のminOccurs = "0"> <XS：complexTypeの> <XS：属性名= "エンコード" タイプ= "pskc：ValueFormatType" 使用= "必要" /> <XS：属性名= "長さ" タイプ= "XS：unsignedInt型" 使用= "必須" /> <XS：属性名= "CheckDigits" タイプ= "XS：ブール" デフォルト= "偽" /> </ XS：complexTypeの> </ XS：要素> <XS ：要素名= "拡張機能" タイプ= "pskc：ExtensionsType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：選択> </ XS：complexTypeの> <XS：complexTypeの名= "ExtensionsType"> <XS ：シーケンス> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のmaxOccurs = "無制限" /> </ XS：SEQUレンス> <XS：属性名= "定義" タイプ= "XS：anyURIの" 使用= "オプション" /> </ XS：complexTypeの> <XS：単純型名= "KeyAlgorithmType"> <XS：制限ベース= "XS： anyURIの "/> </ XS：単純> <XS：simpleTypeの名前=" ValueFormatType "> <XS：制限ベース=" XS：文字列 "> <XS：列挙値=" DECIMAL "/> <XS：列挙値=" HEXADECIMAL "/> <XS：列挙値=" ALPHANUMERIC "/> <XS：列挙値=" BASE64 "/> <XS：列挙値=" 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>
</ XS：制限> </ XS：単純> <XS：complexTypeの名前= "MACMethodType"> <XS：シーケンス> <XS：選択> <XS：要素名= "マッキー" タイプ= "また、xenc：EncryptedDataType" のminOccurs = "0" /> <XS：要素名= "MACKeyReference" タイプ= "XS：文字列" のminOccurs = "0" /> </ XS：選択> <XS：任意の名前空間= "##他" のprocessContents = "緩いです" minOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "アルゴリズム" タイプ= "XS：anyURIの" 使用= "必須" /> </ XS：complexTypeの> <XS：要素名= "KeyContainer" タイプ= "pskc：KeyContainerType" /> </ XS：スキーマ>
This specification contains the registration of a new media type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].
この仕様は、RFC 3023 [RFC3023]にRFC 4288 [RFC4288]の手順およびガイドラインに従って新しいメディアタイプの登録を含んでいます。
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
オプションのパラメータ：文字セット
Indicates the character encoding of enclosed XML.
囲まれたXMLの文字エンコーディングを示します。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2.
エンコードの考慮事項：使用される文字エンコーディングに応じて、8ビット文字を採用することができるXMLを使用しています。 RFC 3023 [RFC3023]、セクション3.2を参照してください。
Security considerations: Please refer to Section 13 of RFC 6030.
セキュリティの考慮事項：RFC 6030のセクション13を参照してください。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 6030.
公開された仕様：RFC 6030。
Applications which use this media type: This media type is being used as a symmetric key container format for transport and provisioning of symmetric keys (One-Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. As such, it is used for key provisioning systems.
このメディアタイプを使用するアプリケーション：このメディアタイプは、強力な認証デバイスの異なるタイプの対称鍵（ワンタイムパスワード（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
詳細のために連絡する個人や電子メールアドレス：フィリップ・ホイヤー、Philip.Hoyer@actividentity.com
Intended usage: LIMITED USE
意図している用法：限定使用
Restrictions on usage: None
使用に関する制限：なし
Author: This specification is a work item of the IETF KEYPROV working group, with mailing list address <keyprov@ietf.org>.
著者：この仕様は、メーリングリストのアドレスで、IETF KEYPROVワーキンググループの作業項目である<keyprov@ietf.org>。
Change controller: The IESG <iesg@ietf.org>
変更コントローラ：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
URI：URN：IETF：のparams：XML：スキーマ：keyprov：pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com).
登録者連絡先：IETF KEYPROVワーキンググループ、フィリップ・ホイヤー（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"?>
<？xml version = "1.0" エンコード= "UTF-8"？>
and its last line is
そしてその最後の行があります
</xs:schema>
</ XS：スキーマ>
This section registers a new XML namespace, "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in [RFC3688].
[RFC3688]のガイドラインにつき、 "pskc：IETF：のparams：XML：NS：keyprov壷" このセクションでは、新しいXML名前空間を、登録します。
URI: 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).
登録者連絡先：IETF KEYPROVワーキンググループ、フィリップ・ホイヤー（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
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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル> pSKC名前空間</ TITLE> </ HEAD> <BODY> <H1> pSKCのための名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：keyprov：pskc </ H2は> <P> <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.
クラス：PSKCアルゴリズムプロファイルレジストリエントリの種類は、暗号化など、作成されて、メッセージ認証コード（MAC）、ワンタイムパスワード（OTP）、ダイジェスト。
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.
非推奨：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のこの特定のプロファイルで（またはしない）が使用されています。
PSKC algorithm profile identifier registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
PSKCアルゴリズムプロファイル識別子の登録は、RFC 5226 [RFC5226]に従って仕様が必要に対象としています。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
IANA has added two initial values to the registry based on the algorithm profiles described in Section 10.
IANAはセクション10で説明されたアルゴリズムプロファイルに基づいて、レジストリに2つの初期値を追加しました。
IANA has created a registry for PSKC version numbers. The registry has the following structure:
IANAはPSKCバージョン番号のレジストリを作成しました。レジストリは、以下の構造を有します：
PSKC Version | Specification
+---------------------------+----------------
| 1.0 | RFC 6030
Standards action is required to define new versions of PSKC. It is not envisioned to deprecate, delete, or modify existing PSKC versions.
標準アクションはPSKCの新しいバージョンを定義するために必要とされます。廃止、削除、または既存のPSKCのバージョンを変更することが想定されていません。
IANA has created a registry for key usage. A description of the <KeyUsage> element can be found in Section 5.
IANAは、キーの使用のためにレジストリを作成しました。 <のKeyUsage>要素の説明は、第5節に見出すことができます。
As part of this registry IANA will maintain the following information:
このレジストリの一部として、IANAは、以下の情報を維持します。
Key Usage: The identifier of the Key Usage.
キー使用法：キー使用法の識別子。
Specification: IANA will add a pointer to the specification containing information about the semantics of a new Key Usage registration.
仕様：IANAは新しいキー使用登録の意味論に関する情報を含む仕様へのポインタを追加します。
Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE.
非推奨：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.
キー使用法レジストリの登録は、RFC 5226 [RFC5226]あたりとして仕様が必要に受けることがあります。専門家レビューは、新しいキー使用法値を定義する必要があります。アップデートは、専門家の承認に基づいて提供することができます。専門家の承認に基づいて、「非推奨」としてエントリをマークすることが可能です。指定された専門家はIESGによって任命されます。
The portable symmetric key container (PSKC) carries sensitive information (e.g., cryptographic keys) and may be transported across the boundaries of one secure perimeter to another. For example, a container residing within the secure perimeter of a back-end provisioning server in a secure room may be transported across the Internet to an end-user device attached to a personal computer. This means that special care MUST be taken to ensure the confidentiality, integrity, and authenticity of the information contained within.
ポータブル対称鍵コンテナ（PSKC）は、機密情報（例えば、暗号鍵）を保持し、別の安全な境界の境界を越えて輸送することができます。例えば、安全な部屋で、バックエンド・プロビジョニング・サーバーの安全な境界内にあるコンテナは、パーソナルコンピュータに接続されているエンドユーザデバイスにインターネットを横切って輸送されてもよいです。これは、特別な注意が内に含まれる情報の機密性、完全性、および信頼性を確保するために取らなければならないことを意味しています。
By design, the container allows two main approaches to guaranteeing the confidentiality of the information it contains while transported.
設計により、コンテナが輸送しながら、それが含まれている情報の機密性を保証するには、2つの主要なアプローチを可能にします。
First, the container key data payload may be encrypted.
まず、コンテナの鍵データペイロードは暗号化されてもよいです。
In this case, no transport layer security is required. However, standard security best practices apply when selecting the strength of the cryptographic algorithm for key data payload encryption. A symmetric cryptographic cipher SHOULD be used -- the longer the cryptographic key, the stronger the protection. Please see Section 6.1 for recommendations of key data payload protection using symmetric cryptographic ciphers. In cases where the exchange of key encryption keys between the sender and the receiver is not possible, asymmetric encryption of the key data payload may be employed, see Section 6.3. Similar to symmetric key cryptography, the stronger the asymmetric key, the more secure the protection.
この場合、トランスポート層セキュリティは必要ありません。キーデータペイロードの暗号化のための暗号アルゴリズムの強度を選択するときただし、標準的なセキュリティのベストプラクティスが適用されます。長い暗号鍵、強力な保護を - 対称暗号の暗号を使用する必要があります。対称暗号の暗号を使用して、キーデータペイロード保護の推奨事項については、セクション6.1を参照してください。送信側と受信側との間の鍵暗号鍵の交換が不可能な場合には、鍵データペイロードの非対称暗号化は、セクション6.3を参照して、使用することができます。対称鍵暗号方式と同様に、強い非対称鍵は、より多くの保護を確保します。
If the key data payload is encrypted with a method that uses one of the password-based encryption methods (PBE methods) detailed in Section 6.2, the key data payload may be subjected to password dictionary attacks to break the encryption password and recover the information. Standard security best practices for selection of strong encryption passwords apply.
キーデータペイロードは6.2節で詳述パスワードベースの暗号化方式（PBE法）のいずれかを使用する方法で暗号化されている場合は、キーデータペイロードは、暗号化パスワードを破ると情報を回復するために、パスワードの辞書攻撃を受けてもよいです。強力な暗号化パスワードの選択のための標準的なセキュリティのベストプラクティスが適用されます。
Additionally, it is strongly RECOMMENDED that practical implementations use PBESalt and PBEIterationCount when PBE encryption is used. A different PBESalt value per PSKC SHOULD be used for best protection.
さらに、強くPBE暗号化を使用する場合の実用的な実装がPBESaltとPBEIterationCountを使用することをお勧めします。 PSKCごとに異なるPBESalt値は、最高の保護のために使用されるべきです。
The second approach to protecting the confidentiality of the key data is based on using lower-layer security mechanisms (e.g., [TLS], [IPsec]). The secure connection established between the source secure perimeter (the provisioning server from the example above) and the target perimeter (the device attached to the end-user computer) utilizes encryption to protect the messages that travel across that connection. No key data payload encryption is required in this mode. Secure connections that encrypt and digest each message provide an extra measure of security.
キーデータの機密性を保護する第二のアプローチは、下位層のセキュリティメカニズムの使用に基づいている（例えば、[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のみトランスポート層セキュリティで保護されているという事実のため、実用的な実装は、man-in-the-middle攻撃に対する保護を確実にしなければなりません。セキュリティで保護されたチャネルのエンドポイントを認証するPSKCの機密性を損なう可能性がある侵入者を排除するために非常に重要です。
The PSKC provides means to guarantee the integrity of the information it contains through the use of digital signatures. It is RECOMMENDED that for best security practices, the digital signature of the container encompasses the entire PSKC. This provides assurances for the integrity of all attributes. It also allows verification of the integrity of a given PSKC even after the container is delivered through the communication channel to the target perimeter and channel message integrity check is no longer possible.
PSKCは、デジタル署名を使用して含まれている情報の完全性を保証する手段を提供します。セキュリティのベストプラクティスのために、コンテナのデジタル署名が全体PSKCを包含することが推奨されます。これは、すべての属性の整合性のための保証を提供します。コンテナは、ターゲット周囲とチャネルメッセージ整合性チェックの通信チャネルを介して配信された後であってもまたはもはや不可能である所与PSKCの完全性の検証を可能にします。
The digital signature of the PSKC is the primary way of showing its authenticity. The recipient of the container SHOULD use the public key associated with the signature to assert the authenticity of the sender by tracing it back to a pre-loaded public key or certificate. Note that the digital signature of the PSKC can be checked even after the container has been delivered through the secure channel of communication.
PSKCのデジタル署名は、その信憑性を示すの主な方法です。コンテナの受取人は、事前ロードされた公開鍵または証明書にそれをバックトレースすることにより、送信者の正当性を主張する署名に関連付けられた公開鍵を使用すべきです。容器は、通信の安全なチャネルを介して配信された後も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.
私たちは、この文書への彼のテキストの貢献のためのハンネス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.
アポストルVassilev、Shuhチャン、ジョン・マーティン、Siddhartバジャジ、ステューVaeth、ケビン・ルイス、フィリップ・ハラム・ベイカー、アンドレア・ドハーティ、マグナスNystrom、ティム・モーゼス、アンダース・ラングレン：この文書の著者は、彼らのフィードバックのために、次の人に感謝したいと思います、ショーン・ターナー、特にロバート・フィルポット。
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.
私たちは、我々はまた、暗号化アルゴリズムの選択（AES-128-CBC対KW-AES-128）と彼の入力にに関する議論をトリガするためアンダース・ラングレンに感謝したいと思います2009年1月に彼のレビューのためにショーン・ターナーに感謝したいと思いますキー付きメッセージに対して計算をダイジェスト。
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（オープン認証のためのイニシアティブ）のメンバーによって以前の仕事に基づいており、自由に技術的なコミュニティに配布することができる形式を指定するには、[OATH]を参照してください。
[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced Encryption Standard (AES)", November 2001.
[FIPS197]国立標準研究所、 "FIPSパブ197：高度暗号化標準（AES）"、2001年11月。
[HOTP] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
【HOTP] M'Raihi、D.、ベラー、M.、Hoornaert、F.、Naccache、D.、およびO. Ranen、 "HOTP：HMACベースのワンタイムパスワードアルゴリズム"、RFC 4226、2005年12月。
[IANAPENREG] IANA, "Private Enterprise Numbers", <http://www.iana.org>.
[IANAPENREG] IANA、 "民間企業番号"、<http://www.iana.org>。
[ISOIEC7812] ISO, "ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system", October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812] ISO、 "ISO / IEC 7812から1：2006識別カード - 発行体の同定 - パート1：ナンバリングシステム"、2006年10月、<http://www.iso.org/iso/iso_catalogue/ catalogue_tc / catalogue_detail.htm？csnumber = 39698>。
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April 2009, <http://www.openauthentication.org/oath-id/prefixes/>.
[OATHMAN] OATH、 "OATHメーカープレフィックス（OMP）のリスト"、2009年4月、<http://www.openauthentication.org/oath-id/prefixes/>。
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography Standard", Version 2.0, March 1999, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS5] RSA Laboratories社、 "PKCS＃5：パスワードベースの暗号化規格"、バージョン2.0、1999年3月、<http://www.rsasecurity.com/rsalabs/pkcs/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"、RFC 4514、2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[RFC5649] Housley氏、R.とM. Dworkin、 "パディングアルゴリズムとのAdvanced Encryption Standard（AES）キーラップ"、RFC 5649、2009年9月。
[SP800-67] National Institute of Standards, "NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", NIST Special Publication 800-67, May 2008.
[SP800-67]国立標準研究所 "は、NIST Special Publication 800から67バージョン1.1：トリプルデータ暗号化アルゴリズム（TDEA）ブロック暗号のための勧告"、は、NIST Special Publication 800から67、2008年5月。
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2から20041028]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型第二版"、World Wide Web Consortium（W3C）の勧告REC-XMLSCHEMA-2から20041028、2004年10月、<のhttp： //www.w3.org/TR/2004/REC-xmlschema-2-20041028>。
[XMLDSIG] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[XMLDSIG]ソロ、D.、Reagle、J.、およびD.イーストレイク、 "XML-署名構文と処理"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XMLDSIGコア-20020212、2002年2月、<のhttp：// WWW。 w3.org/TR/2002/REC-xmldsig-core-20020212>。
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLENC]イーストレイク、D.、 "XML暗号化構文と処理。"、W3C勧告、2002年12月、<http://www.w3.org/TR/xmlenc-core/>。
[XMLENC11] Reagle, J. and D. Eastlake, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium WD WD-xmlenc-core1-20090730, July 2009, <http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>.
[XMLENC11] Reagle、J.とD.イーストレイク、 "XML暗号化構文と処理バージョン1.1"、ワールド・ワイド・ウェブ・コンソーシアムWD WD-xmlenc-core1-20090730、2009年7月、<http://www.w3.org/TR / 2009 / WD-xmlenc-core1-20090730>。
[CAP] MasterCard International, "Chip Authentication Program Functional Architecture", September 2004.
[CAP]マスターカード・インターナショナル、「チップ認証プログラム機能アーキテクチャ」、2004年9月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsecの]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "NIST Special Publication 800-57, Recommendation for Key Management Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[NIST800-57]バーカー、E.、バーカー、W.、バリ、W.、ポーク、W.、およびM. SMID、 "は、NIST Special Publication 800-57、キー管理パート1のための推奨事項：一般（改訂版）" 、は、NIST Special Publication 800-57、2007年3月。
[OATH] "Initiative for Open AuTHentication", <http://www.openauthentication.org>.
[OATH] "オープン認証のためのイニシアティブ"、<http://www.openauthentication.org>。
[PSKC-ALGORITHM-PROFILES] Hoyer, P., Pei, M., Machani, S., and A. Doherty, "Additional Portable Symmetric Key Container (PSKC) Algorithm Profiles", Work in Progress, May 2010.
[PSKCアルゴリズム-PROFILES]ホイヤー、P.、ペイ、M.、Machani、S.、およびA.ドハーティ、 "追加のポータブル対称キーのコンテナ（PSKC）アルゴリズムプロファイル"、進歩、2010年5月での作業。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[XMLNS]オランダ、D.、ブレイ、T.、およびA.素人、 "XMLで名前空間"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XML-名-19990114、1999年1月、<http://www.w3.org / TR / 1999 / REC-XML-名-19990114>。
Appendix A. Use Cases
付録A.ユースケース
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.
これらのユースケースは、実世界の状況にこの仕様の適用性を理解するのに役立ちます。
A.1. Online Use Cases
A.1。オンラインユースケース
This section describes the use cases related to provisioning the keys using an online provisioning protocol.
このセクションでは、オンライン・プロビジョニング・プロトコルを使用して、キーのプロビジョニングに関連するユースケースを説明します。
A.1.1. Transport of Keys from Server to Cryptographic Module
A.1.1。暗号モジュールへのサーバーから鍵の交通
For example, a mobile device user wants to obtain a symmetric key for use with a cryptographic module on the device. The cryptographic module from vendor A initiates the provisioning process against a provisioning system from vendor B using a standards-based provisioning protocol. The provisioning entity delivers one or more keys in a standard format that can be processed by the mobile device.
例えば、モバイルデバイスユーザは、デバイス上の暗号モジュールで使用するための対称鍵を取得したいです。ベンダーAの暗号モジュールは、標準ベースのプロビジョニングプロトコルを使用してベンダーBからプロビジョニングシステムに対するプロビジョニング・プロセスを開始します。プロビジョニング・エンティティは、モバイルデバイスが処理可能な標準形式で1つ以上のキーを配信します。
For example, in a variation of the above, instead of the user's mobile phone, a key is provisioned in the user's soft token application on a laptop using a network-based online protocol. As before, the provisioning system delivers a key in a standard format that can be processed by the soft token on the PC.
例えば、上記の変化はなく、ユーザの携帯電話では、キーは、ネットワークベースのオンラインプロトコルを使用して、ラップトップコンピュータ上のユーザのソフトトークンアプリケーションでプロビジョニングされます。前と同様に、プロビジョニングシステムは、PC上のソフトトークンによって処理することができ、標準形式でキーを提供します。
For example, the end user or the key issuer wants to update or configure an existing key in the cryptographic module and requests a replacement key container. The container may or may not include a new key and may include new or updated key attributes such as a new counter value in HOTP key case, a modified response format or length, a new friendly name, etc.
例えば、エンドユーザーやキー発行者は、暗号モジュール内の既存のキーを更新したり、設定したいと代替キーコンテナを要求します。容器は、または新しいキーを含んでも含まなくてもよいし、そのようなHOTPキー場合、修飾された応答フォーマットまたは長さ、新しいフレンドリ名などに新しいカウンタ値として、新規または更新されたキー属性を含んでいてもよいです
A.1.2. Transport of Keys from Cryptographic Module to Cryptographic Module
A.1.2。暗号モジュールの暗号モジュールからキーの交通
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.
たとえば、ユーザーが別の暗号モジュールから鍵を運ぶために望んでいます。 2つのがあり暗号モジュール、コンピュータ上の1と携帯電話のいずれかで、ユーザーが携帯電話にコンピュータからキーを輸送するために望んでいることがあります。ユーザは、他の暗号モジュールに入力するための標準形式でキーと関連するデータをエクスポートすることができます。
A.1.3. Transport of Keys from Cryptographic Module to Server
A.1.3。暗号モジュールからサーバへの鍵の交通
For example, a user wants to activate and use a new key and related data against a validation system that is not aware of this key. This key may be embedded in the cryptographic module (e.g., a Secure Digital (SD) card, USB drive) that the user has purchased at the local electronics retailer. Along with the cryptographic module, the user may get the key on a CD or a floppy in a standard format. The user can now upload via a secure online channel or import this key and related data into the new validation system and start using the key.
例えば、ユーザは、このキーを認識していない検証システムに対する新しいキーおよび関連データを有効にし、使用することを望んでいます。このキーは、ユーザーがローカルの電子機器小売店で購入したと暗号モジュール（例えば、セキュアデジタル（SD）カード、USBドライブ）に埋め込まれていてもよいです。暗号モジュールに加えて、ユーザーがCDまたは標準フォーマットのフロッピー上のキーを取得することがあります。ユーザーは、安全確実なオンラインチャネルを介してアップロードしたり、新たな検証システムにこのキーと関連データをインポートし、キーを使用して起動することができます。
A.1.4. Server-to-Server Bulk Import/Export of Keys
A.1.4。鍵のサーバ間の一括インポート/エクスポート
From time to time, a key management system may be required to import or export keys in bulk from one entity to another.
時々、鍵管理システムは、別のエンティティから一括で鍵をインポートまたはエクスポートするために必要とすることができます。
For example, instead of importing keys from a manufacturer using a file, a validation server may download the keys using an online protocol. The keys can be downloaded in a standard format that can be processed by a validation system.
たとえば、代わりにファイルを使用して、製造業者から鍵をインポートするの、検証サーバは、オンラインプロトコルを使用して、キーをダウンロードすることができます。キーは、検証システムによって処理することができ、標準形式でダウンロードすることができます。
For example, in a variation of the above, an Over-The-Air (OTA) key provisioning gateway that provisions keys to mobile phones may obtain key material from a key issuer using an online protocol. The keys are delivered in a standard format that can be processed by the key provisioning gateway and subsequently sent to the mobile phone of the end user.
例えば、携帯電話に規定キーはオンラインプロトコルを使用してキー発行者からの鍵材料を得ることができる、上記の変形例では、オーバーザ・エア（OTA）鍵プロビジョニングゲートウェイ。キーは、キープロビジョニングゲートウェイで処理し、続いて、エンドユーザの携帯電話に送信することができる標準的な形式で配信されています。
A.2. Offline Use Cases
A.2。オフラインのユースケース
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.
このセクションでは、輸出と輸入モデルのいくつかのフォームを使用して、一つのシステムから別のキーのオフライン輸送に関連するユースケースを説明します。
A.2.1. Server-to-Server Bulk Import/Export of Keys
A.2.1。鍵のサーバ間の一括インポート/エクスポート
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.
例えば、企業は、既存の検証システムは、OTP認証トークンのために、キーおよび関連データのエクスポート（例えば可能にする機能を有する企業を提供する異なる検証システムBへの既存の検証システムAからポートキーと関連するデータに望ん）標準フォーマットです。 OTPトークンは、標準的なフォーマットであるため、企業は新しい検証システムBにトークンレコードをインポートし、既存のトークンを使用して開始することができます。 2つの検証システムのためのベンダーが同じでも異なっていてもよいことに注意してください。
Appendix B. Requirements
付録B.要件
This section outlines the most relevant requirements that are the basis of this work. Several of the requirements were derived from use cases described above.
このセクションでは、この仕事の基本である最も関連性の高い要件の概要を説明します。要件のいくつかは、上述のユースケースに由来しました。
R1: The format MUST support the transport of multiple types of symmetric keys and related attributes for algorithms including HOTP, other OTP, Challenge/Response, etc.
R1：フォーマット等HOTP、他のOTP、チャレンジ/レスポンス、を含むアルゴリズムのための対称鍵および関連する属性の複数のタイプのトランスポートをサポートしなければなりません
R2: The format MUST handle the symmetric key itself as well of attributes that are typically associated with symmetric keys. Some of these attributes may be
R2は：フォーマットは、典型的には、対称鍵に関連付けられた対称鍵自体もの属性を処理する必要があります。これらの属性の一部であってもよいです
* Unique Key Identifier
*ユニークキー識別子
* Issuer information
*発行者情報
* Algorithm ID
*アルゴリズムID
* Algorithm mode
*アルゴリズムモード
* Issuer Name
*発行者名
* Key friendly name
*キーフレンドリ名
* Event counter value (moving factor for OTP algorithms)
*イベントカウンタ値（OTPアルゴリズムのための因子を動かします）
* Time value
* Time値
R3: The format SHOULD support both offline and online scenarios. That is, it should be serializable to a file as well as it should be possible to use this format in online provisioning protocols.
R3：フォーマットは、オフラインとオンラインの両方のシナリオをサポートする必要があります。つまり、オンライン・プロビジョニングプロトコルでこの形式を使用することができるはずであるとして、それは同様に、ファイルにシリアライズ可能でなければなりません、です。
R4: The format SHOULD allow bulk representation of symmetric keys.
R4：フォーマットは、対称キーの大部分の表現を可能にすべきです。
R5: The format SHOULD allow bulk representation of PINs related to specific keys.
R5：フォーマットは、特定のキーに関連する端子のバルク表現を可能にすべきです。
R6: The format SHOULD be portable to various platforms. Furthermore, it SHOULD be computationally efficient to process.
R6：フォーマットは、さまざまなプラットフォームに移植であるべきです。さらに、それはプロセスへの計算上効率的であるべきです。
R7: The format MUST provide an appropriate level of security in terms of data encryption and data integrity.
R7：フォーマットは、データの暗号化とデータの整合性の観点から適切なレベルのセキュリティを提供しなければなりません。
R8: For online scenarios, the format SHOULD NOT rely on transport layer security (e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS)) for core security requirements.
R8：オンラインシナリオでは、フォーマットはコアセキュリティ要件のためのトランスポート層セキュリティ（例えば、セキュアソケットレイヤ/トランスポート層セキュリティ（SSL / TLS））に依存すべきではありません。
R9: The format SHOULD be extensible. It SHOULD enable extension points allowing vendors to specify additional attributes in the future.
R9：フォーマットは拡張可能であるべきです。これは、ベンダーは、将来的に追加の属性を指定できるようにする拡張ポイントを有効にする必要があります。
R10: The format SHOULD allow for distribution of key derivation data without the actual symmetric key itself. This is to support symmetric key management schemes that rely on key derivation algorithms based on a pre-placed master key. The key derivation data typically consists of a reference to the key, rather than the key value itself.
R10：フォーマットは、実際の対称鍵自体せずに鍵導出データの配信を可能にすべきです。これは、事前に配置され、マスターキーに基づいてキー導出アルゴリズムに依存して、対称鍵管理スキームをサポートすることです。鍵導出データは、典型的には、鍵ではなく、キー値自体への参照から成ります。
R11: The format SHOULD allow for additional life cycle management operations such as counter resynchronization. Such processes require confidentiality between client and server, thus could use a common secure container format, without the transfer of key material.
R11：フォーマットは、このようなカウンタの再同期などの追加のライフサイクル管理操作を可能にすべきです。このようなプロセスは、このように重要な材料の移動せずに、共通の安全なコンテナフォーマットを使用することができ、クライアントとサーバ間の機密性を必要とします。
R12: The format MUST support the use of pre-shared symmetric keys to ensure confidentiality of sensitive data elements.
R12：フォーマットは、機密データ要素の機密性を確保するために事前共有対称鍵の使用をサポートしなければなりません。
R13: The format MUST support a password-based encryption (PBE) [PKCS5] scheme to ensure security of sensitive data elements. This is a widely used method for various provisioning scenarios.
R13：フォーマットは、機密データ要素のセキュリティを確保するために、パスワードベースの暗号化（PBE）PKCS5]方式をサポートしなければなりません。これは、様々なプロビジョニングシナリオのために広く用いられる方法です。
R14: The format SHOULD support asymmetric encryption algorithms such as RSA to ensure end-to-end security of sensitive data elements. This is to support scenarios where a pre-set shared key encryption key is difficult to use.
R14：フォーマットは、機密データ要素のエンドツーエンドのセキュリティを確保するために、RSAなどの非対称暗号化アルゴリズムをサポートしなければなりません。これは、事前に設定した共有鍵暗号鍵は使用することは困難であるシナリオをサポートすることです。
Authors' Addresses
著者のアドレス
Philip Hoyer ActivIdentity, Inc. 117 Waterloo Road London, SE1 8UL UK
フィリップ・ホイヤーActivIdentity社117ウォータールーRoadロンドン、SE1 8UL英国
Phone: +44 (0) 20 7960 0220 EMail: phoyer@actividentity.com
電話：+44（0）20 7960 0220 Eメール：phoyer@actividentity.com
Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Mingliangペイベリサイン社487 E.ミドルロード、マウンテンビュー、CA 94043 USA
Phone: +1 650 426 5173 EMail: mpei@verisign.com
電話：+1 650 426 5173 Eメール：mpei@verisign.com
Salah Machani Diversinet, Inc. 2225 Sheppard Avenue East Suite 1801 Toronto, Ontario M2J 5C2 Canada
サラMachani Diversinet株式会社2225シェパードアベニューイーストスイート1801トロント、オンタリオM2J 5C2カナダ
Phone: +1 416 756 2324 Ext. 321 EMail: smachani@diversinet.com
電話：+1 416 756 2324内線。 321 Eメール：smachani@diversinet.com