[要約] RFC 6063は、Dynamic Symmetric Key Provisioning Protocol（DSKPP）に関する規格です。DSKPPは、セキュアな鍵の配布と管理を可能にするプロトコルであり、セキュリティの向上と効率的な鍵管理を目的としています。
Internet Engineering Task Force (IETF) A. Doherty
Request for Comments: 6063 RSA, The Security Division of EMC
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign, Inc.
S. Machani
Diversinet Corp.
M. Nystrom
Microsoft Corp.
December 2010
Dynamic Symmetric Key Provisioning Protocol (DSKPP)
動的対称キープロビジョニングプロトコル（DSKPP）
Abstract
概要
The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.
動的対称キープロビジョニングプロトコル（DSKPP）は、局所的およびリモートアクセス可能な暗号モジュールへの対称キーの初期化（および構成）のクライアントサーバープロトコルです。プロトコルは、暗号化モジュールの秘密キー機能の有無にかかわらず、および確立された公開キーインフラストラクチャの有無にかかわらず実行できます。
Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module.
プロトコルの2つのバリエーションは、複数の使用法シナリオをサポートしています。4パスバリアントを使用すると、キーはプロビジョニングサーバーと暗号化モジュールによって相互に生成されます。プロビジョニングされたキーは、ワイヤーオーバーザエアまたはオーバーザエアを転送しません。2パスバリアントにより、暗号化モジュールへの事前に生成された対称キーを安全で効率的なダウンロードとインストールが可能にします。
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/rfc6063.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6063で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Key Words ..................................................6
1.2. Version Support ............................................6
1.3. Namespace Identifiers ......................................7
1.3.1. Defined Identifiers .................................7
1.3.2. Identifiers Defined in Related Specifications .......7
1.3.3. Referenced Identifiers ..............................8
2. Terminology .....................................................8
2.1. Definitions ................................................8
2.2. Notation ..................................................10
2.3. Abbreviations .............................................11
3. DSKPP Overview .................................................11
3.1. Protocol Entities .........................................12
3.2. Basic DSKPP Exchange ......................................12
3.2.1. User Authentication ................................12
3.2.2. Protocol Initiated by the DSKPP Client .............14
3.2.3. Protocol Triggered by the DSKPP Server .............16
3.2.4. Variants ...........................................17
3.2.4.1. Criteria for Using the Four-Pass Variant ..17
3.2.4.2. Criteria for Using the Two-Pass Variant ...18
3.3. Status Codes ..............................................18
3.4. Basic Constructs ..........................................20
3.4.1. User Authentication Data (AD) ......................20
3.4.1.1. Authentication Code Format ................20
3.4.1.2. User Authentication Data Calculation ......23
3.4.2. The DSKPP One-Way Pseudorandom Function,
DSKPP-PRF ..........................................24
3.4.3. The DSKPP Message Hash Algorithm ...................24
4. Four-Pass Protocol Usage .......................................25
4.1. The Key Agreement Mechanism ...............................25
4.1.1. Data Flow ..........................................25
4.1.2. Computation ........................................27
4.2. Message Flow ..............................................28
4.2.1. KeyProvTrigger .....................................28
4.2.2. KeyProvClientHello .................................29
4.2.3. KeyProvServerHello .................................30
4.2.4. KeyProvClientNonce .................................32
4.2.5. KeyProvServerFinished ..............................34
5. Two-Pass Protocol Usage ........................................35
5.1. Key Protection Methods ....................................36
5.1.1. Key Transport ......................................36
5.1.2. Key Wrap ...........................................37
5.1.3. Passphrase-Based Key Wrap ..........................37
5.2. Message Flow ..............................................38
5.2.1. KeyProvTrigger .....................................38
5.2.2. KeyProvClientHello .................................39
5.2.3. KeyProvServerFinished ..............................43
6. Protocol Extensions ............................................44
6.1. The ClientInfoType Extension ..............................45
6.2. The ServerInfoType Extension ..............................45
7. Protocol Bindings ..............................................45
7.1. General Requirements ......................................45
7.2. HTTP/1.1 Binding for DSKPP ................................46
7.2.1. Identification of DSKPP Messages ...................46
7.2.2. HTTP Headers .......................................46
7.2.3. HTTP Operations ....................................47
7.2.4. HTTP Status Codes ..................................47
7.2.5. HTTP Authentication ................................47
7.2.6. Initialization of DSKPP ............................47
7.2.7. Example Messages ...................................48
8. DSKPP XML Schema ...............................................49
8.1. General Processing Requirements ...........................49
8.2. Schema ....................................................49
9. Conformance Requirements .......................................58
10. Security Considerations .......................................59
10.1. General ..................................................59
10.2. Active Attacks ...........................................60
10.2.1. Introduction ......................................60
10.2.2. Message Modifications .............................60
10.2.3. Message Deletion ..................................61
10.2.4. Message Insertion .................................62
10.2.5. Message Replay ....................................62
10.2.6. Message Reordering ................................62
10.2.7. Man in the Middle .................................63
10.3. Passive Attacks ..........................................63
10.4. Cryptographic Attacks ....................................63
10.5. Attacks on the Interaction between DSKPP and User
Authentication ...........................................64
10.6. Miscellaneous Considerations .............................65
10.6.1. Client Contributions to K_TOKEN Entropy ...........65
10.6.2. Key Confirmation ..................................65
10.6.3. Server Authentication .............................65
10.6.4. User Authentication ...............................66
10.6.5. Key Protection in Two-Pass DSKPP ..................66
10.6.6. Algorithm Agility .................................67
11. Internationalization Considerations ...........................68
12. IANA Considerations ...........................................68
12.1. URN Sub-Namespace Registration ...........................68
12.2. XML Schema Registration ..................................69
12.3. MIME Media Type Registration .............................69
12.4. Status Code Registration .................................70
12.5. DSKPP Version Registration ...............................70
12.6. PRF Algorithm ID Sub-Registry ............................70
12.6.1. DSKPP-PRF-AES .....................................71
12.6.2. DSKPP-PRF-SHA256 ..................................71
12.7. Key Container Registration ...............................72
13. Intellectual Property Considerations ..........................73
14. Contributors ..................................................73
15. Acknowledgements ..............................................73
16. References ....................................................74
16.1. Normative References .....................................74
16.2. Informative References ...................................76
Appendix A. Usage Scenarios ......................................78
A.1. Single Key Request ........................................78
A.2. Multiple Key Requests .....................................78
A.3. User Authentication .......................................78
A.4. Provisioning Time-Out Policy ............................78
A.5. Key Renewal ...............................................79
A.6. Pre-Loaded Key Replacement ..............................79
A.7. Pre-Shared Manufacturing Key ............................79
A.8. End-to-End Protection of Key Material ...................80
Appendix B. Examples .............................................80
B.1. Trigger Message ...........................................80
B.2. Four-Pass Protocol ......................................81
B.2.1. <KeyProvClientHello> without a Preceding Trigger ......81
B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger .....82
B.2.3. <KeyProvServerHello> Without a Preceding Trigger ......83
B.2.4. <KeyProvServerHello> Assuming Key Renewal .............84
B.2.5. <KeyProvClientNonce> Using Default Encryption .........85
B.2.6. <KeyProvServerFinished> Using Default Encryption ......85
B.3. Two-Pass Protocol .......................................86
B.3.1. Example Using the Key Transport Method ................86
B.3.2. Example Using the Key Wrap Method .....................90
B.3.3. Example Using the Passphrase-Based Key Wrap Method ..94
Appendix C. Integration with PKCS #11 ............................98
C.1. The Four-Pass Variant ...................................98
C.2. The Two-Pass Variant ....................................98
Appendix D. Example of DSKPP-PRF Realizations .................101
D.1. Introduction .............................................101
D.2. DSKPP-PRF-AES ..........................................101
D.2.1. Identification .......................................101
D.2.2. Definition ...........................................101
D.2.3. Example ..............................................102
D.3. DSKPP-PRF-SHA256 .......................................103
D.3.1. Identification .......................................103
D.3.2. Definition ...........................................103
D.3.3. Example ..............................................104
Symmetric-key-based cryptographic systems (e.g., those providing authentication mechanisms such as one-time passwords and challenge-response) offer performance and operational advantages over public key schemes. Such use requires a mechanism for the provisioning of symmetric keys providing equivalent functionality to mechanisms such as the Certificate Management Protocol (CMP) [RFC4210] and Certificate Management over CMS (CMC) [RFC5272] in a Public Key Infrastructure.
対称キーベースの暗号システム（例：1回限りのパスワードやチャレンジ応答などの認証メカニズムを提供するもの）は、公開キースキームよりもパフォーマンスと運用上の利点を提供します。このような使用には、公開キーインフラストラクチャにおけるCMS（CMC）[RFC5272]を超える証明書管理プロトコル（CMP）[RFC4210]などのメカニズムに同等の機能を提供する対称キーのプロビジョニングのメカニズムが必要です。
Traditionally, cryptographic modules have been provisioned with keys during device manufacturing, and the keys have been imported to the cryptographic server using, e.g., a CD-ROM disc shipped with the devices. Some vendors also have proprietary provisioning protocols, which often have not been publicly documented (the Cryptographic Token Key Initialization Protocol (CT-KIP) is one exception [RFC4758]).
従来、暗号化モジュールはデバイスの製造中にキーをプロビジョニングされており、キーはデバイスに出荷されたCD-ROMディスクなどを使用して暗号化サーバーにインポートされてきました。一部のベンダーには独自のプロビジョニングプロトコルもありますが、これはしばしば公開されていません（暗号化トークンキー初期化プロトコル（CT-KIP）は1つの例外[RFC4758]）。
This document describes the Dynamic Symmetric Key Provisioning Protocol (DSKPP), a client-server protocol for provisioning symmetric keys between a cryptographic module (corresponding to DSKPP Client) and a key provisioning server (corresponding to DSKPP Server).
このドキュメントでは、暗号化モジュール（DSKPPクライアントに対応）間の対称キーをプロビジョニングするためのクライアントサーバープロトコル、およびキープロビジョニングサーバー（DSKPPサーバーに対応）の動的対称キープロビジョニングプロトコル（DSKPP）（DSKPP）について説明します。
DSKPP provides an open and interoperable mechanism for initializing and configuring symmetric keys to cryptographic modules that are accessible over the Internet. The description is based on the information contained in [RFC4758], and contains specific enhancements, such as user authentication and support for the [RFC6030] format for transmission of keying material.
DSKPPは、インターネットを介してアクセス可能な暗号モジュールに対称キーを初期化および構成するためのオープンで相互運用可能なメカニズムを提供します。説明は[RFC4758]に含まれる情報に基づいており、キーイング材料の送信のための[RFC6030]形式のユーザー認証やサポートなどの特定の強化が含まれています。
DSKPP has two principal protocol variants. The four-pass protocol variant permits a symmetric key to be established that includes randomness contributed by both the client and the server. The two-pass protocol requires only one round trip instead of two and permits a server specified key to be established.
DSKPPには2つの主要なプロトコルバリアントがあります。4パスプロトコルバリアントにより、クライアントとサーバーの両方が寄与するランダム性を含む対称キーを確立することができます。2パスプロトコルでは、2つではなく1つのラウンドトリップのみが必要であり、サーバー指定されたキーを確立することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
There is a provision made in the syntax for an explicit version number. Only version "1.0" is currently specified.
明示的なバージョン番号の構文で作成された規定があります。現在、バージョン「1.0」のみが指定されています。
The purpose for versioning the protocol is to provide a mechanism by which changes to required cryptographic algorithms (e.g., SHA-256) and attributes (e.g., key size) can be deployed without disrupting existing implementations; likewise, outdated implementations can be de-commissioned without disrupting operations involving newer protocol versions.
プロトコルのバージョンのバージョンの目的は、必要な暗号化アルゴリズム（SHA-256など）と属性（キーサイズなど）の変更を既存の実装を中断することなく展開できるメカニズムを提供することです。同様に、時代遅れの実装は、新しいプロトコルバージョンを含む操作を中断することなく、委任することができます。
The numbering scheme for DSKPP 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, "DSKPP 2.4" would be a lower version than "DSKPP 2.13", which in turn would be lower than "DSKPP 12.3". Leading zeros (e.g., "DSKPP 6.01") MUST be ignored by recipients and MUST NOT be sent.
DSKPPバージョンの番号付けスキームは「<major>。<minor>」です。主要な数字とマイナー数は、個別の整数として扱う必要があり、各数値は1桁よりも高く増加することができます。したがって、「DSKPP 2.4」は「DSKPP 2.13」よりも低いバージョンであり、「DSKPP 12.3」よりも低くなります。主要なゼロ（例： "dskpp 6.01"）は、受信者が無視する必要があり、送信してはなりません。
The major version number should be incremented only if the data formats or security algorithms have changed so dramatically that an older version implementation would not be able to interoperate with a newer version (e.g., removing support for a previously mandatory-to-implement algorithm now found to be insecure). The minor version number indicates new capabilities (e.g., introducing a new algorithm option) and MUST be ignored by an entity with a smaller minor version number but be used for informational purposes by the entity with the larger minor version number.
メジャーバージョン番号は、データ形式またはセキュリティアルゴリズムが非常に劇的に変更された場合にのみインクリメントする必要があります。古いバージョンの実装では、新しいバージョンと相互運用できません（たとえば、以前に必須のアルゴリズムのサポートを削除しました。不安になるため）。マイナーバージョン番号は、新しい機能（たとえば、新しいアルゴリズムオプションを導入するなど）を示し、マイナーバージョン番号が小さいエンティティでは無視する必要がありますが、マイナーバージョン番号が大きいエンティティによって情報目的で使用されます。
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to identify resources, algorithms, and semantics.
このドキュメントでは、均一なリソース識別子（URIS）[RFC3986]を使用して、リソース、アルゴリズム、およびセマンティクスを識別します。
The XML namespace [XMLNS] URI for Version 1.0 of DSKPP is:
DSKPPのバージョン1.0のXML名空間[XMLNS] URIは次のとおりです。
"urn:ietf:params:xml:ns:keyprov:dskpp"
References to qualified elements in the DSKPP schema defined herein use the prefix "dskpp", but any prefix is allowed.
本明細書で定義されているDSKPPスキーマの適格要素への参照は、プレフィックス「DSKPP」を使用しますが、任意のプレフィックスは許可されています。
This document relies on qualified elements already defined in the Portable Symmetric Key Container [RFC6030] namespace, which is represented by the prefix "pskc" and declared as:
このドキュメントは、ポータブル対称キーコンテナ[RFC6030]名前空間で既に定義されている適格な要素に依存しています。これは、プレフィックス「PSKC」で表され、次のように宣言されています。
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
Finally, the DSKPP syntax presented in this document relies on algorithm identifiers defined in the XML Signature [XMLDSIG] namespace:
最後に、このドキュメントで提示されているDSKPP構文は、XML署名[XMLDSIG]名前空間で定義されているアルゴリズム識別子に依存しています。
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to algorithm identifiers in the XML Signature namespace are represented by the prefix "ds".
XML署名名空間のアルゴリズム識別子への参照は、プレフィックス「DS」で表されます。
Terms are defined below as they are used in this document. The same terms may be defined differently in other documents.
このドキュメントで使用されている用語は、以下に定義されています。同じ用語が他のドキュメントで異なる方法で定義される場合があります。
Authentication Code (AC): User Authentication Code comprised of a string of hexadecimal characters known to the device and the server and containing at a minimum a client identifier and a password. This ClientID/password combination is used only once and may have a time limit, and then discarded.
認証コード（AC）：ユーザー認証コードは、デバイスとサーバーに知られている一連の16進数文字で構成され、少なくともクライアント識別子とパスワードを含む。このClientID/Passwordの組み合わせは一度だけ使用され、時間制限があり、その後破棄される場合があります。
Authentication Data (AD): User Authentication Data that is derived from the Authentication Code (AC)
認証データ（AD）：認証コード（AC）から派生したユーザー認証データ
Client ID: An identifier that the DSKPP Server uses to locate the real username or account identifier on the server. It can be a short random identifier that is unrelated to any real usernames.
クライアントID：DSKPPサーバーが使用する識別子で、サーバー上の実際のユーザー名またはアカウント識別子を見つけます。これは、実際のユーザー名とは無関係の短いランダム識別子です。
Cryptographic Module: A component of an application, which enables symmetric key cryptographic functionality
暗号化モジュール：対称的なキー暗号機能を可能にするアプリケーションのコンポーネント
Device: A physical piece of hardware, or a software framework, that hosts symmetric key cryptographic modules
デバイス：対称キー暗号モジュールをホストするハードウェアまたはソフトウェアフレームワークの物理的な部分
Device ID (DeviceID): A unique identifier for the device that houses the cryptographic module, e.g., a mobile phone
デバイスID（deviceID）：暗号化モジュールを収容するデバイスの一意の識別子、例えば携帯電話
DSKPP Client: Manages communication between the symmetric key cryptographic module and the DSKPP Server
DSKPPクライアント：対称キー暗号化モジュールとDSKPPサーバー間の通信を管理する
DSKPP Server: The symmetric key provisioning server that participates in the DSKPP run
DSKPPサーバー：DSKPP実行に参加する対称キープロビジョニングサーバー
DSKPP Server ID (ServerID): The unique identifier of a DSKPP Server
DSKPPサーバーID（ServerID）：DSKPPサーバーの一意の識別子
Key Agreement: A key establishment protocol whereby two or more parties can agree on a key in such a way that both influence the outcome
主要な合意：2つ以上の当事者が結果に影響を与えるような方法でキーに同意できる重要な施設プロトコル
Key Confirmation: The assurance of the rightful participants in a key-establishment protocol that the intended recipient of the shared key actually possesses the shared key
キー確認：共有キーの意図された受信者が実際に共有キーを所有しているというキー確立プロトコルにおける正当な参加者の保証
Key Issuer: An organization that issues symmetric keys to end-users
キー発行者：エンドユーザーに対称キーを発行する組織
Key Package (KP): An object that encapsulates a symmetric key and its configuration data
キーパッケージ（KP）：対称キーとその構成データをカプセル化するオブジェクト
Key ID (KeyID): A unique identifier for the symmetric key
キーID（keyID）：対称キーの一意の識別子
Key Protection Method (KPM): The key transport method used during two-pass DSKPP
Key Protection Method List (KPML): The list of key protection methods supported by a cryptographic module
Key Provisioning Server: A lifecycle management system that provides a key issuer with the ability to provision keys to cryptographic modules hosted on end-users' devices
Key Transport: A key establishment procedure whereby the DSKPP Server selects and encrypts the keying material and then sends the material to the DSKPP Client [NIST-SP800-57]
キートランスポート：DSKPPサーバーがキーイング素材を選択して暗号化し、DSKPPクライアントに資料を送信する重要な設立手順[NIST-SP800-57]
Key Transport Key: The private key that resides on the cryptographic module. This key is paired with the DSKPP Client's public key, which the DSKPP Server uses to encrypt keying material during key transport [NIST-SP800-57]
キートランスポートキー：暗号化モジュールに存在する秘密鍵。このキーは、dskppクライアントの公開キーとペアになっています。これは、dskppサーバーがキートランスポート中にキーイング素材を暗号化するために使用する[nist-sp800-57]
Key Type: The type of symmetric key cryptographic methods for which the key will be used (e.g., Open AUTHentication HMAC-Based One-Time Password (OATH HOTP) or RSA SecurID authentication, AES encryption, etc.)
キータイプ：キーが使用される対称キー暗号化方法のタイプ（例：オープン認証HMACベースのワンタイムパスワード（OATH HOTP）またはRSA SecurID認証、AES暗号化など）
Key Wrapping: A method of encrypting keys for key transport [NIST-SP800-57]
キーラッピング：キートランスポートの暗号化キーの方法[NIST-SP 800-57]
Key Wrapping Key: A symmetric key encrypting key used for key wrapping [NIST-SP800-57]
キーラッピングキー：キーラッピングに使用される対称キー暗号化キー[nist-sp 800-57]
Keying Material: The data necessary (e.g., keys and key configuration data) necessary to establish and maintain cryptographic keying relationships [NIST-SP800-57]
キーイング素材：暗号化のキーイング関係を確立および維持するために必要なデータ（キーやキー構成データなど）[NIST-SP800-57]
Manufacturer's Key: A unique master key pre-issued to a hardware device, e.g., a smart card, during the manufacturing process. If present, this key may be used by a cryptographic module to derive secret keys
メーカーのキー：製造プロセス中に、ハードウェアデバイス（例えばスマートカード）に事前に発行されたユニークなマスターキー。存在する場合、このキーは暗号化モジュールによって使用されてシークレットキーを導き出すことができます
Protocol Run: Complete execution of the DSKPP that involves one exchange (two-pass) or two exchanges (four-pass)
プロトコルの実行：1つの交換（2パス）または2つの交換（4パス）を含むDSKPPの完全な実行
Security Attribute List (SAL): A payload that contains the DSKPP version, DSKPP variant (four- or two-pass), key package formats, key types, and cryptographic algorithms that the cryptographic module is capable of supporting
セキュリティ属性リスト（SAL）：DSKPPバージョン、DSKPPバリアント（4つまたは2つのパス）、キーパッケージ形式、キータイプ、暗号化モジュールがサポートできる暗号化アルゴリズムを含むペイロード
|| String concatenation
[x] Optional element x
A ^ B Exclusive-OR operation on strings A and B
(where A and B are of equal length)
<XMLElement> A typographical convention used in the body of
the text
DSKPP-PRF(k,s,dsLen) A keyed pseudorandom function
E(k,m) Encryption of m with the key k
K Key used to encrypt R_C (either K_SERVER or
K_SHARED), or in MAC or DSKPP_PRF computations
K_AC Secret key that is derived from the
Authentication Code and used for user
authentication purposes
K_MAC Secret key derived during a DSKPP exchange for
use with key confirmation
K_MAC' A second secret key used for server
authentication
K_PROV A provisioning master key from which two keys
are derived: K_TOKEN and K_MAC
K_SERVER Public key of the DSKPP Server; used for
encrypting R_C in the four-pass protocol
variant
K_SHARED Secret key that is pre-shared between the DSKPP
Client and the DSKPP Server; used for
encrypting R_C in the four-pass protocol
variant
K_TOKEN Secret key that is established in a
cryptographic module using DSKPP
R Pseudorandom value chosen by the DSKPP Client
and used for MAC computations
R_C Pseudorandom value chosen by the DSKPP Client
and used as input to the generation of K_TOKEN
R_S Pseudorandom value chosen by the DSKPP Server
and used as input to the generation of K_TOKEN
URL_S DSKPP Server address, as a URL
AC Authentication Code AD Authentication Data DSKPP Dynamic Symmetric Key Provisioning Protocol HTTP Hypertext Transfer Protocol KP Key Package KPM Key Protection Method KPML Key Protection Method List MAC Message Authentication Code PC Personal Computer PDU Protocol Data Unit PKCS Public Key Cryptography Standards PRF Pseudorandom Function PSKC Portable Symmetric Key Container SAL Security Attribute List (see Section 2.1) TLS Transport Layer Security URL Uniform Resource Locator USB Universal Serial Bus XML eXtensible Markup Language
AC認証コード広告認証データDSKPPダイナミック対称キープロビジョニングプロトコルHTTPハイパーテキスト転送プロトコルKPキー保護方法KPMキー保護方法KPMLキー保護メソッドリストMACメッセージ認証コードPCパーソナルコンピューターPDUプロトコルデータユニットPKCキーコンテナSALセキュリティ属性リスト（セクション2.1を参照）TLSトランスポートレイヤーセキュリティURLユニフォームリソースロケーターUSBユニバーサルシリアルバスXML拡張マークアップ言語
The following sub-sections provide a high-level view of protocol internals and how they interact with external provisioning applications. Usage scenarios are provided in Appendix A.
次のサブセクションは、プロトコルの内部と外部プロビジョニングアプリケーションとの対話方法の高レベルのビューを提供します。使用法のシナリオは、付録Aに記載されています。
A DSKPP provisioning transaction has three entities:
DSKPPプロビジョニングトランザクションには3つのエンティティがあります。
Server: The DSKPP provisioning server.
サーバー：DSKPPプロビジョニングサーバー。
Cryptographic Module: The cryptographic module to which the symmetric keys are to be provisioned, e.g., an authentication token.
暗号化モジュール：対称キーをプロビジョニングする暗号化モジュール（例えば、認証トークン）。
Client: The DSKPP Client that manages communication between the cryptographic module and the key provisioning server.
クライアント：暗号化モジュールとキープロビジョニングサーバー間の通信を管理するDSKPPクライアント。
The principal syntax is XML [XML] and it is layered on a transport mechanism such as HTTP [RFC2616] and HTTP Over TLS [RFC2818]. While it is highly desirable for the entire communication between the DSKPP Client and server to be protected by means of a transport providing confidentiality and integrity protection such as HTTP over Transport Layer Security (TLS), such protection is not sufficient to protect the exchange of the symmetric key data between the server and the cryptographic module and DSKPP is designed to permit implementations that satisfy this requirement.
主要な構文はXML [XML]であり、TLS [RFC2818]を介したHTTP [RFC2616]やHTTPなどの輸送メカニズムに重ねられています。DSKPPクライアントとサーバーの間のコミュニケーション全体が、輸送層のセキュリティ（TLS）を介したHTTPなどの機密性と整合性保護を提供する輸送によって保護されることが非常に望ましいものですが、そのような保護は、サーバーと暗号化モジュールとDSKPP間の対称キーデータは、この要件を満たす実装を可能にするように設計されています。
The server only communicates to the client. As far as the server is concerned, the client and cryptographic module may be considered to be a single entity.
サーバーはクライアントとのみ通信します。サーバーに関する限り、クライアントと暗号化モジュールは単一のエンティティと見なされる場合があります。
From a client-side security perspective, however, the client and the cryptographic module are separate logical entities and may in some implementations be separate physical entities as well.
ただし、クライアント側のセキュリティの観点から見ると、クライアントと暗号化モジュールは個別の論理エンティティであり、一部の実装では別々の物理エンティティでもある場合があります。
It is assumed that a device will host an application layered above the cryptographic module, and this application will manage communication between the DSKPP Client and cryptographic module. The manner in which the communicating application will transfer DSKPP elements to and from the cryptographic module is transparent to the DSKPP Server. One method for this transfer is described in [CT-KIP-P11].
デバイスは暗号化モジュールの上に階層化されたアプリケーションをホストし、このアプリケーションはDSKPPクライアントと暗号化モジュール間の通信を管理すると想定されています。通信アプリケーションがDSKPP要素を暗号化モジュールとの間で転送する方法は、DSKPPサーバーに対して透明です。この転送の1つの方法は、[CT-KIP-P11]で説明されています。
In a DSKPP message flow, the user has obtained a new hardware or software device embedded with a cryptographic module. The goal of DSKPP is to provision the same symmetric key and related information to the cryptographic module and the key management server, and associate the key with the correct username (or other account identifier) on the server. To do this, the DSKPP Server MUST authenticate the user to be sure he is authorized for the new key.
DSKPPメッセージフローでは、ユーザーは暗号化モジュールを埋め込んだ新しいハードウェアまたはソフトウェアデバイスを取得しました。DSKPPの目標は、同じ対称キーと関連情報を暗号化モジュールとキー管理サーバーにプロビジョニングし、キーをサーバー上の正しいユーザー名（またはその他のアカウント識別子）に関連付けることです。これを行うには、DSKPPサーバーは、ユーザーが新しいキーに対して許可されていることを確認するためにユーザーを認証する必要があります。
User authentication occurs within the protocol itself *after* the DSKPP Client initiates the first message. In this case, the DSKPP Client MUST have access to the DSKPP Server URL.
ユーザー認証は、DSKPPクライアントが最初のメッセージを開始した後 *後にプロトコル自体内で発生します。この場合、DSKPPクライアントはDSKPPサーバーURLにアクセスできる必要があります。
Alternatively, a DSKPP web service or other form of web application can authenticate a user *before* the first message is exchanged. In this case, the DSKPP Server MUST trigger the DSKPP Client to initiate the first message in the protocol transaction.
または、DSKPP Webサービスまたはその他の形式のWebアプリケーションは、最初のメッセージが交換される前にユーザー *を認証できます。この場合、DSKPPサーバーは、DSKPPクライアントにプロトコルトランザクションで最初のメッセージを開始するようにトリガーする必要があります。
In the following example, the DSKPP Client first initiates DSKPP, and then the user is authenticated using a Client ID and Authentication Code.
次の例では、DSKPPクライアントが最初にDSKPPを開始し、次にユーザーがクライアントIDと認証コードを使用して認証されます。
Crypto DSKPP DSKPP Key Provisioning
Module Client Server Server
| | | |
| | | +---------------+
| | | |Server creates |
| | | |and stores |
| | | |Client ID and |
| | | |Auth. Code and |
| | | |delivers them |
| | | |to user out-of-|
| | | |band. |
| | | +---------------+
| | | |
| +----------------------+ | |
| |User enters Client ID,| | |
| |Auth. Code, and URL | | |
| +----------------------+ | |
| | | |
| |<-- 1. TLS handshake with --->| |
| | server auth. | |
| | | |
| | 2. <KeyProvClientHello> ---->| User -->|
| | | Auth. |
| |<-- [3. <KeyProvServerHello>] | |
| | | |
| | [4. <KeyProvClientNonce>] -->| |
| | | |
| |<- 5. <KeyProvServerFinished> | |
| | | |
| | | |
|<-- Key | | Key -->|
| Package | | Package |
Figure 1: Basic DSKPP Exchange
図1：基本的なDSKPP交換
Before DSKPP begins:
o The Authentication Code is generated by the DSKPP Server, and
delivered to the user via an out-of-band trustworthy channel
(e.g., a paper slip delivered by IT department staff).
o The user typically enters the Client ID and Authentication Code
manually, possibly on a device with only a numeric keypad. Thus,
they are often short numeric values (for example, 8 decimal
digits). However, the DSKPP Server is free to generate them in
any way it wishes.
o The DSKPP Client needs the URL [RFC3986] of the DSKPP Server
(which is not user specific or secret, and may be pre-configured
somehow), and a set of trust anchors for verifying the server
certificate.
o There must be an account for the user that has an identifier and
long-term username (or other account identifier) to which the
token will be associated. The DSKPP Server will use the Client ID
to find the corresponding Authentication Code for user
authentication.
In Step 1, the client establishes a TLS connection, authenticates the server (that is, validates the certificate, and compares the host name in the URL with the certificate) as described in Section 3.1 of [RFC2818].
ステップ1では、クライアントはTLS接続を確立し、[RFC2818]のセクション3.1で説明されているように、サーバーを認証し（つまり証明書を検証し、URLのホスト名を証明書と比較します）。
Next, the DSKPP Client and DSKPP Server exchange DSKPP messages
(which are sent over HTTPS). In these messages:
o The client and server negotiate which cryptographic algorithms
they want to use, which algorithms are supported for protecting
DSKPP messages, and other DSKPP details.
o The client sends the Client ID to the server, and proves that it
knows the corresponding Authentication Code.
o The client and server agree on a secret key (token key or
K_TOKEN); depending on the negotiated protocol variant, this is
either a fresh key derived during the DSKPP run (called "four-pass
variant", since it involves four DSKPP messages) or is generated
by (or pre-exists on) the server and transported to the client
(called "two-pass variant" in the rest of this document, since it
involves two DSKPP messages).
o The server sends a "key package" to the client. The package only
includes the key itself in the case of the "two-pass variant";
with either variant, the key package contains attributes that
influence how the provisioned key will be later used by the
cryptographic module and cryptographic server. The exact contents
depend on the cryptographic algorithm (e.g., for a one-time
password algorithm that supports variable-length OTP values, the
length of the OTP value would be one attribute in the key
package).
After the protocol run has been successfully completed, the cryptographic modules stores the contents of the key package. Likewise, the DSKPP provisioning server stores the contents of the key package with the cryptographic server, and associates these with the correct username. The user can now use the their device to perform symmetric-key based operations.
プロトコルの実行が正常に完了した後、暗号化モジュールはキーパッケージの内容を保存します。同様に、DSKPPプロビジョニングサーバーは、キーパッケージのコンテンツを暗号化サーバーに保存し、これらを正しいユーザー名に関連付けます。ユーザーは、デバイスを使用して対称キーベースの操作を実行できるようになりました。
The exact division of work between the cryptographic module and the DSKPP Client -- and key Provisioning server and DSKPP Server -- are not specified in this document. The figure above shows one possible case, but this is intended for illustrative purposes only.
暗号化モジュールとDSKPPクライアント（およびキープロビジョニングサーバーとDSKPPサーバーの間の正確な作業部門）は、このドキュメントでは指定されていません。上の図は、1つの可能なケースを示していますが、これは例示的な目的のみを目的としています。
In the first message flow (previous section), the Client ID and Authentication Code were delivered to the client by some out-of-band means (such as paper sent to the user).
最初のメッセージフロー（前のセクション）では、クライアントIDと認証コードが、バンド外の手段（ユーザーに送信された紙など）によってクライアントに配信されました。
Web DSKPP DSKPP Web
Browser Client Server Server
| | | |
|<-------- HTTPS browsing + some kind of user auth. --------->|
| | | |
| some HTTP request ----------------------------------------->|
| | |
| | |<------------->|
| | | |
|<----------------------- HTTP response with <KeyProvTrigger> |
| | | |
| Trigger ---->| | |
| | | |
| |<-- 1. TLS handshake with --->| |
| | server auth. | |
| | | |
| | ... continues... | |
Figure 2: DSKPP Exchange with Web-Based Authentication
図2：Webベースの認証とのDSKPP交換
In the second message flow, the user first authenticates to a web server (for example, an IT department's "self-service" Intranet page), using an ordinary web browser and some existing credentials.
2番目のメッセージフローでは、ユーザーは最初に、通常のWebブラウザーと既存の資格情報を使用して、Webサーバー（たとえば、IT部門の「セルフサービス」イントラネットページ）に認証されます。
The user then requests (by clicking a link or submitting a form) provisioning of a new key to the cryptographic module. The web server will reply with a <KeyProvTrigger> message that contains the Client ID, Authentication Code, and URL of the DSKPP Server. This information is also needed by the DSKPP Server; how the web server and DSKPP Server interact is beyond the scope of this document.
次に、ユーザーは（リンクをクリックするか、フォームを送信して）暗号化モジュールへの新しいキーのプロビジョニングを要求します。Webサーバーは、DSKPPサーバーのクライアントID、認証コード、およびURLを含む<keyprovtrigger>メッセージで返信します。この情報は、DSKPPサーバーによっても必要です。WebサーバーとDSKPPサーバーがどのように対話するかは、このドキュメントの範囲を超えています。
The <KeyProvTrigger> message is sent in an HTTP response, and it is marked with MIME type "application/dskpp+xml". It is assumed the web browser has been configured to recognize this MIME type; the browser will start the DSKPP Client and provide it with the <KeyProvTrigger> message.
<keyprovtrigger>メッセージはHTTP応答で送信され、MIMEタイプ「Application/DSKPP XML」がマークされています。WebブラウザがこのMIMEタイプを認識するように構成されていると想定されています。ブラウザはDSKPPクライアントを起動し、<keyprovtrigger>メッセージを提供します。
The DSKPP Client then contacts the DSKPP Server and uses the Client ID and Authentication Code (from the <KeyProvTrigger> message) the same way as in the first message flow.
As noted in the previous section, once the protocol has started, the client and server MAY engage in either a two-pass or four-pass message exchange. The four-pass and two-pass protocols are appropriate in different deployment scenarios. The biggest differentiator between the two is that the two-pass protocol supports transport of an existing key to a cryptographic module, while the four-pass involves key generation on-the-fly via key agreement. In either case, both protocol variants support algorithm agility through the negotiation of encryption mechanisms and key types at the beginning of each protocol run.
前のセクションで述べたように、プロトコルが開始されると、クライアントとサーバーは2パスまたは4パスのメッセージ交換のいずれかに関与する場合があります。4パスと2パスのプロトコルは、さまざまな展開シナリオで適切です。2つの間の最大の差別化要因は、2パスプロトコルが既存のキーの暗号化モジュールへの輸送をサポートしているのに対し、4パスはキー契約を介してフライでキー生成されることです。どちらの場合でも、両方のプロトコルバリアントは、各プロトコルの実行の開始時に暗号化メカニズムとキータイプの交渉を通じてアルゴリズムの俊敏性をサポートします。
The four-pass protocol is needed under one or more of the following conditions:
次の条件の1つ以上で4パスプロトコルが必要です。
o Policy requires that both parties engaged in the protocol jointly contribute entropy to the key. Enforcing this policy mitigates the risk of exposing a key during the provisioning process as the key is generated through mutual agreement without being transferred over-the-air or over-the-wire. It also mitigates risk of exposure after the key is provisioned, as the key will not be vulnerable to a single point of attack in the system.
o ポリシーでは、プロトコルに従事した両当事者が共同でエントロピーをキーに寄付することが必要です。このポリシーを実施することは、キーが航空または電線を越えずに譲渡されることなく相互の合意を通じて生成されるため、プロビジョニングプロセス中にキーを公開するリスクを軽減します。また、キーがシステムの単一の攻撃ポイントに対して脆弱ではないため、キーがプロビジョニングされた後に曝露のリスクを軽減します。
o A cryptographic module does not have private key capabilities.
o 暗号化モジュールには、秘密のキー機能がありません。
o The cryptographic module is hosted by a device that neither was pre-issued with a manufacturer's key or other form of pre-shared key (as might be the case with a smart card or Subscriber Identity Module (SIM) card) nor has a keypad that can be used for entering a passphrase (such as present on a mobile phone).
o 暗号化モジュールは、メーカーのキーまたは他の形式の事前共有キーも事前に発行されていないデバイスによってホストされています（スマートカードまたはサブスクライバーIDモジュール（SIM）カードの場合はそうです）、また、キーパッドはありません。パスフレーズの入力に使用できます（携帯電話に存在するなど）。
The two-pass protocol is needed under one or more of the following conditions:
次の条件の1つ以上で2パスプロトコルが必要です。
o Pre-existing (i.e., legacy) keys must be provisioned via transport to the cryptographic module.
o 既存の（つまり、レガシー）キーは、暗号化モジュールへの輸送を介してプロビジョニングする必要があります。
o The cryptographic module is hosted on a device that was pre-issued with a manufacturer's key (such as may exist on a smart card), or other form of pre-shared key (such as may exist on a SIM-card), and is capable of performing private key operations.
o 暗号化モジュールは、メーカーのキー（スマートカードに存在する可能性があるなど）または他の形式の事前共有キー（SIMカードに存在するなど）で事前に発行されたデバイスでホストされています。秘密キー操作を実行できます。
o The cryptographic module is hosted by a device that has a built-in keypad with which a user may enter a passphrase, useful for deriving a key wrapping key for distribution of keying material.
o 暗号化モジュールは、ユーザーがパスフレーズを入力できる組み込みキーパッドを備えたデバイスによってホストされており、キーイング材料の配布のためのキーラッピングキーを導き出すのに役立ちます。
Upon transmission or receipt of a message for which the Status attribute's value is not "Success" or "Continue", the default behavior, unless explicitly stated otherwise below, is that both the DSKPP Server and the DSKPP Client MUST immediately terminate the DSKPP run. DSKPP Servers and DSKPP Clients MUST delete any secret values generated as a result of failed runs of DSKPP. Session identifiers MAY be retained from successful or failed protocol runs for replay detection purposes, but such retained identifiers MUST NOT be reused for subsequent runs of the protocol.
ステータス属性の値が「成功」または「継続」ではないメッセージを送信または受信すると、デフォルトの動作は、明示的に特に以下に述べられない限り、DSKPPサーバーとDSKPPクライアントの両方がDSKPPの実行を直ちに終了する必要があることです。DSKPPサーバーとDSKPPクライアントは、DSKPPの実行が失敗した結果として生成された秘密の値を削除する必要があります。セッション識別子は、リプレイ検出の目的で成功したプロトコルの実行または失敗したプロトコルの実行から保持される場合がありますが、そのような保持された識別子は、プロトコルの後続の実行のために再利用してはなりません。
When possible, the DSKPP Client SHOULD present an appropriate error message to the user.
可能であれば、DSKPPクライアントはユーザーに適切なエラーメッセージを提示する必要があります。
These status codes are valid in all DSKPP Response messages unless explicitly stated otherwise:
これらのステータスコードは、明示的に特に述べられていない限り、すべてのDSKPP応答メッセージで有効です。
Continue: The DSKPP Server is ready for a subsequent request from the DSKPP Client. It cannot be sent in the server's final message.
続行：DSKPPサーバーは、DSKPPクライアントからの後続の要求に対応しています。サーバーの最終メッセージで送信することはできません。
Success: Successful completion of the DSKPP session. It can only be sent in the server's final message.
成功：DSKPPセッションの正常な完了。サーバーの最終メッセージでのみ送信できます。
Abort: The DSKPP Server rejected the DSKPP Client's request for unspecified reasons.
中断：DSKPPサーバーは、不特定の理由でDSKPPクライアントの要求を拒否しました。
AccessDenied: The DSKPP Client is not authorized to contact this DSKPP Server.
AccessDenied：DSKPPクライアントは、このDSKPPサーバーに連絡することを許可されていません。
MalformedRequest: The DSKPP Server failed to parse the DSKPP Client's request.
MALFORMEDREQUEST：DSKPPサーバーは、DSKPPクライアントの要求を解析できませんでした。
UnknownRequest: The DSKPP Client made a request that is unknown to the DSKPP Server.
不明なリクエスト：DSKPPクライアントは、DSKPPサーバーに不明なリクエストを行いました。
UnknownCriticalExtension: A DSKPP extension marked as "Critical" could not be interpreted by the receiving party.
不明なcriticalextension：「クリティカル」としてマークされたDSKPP拡張機能は、受信当事者によって解釈できませんでした。
UnsupportedVersion: The DSKPP Client used a DSKPP version not supported by the DSKPP Server. This error is only valid in the DSKPP Server's first response message.
UnsportEdversion：DSKPPクライアントは、DSKPPサーバーによってサポートされていないDSKPPバージョンを使用しました。このエラーは、DSKPPサーバーの最初の応答メッセージでのみ有効です。
NoSupportedKeyTypes: "NoSupportedKeyTypes" indicates that the DSKPP Client only suggested key types that are not supported by the DSKPP Server. This error is only valid in the DSKPP Server's first response message.
nosupportedKeyTypes： "nosupportedKeyTypes"は、DSKPPクライアントがDSKPPサーバーでサポートされていないキータイプのみを提案したことを示します。このエラーは、DSKPPサーバーの最初の応答メッセージでのみ有効です。
NoSupportedEncryptionAlgorithms: The DSKPP Client only suggested encryption algorithms that are not supported by the DSKPP Server. This error is only valid in the DSKPP Server's first response message.
nosupportedencryptionalgorithms：DSKPPクライアントは、DSKPPサーバーによってサポートされていない暗号化アルゴリズムのみを提案しました。このエラーは、DSKPPサーバーの最初の応答メッセージでのみ有効です。
NoSupportedMacAlgorithms: The DSKPP Client only suggested MAC algorithms that are not supported by the DSKPP Server. This error is only valid in the DSKPP Server's first response message.
nosupportedmacalgorithms：dskppクライアントは、DSKPPサーバーによってサポートされていないMacアルゴリズムのみを提案しました。このエラーは、DSKPPサーバーの最初の応答メッセージでのみ有効です。
NoProtocolVariants: The DSKPP Client did not suggest a required protocol variant (either two-pass or four-pass). This error is only valid in the DSKPP Server's first response message.
Noprotocolvariants：DSKPPクライアントは、必要なプロトコルバリアント（2パスまたは4パスのいずれか）を提案しませんでした。このエラーは、DSKPPサーバーの最初の応答メッセージでのみ有効です。
NoSupportedKeyPackages: The DSKPP Client only suggested key package formats that are not supported by the DSKPP Server. This error is only valid in the DSKPP Server's first response message.
NoSupportedKeyPackages：DSKPPクライアントは、DSKPPサーバーでサポートされていない主要なパッケージ形式のみを提案しました。このエラーは、DSKPPサーバーの最初の応答メッセージでのみ有効です。
AuthenticationDataMissing: The DSKPP Client didn't provide Authentication Data that the DSKPP Server required.
AuthenticationDataMissing：DSKPPクライアントは、DSKPPサーバーが必要とする認証データを提供しませんでした。
AuthenticationDataInvalid: The DSKPP Client supplied User Authentication Data that the DSKPP Server failed to validate.
AuthenticationDatainValid：DSKPPクライアントは、DSKPPサーバーが検証に失敗したユーザー認証データを提供しました。
InitializationFailed: The DSKPP Server could not generate a valid key given the provided data. When this status code is received, the DSKPP Client SHOULD try to restart DSKPP, as it is possible that a new run will succeed.
initializationFailed：DSKPPサーバーは、提供されたデータを与えられた有効なキーを生成できませんでした。このステータスコードを受信すると、DSKPPクライアントはDSKPPを再起動しようとする必要があります。これは、新しい実行が成功する可能性があるためです。
ProvisioningPeriodExpired: The provisioning period set by the DSKPP Server has expired. When the status code is received, the DSKPP Client SHOULD report the reason for key initialization failure to the user and the user MUST register with the DSKPP Server to initialize a new key.
ProvisioningPerioDexpired：DSKPPサーバーによって設定されたプロビジョニング期間の有効期限が切れています。ステータスコードを受信した場合、DSKPPクライアントはユーザーにキー初期化障害の理由を報告する必要があり、ユーザーは新しいキーを初期化するためにDSKPPサーバーに登録する必要があります。
The following calculations are used in both DSKPP variants.
以下の計算は、両方のDSKPPバリアントで使用されます。
User Authentication Data (AD) is derived from a Client ID and Authentication Code that the user enters before the first DSKPP message is sent.
ユーザー認証データ（AD）は、最初のDSKPPメッセージが送信される前にユーザーが入力するクライアントIDおよび認証コードから派生します。
Note: The user will typically enter the Client ID and Authentication Code manually, possibly on a device with only numeric keypad. Thus, they are often short numeric values (for example, 8 decimal digits). However, the DSKPP Server is free to generate them in any way it wishes.
注：ユーザーは通常、数値キーパッドのみを備えたデバイスに、クライアントIDと認証コードを手動で入力します。したがって、それらはしばしば短い数値値です（たとえば、小数桁8）。ただし、DSKPPサーバーは、希望する方法で自由に生成できます。
AC is encoded in Type-Length-Value (TLV) format. The format consists of a minimum of two TLVs and a variable number of additional TLVs, depending on implementation.
ACは、型-Length-Value（TLV）形式でエンコードされています。この形式は、実装に応じて、最低2つのTLVと可変数の追加のTLVで構成されています。
The TLV fields are defined as follows:
TLVフィールドは次のように定義されています。
Type (1 character) A hexadecimal character identifying the type of information contained in the Value field.
タイプ（1文字）値フィールドに含まれる情報のタイプを識別する16進数文字。
Length (2 characters) Two hexadecimal characters indicating the length of the Value field to follow. The field value MAY be up to 255 characters. The Length value 00 MAY be used to specify custom tags without any field values.
長さ（2文字）2つの16進数文字は、次の値フィールドの長さを示しています。フィールド値は最大255文字になる可能性があります。長さの値00を使用して、フィールド値のないカスタムタグを指定できます。
Value (variable length) A variable-length string of hexadecimal characters containing the instance-specific information for this TLV.
値（変数長）このTLVのインスタンス固有の情報を含む16進数文字の可変長文字列。
The following table summarizes the TLVs defined in this document. Optional TLVs are allowed for vendor-specific extensions with the constraint that the high bit MUST be set to indicate a vendor-specific type. Other TLVs are left for later revisions of this protocol.
次の表は、このドキュメントで定義されているTLVをまとめたものです。オプションのTLVは、ベンダー固有のタイプを示すために高ビットを設定する必要があるという制約を備えたベンダー固有の拡張機能に許可されます。他のTLVは、このプロトコルの後の改訂に残されています。
+------+------------+-------------------------------------------+
| Type | TLV Name | Conformance | Example Usage |
+------+------------+-------------------------------------------+
| 1 | Client ID | Mandatory | { "AC00000A" } |
+------+------------+-------------+-----------------------------+
| 2 | Password | Mandatory | { "3582AF0C3E" } |
+------+------------+-------------+-----------------------------+
| 3 | Checksum | Optional | { "4D5" } |
+------+------------+-------------+-----------------------------+
The Client ID is a mandatory TLV that represents the requester's identifier of maximum length 255. The value is represented as a string of hexadecimal characters that identifies the key request. For example, suppose Client ID is set to "AC00000A", the Client ID TLV in the AC will be represented as "108AC00000A".
クライアントIDは、最大長255の要求者の識別子を表す必須のTLVです。値は、キーリクエストを識別する1ヘクサデシマル文字の文字列として表されます。たとえば、クライアントIDが「AC00000A」に設定されていると仮定し、ACのクライアントID TLVは「108AC00000A」として表されます。
The Password is a mandatory TLV the contains a one-time use shared secret known by the user and the Provisioning Server. The Password value is unique and SHOULD be a random string to make AC more difficult to guess. The string MUST contain hexadecimal characters only. For example, suppose password is set to "3582AF0C3E", then the Password TLV would be "20A3582AF0C3E".
パスワードは必須のTLVです。これには、ユーザーとプロビジョニングサーバーが知っている1回限りの使用共有秘密が含まれています。パスワード値は一意であり、ACを推測するのがより困難になるためのランダムな文字列である必要があります。文字列には、16進数文字のみを含める必要があります。たとえば、パスワードが「3582AF0C3E」に設定されていると仮定し、パスワードTLVが「20A3582AF0C3E」になると仮定します。
The Checksum is an OPTIONAL TLV, which is generated by the issuing server and sent to the user as part of the AC. If the TLV is provided, the checksum value MUST be computed using the CRC16 algorithm [ISO3309]. When the user enters the AC, the typed AC string of characters is verified with the checksum to ensure it is correctly entered by the user. For example, suppose the AC with combined Client ID tag and Password tag is set to "108AC00000A20A3582AF0C3E", then the CRC16 calculation would generate a checksum of 0x356, resulting in a Checksum TLV of "334D5". The complete AC string in this example would be "108AC00000A20A3582AF0C3E3034D5".
チェックサムはオプションのTLVであり、発行サーバーによって生成され、ACの一部としてユーザーに送信されます。TLVが提供される場合、CRC16アルゴリズム[ISO3309]を使用してチェックサム値を計算する必要があります。ユーザーがACに入ると、型付けされたAC文字列の文字列がチェックサムで検証され、ユーザーが正しく入力するようにします。たとえば、クライアントIDタグとパスワードを組み合わせたACが「108AC00000A20A3582AF0C3E」に設定されていると仮定し、CRC16計算により0x356のチェックサムが生成され、「334D5」のチェックサムTLVが生成されます。この例の完全なAC文字列は、「108AC00000A20A3582AF0C3E3034D5」です。
Although this specification recommends using hexadecimal characters only for the AC at the application's user interface layer and making the TLV triples non-transparent to the user as described in the example above; implementations MAY additionally choose to use other printable Unicode characters [UNICODE] at the application's user interface layer in order to meet specific local, context or usability requirements. When non-hexadecimal characters are desired at the user interface layer such as when other printable US-ASCII characters or international characters are used, SASLprep [RFC4013] MUST be used to normalize user input before converting it to a string of hexadecimal characters. For example, if a given application allows the use of any printable US-ASCII characters and extended ASCII characters for Client ID and Password fields, and the Client ID is set to "myclient!D" and the associated Password is set to "mYpas&#rD", the user enters through the keyboard or other means a Client ID of "myclient!D" and a Password of "mYpas&#rD" in separate form fields or as instructed by the provider. The application's layer processing user input MUST then convert the values entered by the user to the following string for use in the protocol: "1146D79636C69656E7421442126D5970617326237244" (note that in this example the Checksum TLV is not added).
ただし、この仕様では、アプリケーションのユーザーインターフェイスレイヤーでのACに対してのみ16進数文字を使用し、上記の例で説明されているように、TLVをユーザーに対して非透明にすることをお勧めします。実装は、特定のローカル、コンテキスト、またはユーザビリティ要件を満たすために、アプリケーションのユーザーインターフェイスレイヤーで他の印刷可能なUnicode文字[Unicode]を使用することを選択できます。他の印刷可能なUS-ASCII文字や国際文字を使用する場合など、ユーザーインターフェイスレイヤーで非ヘキサデシマル文字が望まれている場合、SASLPrep [RFC4013]を使用して、16進入力文字に変換する前にユーザー入力を正規化する必要があります。たとえば、特定のアプリケーションで、クライアントIDおよびパスワードフィールドに印刷可能なUS-ASCII文字と拡張ASCII文字を使用できる場合、クライアントIDは「MyClient！D」に設定され、関連するパスワードは「MyPas＆＃」に設定されています。rd "、ユーザーはキーボードまたはその他を介して入力します。「myclient！d」のクライアントIDと、別の形式のフィールドでの「mypas＆＃rd」のパスワードを意味します。アプリケーションのレイヤー処理ユーザー入力は、プロトコルで使用するためにユーザーが入力した値を次の文字列に変換する必要があります： "1146d79636c69656e7421442126d5970617326237244"（この例では、TLVが追加されていません）。
The example is explained further below in detail:
この例については、以下で詳しく説明しています。
Assume that the raw Client ID value or the value entered by the use is: myclient!ID
生のクライアントID値または使用によって入力された値は、myClient！idであると仮定します。
The Client ID value as characters names is:
文字名としてのクライアントID値は次のとおりです。
U+006D LATIN SMALL LETTER M character U+0079 LATIN SMALL LETTER Y character U+0063 LATIN SMALL LETTER C character U+006C LATIN SMALL LETTER L character U+0069 LATIN SMALL LETTER I character U+0065 LATIN SMALL LETTER E character U+006E LATIN SMALL LETTER N character U+0074 LATIN SMALL LETTER T character U+0021 EXCLAMATION MARK character (!) U+0044 LATIN CAPITAL LETTER D character
u 006dラテンスモールレターMキャラクターU 0079ラテンスモールレターyキャラクターy 0063ラテンスモールレターCキャラクターc文字u 006cラテンスモールレターlキャラクターlラテンスモールレターiキャラクターu 0065ラテンスモールレターeキャラクターu 006eラテンスモールレターnキャラクター0074ラテン語の小文字t文字u 0021感嘆符マークキャラクター（！）u 0044ラテンキャピタルレターd文字
The UTF-8 conversion of the Client ID value is: 6D 79 63 6C 69 65 6E 74 21 44
クライアントID値のUTF-8変換は次のとおりです。6d7963 6c 69 65 6e 74 21 44
The length of the Client ID value in hexadecimal characters is: 14
16進数文字のクライアントID値の長さは次のとおりです。
The TLV presentation of the Client ID field is: 1146D79636C69656E742144
クライアントIDフィールドのTLVプレゼンテーションは、1146D79636C69656E742144です。
The raw Password value or the value entered by the user is: mYpas&#rD
生のパスワード値またはユーザーが入力した値は次のとおりです。
The Password value as character names is:
文字名としてのパスワード値は次のとおりです。
U+006D LATIN SMALL LETTER M character
U+0059 LATIN LARGE LETTER Y character
U+0070 LATIN SMALL LETTER P character
U+0061 LATIN SMALL LETTER A character
U+0073 LATIN SMALL LETTER S character
U+0026 AMPERSAND character (&)
U+0023 POUND SIGN character (#)
U+0072 LATIN SMALL LETTER R character
U+0044 LATIN LARGE LETTER D character
The UTF-8 conversion of the password value is: 6D 59 70 61 73 26 23 72 44
パスワード値のUTF-8変換は次のとおりです。6d5970 61 73 26 23 72 44
The length of the password value in hexadecimal characters is: 12
16進数文字のパスワード値の長さは次のとおりです。
The TLV presentation of the password field is: 2126D5970617326237244
パスワードフィールドのTLVプレゼンテーションは、2126D5970617326237244です。
The combined Client ID and password fields value or the AC value is:
1146D79636C69656E7421442126D5970617326237244
The Authentication Data consists of a Client ID (extracted from the AC) and a value, which is derived from AC as follows (refer to Section 3.4.2 for a description of DSKPP-PRF in general and Appendix D for a description of DSKPP-PRF-AES):
認証データは、クライアントID（ACから抽出）と値で構成されます。これは、次のようにACから導出されます（DSKPP-PRFの説明については、DSKPP-DSKPPの説明については付録Dで派生します。prf-aes）：
MAC = DSKPP-PRF(K_AC, AC->ClientID||URL_S||R_C||[R_S], 16)
In four-pass DSKPP, the cryptographic module uses R_C, R_S, and URL_S to calculate the MAC, where URL_S is the URL the DSKPP Client uses when contacting the DSKPP Server. In two-pass DSKPP, the cryptographic module does not have access to R_S, therefore only R_C is used in combination with URL_S to produce the MAC. In either case, K_AC MUST be derived from AC->password as follows [PKCS-5]:
4パスDSKPPでは、暗号化モジュールはR_C、R_S、およびURL_Sを使用してMACを計算します。ここで、URL_SはDSKPPサーバーに連絡するときにDSKPPクライアントが使用するURLです。2パスDSKPPでは、暗号化モジュールはR_Sにアクセスできないため、R_CのみがURL_Sと組み合わせてMACを生成するために使用されます。どちらの場合でも、K_ACは次のようにAC->パスワードから派生する必要があります[PKCS-5]：
K_AC = PBKDF2(AC->password, R_C || K, iter_count, 16)
One of the following values for K MUST be used:
kの次の値のいずれかを使用する必要があります。
a. In four-pass: * The public key of the DSKPP Server (K_SERVER), or (in the pre-shared key variant) the pre-shared key between the client and the server (K_SHARED). b. In two-pass: * The public key of the DSKPP Client, or the public key of the device when a device certificate is available. * The pre-shared key between the client and the server (K_SHARED). * A passphrase-derived key.
a. 4パス： * DSKPPサーバーの公開キー（k_server）、または（事前に共有キーバリアントで）クライアントとサーバーの間の事前共有キー（k_shared）。b。2パス： * DSKPPクライアントの公開鍵、またはデバイス証明書が利用可能な場合のデバイスの公開キー。*クライアントとサーバーの間の事前に共有キー（k_shared）。*パスフレーズ由来キー。
The iteration count, iter_count, MUST be set to at least 100,000 except in the last two two-pass cases (where K is set to K_SHARED or a passphrase-derived key), in which case iter_count MUST be set to 1.
イテレーションカウント、iter_countは、最後の2つの2パスケース（kはk_sharedまたはパスフレーズ由来キーに設定されている場合）を除き、少なくとも100,000に設定する必要があります。
Regardless of the protocol variant employed, there is a requirement for a cryptographic primitive that provides a deterministic transformation of a secret key k and a varying length octet string s to a bit string of specified length dsLen.
採用されているプロトコルのバリアントに関係なく、秘密のキーKとさまざまな長さのオクテット文字列の決定論的変換を、指定された長さのdslenのビットストリングに提供する暗号化原始の要件があります。
This primitive must meet the same requirements as for a keyed hash function: it MUST take an arbitrary length input and generate an output that is one way and collision free (for a definition of these terms, see, e.g., [FAQ]). Further, its output MUST be unpredictable even if other outputs for the same key are known.
このプリミティブは、キー付きハッシュ関数と同じ要件を満たす必要があります。任意の長さの入力を取得し、1つの方法と衝突のない出力を生成する必要があります（これらの用語の定義については、[FAQ]を参照）。さらに、同じキーの他の出力が既知であっても、その出力は予測不可能でなければなりません。
From the point of view of this specification, DSKPP-PRF is a "black-box" function that, given the inputs, generates a pseudorandom value and MAY be realized by any appropriate and competent cryptographic technique. Appendix D contains two example realizations of DSKPP-PRF.
この仕様の観点から見ると、DSKPP-PRFは「ブラックボックス」関数であり、入力を考慮して擬似ランダム値を生成し、適切で有能な暗号化手法によって実現される可能性があります。付録Dには、DSKPP-PRFの2つの例の実現が含まれています。
DSKPP-PRF(k, s, dsLen)
dskpp-prf（k、s、dslen）
Input:
入力：
k secret key in octet string format s octet string of varying length consisting of variable data distinguishing the particular string being derived dsLen desired length of the output
octet文字列形式のkシークレットキーは、さまざまな長さのオクテット文字列派生の特定の文字列を区別するさまざまなデータで構成されます。
Output:
出力：
DS pseudorandom string, dsLen octets long
ds pseudorandom string、dslen octets long
For the purposes of this document, the secret key k MUST be at least 16 octets long.
このドキュメントの目的のために、秘密のキーKは少なくとも16オクテットの長さでなければなりません。
When sending its last message in a protocol run, the DSKPP Server generates a MAC that is used by the client for key confirmation. Computation of the MAC MUST include a hash of all DSKPP messages sent by the client and server during the transaction. To compute a message hash for the MAC given a sequence of DSKPP messages msg_1, ..., msg_n, the following operations MUST be carried out: a. The sequence of messages contains all DSKPP Request and Response messages up to but not including this message. b. Re-transmitted messages are removed from the sequence of messages. Note: The resulting sequence of messages MUST be an alternating sequence of DSKPP Request and DSKPP Response messages c. The contents of each message is concatenated together. d. The resultant string is hashed using SHA-256 in accordance with [FIPS180-SHA].
プロトコルの実行で最後のメッセージを送信すると、DSKPPサーバーは、クライアントがキー確認に使用するMacを生成します。Macの計算には、トランザクション中にクライアントとサーバーが送信したすべてのDSKPPメッセージのハッシュを含める必要があります。DSKPPメッセージMSG_1、...、MSG_Nのシーケンスを与えられたMACのメッセージハッシュを計算するには、次の操作を実行する必要があります。メッセージのシーケンスには、すべてのDSKPPリクエストと応答メッセージが含まれていますが、このメッセージは含まれません。b。再送信されたメッセージは、メッセージのシーケンスから削除されます。注：結果のメッセージのシーケンスは、DSKPPリクエストとDSKPP応答メッセージの交互のシーケンスでなければなりませんc。各メッセージの内容は一緒に連結されています。d。結果の文字列は、[FIPS180-SHA]に従ってSHA-256を使用してハッシュされます。
This section describes the methods and message flow that comprise the four-pass protocol variant. Four-pass DSKPP depends on a client-server key agreement mechanism.
このセクションでは、4パスプロトコルバリアントを含むメソッドとメッセージフローについて説明します。4パスDSKPPは、クライアントサーバーキー契約メカニズムに依存します。
With four-pass DSKPP, the symmetric key that is the target of provisioning, is generated on-the-fly without being transferred between the DSKPP Client and DSKPP Server. The data flow and computation are described below.
4パスDSKPPを使用すると、プロビジョニングのターゲットである対称キーが、DSKPPクライアントとDSKPPサーバー間で転送されることなく、オンザフライで生成されます。データフローと計算については、以下に説明します。
A sample data flow showing key generation during the four-pass protocol is shown in Figure 3.
4パスプロトコル中のキー生成を示すサンプルデータフローを図3に示します。
+----------------------+ +----------------------+
| +------------+ | | |
| | Server key | | | |
| +<-| Public |------>------------->-------------+---------+ |
| | | Private | | | | | |
| | +------------+ | | | | |
| | | | | | | |
| V V | | V V |
| | +---------+ | | +---------+ | |
| | | Decrypt |<-------<-------------<-----------| Encrypt | | |
| | +---------+ | | +---------+ | |
| | | +--------+ | | ^ | |
| | | | Server | | | | | |
| | | | Random |--->------------->------+ +----------+ | |
| | | +--------+ | | | | Client | | |
| | | | | | | | Random | | |
| | | | | | | +----------+ | |
| | | | | | | | | |
| | V V | | V V | |
| | +------------+ | | +------------+ | |
| +-->| DSKPP PRF | | | | DSKPP PRF |<----+ |
| +------------+ | | +------------+ |
| | | | | |
| V | | V |
| +-------+ | | +-------+ |
| | Key | | | | Key | |
| +-------+ | | +-------+ |
| +-------+ | | +-------+ |
| |Key Id |-------->------------->------|Key Id | |
| +-------+ | | +-------+ |
+----------------------+ +----------------------+
DSKPP Server DSKPP Client
Figure 3: Principal Data Flow for DSKPP Key Generation Using Public Server Key
図3：パブリックサーバーキーを使用したDSKPPキー生成の主要なデータフロー
The inclusion of the two random nonces (R_S and R_C) in the key generation provides assurance to both sides (the cryptographic module and the DSKPP Server) that they have contributed to the key's randomness and that the key is unique. The inclusion of the encryption key (K) ensures that no man in the middle may be present, or else the cryptographic module will end up with a key different from the one stored by the legitimate DSKPP Server.
キー生成に2つのランダムノンセ（R_SおよびR_C）を含めることは、キーのランダム性に貢献し、キーが一意であることを、両側（暗号化モジュールとDSKPPサーバー）に保証を提供します。暗号化キー（k）を含めることにより、中央に人が存在しないことが保証されます。そうしないと、暗号化モジュールが正当なDSKPPサーバーによって保存されているキーとは異なるキーになります。
Conceptually, although R_C is one pseudorandom string, it may be viewed as consisting of two components, R_C1 and R_C2, where R_C1 is generated during the protocol run, and R_C2 can be pre-generated and loaded on the cryptographic module before the device is issued to the user. In that case, the latter string, R_C2, SHOULD be unique for each cryptographic module.
概念的には、R_Cは1つの擬似ランダム文字列ですが、R_C1とR_C2の2つのコンポーネントで構成されていると見なされる場合があります。ここで、R_C1はプロトコルの実行中に生成され、R_C2はデバイスが発行される前に暗号化モジュールに事前に生成およびロードできます。ユーザーに。その場合、後者の文字列であるR_C2は、暗号化モジュールごとに一意でなければなりません。
A man in the middle (in the form of corrupt client software or a mistakenly contacted server) may present his own public key to the cryptographic module. This will enable the attacker to learn the client's version of K_TOKEN. However, the attacker is not able to persuade the legitimate server to derive the same value for K_TOKEN, since K_TOKEN is a function of the public key involved, and the attacker's public key must be different than the correct server's (or else the attacker would not be able to decrypt the information received from the client). Therefore, once the attacker is no longer "in the middle," the client and server will detect that they are "out of sync" when they try to use their keys. In the case of encrypting R_C with K_SERVER, it is therefore important to verify that K_SERVER really is the legitimate server's key. One way to do this is to independently validate a newly generated K_TOKEN against some validation service at the server (e.g., using a connection independent from the one used for the key generation).
中央の男性（破損したクライアントソフトウェアまたは誤って連絡されたサーバーの形式）は、暗号化モジュールに自分の公開鍵を提示することができます。これにより、攻撃者はクライアントのK_TOKENのバージョンを学習できます。ただし、攻撃者は、K_TOKENが関与する公開鍵の関数であり、攻撃者の公開鍵は正しいサーバーとは異なる必要があるため、K_TOKENの同じ値を導き出すように合法的なサーバーを説得することはできません（または攻撃者は攻撃者が異なる必要があります。クライアントから受信した情報を復号化できます）。したがって、攻撃者が「真ん中に」なくなったら、クライアントとサーバーは、キーを使用しようとすると「同期していない」ことを検出します。したがって、K_Serverを使用してR_Cを暗号化する場合、K_Serverが実際に正当なサーバーの鍵であることを確認することが重要です。これを行う1つの方法は、サーバーでの検証サービスに対して新しく生成されたK_TOKENを独立して検証することです（たとえば、キー生成に使用されるものとは独立した接続を使用すること）。
In four-pass DSKPP, the client and server both generate K_TOKEN and K_MAC by deriving them from a provisioning key (K_PROV) using the DSKPP-PRF (refer to Section 3.4.2) as follows:
4パスDSKPPでは、クライアントとサーバーの両方がK_TOKENとK_MACを生成します。
K_PROV = DSKPP-PRF(k,s,dsLen), where
k_prov = dskpp-prf（k、s、dslen）、ここで
k = R_C (i.e., the secret random value chosen by the DSKPP
Client)
s = "Key generation" || K || R_S (where K is the key used to
encrypt R_C and R_S is the random value chosen by the DSKPP
Server)
dsLen = (desired length of K_PROV whose first half constitutes
K_MAC and second half constitutes K_TOKEN)
Then, K_TOKEN and K_MAC are derived from K_PROV, where
次に、k_tokenとk_macはk_provから派生しています。
K_PROV = K_MAC || K_TOKEN
k_prov = k_mac ||k_token
When computing K_PROV, the derived keys, K_MAC and K_TOKEN, MAY be subject to an algorithm-dependent transform before being adopted as a key of the selected type. One example of this is the need for parity in DES keys.
K_PROVを計算する場合、派生キーであるK_MACおよびK_TOKENは、選択したタイプのキーとして採用される前に、アルゴリズム依存の変換の対象となる場合があります。この一例は、DESキーのパリティの必要性です。
Note that this computation pertains to four-pass DSKPP only.
この計算は、4パスDSKPPのみに関係していることに注意してください。
The four-pass protocol flow consists of two message exchanges:
1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerHello>
2: Pass 3 = <KeyProvClientNonce>, Pass 4 = <KeyProvServerFinished>
The first pair of messages negotiate cryptographic algorithms and exchange nonces. The second pair of messages establishes a symmetric key using mutually authenticated key agreement.
メッセージの最初のペアは、暗号化アルゴリズムを交渉し、Noncesを交換します。2番目のメッセージのペアは、相互に認証されたキー契約を使用して対称キーを確立します。
The purpose and content of each message are described below. XML format and examples are in Section 8 and Appendix B.
各メッセージの目的と内容については、以下に説明します。XML形式と例は、セクション8および付録Bにあります。
DSKPP Client DSKPP Server
------------ ------------
[<---] AD, [DeviceID],
[KeyID], [URL_S]
When this message is sent: The "trigger" message is optional. The DSKPP Server sends this message after the following out-of-band steps are performed: 1. A user directed their browser to a key provisioning web application and signs in (i.e., authenticates). 2. The user requests a key. 3. The web application processes the request and returns an Authentication Code to the user, e.g., in response to an enrollment request via a secure web session. 4. The web application retrieves the Authentication Code from the user (possibly by asking the user to enter it using a web form, or alternatively by the user selecting a URL in which the Authentication Code is embedded). 5. The web application derives Authentication Data (AD) from the Authentication Code as described in Section 3.4.1. 6. The web application passes AD, and possibly a DeviceID (identifies a particular device to which the key is to be provisioned) and/or KeyID (identifies a key that will be replaced) to the DSKPP Server.
このメッセージが送信されると、「トリガー」メッセージはオプションです。DSKPPサーバーは、次のバンド外の手順が実行された後にこのメッセージを送信します。1。ユーザーがブラウザを主要なプロビジョニングWebアプリケーションに向け、サイン内（つまり、認証）に向けました。2.ユーザーはキーを要求します。3. Webアプリケーションは、リクエストを処理し、ユーザーに認証コードを返します。たとえば、安全なWebセッションを介した登録要求に応じて。4. Webアプリケーションは、ユーザーから認証コードを取得します（おそらく、ユーザーにWebフォームを使用して入力するように依頼するか、またはユーザーが認証コードが埋め込まれているURLを選択することにより）。5. Webアプリケーションは、セクション3.4.1で説明されているように、認証コードから認証データ（AD）を導き出します。6. WebアプリケーションはADに合格し、場合によってはDeviceID（キーがプロビジョニングされる特定のデバイスを識別します）および/またはkeyID（置き換えるキーを識別します）。
Purpose of this message: To start a DSKPP session: The DSKPP Server uses this message to trigger a client-side application to send the first DSKPP message. To provide a way for the key provisioning system to get the DSKPP Server URL to the DSKPP Client.
このメッセージの目的：DSKPPセッションを開始するには：DSKPPサーバーはこのメッセージを使用してクライアント側のアプリケーションをトリガーして最初のDSKPPメッセージを送信します。キープロビジョニングシステムがDSKPPサーバーURLをDSKPPクライアントに取得する方法を提供する。
So the key provisioning system can point the DSKPP Client to a particular cryptographic module that was pre-configured in the DSKPP provisioning server.
したがって、主要なプロビジョニングシステムは、DSKPPクライアントをDSKPPプロビジョニングサーバーに事前に構成された特定の暗号化モジュールに向けることができます。
In the case of key renewal, to identify the key to be replaced.
キーリニューアルの場合、交換するキーを特定します。
What is contained in this message: AD MUST be provided to allow the DSKPP Server to authenticate the user before completing the protocol run.
このメッセージに含まれるもの：ADを提供する必要があります。ADは、DSKPPサーバーがプロトコルの実行を完了する前にユーザーを認証できるようにする必要があります。
A DeviceID MAY be included to allow a key provisioning application to bind the provisioned key to a specific device.
キープロビジョニングアプリケーションがプロビジョニングキーを特定のデバイスにバインドできるようにするために、DeviceIDを含めることができます。
A KeyID MAY be included to allow the key provisioning application to identify a key to be replaced, e.g., in the case of key renewal.
KeyIDを含めて、キープロビジョニングアプリケーションがキーを交換するキーを識別できるようにすることができます。たとえば、キーリニューアルの場合。
The Server URL MAY be included to allow the key provisioning application to inform the DSKPP Client of which server to contact.
サーバーURLは、キープロビジョニングアプリケーションがDSKPPクライアントにどのサーバーに連絡できるかを通知できるようにするために含まれている場合があります。
DSKPP Client DSKPP Server
------------ ------------
SAL, [AD],
[DeviceID], [KeyID] --->
When this message is sent: When a DSKPP Client first connects to a DSKPP Server, it is required to send the <KeyProvClientHello> as its first message. The client can also send a <KeyProvClientHello> in response to a <KeyProvTrigger>.
このメッセージが送信されたとき：DSKPPクライアントが最初にDSKPPサーバーに接続する場合、<KeyProvClientHello>を最初のメッセージとして送信する必要があります。クライアントは、A <keyprovtrigger>に応じて<keyprovclienthello>を送信することもできます。
What is contained in this message: The Security Attribute List (SAL) included with <KeyProvClientHello> contains the combinations of DSKPP versions, variants, key package formats, key types, and cryptographic algorithms that the DSKPP Client supports in order of the client's preference (favorite choice first).
このメッセージに含まれるもの：<keyprovclienthello>に含まれるセキュリティ属性リスト（SAL）には、DSKPPバージョン、バリアント、キーパッケージ形式、キータイプ、およびDSKPPクライアントがクライアントの優先順位でサポートする暗号化アルゴリズムの組み合わせが含まれています（最初に好きな選択）。
If <KeyProvClientHello> was preceded by a <KeyProvTrigger>, then this message MUST also include the Authentication Data (AD), DeviceID, and/or KeyID that was provided with the trigger.
<keyprovclienthello>の前に<keyprovtrigger>がある場合、このメッセージには、トリガーで提供された認証データ（AD）、DeviceID、および/またはKeyIDも含める必要があります。
If <KeyProvClientHello> was not preceded by a <KeyProvTrigger>, then this message MAY contain a DeviceID that was pre-shared with the DSKPP Server, and a key ID associated with a key previously provisioned by the DSKPP provisioning server.
<keyprovclienthello>の前に<keyprovtrigger>が先行していない場合、このメッセージにはDSKPPサーバーで事前に共有されたデバイスADと、以前にDSKPPプロビジョニングサーバーによってプロビジョニングされたキーに関連付けられたキーIDが含まれる場合があります。
Application note: If this message is preceded by trigger message <KeyProvTrigger>, then the application will already have AD available (see Section 4.2.1). However, if this message was not preceded by <KeyProvTrigger>, then the application MUST retrieve the User Authentication Code, possibly by prompting the user to manually enter their Authentication Code, e.g., on a device with only a numeric keypad.
アプリケーションノート：このメッセージの前にトリガーメッセージ<keyprovtrigger>がある場合、アプリケーションには既にADが利用可能になります（セクション4.2.1を参照）。ただし、このメッセージの前に<keyprovtrigger>が先行していない場合、アプリケーションはユーザー認証コードを取得する必要があります。これは、ユーザーが数値キーパッドのみのデバイスで認証コードを手動で入力するように求めることにより、ユーザーに認証コードを入力するように求める必要があります。
The application MUST also derive Authentication Data (AD) from the Authentication Code, as described in Section 3.4.1, and save it for use in its next message, <KeyProvClientNonce>.
また、アプリケーションは、セクション3.4.1で説明されているように、認証コードから認証データ（AD）を導出し、次のメッセージ<keyprovclientnonce>で使用するために保存する必要があります。
How the DSKPP Server uses this message: The DSKPP Server will look for an acceptable combination of DSKPP version, variant (in this case, four-pass), key package format, key type, and cryptographic algorithms. If the DSKPP Client's SAL does not match the capabilities of the DSKPP Server, or does not comply with key provisioning policy, then the DSKPP Server will set the Status attribute to something other than "Continue". Otherwise, the Status attribute will be set to "Continue".
DSKPPサーバーがこのメッセージを使用する方法：DSKPPサーバーは、DSKPPバージョン、バリアント（この場合は4パス）、キーパッケージ形式、キータイプ、および暗号化アルゴリズムの許容可能な組み合わせを探します。DSKPPクライアントのSALがDSKPPサーバーの機能と一致しないか、キープロビジョニングポリシーに準拠していない場合、DSKPPサーバーはステータス属性を「続行」以外のものに設定します。それ以外の場合、ステータス属性は「続行」に設定されます。
If included in <KeyProvClientHello>, the DSKPP Server will validate the Authentication Data (AD), DeviceID, and KeyID. The DSKPP Server MUST NOT accept the DeviceID unless the server sent the DeviceID in a preceding trigger message. Note that it is also legitimate for a DSKPP Client to initiate the DSKPP run without having received a <KeyProvTrigger> message from a server, but in this case any provided DeviceID MUST NOT be accepted by the DSKPP Server unless the server has access to a unique key for the identified device and that key will be used in the protocol.
<keyprovclienthello>に含まれている場合、DSKPPサーバーは認証データ（AD）、DeviceID、およびKeyIDを検証します。DSKPPサーバーは、前のトリガーメッセージでサーバーがDeviceIDを送信しない限り、DeviceIDを受け入れてはなりません。DSKPPクライアントがサーバーから<Keyprovtrigger>メッセージを受信せずにDSKPP実行を開始することも合法であることに注意してください。ただし、この場合、サーバーが一意のアクセスにアクセスしない限り、DSKPPサーバーに提供されたDeviceIDはDSKPPサーバーに受け入れられないことに注意してください。識別されたデバイスのキーとそのキーは、プロトコルで使用されます。
DSKPP Client DSKPP Server
------------ ------------
<--- SAL, R_S, [K], [MAC]
When this message is sent: The DSKPP Server will send this message in response to a <KeyProvClientHello> message after it looks for an acceptable combination of DSKPP version, variant (in this case, four-pass), key package format, key type, and set of cryptographic algorithms. If it could not find an acceptable combination, then it will still send the message, but with a failure status.
このメッセージが送信されると：DSKPPサーバーは、DSKPPバージョン、バリアント（この場合は4パス）、キーパッケージ形式、キータイプ、暗号化アルゴリズムのセット。許容可能な組み合わせが見つからなかった場合、メッセージは引き続き送信されますが、障害ステータスがあります。
Purpose of this message: With this message, the context for the protocol run is set. Furthermore, the DSKPP Server uses this message to transmit a random nonce, which is required for each side to agree upon the same symmetric key (K_TOKEN).
このメッセージの目的：このメッセージを使用すると、プロトコルの実行のコンテキストが設定されます。さらに、DSKPPサーバーはこのメッセージを使用してランダムなノンセを送信します。これは、各側が同じ対称キー（k_token）に同意するために必要です。
What is contained in this message: A status attribute equivalent to the server's return code to <KeyProvClientHello>. If the server found an acceptable set of attributes from the client's SAL, then it sets status to Continue and returns an SAL (selected from the SAL that it received in <KeyProvClientHello>). The Server's SAL specifies the DSKPP version and variant (in this case, four-pass), key type, cryptographic algorithms, and key package format that the DSKPP Client MUST use for the remainder of the protocol run.
このメッセージに含まれるもの：<keyprovclienthello>へのサーバーの戻りコードに相当するステータス属性。サーバーがクライアントのSALから許容可能な属性セットを見つけた場合、ステータスを設定して継続してSAL（<KeyProvClientHello>で受け取ったSALから選択）を返します。サーバーのSALは、DSKPPバージョンとバリアント（この場合は4パス）、キータイプ、暗号化アルゴリズム、およびDSKPPクライアントが残りのプロトコル実行に使用する必要があるキーパッケージ形式を指定します。
A random nonce (R_S) for use in generating a symmetric key through key agreement; the length of R_S may depend on the selected key type.
キー契約を通じて対称キーを生成する際に使用するランダムノンセ（R_S）。R_Sの長さは、選択したキータイプに依存する場合があります。
A key (K) for the DSKPP Client to use for encrypting the client nonce included with <KeyProvClientNonce>. K represents the server's public key (K_SERVER) or a pre-shared secret key (K_SHARED).
DSKPPクライアントが<KeyProvClientNonce>に含まれるクライアントNonCEを暗号化するために使用するキー（k）。Kは、サーバーの公開キー（K_Server）または事前に共有されたシークレットキー（K_Shared）を表します。
A MAC MUST be present if a key is being renewed so that the DSKPP Client can confirm that the replacement key came from a trusted server. This MAC MUST be computed using DSKPP-PRF (see Section 3.4.2), where the input parameter k MUST be set to the existing MAC key K_MAC' (i.e., the value of the MAC key that existed before this protocol run; the implementation MAY specify K_MAC' to be the value of the K_TOKEN that is being replaced), and input parameter dsLen MUST be set to the length of R_S.
DSKPPクライアントが交換キーが信頼できるサーバーから来たことを確認できるように、キーが更新されている場合は、Macが存在する必要があります。このMACは、DSKPP-PRF（セクション3.4.2を参照）を使用して計算する必要があります。ここで、入力パラメーターkは既存のMACキーK_MAC 'に設定する必要があります（つまり、このプロトコルが実行される前に存在するMACキーの値、実装は実装です。K_MAC 'を交換しているK_TOKENの値であることを指定し、入力パラメーターDSLENをR_Sの長さに設定する必要があります。
How the DSKPP Client uses this message: When the Status attribute is not set to "Continue", this indicates failure and the DSKPP Client MUST abort the protocol.
DSKPPクライアントがこのメッセージを使用する方法：ステータス属性が「続行」に設定されていない場合、これは障害を示し、DSKPPクライアントはプロトコルを中止する必要があります。
If successful execution of the protocol will result in the replacement of an existing key with a newly generated one, the DSKPP Client MUST verify the MAC provided in <KeyProvServerHello>. The DSKPP Client MUST terminate the DSKPP session if the MAC does not verify, and MUST delete any nonces, keys, and/or secrets associated with the failed run.
プロトコルの実行が成功した場合、既存のキーを新しく生成したキーに置き換えると、DSKPPクライアントは<keyprovserverhello>で提供されるMacを確認する必要があります。DSKPPクライアントは、Macが確認しない場合はDSKPPセッションを終了する必要があり、実行された実行に関連するNonces、キー、および/またはシークレットを削除する必要があります。
If the Status attribute is set to "Continue", the cryptographic module generates a random nonce (R_C) using the cryptographic algorithm specified in the SAL. The length of the nonce R_C will depend on the selected key type.
ステータス属性が「継続」に設定されている場合、暗号化モジュールは、SALで指定された暗号化アルゴリズムを使用して、ランダムな非CE（R_C）を生成します。NonCe R_Cの長さは、選択したキータイプに依存します。
Encrypt R_C using K and the encryption algorithm included in the SAL.
KとSALに含まれるKと暗号化アルゴリズムを使用してR_Cを暗号化します。
The method the DSKPP Client MUST use to encrypt R_C: If K is equivalent to K_SERVER (i.e., the public key of the DSKPP Server), then an RSA encryption scheme from PKCS #1 [PKCS-1] MAY be used. If K is equivalent to K_SERVER, then the cryptographic module SHOULD verify the server's certificate before using it to encrypt R_C as described in [RFC2818], Section 3.1, and [RFC5280].
If K is equivalent to K_SHARED, the DSKPP Client MAY use the DSKPP-PRF to avoid dependence on other algorithms. In this case, the client uses K_SHARED as input parameter k (K_SHARED SHOULD be used solely for this purpose) as follows:
dsLen = len(R_C), where "len" is the length of R_C
DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen)
This will produce a pseudorandom string DS of length equal to R_C. Encryption of R_C MAY then be achieved by XOR-ing DS with R_C:
これにより、r_cに等しい長さの擬似ランダム文字列dsが生成されます。R_Cの暗号化は、R_Cを使用してXOR-ing DSによって達成される場合があります。
E(DS, R_C) = DS ^ R_C
The DSKPP Server will then perform the reverse operation to extract R_C from E(DS, R_C).
DSKPPサーバーは、E（DS、R_C）からR_Cを抽出する逆操作を実行します。
DSKPP Client DSKPP Server
------------ ------------
E(K,R_C), AD --->
When this message is sent: The DSKPP Client will send this message immediately following a <KeyProvServerHello> message whose status was set to "Continue".
このメッセージが送信されると、DSKPPクライアントは、ステータスが「続行」に設定された<keyprovserverhello>メッセージの直後にこのメッセージを送信します。
Purpose of this message: With this message the DSKPP Client transmits User Authentication Data (AD) and a random nonce encrypted with the DSKPP Server's key (K). The client's random nonce is required for each side to agree upon the same symmetric key (K_TOKEN).
このメッセージの目的：このメッセージを使用すると、DSKPPクライアントはユーザー認証データ（AD）とDSKPPサーバーのキー（k）で暗号化されたランダムな非CEを送信します。クライアントのランダムなノンセは、各側が同じ対称キー（k_token）に同意するために必要です。
What is contained in this message: Authentication Data (AD) that was derived from an Authentication Code entered by the user before <KeyProvClientHello> was sent (refer to Section 3.2).
このメッセージに含まれるもの：<keyprovclienthello>が送信される前にユーザーが入力した認証コードから派生した認証データ（AD）（セクション3.2を参照）。
The DSKPP Client's random nonce (R_C), which was encrypted as described in Section 4.2.3.
DSKPPクライアントのランダムノンセ（R_C）は、セクション4.2.3で説明されているように暗号化されました。
How the DSKPP Server uses this message: The DSKPP Server MUST use AD to authenticate the user. If authentication fails, then the DSKPP Server MUST set the return code to a failure status.
DSKPPサーバーがこのメッセージを使用する方法：DSKPPサーバーはADを使用してユーザーを認証する必要があります。認証が失敗した場合、DSKPPサーバーはreturnコードを故障ステータスに設定する必要があります。
If user authentication passes, the DSKPP Server decrypts R_C using its key (K). The decryption method is based on whether K that was transmitted to the client in <KeyProvServerHello> was equal to the server's public key (K_SERVER) or a pre-shared key (K_SHARED) (refer to Section 4.2.3 for a description of how the DSKPP Client encrypts R_C).
ユーザー認証が合格した場合、DSKPPサーバーはキー（k）を使用してR_Cを復号化します。復号化法は、<keyprovserverhello>でクライアントに送信されたKがサーバーの公開キー（k_server）または恥ずかしさキー（k_shared）に等しいかどうかに基づいています（セクション4.2.3を参照してください。DSKPPクライアントはR_Cを暗号化します）。
After extracting R_C, the DSKPP Server computes K_TOKEN using a combination of the two random nonces R_S and R_C and its encryption key, K, as described in Section 4.1.2. The particular realization of DSKPP-PRF (e.g., those defined in Appendix D) depends on the MAC algorithm contained in the <KeyProvServerHello> message. The DSKPP Server then generates a key package that contains key usage attributes such as expiry date and length. The key package MUST NOT include K_TOKEN since in the four-pass variant K_TOKEN is never transmitted between the DSKPP Server and Client. The server stores K_TOKEN and the key package with the user's account on the cryptographic server.
R_Cを抽出した後、DSKPPサーバーは、セクション4.1.2で説明されているように、2つのランダムなNonces R_Sとその暗号化キーKの組み合わせを使用してK_TOKENを計算します。DSKPP-PRFの特定の実現（たとえば、付録Dで定義されているもの）は、<keyprovserverhello>メッセージに含まれるMacアルゴリズムに依存します。次に、DSKPPサーバーは、有効期限や長さなどの主要な使用法属性を含むキーパッケージを生成します。K_TOKENは、dskppサーバーとクライアントの間に送信されないため、キーパッケージにはk_tokenを含めてはなりません。サーバーは、暗号化サーバーにユーザーのアカウントを備えたK_TOKENとキーパッケージを保存します。
Finally, the server generates a key confirmation MAC that the client will use to avoid a false "Commit" message that would cause the cryptographic module to end up in state in which the server does not recognize the stored key.
最後に、サーバーは、クライアントが使用するキー確認MACを生成します。クライアントは、サーバーが保存されたキーを認識しない状態になるという誤った「コミット」メッセージを回避するために使用します。
The MAC used for key confirmation MUST be calculated as follows:
キー確認に使用されるMacは、次のように計算する必要があります。
msg_hash = SHA-256(msg_1, ..., msg_n)
msg_hash = sha-256（msg_1、...、msg_n）
dsLen = len(msg_hash)
dslen = len（msg_hash）
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash, dsLen) where
mac = dskpp-prf（k_mac、 "mac 1 computation" || msg_hash、dslen）
MAC The DSKPP Pseudorandom Function defined in Section 3.4.2 is used to compute the MAC. The particular realization of DSKPP-PRF (e.g., those defined in Appendix D) depends on the MAC algorithm contained in the <KeyProvServerHello> message. The MAC MUST be computed using the existing MAC key (K_MAC), and a string that is formed by concatenating the (ASCII) string "MAC 1 computation" and a msg_hash.
MACセクション3.4.2で定義されているDSKPP疑似ランダム関数は、MACの計算に使用されます。DSKPP-PRFの特定の実現（たとえば、付録Dで定義されているもの）は、<keyprovserverhello>メッセージに含まれるMacアルゴリズムに依存します。MACは、既存のMACキー（K_MAC）を使用して計算する必要があります。また、（ASCII）文字列「MAC 1計算」とMSG_HASHを連結することにより形成される文字列を使用する必要があります。
K_MAC The key derived from K_PROV, as described in Section 4.1.2.
K_MACセクション4.1.2で説明されているように、K_Provから派生したキー。
msg_hash The message hash (defined in Section 3.4.3) of messages msg_1, ..., msg_n.
msg_hashメッセージmsg_1、...、msg_nのメッセージハッシュ（セクション3.4.3で定義）。
DSKPP Client DSKPP Server
------------ ------------
<--- KP, MAC
When this message is sent: The DSKPP Server will send this message after authenticating the user and, if authentication passed, generating K_TOKEN and a key package, and associating them with the user's account on the cryptographic server.
このメッセージが送信されると、DSKPPサーバーはユーザーを認証した後、認証が渡された場合、K_TOKENとキーパッケージを生成し、暗号化サーバー上のユーザーのアカウントに関連付けた場合にこのメッセージを送信します。
Purpose of this message: With this message, the DSKPP Server confirms generation of the key (K_TOKEN) and transmits the associated identifier and application-specific attributes, but not the key itself, in a key package to the client for protocol completion.
このメッセージの目的：このメッセージを使用すると、DSKPPサーバーはキー（k_token）の生成を確認し、関連する識別子およびアプリケーション固有の属性を送信しますが、キー自体ではなく、プロトコル完了のためのクライアントのキーパッケージで送信します。
What is contained in this message: A status attribute equivalent to the server's return code to <KeyProvClientNonce>. If user authentication passed, and the server successfully computed K_TOKEN, generated a key package, and associated them with the user's account on the cryptographic server, then it sets the Status attribute to "Success". If the Status attribute is set to "Success", then this message acts as a "Commit" message, instructing the cryptographic module to store the generated key (K_TOKEN) and associate the given key identifier with this key. As such, a key package (KP) MUST be included in this message, which holds an identifier for the generated key (but not the key itself) and additional configuration, e.g., the identity of the DSKPP Server, key usage attributes, etc. The default symmetric key package format MUST be based on the Portable Symmetric Key Container (PSKC) defined in [RFC6030]. Alternative formats MAY include [RFC6031], PKCS #12 [PKCS-12], or PKCS #5 XML [PKCS-5-XML] format.
このメッセージに含まれるもの：<KeyProvClientNonce>にサーバーの戻りコードに相当するステータス属性。ユーザー認証が合格し、サーバーがK_TOKENを正常に計算し、キーパッケージを生成し、暗号化サーバー上のユーザーのアカウントに関連付けた場合、ステータス属性を「成功」に設定します。ステータス属性が「成功」に設定されている場合、このメッセージは「コミット」メッセージとして機能し、暗号化モジュールに生成されたキー（k_token）を保存し、指定されたキー識別子をこのキーに関連付けます。そのため、キーパッケージ（KP）をこのメッセージに含める必要があります。このメッセージは、生成されたキー（キー自体ではなく）の識別子と追加の構成、例えばDSKPPサーバーのID、キー使用属性などを保持します。デフォルトの対称キーパッケージ形式は、[RFC6030]で定義されているポータブル対称キーコンテナ（PSKC）に基づいている必要があります。代替形式には、[RFC6031]、PKCS＃12 [PKCS-12]、またはPKCS＃5 XML [PKCS-5-XML]形式が含まれます。
With KP, the server includes a key confirmation MAC that the client uses to avoid a false "Commit" message. The MAC algorithm is the same DSKPP-PRF that was sent in the <KeyProvServerHello> message.
KPを使用すると、サーバーには、クライアントが誤った「コミット」メッセージを回避するために使用する重要な確認MACが含まれています。Macアルゴリズムは、<keyprovserverhello>メッセージで送信されたDSKPP-PRFと同じです。
How the DSKPP Client uses this message: When the Status attribute is not set to "Success", this indicates failure and the DSKPP Client MUST abort the protocol.
DSKPPクライアントがこのメッセージを使用する方法：ステータス属性が「成功」に設定されていない場合、これは失敗を示し、DSKPPクライアントはプロトコルを中止する必要があります。
After receiving a <KeyProvServerFinished> message with Status = "Success", the DSKPP Client MUST verify the key confirmation MAC that was transmitted with this message. The DSKPP Client MUST terminate the DSKPP session if the MAC does not verify, and MUST, in this case, also delete any nonces, keys, and/or secrets associated with the failed run of the protocol.
Status = "Success"を使用して<keyprovserverfinished>メッセージを受信した後、DSKPPクライアントは、このメッセージで送信された重要な確認MACを確認する必要があります。DSKPPクライアントは、MACが検証しない場合はDSKPPセッションを終了する必要があり、この場合、プロトコルの実行された実行に関連付けられた非セース、キー、および/またはシークレットも削除する必要があります。
If <KeyProvServerFinished> has Status = "Success", and the MAC was verified, then the DSKPP Client MUST calculate K_TOKEN from the combination of the two random nonces R_S and R_C and the server's encryption key, K, as described in Section 4.1.2. The DSKPP-PRF is the same one used for MAC computation. The DSKPP Client associates the key package contained in <KeyProvServerFinished> with the generated key, K_TOKEN, and stores this data permanently on the cryptographic module.
<keyprovserverfinished>のステータス= "success"があり、Macが検証された場合、dskppクライアントは、セクション4.1.2で説明されているように、2つのランダムなnonces r_cとサーバーの暗号化キーkの組み合わせからk_tokenを計算する必要があります。。DSKPP-PRFは、MAC計算に使用されるものと同じです。dskppクライアントは、<keyprovserverfinished>に含まれるキーパッケージを生成されたキーK_TOKENで関連付け、このデータを暗号化モジュールに永久に保存します。
After this operation, it MUST NOT be possible to overwrite the key unless knowledge of an authorizing key is proven through a MAC on a later <KeyProvServerHello> (and <KeyProvServerFinished>) message.
この操作の後、承認キーの知識が後の<keyprovserverhello>（および<keyprovserverfinished>）メッセージのMacを通じて証明されない限り、キーを上書きすることはできないはずです。
This section describes the methods and message flow that comprise the two-pass protocol variant. Two-pass DSKPP is essentially a transport of keying material from the DSKPP Server to the DSKPP Client. The DSKPP Server transmits keying material in a key package formatted in accordance with [RFC6030], [RFC6031], PKCS #12 [PKCS-12], or PKCS #5 XML [PKCS-5-XML].
このセクションでは、2パスプロトコルバリアントを含むメソッドとメッセージフローについて説明します。2パスDSKPPは、基本的にDSKPPサーバーからDSKPPクライアントへのキーイング材料の輸送です。DSKPPサーバーは、[RFC6030]、[RFC6031]、PKCS＃12 [PKCS-12]、またはPKCS＃5 XML [PKCS-5-XML]に従ってフォーマットされたキーパッケージでキーイング素材を送信します。
The keying material includes a provisioning master key, K_PROV, from which the DSKPP Client derives two keys: the symmetric key to be established in the cryptographic module, K_TOKEN, and a key, K_MAC, used for key confirmation. The keying material also includes key usage attributes, such as expiry date and length.
キーイング素材には、DSKPPクライアントが2つのキーを導き出すプロビジョニングマスターキーK_Provが含まれています。暗号化モジュールK_TOKENで確立される対称キーと、キー確認に使用されるキー、K_MAC。キーイング素材には、有効期限や長さなどの主要な使用属性も含まれています。
The DSKPP Server encrypts K_PROV to ensure that it is not exposed to any other entity than the DSKPP Server and the cryptographic module itself. The DSKPP Server uses any of three key protection methods to encrypt K_PROV: Key Transport, Key Wrap, and Passphrase-Based Key Wrap Key Protection methods.
DSKPPサーバーはK_Provを暗号化して、DSKPPサーバーと暗号化モジュール自体以外のエンティティにさらされないようにします。DSKPPサーバーは、3つの主要な保護方法のいずれかを使用して、K_Prov、キートランスポート、キーラップ、およびパスフレーズベースのキーラップキー保護方法の暗号化です。
While the DSKPP Client and server may negotiate the key protection method to use, the actual key protection is carried out in the KeyPackage. The format of a KeyPackage specifies how a key should be protected using the three key protection methods. The following KeyPackage formats are defined for DSKPP:
DSKPPクライアントとサーバーは、使用する重要な保護方法を交渉する場合がありますが、実際の重要な保護はキーパッケージで実行されます。キーパッケージの形式は、3つのキー保護方法を使用してキーを保護する方法を指定します。次のキーパッケージ形式は、DSKPPに対して定義されています。
o PSKC Key Container [RFC6030] at urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
o urn：ietf：params：xml：ns：keyprov：dskpp：pskc-key-containerのpskcキーコンテナ[rfc6030]
o SKPC Key Container [RFC6031] at urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container
o skpcキーコンテナ[rfc6031] at urn：ietf：params：xml：ns：keyprov：dskpp：skpc-key-container
o PKCS12 Key Container [PKCS-12] at urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container
o pkcs12キーコンテナ[PKCS-12]のurn：ietf：params：xml：ns：keyprov：dskpp：pkcs12-key-container
o PKCS5-XML Key Container [PKCS-5-XML] at urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container
o PKCS5-XMLキーコンテナ[PKCS-5-XML] at URN：IETF：params：xml：ns：keyprov：dskpp：pkcs5-xml-key-container
Each of the key protection methods is described below.
主要な保護方法のそれぞれを以下に説明します。
This section introduces three key protection methods for the two-pass variant. Additional methods MAY be defined by external entities or through the IETF process.
このセクションでは、2パスバリアントの3つの重要な保護方法を紹介します。追加の方法は、外部エンティティまたはIETFプロセスを介して定義される場合があります。
Purpose of this method: This method is intended for PKI-capable devices. The DSKPP Server encrypts keying material and transports it to the DSKPP Client. The server encrypts the keying material using the public key of the DSKPP Client, whose private key part resides in the cryptographic module. The DSKPP Client decrypts the keying material and uses it to derive the symmetric key, K_TOKEN.
この方法の目的：この方法は、PKI対応デバイスを対象としています。DSKPPサーバーはキーイング素材を暗号化し、DSKPPクライアントに輸送します。サーバーは、DSKPPクライアントの公開鍵を使用してキーイング素材を暗号化します。DSKPPクライアントはキーイング素材を復号化し、それを使用して対称キーK_TOKENを導き出します。
This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp:transport
The DSKPP Server and Client MUST support the following mechanism: http://www.w3.org/2001/04/xmlenc#rsa-1_5 encryption mechanism defined in [XMLENC].
DSKPPサーバーとクライアントは、次のメカニズムをサポートする必要があります。http：//www.w3.org/2001/04/xmlenc#rsa-1_5暗号化メカニズム[xmlenc]で定義されています。
Purpose of this method: This method is ideal for pre-keyed devices, e.g., SIM cards. The DSKPP Server encrypts keying material using a pre-shared key wrapping key and transports it to the DSKPP Client. The DSKPP Client decrypts the keying material, and uses it to derive the symmetric key, K_TOKEN.
この方法の目的：この方法は、たとえばSIMカードなどの鍵となるデバイスに最適です。DSKPPサーバーは、事前に共有キーラッピングキーを使用してキーイング素材を暗号化し、DSKPPクライアントに輸送します。DSKPPクライアントはキーイング素材を復号化し、それを使用して対称キーK_Tokenを導き出します。
This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp:wrap
The DSKPP Server and Client MUST support all of the following key wrapping mechanisms:
DSKPPサーバーとクライアントは、次のすべての主要なラッピングメカニズムをサポートする必要があります。
AES128 KeyWrap Refer to id-aes128-wrap in [RFC3394] and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES128 keywrapは、[rfc3394]およびhttp://www.w3.org/2001/04/xmlenc#kw-aes128の[rfc3394]およびhttp://www.w3.org/2001/2001のID-aes128-wrapを参照してください。
AES128 KeyWrap with Padding Refer to id-aes128-wrap-pad in [RFC5649] and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
パディング付きのAES128キーワラプは、[rfc5649]およびhttp://www.w3.org/2001/04/xmlenc#kw-aes128 in [xmlenc] in [rfc5649]およびhttp://www.w3.orgのID-aes128-wrap-padを参照してください。
AES-CBC-128 Refer to [FIPS197-AES] and http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
AES-CBC-128は[fips197-aes]およびhttp://www.w3.org/2001/04/xmlenc#aes128-cbcを参照してください[xmlenc]
Purpose of this method: This method is a variation of the Key Wrap Method that is applicable to constrained devices with keypads, e.g., mobile phones. The DSKPP Server encrypts keying material using a wrapping key derived from a user-provided passphrase, and transports the encrypted material to the DSKPP Client. The DSKPP Client decrypts the keying material, and uses it to derive the symmetric key, K_TOKEN.
この方法の目的：この方法は、キーパッドを備えた制約されたデバイス、たとえば携帯電話に適用できるキーラップメソッドのバリエーションです。DSKPPサーバーは、ユーザーが提供するパスフレーズから派生したラッピングキーを使用してキーイング素材を暗号化し、暗号化された素材をDSKPPクライアントに輸送します。DSKPPクライアントはキーイング素材を復号化し、それを使用して対称キーK_Tokenを導き出します。
To preserve the property of not exposing K_TOKEN to any other entity than the DSKPP Server and the cryptographic module itself, the method SHOULD be employed only when the device contains facilities (e.g., a keypad) for direct entry of the passphrase.
K_TOKENをDSKPPサーバーと暗号化モジュール以外のエンティティに公開しないプロパティを保存するには、パスフレーズの直接入力のためにデバイスに機能（キーパッドなど）が含まれている場合にのみ、この方法を使用する必要があります。
This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
The DSKPP Server and Client MUST support the following:
DSKPPサーバーとクライアントは、次のことをサポートする必要があります。
* The PBES2 password-based encryption scheme defined in [PKCS-5] (and identified as http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 in [PKCS-5-XML]).
* [PKCS-5]で定義されたPBES2パスワードベースの暗号化スキーム（および[PKCS-5-XML]のhttp://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2）。
* The PBKDF2 passphrase-based key derivation function also defined in [PKCS-5] (and identified as http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 in [PKCS-5-XML]).
* [PKCS-5]でも定義されているPBKDF2パスフレーズベースのキー導出関数（および[PKCS-5-XML]のhttp://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2として識別されます）。
* All of the following key wrapping mechanisms:
* 次のすべての重要なラッピングメカニズム：
AES128 KeyWrap Refer to id-aes128-wrap in [RFC3394] and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES128 keywrapは、[rfc3394]およびhttp://www.w3.org/2001/04/xmlenc#kw-aes128の[rfc3394]およびhttp://www.w3.org/2001/2001のID-aes128-wrapを参照してください。
AES128 KeyWrap with Padding Refer to id-aes128-wrap-pad in [RFC5649] and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
パディング付きのAES128キーワラプは、[rfc5649]およびhttp://www.w3.org/2001/04/xmlenc#kw-aes128 in [xmlenc] in [rfc5649]およびhttp://www.w3.orgのID-aes128-wrap-padを参照してください。
AES-CBC-128 Refer to [FIPS197-AES] and http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
AES-CBC-128は[fips197-aes]およびhttp://www.w3.org/2001/04/xmlenc#aes128-cbcを参照してください[xmlenc]
The two-pass protocol flow consists of one exchange:
1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished>
Although there is no exchange of the <ServerHello> message or the <ClientNonce> message, the DSKPP Client is still able to specify algorithm preferences and supported key types in the <KeyProvClientHello> message.
<serverhello>メッセージまたは<clientnonce>メッセージの交換はありませんが、dskppクライアントは<keyprovclienthello>メッセージでアルゴリズムの設定を指定し、キータイプをサポートすることができます。
The purpose and content of each message are described below. XML format and examples are in Section 8 and Appendix B.
各メッセージの目的と内容については、以下に説明します。XML形式と例は、セクション8および付録Bにあります。
The trigger message is used in exactly the same way for the two-pass variant as for the four-pass variant; refer to Section 4.2.1.
トリガーメッセージは、4パスバリアントとまったく同じ方法で使用されます。セクション4.2.1を参照してください。
DSKPP Client DSKPP Server
------------ ------------
SAL, AD, R_C,
[DeviceID], [KeyID],
KPML --->
When this message is sent: When a DSKPP Client first connects to a DSKPP Server, it is required to send the <KeyProvClientHello> as its first message. The client can also send <KeyProvClientHello> in response to a <KeyProvTrigger> message.
このメッセージが送信されたとき：DSKPPクライアントが最初にDSKPPサーバーに接続する場合、<KeyProvClientHello>を最初のメッセージとして送信する必要があります。クライアントは、<keyprovtrigger>メッセージに応じて<keyprovclienthello>を送信することもできます。
Purpose of this message: With this message, the DSKPP Client specifies its algorithm preferences and supported key types as well as which DSKPP versions, protocol variants (in this case "two-pass"), key package formats, and key protection methods that it supports. Furthermore, the DSKPP Client facilitates user authentication by transmitting the Authentication Data (AD) that was provided by the user before the first DSKPP message was sent.
このメッセージの目的：このメッセージを使用すると、DSKPPクライアントは、アルゴリズムの設定とサポートされたキータイプ、およびどのdskppバージョン、プロトコルバリアント（この場合は「2パス」）、キーパッケージ形式、および主要な保護方法を指定します。サポート。さらに、DSKPPクライアントは、最初のDSKPPメッセージが送信される前にユーザーが提供した認証データ（AD）を送信することにより、ユーザー認証を促進します。
Application note: This message MUST send User Authentication Data (AD) to the DSKPP Server. If this message is preceded by trigger message <KeyProvTrigger>, then the application will already have AD available (see Section 4.2.1). However, if this message was not preceded by <KeyProvTrigger>, then the application MUST retrieve the User Authentication Code, possibly by prompting the user to manually enter their Authentication Code, e.g., on a device with only a numeric keypad. The application MUST also derive Authentication Data (AD) from the Authentication Code, as described in Section 3.4.1, and save it for use in its next message, <KeyProvClientNonce>.
アプリケーションノート：このメッセージは、ユーザー認証データ（AD）をDSKPPサーバーに送信する必要があります。このメッセージの前にトリガーメッセージ<keyprovtrigger>がある場合、アプリケーションには既にADが利用可能になります（セクション4.2.1を参照）。ただし、このメッセージの前に<keyprovtrigger>が先行していない場合、アプリケーションはユーザー認証コードを取得する必要があります。これは、ユーザーが数値キーパッドのみのデバイスで認証コードを手動で入力するように求めることにより、ユーザーに認証コードを入力するように求める必要があります。また、アプリケーションは、セクション3.4.1で説明されているように、認証コードから認証データ（AD）を導出し、次のメッセージ<keyprovclientnonce>で使用するために保存する必要があります。
What is contained in this message: The Security Attribute List (SAL) included with <KeyProvClientHello> contains the combinations of DSKPP versions, variants, key package formats, key types, and cryptographic algorithms that the DSKPP Client supports in order of the client's preference (favorite choice first).
このメッセージに含まれるもの：<keyprovclienthello>に含まれるセキュリティ属性リスト（SAL）には、DSKPPバージョン、バリアント、キーパッケージ形式、キータイプ、およびDSKPPクライアントがクライアントの優先順位でサポートする暗号化アルゴリズムの組み合わせが含まれています（最初に好きな選択）。
Authentication Data (AD) that was either included with <KeyProvTrigger>, or generated as described in the "Application Note" above.
<keyprovtrigger>に含まれる認証データ（AD）、または上記の「アプリケーションノート」で説明されているように生成されました。
The DSKPP Client's random nonce (R_C), which was used by the client when generating AD. By inserting R_C into the DSKPP session, the DSKPP Client is able to ensure the DSKPP Server is live before committing the key.
DSKPPクライアントのランダムなNonCE（R_C）は、ADを生成するときにクライアントが使用しました。DSKPPセッションにR_Cを挿入することにより、DSKPPクライアントは、キーをコミットする前にDSKPPサーバーがライブであることを確認できます。
If <KeyProvClientHello> was preceded by a <KeyProvTrigger>, then this message MUST also include the DeviceID and/or KeyID that was provided with the trigger. Otherwise, if a trigger message did not precede <KeyProvClientHello>, then this message MAY include a DeviceID that was pre-shared with the DSKPP Server, and MAY contain a key ID associated with a key previously provisioned by the DSKPP provisioning server.
<keyprovclienthello>の前に<keyprovtrigger>がある場合、このメッセージには、トリガーで提供されたデバイスイドおよび/またはkeyIDも含める必要があります。それ以外の場合、トリガーメッセージが<keyprovclienthello>に先行しなかった場合、このメッセージにはDSKPPサーバーで事前に共有されたデバイスIDが含まれ、DSKPPプロビジョニングサーバーによって以前にプロビジョニングされたキーに関連付けられたキーIDが含まれる場合があります。
The list of key protection methods (KPML) that the DSKPP Client supports. Each item in the list MAY include an encryption key "payload" for the DSKPP Server to use to protect keying material that it sends back to the client. The payload MUST be of type <ds:KeyInfoType> ([XMLDSIG]). For each key protection method, the allowable choices for <ds:KeyInfoType> are:
DSKPPクライアントがサポートする主要な保護方法（KPML）のリスト。リストの各アイテムには、DSKPPサーバーの暗号化キー「ペイロード」が含まれている場合があります。ペイロードは<ds：keyinfotype>（[xmldsig]）でなければなりません。各主要な保護方法について、<ds：keyInfotype>の許容選択は次のとおりです。
* Key Transport Only those choices of <ds:KeyInfoType> that identify a public key (i.e., <ds:KeyName>, <ds:KeyValue>, <ds:X509Data>, or <ds: PGPData>). The <ds:X509Certificate> option of the <ds: X509Data> alternative is RECOMMENDED when the public key corresponding to the private key on the cryptographic module has been certified.
* キー輸送公開キー（つまり、<ds：keyname>、<ds：keyvalue>、<ds：x509data>、または<ds：pgpdata>）を識別する<ds：keyinfotype>の選択のみ。<ds：x509certificate> <ds：x509data>代替のオプションは、暗号化モジュールの秘密鍵に対応する公開キーが認定されている場合に推奨されます。
* Key Wrap Only those choices of <ds:KeyInfoType> that identify a symmetric key (i.e., <ds:KeyName> and <ds:KeyValue>). The <ds: KeyName> alternative is RECOMMENDED.
* キーラップ<ds：keyInfotype>の選択のみをラップします。これは、対称キー（つまり、<ds：keyname>および<ds：keyvalue>）を識別します。<ds：keyname>代替案をお勧めします。
* Passphrase-Based Key Wrap The <ds:KeyName> option MUST be used and the key name MUST identify the passphrase that will be used by the server to generate the key wrapping key. The identifier and passphrase components of <ds:KeyName> MUST be set to the Client ID and Authentication Code components of AD (same AD as contained in this message).
* PassPhraseベースのキーラップ<ds：keyname>オプションを使用する必要があり、キー名はサーバーが使用してキーラッピングキーを生成するために使用されるパスフレーズを識別する必要があります。<ds：keyname>の識別子とパスフレーズコンポーネントは、ADのクライアントIDおよび認証コードコンポーネントに設定する必要があります（このメッセージに含まれるADと同じAD）。
How the DSKPP Server uses this message: The DSKPP Server will look for an acceptable combination of DSKPP version, variant (in this case, two-pass), key package format, key type, and cryptographic algorithms. If the DSKPP Client's SAL does not match the capabilities of the DSKPP Server, or does not comply with key provisioning policy, then the DSKPP Server will set the Status attribute to something other than "Success". Otherwise, the Status attribute will be set to "Success".
DSKPPサーバーがこのメッセージを使用する方法：DSKPPサーバーは、DSKPPバージョン、バリアント（この場合は2パス）、キーパッケージ形式、キータイプ、および暗号化アルゴリズムの許容可能な組み合わせを探します。DSKPPクライアントのSALがDSKPPサーバーの機能と一致しない場合、またはキープロビジョニングポリシーに準拠していない場合、DSKPPサーバーはステータス属性を「成功」以外のものに設定します。それ以外の場合、ステータス属性は「成功」に設定されます。
The DSKPP Server will validate the DeviceID and KeyID if included in <KeyProvClientHello>. The DSKPP Server MUST NOT accept the DeviceID unless the server sent the DeviceID in a preceding trigger message. Note that it is also legitimate for a DSKPP Client to initiate the DSKPP run without having received a <KeyProvTrigger> message from a server, but in this case any provided DeviceID MUST NOT be accepted by the DSKPP Server unless the server has access to a unique key for the identified device and that key will be used in the protocol.
dskppサーバーは、<keyprovclienthello>に含まれている場合、DeviceIDとKeyIDを検証します。DSKPPサーバーは、前のトリガーメッセージでサーバーがDeviceIDを送信しない限り、DeviceIDを受け入れてはなりません。DSKPPクライアントがサーバーから<Keyprovtrigger>メッセージを受信せずにDSKPP実行を開始することも合法であることに注意してください。ただし、この場合、サーバーが一意のアクセスにアクセスしない限り、DSKPPサーバーに提供されたDeviceIDはDSKPPサーバーに受け入れられないことに注意してください。識別されたデバイスのキーとそのキーは、プロトコルで使用されます。
The DSKPP Server MUST use AD to authenticate the user. If authentication fails, then the DSKPP Server MUST set the return code to a failure status, and MUST, in this case, also delete any nonces, keys, and/or secrets associated with the failed run of the protocol.
DSKPPサーバーは、ADを使用してユーザーを認証する必要があります。認証が失敗した場合、DSKPPサーバーはreturnコードを障害ステータスに設定する必要があり、この場合、プロトコルの実行された実行に関連付けられたnonces、キー、および/またはシークレットも削除する必要があります。
If user authentication passes, the DSKPP Server generates a key K_PROV. In the two-pass case, wherein the client does not have access to R_S, K_PROV is randomly generated solely by the DSKPP Server wherein K_PROV MUST consist of two parts of equal length, i.e.,
ユーザー認証が合格した場合、DSKPPサーバーはキーK_Provを生成します。クライアントがR_Sにアクセスできない2つのパスの場合、K_ProvはDSKPPサーバーのみによってランダムに生成され、K_Provは等しい長さの2つの部分、つまり、つまり、つまり、
K_PROV = K_MAC || K_TOKEN
k_prov = k_mac ||k_token
The length of K_TOKEN (and hence also the length of K_MAC) is determined by the type of K_TOKEN, which MUST be one of the key types supported by the DSKPP Client. In cases where the desired key length for K_TOKEN is different from the length of K_MAC for the underlying MAC algorithm, the greater length of the two MUST be chosen to generate K_PROV. The actual MAC key is truncated from the resulting K_MAC when it is used in the MAC algorithm when K_MAC is longer than necessary in order to match the desired K_TOKEN length. If K_TOKEN is longer than needed in order to match the K_MAC length, the provisioning server and the receiving client must determine the actual secret key length from the target key algorithm and store only the truncated portion of the K_TOKEN. The truncation MUST take the beginning bytes of the desired length from K_TOKEN or K_MAC for the actual key. For example, when a provisioning server provisions an event based HOTP secret key with length 20 and MAC algorithm DSKPP-PRF-SHA256 (Appendix D), K_PROV length will be 64. The derived K_TOKEN and K_MAC will each consist of 32 bytes. The actual HOTP key should be the first 20 bytes of the K_TOKEN.
K_TOKENの長さ（したがって、K_MACの長さも）は、K_TOKENのタイプによって決まります。これは、DSKPPクライアントがサポートするキータイプの1つでなければなりません。K_TOKENの目的のキー長が基礎となるMACアルゴリズムのK_MACの長さと異なる場合、K_Provを生成するには2つの長さを選択する必要があります。実際のMACキーは、K_MACが目的のK_TOKENの長さを一致させるために必要以上に長い場合に、MACアルゴリズムで使用される場合、結果のK_MACから切り捨てられます。K_TOKENがK_MACの長さを一致させるために必要以上に長い場合、プロビジョニングサーバーと受信クライアントは、ターゲットキーアルゴリズムから実際のシークレットキーの長さを決定し、K_TOKENの切り捨てられた部分のみを保存する必要があります。切り捨ては、実際のキーのK_TOKENまたはK_MACから目的の長さの開始バイトを取得する必要があります。たとえば、プロビジョニングサーバーが長さ20およびMACアルゴリズムDSKPP-PRF-SHA256（付録D）を備えたイベントベースのHOTPシークレットキーを提供すると、K_PROVの長さは64になります。実際のHOTPキーは、K_TOKENの最初の20バイトである必要があります。
Once K_PROV is computed, the DSKPP Server selects one of the key protection methods from the DSKPP Client's KPML, and uses that method and corresponding payload to encrypt K_PROV. The DSKPP Server generates a key package to transport the key encryption method information and the encrypted provisioning key (K_PROV). The encrypted data format is subject to the choice supported by the selected key package. The key package MUST specify and use the selected key protection method and the key information that was received in <KeyProvClientHello>. The key package also includes key usage attributes such as expiry date and length. The server stores the key package and K_TOKEN with a user account on the cryptographic server.
K_Provが計算されると、DSKPPサーバーはDSKPPクライアントのKPMLから主要な保護方法の1つを選択し、その方法と対応するペイロードを使用してK_Provを暗号化します。DSKPPサーバーは、キー暗号化メソッド情報と暗号化されたプロビジョニングキー（K_PROV）を輸送するためのキーパッケージを生成します。暗号化されたデータ形式は、選択したキーパッケージでサポートされている選択の対象となります。キーパッケージは、選択したキー保護方法と<keyprovclienthello>で受信されたキー情報を指定して使用する必要があります。キーパッケージには、有効期限や長さなどの主要な使用属性も含まれています。サーバーは、キーパッケージを保存し、K_TOKENは暗号化サーバーにユーザーアカウントを使用して保存します。
The server generates a MAC for key confirmation, which the client will use to avoid a false "Commit" message that would cause the cryptographic module to end up in state in which the server does not recognize the stored key.
サーバーは、キー確認用のMACを生成します。これは、クライアントが使用して、暗号化モジュールが保存されたキーを認識しない状態になる誤った「コミット」メッセージを回避するために使用します。
In addition, if an existing key is being renewed, the server generates a second MAC that it will return to the client as server Authentication Data (AD) so that the DSKPP Client can confirm that the replacement key came from a trusted server.
さらに、既存のキーが更新されている場合、サーバーは、DSKPPクライアントが交換キーが信頼できるサーバーから来たことを確認できるように、サーバー認証データ（AD）としてクライアントに戻る2番目のMacを生成します。
The method the DSKPP Server MUST use to calculate the key confirmation MAC:
DSKPPサーバーが主要な確認MACを計算するために使用する必要がある方法：
msg_hash = SHA-256(msg_1, ..., msg_n)
msg_hash = sha-256（msg_1、...、msg_n）
dsLen = len(msg_hash)
dslen = len（msg_hash）
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || ServerID, dsLen)
Mac = dskpp-prf（k_mac、 "mac 1 computation" || msg_hash || serverId、dslen）
where
ただし
MAC The MAC MUST be calculated using the already established MAC algorithm and MUST be computed on the (ASCII) string "MAC 1 computation", msg_hash, and ServerID using the existing MAC key K_MAC.
Mac Macは、既に確立されたMacアルゴリズムを使用して計算する必要があり、（ASCII）文字列「Mac 1 Computation」、MSG_HASH、およびServerIDで既存のMACキーK_MACを使用して計算する必要があります。
K_MAC The key that is derived from K_PROV, which the DSKPP Server MUST provide to the cryptographic module.
k_mac k_provから派生したキーは、DSKPPサーバーが暗号化モジュールに提供する必要があります。
msg_hash The message hash, defined in Section 3.4.3, of messages msg_1, ..., msg_n.
MSG_HASHメッセージMSG_1、...、MSG_Nのセクション3.4.3で定義されているメッセージハッシュ。
ServerID The identifier that the DSKPP Server MUST include in the <KeyPackage> element of <KeyProvServerFinished>.
serverID dskppサーバーが<keyprovserverfinished>の<keypackage>要素に含める必要がある識別子。
If DSKPP-PRF (defined in Section 3.4.2) is used as the MAC algorithm, then the input parameter s MUST consist of the concatenation of the (ASCII) string "MAC 1 computation", msg_hash, and ServerID, and the parameter dsLen MUST be set to the length of msg_hash.
DSKPP-PRF（セクション3.4.2で定義）がMACアルゴリズムとして使用されている場合、入力パラメーターsは（ASCII）文字列「MAC 1計算」、MSG_HASH、およびServerID、およびパラメーターDSLENENの連結で構成されている必要があります。MSG_HASHの長さに設定する必要があります。
The method the DSKPP Server MUST use to calculate the server authentication MAC:
DSKPPサーバーがサーバー認証Macを計算するために使用する必要がある方法：
The MAC MUST be computed on the (ASCII) string "MAC 2 computation", the server identifier ServerID, and R, using a pre-existing MAC key K_MAC' (the MAC key that existed before this protocol run). Note that the implementation may specify K_MAC' to be the value of the K_TOKEN that is being replaced.
Macは、（ASCII）文字列「Mac 2計算」、サーバー識別子ServerID、およびRを使用して計算する必要があります。これは、既存のMACキーK_MAC（このプロトコルが実行される前に存在するMACキー）を使用します。実装により、K_MAC 'が交換されているK_TOKENの値であることを指定する場合があることに注意してください。
If DSKPP-PRF is used as the MAC algorithm, then the input parameter s MUST consist of the concatenation of the (ASCII) string "MAC 2 computation" ServerID, and R. The parameter dsLen MUST be set to at least 16 (i.e., the length of the MAC MUST be at least 16 octets):
DSKPP-PRFがMacアルゴリズムとして使用される場合、入力パラメーターsは（ASCII）文字列「Mac 2計算」ServerIDの連結で構成する必要があります。MACの長さは、少なくとも16オクテットでなければなりません）：
dsLen >= 16
dslen> = 16
MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, dsLen)
mac = dskpp-prf（k_mac '、 "mac 2 computation" || serverId || r、dslen）
The MAC algorithm MUST be the same as the algorithm used by the DSKPP Server to calculate the key confirmation MAC.
MACアルゴリズムは、キー確認MACを計算するためにDSKPPサーバーで使用されているアルゴリズムと同じでなければなりません。
DSKPP Client DSKPP Server
------------ ------------
<--- KP, MAC, AD
When this message is sent: The DSKPP Server will send this message after authenticating the user and, if authentication passed, generating K_TOKEN and a key package, and associating them with the user's account on the cryptographic server.
このメッセージが送信されると、DSKPPサーバーはユーザーを認証した後、認証が渡された場合、K_TOKENとキーパッケージを生成し、暗号化サーバー上のユーザーのアカウントに関連付けた場合にこのメッセージを送信します。
Purpose of this message: With this message, the DSKPP Server transports a key package containing the encrypted provisioning key (K_PROV) and key usage attributes.
このメッセージの目的：このメッセージを使用すると、DSKPPサーバーは、暗号化されたプロビジョニングキー（k_prov）とキー使用属性を含むキーパッケージを輸送します。
What is contained in this message: A Status attribute equivalent to the server's return code to <KeyProvClientHello>. If the server found an acceptable set of attributes from the client's SAL, then it sets Status to "Success".
The confirmation message MUST include the Key Package (KP) that holds the DSKPP Server's ID, key ID, key type, encrypted provisioning key (K_PROV), encryption method, and additional configuration information. The default symmetric key package format MUST be based on the Portable Symmetric Key Container (PSKC) defined in [RFC6030]. Alternative formats MAY include [RFC6031], PKCS #12 [PKCS-12], or PKCS #5 XML [PKCS-5-XML].
確認メッセージには、DSKPPサーバーのID、キーID、キータイプ、暗号化されたプロビジョニングキー（k_prov）、暗号化方法、および追加の構成情報を保持するキーパッケージ（KP）を含める必要があります。デフォルトの対称キーパッケージ形式は、[RFC6030]で定義されているポータブル対称キーコンテナ（PSKC）に基づいている必要があります。代替形式には、[RFC6031]、PKCS＃12 [PKCS-12]、またはPKCS＃5 XML [PKCS-5-XML]が含まれます。
This message MUST include a MAC that the DSKPP Client will use for key confirmation. This key confirmation MAC is calculated using the "MAC 1 computation" as described in the previous section.
このメッセージには、DSKPPクライアントがキー確認に使用するMacを含める必要があります。この重要な確認MACは、前のセクションで説明されている「Mac 1計算」を使用して計算されます。
Finally, if an existing key is being replaced, then this message MUST also include a server authentication MAC (calculated using the "MAC 2 computation" as described in the previous section), which is passed as AD to the DSKPP Client.
最後に、既存のキーが置き換えられている場合、このメッセージには、DSKPPクライアントにADとして渡されるサーバー認証Mac（前のセクションで説明されている「Mac 2計算」を使用して計算）も含める必要があります。
How the DSKPP Client uses this message: After receiving a <KeyProvServerFinished> message with Status = "Success", the DSKPP Client MUST verify both MACs (MAC and AD). The DSKPP Client MUST terminate the DSKPP run if either MAC does not verify, and MUST, in this case, also delete any nonces, keys, and/or secrets associated with the failed run of the protocol.
DSKPPクライアントがこのメッセージを使用する方法：a <keyprovserverfinished>メッセージをStatus = "Success"で受信した後、DSKPPクライアントは両方のMac（MacとAD）を検証する必要があります。DSKPPクライアントは、いずれかのMACが検証しない場合、DSKPP実行を終了する必要があり、この場合、プロトコルの実行された実行に関連付けられた非セース、キー、および/または秘密も削除する必要があります。
If <KeyProvServerFinished> has Status = "Success" and the MACs were verified, then the DSKPP Client MUST extract K_PROV from the provided key package, and derive K_TOKEN. Finally, the DSKPP Client initializes the cryptographic module with K_TOKEN and the corresponding key usage attributes. After this operation, it MUST NOT be possible to overwrite the key unless knowledge of an authorizing key is proven through a MAC on a later <KeyProvServerFinished> message.
<keyprovserverfinished>のステータス= "success"があり、Macが検証された場合、DSKPPクライアントは提供されたキーパッケージからk_provを抽出し、k_tokenを導き出す必要があります。最後に、DSKPPクライアントは、K_TOKENと対応する主要な使用属性を使用して暗号化モジュールを初期化します。この操作の後、承認キーの知識が後の<keyprovserverfinished>メッセージのMacを通じて証明されない限り、キーを上書きすることはできないはずです。
DSKPP has been designed to be extensible. The sub-sections below define two extensions that are included with the DSKPP schema. Since it is possible that the use of extensions will harm interoperability, protocol designers are advised to carefully consider the use of extensions. For example, if a particular implementation relies on the presence of a proprietary extension, then it may not be able to interoperate with independent implementations that have no knowledge of this extension.
DSKPPは、拡張可能になるように設計されています。以下のサブセクションは、DSKPPスキーマに含まれる2つの拡張機能を定義します。拡張機能の使用が相互運用性に害を及ぼす可能性があるため、プロトコル設計者は拡張機能の使用を慎重に検討することをお勧めします。たとえば、特定の実装が独自の拡張の存在に依存している場合、この拡張の知識がない独立した実装と相互運用できない場合があります。
Extensions may be sent with any DSKPP message using the ExtensionsType. The ExtensionsType type is a list of Extensions containing type-value pairs that define optional features supported by a DSKPP Client or server. Each extension MAY be marked as Critical by setting the Critical attribute of the Extension to "true". Unless an extension is marked as Critical, a receiving party need not be able to interpret it; a receiving party is always free to disregard any (non-critical) extensions.
拡張機能を使用して、extensionsをDSKPPメッセージで送信できます。extensionStypeタイプは、DSKPPクライアントまたはサーバーによってサポートされているオプションの機能を定義するタイプ値ペアを含む拡張機能のリストです。拡張機能の重要な属性を「true」に設定することにより、各拡張機能が重要であるとマークされる場合があります。拡張機能が重要であるとマークされていない限り、受信者はそれを解釈することはできません。受信当事者は、常に（クリティカルではない）拡張機能を自由に無視できます。
The ClientInfoType extension MAY contain any client-specific data required of an application. This extension MAY be present in a <KeyProvClientHello> or <KeyProvClientNonce> message. When present, this extension MUST NOT be marked as Critical.
ClientInfotype拡張機能には、アプリケーションに必要なクライアント固有のデータが含まれている場合があります。この拡張機能は、<keyprovclienthello>または<keyprovclientnonce>メッセージに存在する場合があります。存在する場合、この拡張機能はクリティカルとしてマークされてはなりません。
DSKPP Servers MUST support this extension. DSKPP Servers MUST NOT attempt to interpret the data it carries and, if received, MUST include it unmodified in the current protocol run's next server response. DSKPP Servers need not retain the ClientInfoType data.
DSKPPサーバーはこの拡張機能をサポートする必要があります。DSKPPサーバーは、携帯するデータの解釈を試みてはなりません。受信した場合は、現在のプロトコル実行の次のサーバー応答に変更されていないことを含める必要があります。DSKPPサーバーは、ClientInfotypeデータを保持する必要はありません。
The ServerInfoType extension MAY contain any server-specific data required of an application, e.g., state information. This extension is only valid in <KeyProvServerHello> messages for which the Status attribute is set to "Continue". When present, this extension MUST NOT be marked as Critical.
ServerInfotype拡張機能には、アプリケーションに必要なサーバー固有のデータ、たとえば状態情報が含まれている場合があります。この拡張機能は、ステータス属性が「継続」に設定されている<keyprovserverhello>メッセージでのみ有効です。存在する場合、この拡張機能はクリティカルとしてマークされてはなりません。
DSKPP Clients MUST support this extension. DSKPP Clients MUST NOT attempt to interpret the data it carries and, if received, MUST include it unmodified in the current protocol run's next client request (i.e., the <KeyProvClientNonce> message). DSKPP Clients need not retain the ServerInfoType data.
DSKPPクライアントはこの拡張機能をサポートする必要があります。DSKPPクライアントは、携帯するデータの解釈を試みてはなりません。受信した場合、現在のプロトコル実行の次のクライアント要求（つまり、<keyprovclientnonce>メッセージ）に変更されていないことを含める必要があります。DSKPPクライアントは、serverInfotypeデータを保持する必要はありません。
DSKPP assumes a reliable transport.
DSKPPは信頼できる輸送を想定しています。
This section presents a binding of the previous messages to HTTP/1.1 [RFC2616]. This HTTP binding is mandatory to implement, although newer versions of the specification might define additional bindings in the future. Note that the HTTP client will normally be different from the DSKPP Client (i.e., the HTTP client will "proxy" DSKPP messages from the DSKPP Client to the DSKPP Server). Likewise, on the HTTP server side, the DSKPP Server MAY receive DSKPP message from a "front-end" HTTP server. The DSKPP Server will be identified by a specific URL, which may be pre-configured, or provided to the client during initialization.
このセクションでは、以前のメッセージのHTTP/1.1 [RFC2616]への結合を示します。このHTTPバインディングは実装するために必須ですが、仕様の新しいバージョンは将来の追加のバインディングを定義する可能性があります。HTTPクライアントは通常、DSKPPクライアントとは異なることに注意してください（つまり、HTTPクライアントはDSKPPクライアントからDSKPPサーバーへの「プロキシ」DSKPPメッセージを「プロキシ」します）。同様に、HTTPサーバー側では、DSKPPサーバーは「フロントエンド」HTTPサーバーからDSKPPメッセージを受信する場合があります。DSKPPサーバーは、特定のURLによって識別されます。特定のURLは、事前に構成されているか、初期化中にクライアントに提供されます。
The MIME type for all DSKPP messages MUST be
すべてのDSKPPメッセージのMIMEタイプはそうでなければなりません
application/dskpp+xml
In order to avoid caching of responses carrying DSKPP messages by proxies, the following holds:
プロキシによるDSKPPメッセージを伝える応答のキャッシュを回避するために、次のものが保持されます。
o When using HTTP/1.1, requesters SHOULD: * Include a Cache-Control header field set to "no-cache, no-store". * Include a Pragma header field set to "no-cache".
o HTTP/1.1を使用する場合、要求者は次のことが必要です。*「ノーキャッシュ」に設定されたプラグマヘッダーフィールドを含めます。
o When using HTTP/1.1, responders SHOULD: * Include a Cache-Control header field set to "no-cache, no-must-revalidate, private". * Include a Pragma header field set to "no-cache". * NOT include a Validator, such as a Last-Modified or ETag header.
o HTTP/1.1を使用する場合、レスポンダーは次のようにする必要があります。*「ノーキャッシュ」に設定されたプラグマヘッダーフィールドを含めます。*ラスト修飾ヘッダーやETAGヘッダーなどのバリデーターを含めません。
To handle content negotiation, HTTP requests MAY include an HTTP Accept header field. This header field SHOULD should be identified using the MIME type specified in Section 7.2.1. The Accept header MAY include additional content types defined by future versions of this protocol.
コンテンツの交渉を処理するために、HTTPリクエストにはHTTP Accept Headerフィールドが含まれる場合があります。このヘッダーフィールドは、セクション7.2.1で指定されたMIMEタイプを使用して識別する必要があります。Acceptヘッダーには、このプロトコルの将来のバージョンで定義された追加のコンテンツタイプが含まれる場合があります。
There are no other restrictions on HTTP headers, besides the requirement to set the Content-Type header value to the MIME type specified in Section 7.2.1.
セクション7.2.1で指定されたMIMEタイプにコンテンツタイプのヘッダー値を設定する要件に加えて、HTTPヘッダーに他の制限はありません。
Persistent connections as defined in HTTP/1.1 are OPTIONAL. DSKPP requests are mapped to HTTP requests with the POST method. DSKPP responses are mapped to HTTP responses.
HTTP/1.1で定義されている永続的な接続はオプションです。DSKPPリクエストは、POSTメソッドを使用してHTTPリクエストにマッピングされます。DSKPP応答は、HTTP応答にマッピングされます。
For the four-pass DSKPP, messages within the protocol run are bound together. In particular, <KeyProvServerHello> is bound to the preceding <KeyProvClientHello> by being transmitted in the corresponding HTTP response. <KeyProvServerHello> MUST have a SessionID attribute, and the SessionID attribute of the subsequent <KeyProvClientNonce> message MUST be identical. <KeyProvServerFinished> is then once again bound to the rest through HTTP (and possibly through a SessionID).
4パスDSKPPの場合、プロトコルの実行内のメッセージが一緒にバインドされます。特に、<keyprovserverhello>は、対応するHTTP応答で送信されることにより、前の<keyprovclienthello>に結合します。<keyprovserverhello>にはsessionID属性が必要であり、その後の<keyprovclientnonce>メッセージのセッションID属性は同一でなければなりません。<keyprovserverfinished>は、httpを介して（そしておそらくセッションIDを介して）残りに再び結合します。
A DSKPP HTTP responder that refuses to perform a message exchange with a DSKPP HTTP requester SHOULD return a 403 (Forbidden) response. In this case, the content of the HTTP body is not significant. In the case of an HTTP error while processing a DSKPP request, the HTTP server MUST return a 500 (Internal Server Error) response. This type of error SHOULD be returned for HTTP-related errors detected before control is passed to the DSKPP processor, or when the DSKPP processor reports an internal error (for example, the DSKPP XML namespace is incorrect, or the DSKPP schema cannot be located). If a request is received that is not a DSKPP Client message, the DSKPP responder MUST return a 400 (Bad request) response.
dskpp http requesterを使用してメッセージ交換を実行することを拒否するDSKPP HTTP Responderは、403（禁止）応答を返す必要があります。この場合、HTTP本体の含有量は重要ではありません。DSKPP要求の処理中にHTTPエラーの場合、HTTPサーバーは500（内部サーバーエラー）応答を返す必要があります。このタイプのエラーは、制御がDSKPPプロセッサに渡される前に検出されたHTTP関連エラーの場合、またはDSKPPプロセッサが内部エラーを報告した場合に返信する必要があります（たとえば、DSKPP XMLネームスペースが正しくないか、DSKPPスキーマを見つけることができません）。DSKPPクライアントメッセージではないリクエストを受信した場合、DSKPP応答者は400（悪い要求）応答を返す必要があります。
In these cases (i.e., when the HTTP response code is 4xx or 5xx), the content of the HTTP body is not significant.
これらの場合（つまり、HTTP応答コードが4xxまたは5xxの場合）、HTTPボディの内容は有意ではありません。
Redirection status codes (3xx) apply as usual.
リダイレクトステータスコード（3xx）が通常どおりに適用されます。
Whenever the HTTP POST is successfully invoked, the DSKPP HTTP responder MUST use the 200 status code and provide a suitable DSKPP message (possibly with DSKPP error information included) in the HTTP body.
HTTP投稿が正常に呼び出されるときはいつでも、DSKPP HTTP Responderは200ステータスコードを使用し、HTTPボディに適切なDSKPPメッセージ（おそらくDSKPPエラー情報が含まれている可能性があります）を提供する必要があります。
No support for HTTP/1.1 authentication is assumed.
HTTP/1.1認証のサポートは想定されていません。
If a user requests key initialization in a browsing session, and if that request has an appropriate Accept header (e.g., to a specific DSKPP Server URL), the DSKPP Server MAY respond by sending a DSKPP initialization message in an HTTP response with Content-Type set according to Section 7.2.1 and response code set to 200 (OK). The initialization message MAY carry data in its body, such as the URL for the DSKPP Client to use when contacting the DSKPP Server. If the message does carry data, the data MUST be a valid instance of a <KeyProvTrigger> element.
ユーザーがブラウジングセッションでキーイニシャル化を要求し、そのリクエストに適切な受け入れヘッダー（特定のDSKPPサーバーURLに）がある場合、DSKPPサーバーは、コンテンツタイプのHTTP応答でDSKPP初期化メッセージを送信して応答する場合があります。セクション7.2.1に従って設定し、応答コードは200（OK）に設定されています。初期化メッセージは、DSKPPサーバーに連絡するときにDSKPPクライアントが使用するURLなど、その本体にデータを伝達する場合があります。メッセージがデータを伝達する場合、データは<keyprovtrigger>要素の有効なインスタンスでなければなりません。
Note that if the user's request was directed to some other resource, the DSKPP Server MUST NOT respond by combining the DSKPP content type with response code 200. In that case, the DSKPP Server SHOULD respond by sending a DSKPP initialization message in an HTTP response with Content-Type set according to Section 7.2.1 and response code set to 406 (Not Acceptable).
ユーザーの要求が他のリソースに向けられた場合、DSKPPサーバーはDSKPPコンテンツタイプと応答コード200を組み合わせることで応答してはなりません。その場合、DSKPPサーバーはHTTP応答でDSKPP初期化メッセージを送信して応答する必要があります。セクション7.2.1に従って設定されたコンテンツタイプと406に設定された応答コード（受け入れられません）。
a. Initialization from DSKPP Server: HTTP/1.1 200 OK
a. DSKPPサーバーからの初期化：HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/dskpp+xml
Content-Length: <some value>
DSKPP initialization data in XML form...
XMLフォームのDSKPP初期化データ...
b. Initial request from DSKPP Client: POST http://example.com/cgi-bin/DSKPP-server HTTP/1.1
b. DSKPPクライアントからの最初のリクエスト：http://example.com/cgi-bin/dskpp-server http/1.1を投稿する
Cache-Control: no-cache, no-store
Pragma: no-cache
Host: www.example.com
Content-Type: application/dskpp+xml
Content-Length: <some value>
DSKPP data in XML form (supported version, supported algorithms...)
XMLフォームのDSKPPデータ（サポートバージョン、サポートされているアルゴリズム...）
c. Initial response from DSKPP Server: HTTP/1.1 200 OK
c. DSKPPサーバーからの初期応答：HTTP/1.1 200 OK
Cache-Control: no-cache, no-must-revalidate, private
Pragma: no-cache
Content-Type: application/dskpp+xml
Content-Length: <some value>
DSKPP data in XML form (server random nonce, server public key, ...)
XMLフォームのDSKPPデータ（サーバーランダムノンセ、サーバー公開キー、...）
Some DSKPP elements rely on the parties being able to compare received values with stored values. Unless otherwise noted, all elements that have the XML schema "xs:string" type, or a type derived from it, MUST be compared using an exact binary comparison. In particular, DSKPP implementations MUST NOT depend on case-insensitive string comparisons, normalization or trimming of white space, or conversion of locale-specific formats such as numbers.
一部のDSKPP要素は、受信値を保存された値と比較することができる当事者に依存しています。特に明記しない限り、XMLスキーマ「XS：String」タイプを持つすべての要素、またはそれから派生したタイプは、正確なバイナリ比較を使用して比較する必要があります。特に、DSKPPの実装は、ケースに依存しない文字列の比較、ホワイトスペースの正規化またはトリミング、または数字などのロケール固有の形式の変換に依存してはなりません。
Implementations that compare values that are represented using different character encodings MUST use a comparison method that returns the same result as converting both values to the Unicode character encoding [UNICODE] and then performing an exact binary comparison.
異なる文字エンコーディングを使用して表される値を比較する実装は、両方の値をユニコード文字エンコード[Unicode]に変換し、正確なバイナリ比較を実行するのと同じ結果を返す比較方法を使用する必要があります。
No collation or sorting order for attributes or element values is defined. Therefore, DSKPP implementations MUST NOT depend on specific sorting orders for values.
属性または要素値の照合または並べ替え順序は定義されていません。したがって、DSKPPの実装は、値の特定のソート順序に依存してはなりません。
<?xml version="1.0" encoding="utf-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:dskpp"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<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="urn:ietf:params:xml:ns:keyprov:pskc"
schemaLocation="keyprov-pskc-1.0.xsd"/>
<xs:complexType name="AbstractRequestType" abstract="true">
<xs:annotation>
<xs:documentation> Basic types </xs:documentation>
</xs:annotation>
<xs:attribute name="Version" type="dskpp:VersionType"
use="required"/>
</xs:complexType>
<xs:complexType name="AbstractResponseType" abstract="true">
<xs:annotation>
<xs:documentation> Basic types </xs:documentation>
</xs:annotation>
<xs:attribute name="Version" type="dskpp:VersionType"
use="required"/>
<xs:attribute name="SessionID" type="dskpp:IdentifierType" />
<xs:attribute name="Status" type="dskpp:StatusCode"
use="required"/>
</xs:complexType>
<xs:simpleType name="VersionType">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string">
<xs:maxLength value="128" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="StatusCode">
<xs:restriction base="xs:string">
<xs:enumeration value="Continue" />
<xs:enumeration value="Success" />
<xs:enumeration value="Abort" />
<xs:enumeration value="AccessDenied" />
<xs:enumeration value="MalformedRequest" />
<xs:enumeration value="UnknownRequest" />
<xs:enumeration value="UnknownCriticalExtension" />
<xs:enumeration value="UnsupportedVersion" />
<xs:enumeration value="NoSupportedKeyTypes" />
<xs:enumeration value="NoSupportedEncryptionAlgorithms" />
<xs:enumeration value="NoSupportedMacAlgorithms" />
<xs:enumeration value="NoProtocolVariants" />
<xs:enumeration value="NoSupportedKeyPackages" />
<xs:enumeration value="AuthenticationDataMissing" />
<xs:enumeration value="AuthenticationDataInvalid" />
<xs:enumeration value="InitializationFailed" />
<xs:enumeration value="ProvisioningPeriodExpired" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeviceIdentifierDataType">
<xs:choice>
<xs:element name="DeviceId" type="pskc:DeviceInfoType" />
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
</xs:complexType>
<xs:simpleType name="PlatformType">
<xs:restriction base="xs:string">
<xs:enumeration value="Hardware" />
<xs:enumeration value="Software" />
<xs:enumeration value="Unspecified" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="TokenPlatformInfoType">
<xs:attribute name="KeyLocation"
type="dskpp:PlatformType"/>
<xs:attribute name="AlgorithmLocation"
type="dskpp:PlatformType"/>
</xs:complexType>
<xs:simpleType name="NonceType">
<xs:restriction base="xs:base64Binary">
<xs:minLength value="16" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="AlgorithmsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Algorithm" type="dskpp:AlgorithmType"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="AlgorithmType">
<xs:restriction base="xs:anyURI" />
</xs:simpleType>
<xs:complexType name="ProtocolVariantsType">
<xs:sequence>
<xs:element name="FourPass" minOccurs="0" />
<xs:element name="TwoPass"
type="dskpp:KeyProtectionDataType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyProtectionDataType">
<xs:annotation>
<xs:documentation xml:lang="en">
This element is only valid for two-pass DSKPP.
</xs:documentation>
</xs:annotation>
<xs:sequence maxOccurs="unbounded">
<xs:element name="SupportedKeyProtectionMethod"
type="xs:anyURI"/>
<xs:element name="Payload"
type="dskpp:PayloadType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PayloadType">
<xs:choice>
<xs:element name="Nonce" type="dskpp:NonceType" />
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="KeyPackagesFormatType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="KeyPackageFormatType">
<xs:restriction base="xs:anyURI" />
</xs:simpleType>
<xs:complexType name="AuthenticationDataType">
<xs:annotation>
<xs:documentation xml:lang="en">
Authentication Data contains a MAC.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="ClientID"
type="dskpp:IdentifierType" minOccurs="0"/>
<xs:choice>
<xs:element name="AuthenticationCodeMac"
type="dskpp:AuthenticationMacType"/>
<xs:any namespace="##other" processContents="strict" />
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AuthenticationMacType">
<xs:sequence>
<xs:element minOccurs="0" name="Nonce"
type="dskpp:NonceType"/>
<xs:element minOccurs="0" name="IterationCount"
type="xs:int"/>
<xs:element name="Mac" type="dskpp:MacType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="MacType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm" type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="KeyPackageType">
<xs:sequence>
<xs:element minOccurs="0" name="ServerID"
type="xs:anyURI"/>
<xs:element minOccurs="0" name="KeyProtectionMethod"
type="xs:anyURI" />
<xs:choice>
<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="InitializationTriggerType">
<xs:sequence>
<xs:element minOccurs="0" name="DeviceIdentifierData"
type="dskpp:DeviceIdentifierDataType" />
<xs:element minOccurs="0" name="KeyID"
type="xs:base64Binary"/>
<xs:element minOccurs="0" name="TokenPlatformInfo"
type="dskpp:TokenPlatformInfoType" />
<xs:element name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="ServerUrl"
type="xs:anyURI"/>
<xs:any minOccurs="0" namespace="##other"
processContents="strict" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ExtensionsType">
<xs:annotation>
<xs:documentation> Extension types </xs:documentation>
</xs:annotation>
<xs:sequence maxOccurs="unbounded">
<xs:element name="Extension"
type="dskpp:AbstractExtensionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AbstractExtensionType" abstract="true">
<xs:attribute name="Critical" type="xs:boolean" />
</xs:complexType>
<xs:complexType name="ClientInfoType">
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractExtensionType">
<xs:sequence>
<xs:element name="Data" type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ServerInfoType">
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractExtensionType">
<xs:sequence>
<xs:element name="Data" type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvTrigger"
type="dskpp:KeyProvTriggerType">
<xs:annotation>
<xs:documentation> DSKPP PDUs </xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvTriggerType">
<xs:annotation>
<xs:documentation xml:lang="en">
Message used to trigger the device to initiate a
DSKPP run.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="dskpp:InitializationTriggerType" />
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="dskpp:VersionType"/>
</xs:complexType>
<xs:element name="KeyProvClientHello"
type="dskpp:KeyProvClientHelloPDU">
<xs:annotation>
<xs:documentation>KeyProvClientHello PDU</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvClientHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from DSKPP Client to DSKPP Server to
initiate a DSKPP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractRequestType">
<xs:sequence>
<xs:element minOccurs="0" name="DeviceIdentifierData"
type="dskpp:DeviceIdentifierDataType" />
<xs:element minOccurs="0" name="KeyID"
type="xs:base64Binary" />
<xs:element minOccurs="0" name="ClientNonce"
type="dskpp:NonceType" />
<xs:element name="SupportedKeyTypes"
type="dskpp:AlgorithmsType" />
<xs:element name="SupportedEncryptionAlgorithms"
type="dskpp:AlgorithmsType" />
<xs:element name="SupportedMacAlgorithms"
type="dskpp:AlgorithmsType" />
<xs:element minOccurs="0"
name="SupportedProtocolVariants"
type="dskpp:ProtocolVariantsType" />
<xs:element minOccurs="0" name="SupportedKeyPackages"
type="dskpp:KeyPackagesFormatType" />
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvServerHello"
type="dskpp:KeyProvServerHelloPDU">
<xs:annotation>
<xs:documentation>KeyProvServerHello PDU</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Response message sent from DSKPP Server to DSKPP Client
in four-pass DSKPP.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType"
type="dskpp:AlgorithmType"/>
<xs:element name="EncryptionAlgorithm"
type="dskpp:AlgorithmType" />
<xs:element name="MacAlgorithm"
type="dskpp:AlgorithmType"/>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType"/>
<xs:element name="KeyPackageFormat"
type="dskpp:KeyPackageFormatType" />
<xs:element name="Payload" type="dskpp:PayloadType"/>
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
<xs:element minOccurs="0" name="Mac"
type="dskpp:MacType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvClientNonce"
type="dskpp:KeyProvClientNoncePDU">
<xs:annotation>
<xs:documentation>KeyProvClientNonce PDU</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvClientNoncePDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Response message sent from DSKPP Client to
DSKPP Server in a four-pass DSKPP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce"
type="xs:base64Binary"/>
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationDataType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
</xs:sequence>
<xs:attribute name="SessionID"
type="dskpp:IdentifierType" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="KeyProvServerFinished"
type="dskpp:KeyProvServerFinishedPDU">
<xs:annotation>
<xs:documentation>
KeyProvServerFinished PDU
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="KeyProvServerFinishedPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Final message sent from DSKPP Server to DSKPP Client in
a DSKPP session. A MAC value serves for key
confirmation, and optional AuthenticationData serves for
server authentication.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="dskpp:AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyPackage"
type="dskpp:KeyPackageType" />
<xs:element minOccurs="0" name="Extensions"
type="dskpp:ExtensionsType" />
<xs:element name="Mac" type="dskpp:MacType" />
<xs:element minOccurs="0" name="AuthenticationData"
type="dskpp:AuthenticationMacType" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
In order to assure that all implementations of DSKPP can interoperate, the DSKPP Server:
DSKPPのすべての実装が相互運用できることを保証するために、DSKPPサーバー：
a. MUST implement the four-pass variation of the protocol (Section 4)
a. プロトコルの4パスバリエーションを実装する必要があります（セクション4）
b. MUST implement the two-pass variation of the protocol (Section 5)
b. プロトコルの2パスバリエーションを実装する必要があります（セクション5）
c. MUST support user authentication (Section 3.2.1)
c. ユーザー認証をサポートする必要があります（セクション3.2.1）
d. MUST support the following key derivation functions: * DSKPP-PRF-AES DSKPP-PRF realization (Appendix D) * DSKPP-PRF-SHA256 DSKPP-PRF realization (Appendix D)
d. 次のキー導出関数をサポートする必要があります。
e. MUST support the following encryption mechanisms for protection of the client nonce in the four-pass protocol: * Mechanism described in Section 4.2.4
e. 4パスプロトコルでクライアントの非CEを保護するための次の暗号化メカニズムをサポートする必要があります： *セクション4.2.4で説明するメカニズム
f. MUST support one of the following encryption algorithms for
symmetric key operations, e.g., key wrap:
* KW-AES128 without padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
* KW-AES128 with padding; refer to
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC] and
[RFC5649]
* AES-CBC-128; refer to [FIPS197-AES]
g. MUST support the following encryption algorithms for asymmetric key operations, e.g., key transport: * RSA Encryption Scheme [PKCS-1]
g. 非対称キー操作のための次の暗号化アルゴリズムをサポートする必要があります。
h. MUST support the following integrity/KDF MAC functions: * DSKPP-PRF-AES (Appendix D) * DSKPP-PRF-SHA256 (Appendix D)
h. 次の整合性/KDF Mac関数をサポートする必要があります： * DSKPP-PRF-AES（付録D） * DSKPP-PRF-SHA256（付録D）
i. MUST support the PSKC key package [RFC6030]; all three PSKC key protection methods (Key Transport, Key Wrap, and Passphrase-Based Key Wrap) MUST be implemented
i. PSKCキーパッケージ[RFC6030]をサポートする必要があります。3つのPSKCキー保護方法（キートランスポート、キーラップ、およびパスフレーズベースのキーラップ）を実装する必要があります
j. MAY support the ASN.1 key package as defined in [RFC6031]
j. [RFC6031]で定義されているように、ASN.1キーパッケージをサポートすることができます
DSKPP Clients MUST support either the two-pass or the four-pass variant of the protocol. DSKPP Clients MUST fulfill all requirements listed in item (c) - (j).
DSKPPクライアントは、プロトコルの2パスまたは4パスバリアントのいずれかをサポートする必要があります。DSKPPクライアントは、アイテム（c） - （j）にリストされているすべての要件を満たす必要があります。
Finally, implementations of DSKPP MUST bind DSKPP messages to HTTP/1.1 as described in Section 7.2.
最後に、DSKPPの実装は、セクション7.2で説明されているように、DSKPPメッセージをHTTP/1.1にバインドする必要があります。
Of course, DSKPP is a security protocol, and one of its major functions is to allow only authorized parties to successfully initialize a cryptographic module with a new symmetric key. Therefore, a particular implementation may be configured with any of a number of restrictions concerning algorithms and trusted authorities that will prevent universal interoperability.
もちろん、DSKPPはセキュリティプロトコルであり、その主要な機能の1つは、認可された当事者のみが新しい対称キーを使用して暗号化モジュールを正常に初期化できるようにすることです。したがって、特定の実装は、普遍的な相互運用性を防ぐアルゴリズムと信頼できる当局に関する多くの制限のいずれかで構成される場合があります。
DSKPP is designed to protect generated keying material from exposure. No entities other than the DSKPP Server and the cryptographic module will have access to a generated K_TOKEN if the cryptographic algorithms used are of sufficient strength and, on the DSKPP Client side, generation and encryption of R_C and generation of K_TOKEN take place as specified in the cryptographic module. This applies even if malicious software is present in the DSKPP Client. However, as discussed in the following sub-sections, DSKPP does not protect against certain other threats resulting from man-in-the-middle attacks and other forms of attacks. DSKPP MUST, therefore, be run over a transport providing confidentiality and integrity, such as HTTP over Transport Layer Security (TLS) with a suitable ciphersuite [RFC2818], when such threats are a concern. Note that TLS ciphersuites with anonymous key exchanges are not suitable in those situations [RFC5246].
DSKPPは、生成されたキーイング材料を暴露から保護するように設計されています。DSKPPサーバーと暗号化モジュール以外のエンティティは、使用された暗号化アルゴリズムが十分な強度であり、DSKPPクライアント側ではR_Cの生成と暗号化とK_TOKENの生成が行われた場合、生成されたK_TOKENにアクセスできません。暗号化モジュール。これは、DSKPPクライアントに悪意のあるソフトウェアが存在する場合でも適用されます。ただし、以下のサブセクションで説明したように、DSKPPは、中間の攻撃や他の形態の攻撃に起因する特定の他の脅威から保護しません。したがって、DSKPPは、そのような脅威が懸念される場合、適切なCiphersuite [RFC2818]を使用して、輸送層セキュリティ（TLS）を超えるHTTPなどの秘密性と整合性を提供する輸送上で実行する必要があります。匿名のキー交換を備えたTLSシファースーツは、そのような状況では適していないことに注意してください[RFC5246]。
An active attacker MAY attempt to modify, delete, insert, replay, or reorder messages for a variety of purposes including service denial and compromise of generated keying material.
アクティブな攻撃者は、サービスの拒否や生成されたキーイング材料の妥協など、さまざまな目的でメッセージを変更、削除、挿入、リプレイ、または再注文しようとする場合があります。
Modifications to a <KeyProvTrigger> message will either cause denial of service (modifications of any of the identifiers or the Authentication Code) or will cause the DSKPP Client to contact the wrong DSKPP Server. The latter is in effect a man-in-the-middle attack and is discussed further in Section 10.2.7.
<keyprovtrigger>メッセージの変更は、サービスの拒否（識別子または認証コードの変更）を引き起こすか、DSKPPクライアントに間違ったDSKPPサーバーに連絡するようになります。後者は実際には中間の攻撃であり、セクション10.2.7でさらに議論されています。
An attacker may modify a <KeyProvClientHello> message. This means that the attacker could indicate a different key or device than the one intended by the DSKPP Client, and could also suggest other cryptographic algorithms than the ones preferred by the DSKPP Client, e.g., cryptographically weaker ones. The attacker could also suggest earlier versions of DSKPP, in case these versions have been shown to have vulnerabilities. These modifications could lead to an attacker succeeding in initializing or modifying another cryptographic module than the one intended (i.e., the server assigning the generated key to the wrong module) or gaining access to a generated key through the use of weak cryptographic algorithms or protocol versions. DSKPP implementations MAY protect against the latter by having strict policies about what versions and algorithms they support and accept. The former threat (assignment of a generated key to the wrong module) is not possible when the shared-key variant of DSKPP is employed (assuming existing shared keys are unique per cryptographic module), but is possible in the public key variation. Therefore, DSKPP Servers MUST NOT accept unilaterally provided device identifiers in the public key variation. This is also indicated in the protocol description. In the shared-key variation, however, an attacker may be able to provide the wrong identifier (possibly also leading to the incorrect user being associated with the generated key) if the attacker has real-time access to the cryptographic module with the identified key. The result of this attack could be that the generated key is associated with the correct cryptographic module but the module is associated with the incorrect user. See Section 10.5 for a further discussion of this threat and possible countermeasures.
攻撃者は、<keyprovclienthello>メッセージを変更できます。これは、攻撃者がDSKPPクライアントが意図したものとは異なるキーまたはデバイスを示すことができ、DSKPPクライアント、たとえば暗号的に弱いものよりも他の暗号化アルゴリズムを示唆することができることを意味します。攻撃者は、これらのバージョンに脆弱性があることが示されている場合に備えて、DSKPPの以前のバージョンを提案することもできます。これらの変更は、攻撃者が他の暗号化モジュールの初期化または変更に成功する可能性があります（つまり、生成されたキーを間違ったモジュールに割り当てるサーバー）、または弱い暗号化アルゴリズムまたはプロトコルバージョンの使用を通じて生成されたキーへのアクセスを獲得することができます。。DSKPPの実装は、サポートおよび受け入れるバージョンとアルゴリズムについて厳格なポリシーを持つことにより、後者から保護する場合があります。DSKPPの共有キーバリアントが採用されている場合（既存の共有キーが暗号化モジュールごとに一意であると仮定して）、以前の脅威（間違ったモジュールへの生成されたキーの割り当て）は不可能ですが、公開キーのバリエーションでは可能です。したがって、DSKPPサーバーは、公開キーのバリエーションで一方的に提供されたデバイス識別子を受け入れてはなりません。これは、プロトコルの説明にも示されています。ただし、共有キーのバリエーションでは、攻撃者が識別されたキーを使用して暗号化モジュールにリアルタイムでアクセスできる場合、攻撃者が間違った識別子（生成されたキーに関連付けられている誤ったユーザーにもつながる可能性がある可能性があります）を提供できる場合があります。。この攻撃の結果、生成されたキーが正しい暗号化モジュールに関連付けられているが、モジュールは間違ったユーザーに関連付けられている可能性があります。この脅威と可能性のある対策についてのさらなる議論については、セクション10.5を参照してください。
An attacker may also modify a <KeyProvServerHello> message. This means that the attacker could indicate different key types, algorithms, or protocol versions than the legitimate server would, e.g., cryptographically weaker ones. The attacker may also provide a different nonce than the one sent by the legitimate server. Clients MAY protect against the former through strict adherence to policies regarding permissible algorithms and protocol versions. The latter (wrong nonce) will not constitute a security problem, as a generated key will not match the key generated on the legitimate server. Also, whenever the DSKPP run would result in the replacement of an existing key, the <Mac> element protects against modifications of R_S.
攻撃者は、<keyprovserverhello>メッセージを変更することもできます。これは、攻撃者が、例えば暗号化されたサーバーのサーバーとは、異なるキータイプ、アルゴリズム、またはプロトコルバージョンを示すことができることを意味します。攻撃者は、正当なサーバーから送信されたサーバーとは異なる非CEを提供する場合があります。クライアントは、許容されるアルゴリズムとプロトコルバージョンに関するポリシーを厳密に遵守することにより、前者を保護する場合があります。後者（間違った非CE）はセキュリティの問題を構成しません。生成されたキーは、正当なサーバーで生成されたキーと一致しないためです。また、DSKPPの実行が既存のキーを置き換えると、<Mac>要素はR_Sの変更から保護されます。
Modifications of <KeyProvClientNonce> messages are also possible. If an attacker modifies the SessionID attribute, then, in effect, a switch to another session will occur at the server, assuming the new SessionID is valid at that time on the server. It still will not allow the attacker to learn a generated K_TOKEN since R_C has been wrapped for the legitimate server. Modifications of the <EncryptedNonce> element, e.g., replacing it with a value for which the attacker knows an underlying R'C, will not result in the client changing its pre-DSKPP state, since the server will be unable to provide a valid MAC in its final message to the client. The server MAY, however, end up storing K'TOKEN rather than K_TOKEN. If the cryptographic module has been associated with a particular user, then this could constitute a security problem. For a further discussion about this threat, and a possible countermeasure, see Section 10.5 below. Note that use of TLS does not protect against this attack if the attacker has access to the DSKPP Client (e.g., through malicious software, "Trojans") [RFC5246].
<keyprovclientnonce>メッセージの変更も可能です。攻撃者がSessionID属性を変更した場合、実際には、サーバーで新しいSessionIDが有効であると仮定して、サーバーで別のセッションへの切り替えが発生します。R_Cが合法的なサーバーにラップされているため、攻撃者が生成されたK_TOKENを学習することはできません。<encryptedNonce>要素の変更、たとえば、攻撃者が基礎となるR'Cを知っている値に置き換えると、サーバーは有効なMacを提供できないため、クライアントがDSKPP以前の状態を変更しません。クライアントへの最後のメッセージ。ただし、サーバーは、K_TOKENではなくK'TOKENを保存することになります。暗号化モジュールが特定のユーザーに関連付けられている場合、これはセキュリティの問題を構成する可能性があります。この脅威についてのさらなる議論、および可能性のある対策については、以下のセクション10.5を参照してください。TLSの使用は、攻撃者がDSKPPクライアントにアクセスできる場合（例えば、悪意のあるソフトウェア「トロイの木馬」）[RFC5246]を使用している場合、この攻撃から保護しないことに注意してください。
Finally, attackers may also modify the <KeyProvServerFinished> message. Replacing the <Mac> element will only result in denial of service. Replacement of any other element may cause the DSKPP Client to associate, e.g., the wrong service with the generated key. DSKPP SHOULD be run over a transport providing confidentiality and integrity when this is a concern.
最後に、攻撃者は<keyprovserverfinished>メッセージを変更することもできます。<mac>要素を置き換えると、サービスが拒否されるだけです。他の要素を置き換えると、DSKPPクライアントが生成されたキーとの間違ったサービスを関連付けることがあります。DSKPPは、これが懸念事項である場合、機密性と完全性を提供する輸送上で実行する必要があります。
Message deletion will not cause any other harm than denial of service, since a cryptographic module MUST NOT change its state (i.e., "commit" to a generated key) until it receives the final message from the DSKPP Server and successfully has processed that message, including validation of its MAC. A deleted <KeyProvServerFinished> message will not cause the server to end up in an inconsistent state vis-a-vis the cryptographic module if the server implements the suggestions in Section 10.5.
暗号化モジュールは、DSKPPサーバーから最終メッセージを受信し、そのメッセージを正常に処理するまで、暗号化モジュールが状態を変更してはならない（つまり、生成されたキーに「コミット」する）、拒否以外の害を引き起こすことはありません。Macの検証を含む。削除された<keyprovserverfinished>メッセージは、サーバーがセクション10.5で提案を実装した場合、暗号化モジュールの存在状態の一貫性のない状態になることはありません。
An active attacker may initiate a DSKPP run at any time, and suggest any device identifier. DSKPP Server implementations MAY receive some protection against inadvertently initializing a key or inadvertently replacing an existing key or assigning a key to a cryptographic module by initializing the DSKPP run by use of the <KeyProvTrigger>. The <AuthenticationData> element allows the server to associate a DSKPP run e.g., with an earlier user-authenticated session. The security of this method, therefore, depends on the ability to protect the <AuthenticationData> element in the DSKPP initialization message. If an eavesdropper is able to capture this message, he may race the legitimate user for a key initialization. DSKPP over a transport providing confidentiality and integrity, coupled with the recommendations in Section 10.5, is RECOMMENDED when this is a concern.
アクティブな攻撃者は、いつでもDSKPP実行を開始し、任意のデバイス識別子を提案することができます。DSKPPサーバーの実装は、<keyprovtrigger>を使用してDSKPPを初期化することにより、キーを不注意に初期化するか、既存のキーを不注意に置き換えるか、暗号化モジュールにキーを割り当てることからある程度の保護を受ける場合があります。<AuthenticationData>要素により、サーバーは、以前のユーザー認証セッションでDSKPP実行を関連付けることができます。したがって、このメソッドのセキュリティは、DSKPP初期化メッセージの<AuthenticationData>要素を保護する機能に依存します。盗聴者がこのメッセージをキャプチャできる場合、キーイニシャル化のために正当なユーザーをレースすることができます。これが懸念事項である場合は、セクション10.5の推奨事項と相まって、機密性と完全性を提供する輸送に関するDSKPPが推奨されます。
Insertion of other messages into an existing protocol run is seen as equivalent to modification of legitimately sent messages.
既存のプロトコルの実行に他のメッセージを挿入することは、合法的に送信されたメッセージの変更に相当すると見なされます。
During four-pass DSKPP, attempts to replay a previously recorded DSKPP message will be detected, as the use of nonces ensures that both parties are live. For example, a DSKPP Client knows that a server it is communicating with is "live" since the server MUST create a MAC on information sent by the client.
4パスDSKPP中に、以前に記録されたDSKPPメッセージを再生しようとする試みが検出されます。ノンセの使用により、両当事者がライブであることが保証されます。たとえば、DSKPPクライアントは、クライアントから送信された情報でサーバーがMacを作成する必要があるため、通信しているサーバーが「ライブ」であることを知っています。
The same is true for two-pass DSKPP thanks to the requirement that the client sends R in the <KeyProvClientHello> message and that the server includes R in the MAC computation.
クライアントが<keyprovclienthello>メッセージでRを送信するという要件と、サーバーがMac計算にrを含むという要件のおかげで、2パスDSKPPにも同じことが言えます。
An attacker may attempt to re-order four-pass DSKPP messages but this will be detected, as each message is of a unique type. Note: Message re-ordering attacks cannot occur in two-pass DSKPP since each party sends at most one message each.
攻撃者は4パスDSKPPメッセージを再注文しようとする場合がありますが、各メッセージは一意のタイプであるため、これが検出されます。注：各パーティーはそれぞれ最大1つのメッセージを送信するため、2パスDSKPPでメッセージの再注文攻撃は発生できません。
In addition to other active attacks, an attacker posing as a man in the middle may be able to provide his own public key to the DSKPP Client. This threat and countermeasures to it are discussed in Section 4.1.1. An attacker posing as a man in the middle may also be acting as a proxy and, hence, may not interfere with DSKPP runs but still learn valuable information; see Section 10.3.
他のアクティブな攻撃に加えて、真ん中にいる男性を装った攻撃者は、DSKPPクライアントに自分の公開鍵を提供できる場合があります。この脅威とそれに対する対策については、セクション4.1.1で説明します。真ん中の男性を装った攻撃者は、代理人としても機能している可能性があるため、DSKPPの実行を妨げない可能性がありますが、それでも貴重な情報を学習できます。セクション10.3を参照してください。
Passive attackers may eavesdrop on DSKPP runs to learn information that later on may be used to impersonate users, mount active attacks, etc.
受動的な攻撃者は、DSKPPを実行して、後でユーザーになりすましたり、アクティブな攻撃をマウントしたりするために使用される情報を学習するために実行されます。
If DSKPP is not run over a transport providing confidentiality, a passive attacker may learn:
DSKPPが機密性を提供する輸送機関で実行されていない場合、受動的な攻撃者は次のことを学ぶことができます。
o What cryptographic modules a particular user possesses
o 特定のユーザーが持っている暗号化モジュール
o The identifiers of keys on those cryptographic modules and other attributes pertaining to those keys, e.g., the lifetime of the keys
o これらの暗号化モジュールおよびそれらのキーに関連するその他の属性のキーの識別子、例えばキーの寿命
o DSKPP versions and cryptographic algorithms supported by a particular DSKPP Client or server
o 特定のDSKPPクライアントまたはサーバーによってサポートされるDSKPPバージョンと暗号化アルゴリズム
o Any value present in an <extension> that is part of <KeyProvClientHello>
o <keyprovclienthello>の一部である<extension>に存在する任意の値
Whenever the above is a concern, DSKPP MUST be run over a transport providing confidentiality. If man-in-the-middle attacks for the purposes described above are a concern, the transport MUST also offer server-side authentication.
上記が懸念されるときはいつでも、DSKPPは機密性を提供する輸送を介して実行する必要があります。上記の目的で中間の攻撃が懸念事項である場合、トランスポートはサーバー側の認証も提供する必要があります。
An attacker with unlimited access to an initialized cryptographic module may use the module as an "oracle" to pre-compute values that later on may be used to impersonate the DSKPP Server. Section 4.1.1 contains a discussion of this threat and steps RECOMMENDED to protect against it.
初期化された暗号化モジュールに無制限にアクセスできる攻撃者は、モジュールを「Oracle」として使用して、後でDSKPPサーバーを偽装するために使用される値を事前計算することができます。セクション4.1.1には、この脅威とそれを保護するために推奨される手順の議論が含まれています。
Implementers are advised that cryptographic algorithms become weaker with time. As new cryptographic techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations SHOULD be modular allowing new algorithms to be readily inserted. That is, implementers SHOULD be prepared to regularly update the algorithms in their implementations.
実装者は、暗号化アルゴリズムが時間とともに弱くなることをお勧めします。新しい暗号化技術が開発され、コンピューティングのパフォーマンスが向上すると、特定の暗号化アルゴリズムを破る作業要因が減少します。したがって、暗号化アルゴリズムの実装は、新しいアルゴリズムを容易に挿入できるようにするモジュラーである必要があります。つまり、実装者は、実装のアルゴリズムを定期的に更新する準備をする必要があります。
If keys generated in DSKPP will be associated with a particular user at the DSKPP Server (or a server trusted by, and communicating with the DSKPP Server), then in order to protect against threats where an attacker replaces a client-provided encrypted R_C with his own R'C (regardless of whether the public key variation or the shared-secret variation of DSKPP is employed to encrypt the client nonce), the server SHOULD NOT commit to associate a generated K_TOKEN with the given cryptographic module until the user simultaneously has proven both possession of the device that hosts the cryptographic module containing K_TOKEN and some out-of-band provided authenticating information (e.g., an Authentication Code). For example, if the cryptographic module is a one-time password token, the user could be required to authenticate with both a one-time password generated by the cryptographic module and an out-of-band provided Authentication Code in order to have the server "commit" to the generated OTP value for the given user. Preferably, the user SHOULD perform this operation from another host than the one used to initialize keys on the cryptographic module, in order to minimize the risk of malicious software on the client interfering with the process.
DSKPPで生成されたキーがDSKPPサーバーの特定のユーザー（またはDSKPPサーバーによって信頼され、DSKPPサーバーと通信されるサーバー）に関連付けられている場合、攻撃者がクライアントが提供する暗号化されたR_Cを彼のクライアントが提供するR_Cを置き換える脅威から保護するために独自のR'C（公開キーのバリエーションまたはDSKPPの共有分泌範囲のバリエーションがクライアントNonCeを暗号化するために採用されているかどうかに関係なく、サーバーは、ユーザーが同時に証明されるまで、生成されたK_TOKENを特定の暗号モジュールに関連付けることをコミットすべきではありませんK_TOKENを含む暗号化モジュールをホストするデバイスの所有と、一部の帯域外では、認証情報（認証コードなど）が提供されました。たとえば、暗号化モジュールが1回限りのパスワードトークンである場合、ユーザーは、暗号化モジュールによって生成された1回限りのパスワードと、サーバーを持つために帯域外で提供された認証コードの両方で認証する必要があります。指定されたユーザーの生成されたOTP値に「コミット」します。できれば、ユーザーは、クライアントがプロセスに干渉する悪意のあるソフトウェアのリスクを最小限に抑えるために、暗号化モジュールのキーを初期化するために使用されるホストよりも別のホストからこの操作を実行する必要があります。
Note: This scenario, wherein the attacker replaces a client-provided R_C with his own R'C, does not apply to two-pass DSKPP as the client does not provide any entropy to K_TOKEN. The attack as such (and its countermeasures) still applies to two-pass DSKPP, however, as it essentially is a man-in-the-middle attack.
注：攻撃者がクライアントが提供するR_Cを自分のR'Cに置き換えるこのシナリオは、クライアントがK_TOKENにエントロピーを提供しないため、2パスDSKPPには適用されません。ただし、そのような攻撃（およびその対策）は、本質的には中程度の攻撃であるため、2パスDSKPPに依然として適用されます。
Another threat arises when an attacker is able to trick a user into authenticating to the attacker rather than to the legitimate service before the DSKPP run. If successful, the attacker will then be able to impersonate the user towards the legitimate service, and subsequently receive a valid DSKPP trigger. If the public key variant of DSKPP is used, this may result in the attacker being able to (after a successful DSKPP run) impersonate the user. Ordinary precautions MUST, therefore, be in place to ensure that users authenticate only to legitimate services.
別の脅威は、攻撃者がDSKPPが実行される前に正当なサービスではなく、攻撃者に認証するようにユーザーをだましている場合に発生します。成功した場合、攻撃者はユーザーに正当なサービスになりすまし、その後有効なDSKPPトリガーを受け取ることができます。DSKPPの公開キーのバリアントが使用されている場合、これにより、攻撃者が（成功したDSKPP実行後）ユーザーになりすますことができるようになります。したがって、ユーザーが正当なサービスのみに認証されるようにするために、通常の予防措置を整える必要があります。
In four-pass DSKPP, both the client and the server provide randomizing material to K_TOKEN, in a manner that allows both parties to verify that they did contribute to the resulting key. In the two-pass DSKPP version defined herein, only the server contributes to the entropy of K_TOKEN. This means that a broken or compromised (pseudo)random number generator in the server may cause more damage than it would in the four-pass variant. Server implementations SHOULD therefore take extreme care to ensure that this situation does not occur.
4パスDSKPPでは、クライアントとサーバーの両方がK_TOKENにランダム化資料を提供します。本明細書で定義されている2パスDSKPPバージョンでは、サーバーのみがK_TOKENのエントロピーに寄与します。これは、サーバー内の壊れたまたは侵害された（擬似）乱数ジェネレーターが、4パスバリアントよりも多くの損傷を引き起こす可能性があることを意味します。したがって、サーバーの実装は、この状況が発生しないことを確認するために非常に注意する必要があります。
four-pass DSKPP Servers provide key confirmation through the MAC on R_C in the <KeyProvServerFinished> message. In the two-pass DSKPP variant described herein, key confirmation is provided by the MAC including R, using K_MAC.
4パスDSKPPサーバーは、<keyprovserverfinished>メッセージのR_CのMacを介して重要な確認を提供します。本明細書に記載されている2パスDSKPPバリアントでは、K_MACを使用してRを含むMACによって重要な確認が提供されます。
DSKPP Servers MUST authenticate themselves whenever a successful DSKPP two-pass protocol run would result in an existing K_TOKEN being replaced by a K_TOKEN', or else a denial-of-service attack where an unauthorized DSKPP Server replaces a K_TOKEN with another key would be possible. In two-pass DSKPP, servers authenticate by including the AuthenticationDataType extension containing a MAC as described in Section 5 for two-pass DSKPP.
DSKPPサーバーは、DSKPPの2パスプロトコルの実行が成功すると、既存のK_TOKENがK_TOKENに置き換えられる場合、または不正なDSKPPサーバーが別のキーに置き換えられるサービス拒否攻撃を行うと、自分自身を認証する必要があります。。2パスDSKPPでは、セクション5で説明されているMACを含むAuthenticationDatatype拡張子を2パスDSKPPのAuthenticationDatatype拡張子を含めることにより、サーバーが認証されます。
Whenever a successful DSKPP two-pass protocol run would result in an existing K_TOKEN being replaced by a K_TOKEN', the DSKPP Client and Server MUST do the following to prevent a denial-of-service attack where an unauthorized DSKPP Server replaces a K_TOKEN with another key:
DSKPPの2パスプロトコルの実行が成功すると、既存のK_TOKENがK_TOKENに置き換えられる場合、DSKPPクライアントとサーバーは、不正なDSKPPサーバーがK_TOKENを別のDSKPPサーバーに置き換えるサービス拒否攻撃を防ぐために以下を実行する必要があります。鍵：
o The DSKPP Server MUST use the AuthenticationDataType extension to transmit a second MAC, calculated as described in Section 5.2.2.
o DSKPPサーバーは、セクション5.2.2で説明されているように計算された2番目のMACを送信するために、AuthenticationDatatype拡張機能を使用する必要があります。
o The DSKPP Client MUST authenticate the server using the MAC contained in the AuthenticationDataType extension received from the DSKPP Server to which it is connected.
o DSKPPクライアントは、接続されているDSKPPサーバーから受信したAuthenticationDatatype拡張機能に含まれるMacを使用してサーバーを認証する必要があります。
A DSKPP Server MUST authenticate a client to ensure that K_TOKEN is delivered to the intended device. The following measures SHOULD be considered:
DSKPPサーバーは、K_TOKENが意図したデバイスに配信されるようにクライアントを認証する必要があります。以下の測定値を考慮する必要があります。
o When an Authentication Code is used for client authentication, a password dictionary attack on the Authentication Data is possible.
o クライアント認証に認証コードが使用される場合、認証データに対するパスワード辞書攻撃が可能です。
o The length of the Authentication Code when used over a non-secure channel SHOULD be longer than what is used over a secure channel. When a device, e.g., some mobile phones with small screens, cannot handle a long Authentication Code in a user-friendly manner, DSKPP SHOULD rely on a secure channel for communication.
o 非セキュアチャネルで使用する場合の認証コードの長さは、安全なチャネルで使用されるものよりも長くする必要があります。たとえば、小さな画面を備えた一部の携帯電話では、ユーザーフレンドリーな方法で長い認証コードを処理できない場合、DSKPPはコミュニケーションのために安全なチャネルに依存する必要があります。
o In the case that a non-secure channel has to be used, the Authentication Code SHOULD be sent to the server MAC'd as specified in Section 3.4.1. The Authentication Code and nonce value MUST be strong enough to prevent offline brute-force recovery of the Authentication Code from the Hashed MAC (HMAC) data. Given that the nonce value is sent in plaintext format over a non-secure transport, the cryptographic strength of the Authentication Data depends more on the quality of the Authentication Code.
o 非セキュアチャネルを使用する必要がある場合、セクション3.4.1で指定されているように、認証コードをサーバーMAC'Dに送信する必要があります。認証コードとNonCE値は、Hashed Mac（HMAC）データから認証コードのオフラインのブルートフォース回復を防ぐのに十分な強力でなければなりません。NonCe値が非セキュアなトランスポートよりもプレーンテキスト形式で送信されることを考えると、認証データの暗号化強度は、認証コードの品質により大きく依存します。
o When the Authentication Code is sent from the DSKPP Server to the device in a DSKPP initialization trigger message, an eavesdropper may be able to capture this message and race the legitimate user for a key initialization. To prevent this, the transport layer used to send the DSKPP trigger MUST provide confidentiality and integrity, e.g. a secure browser session.
o dskpp初期化トリガーメッセージで認証コードがdskppサーバーからデバイスに送信されると、盗聴者はこのメッセージをキャプチャし、キーイニシャル化のために正当なユーザーに競うことができます。これを防ぐために、DSKPPトリガーの送信に使用される輸送層は、機密性と整合性を提供する必要があります。安全なブラウザセッション。
Three key protection methods are defined for the different usages of two-pass DSKPP, which MUST be supported by a key package format, such as [RFC6030] and [RFC6031]. Therefore, key protection in the two-pass DSKPP is dependent upon the security of the key package format selected for a protocol run. Some considerations for the Passphrase-Based Key Wrap method follow.
[RFC6030]や[RFC6031]などのキーパッケージ形式でサポートする必要がある2パスDSKPPのさまざまな使用法に対して、3つの主要な保護方法が定義されています。したがって、2パスDSKPPの主要な保護は、プロトコルの実行に選択されたキーパッケージ形式のセキュリティに依存します。PassPhraseベースのキーラップメソッドに関するいくつかの考慮事項が続きます。
The Passphrase-Based Key Wrap method SHOULD depend upon the PBKDF2 function from [PKCS-5] to generate an encryption key from a passphrase and salt string. It is important to note that passphrase-based encryption is generally limited in the security that it provides despite the use of salt and iteration count in PBKDF2 to increase the complexity of attack. Implementations SHOULD therefore take additional measures to strengthen the security of the Passphrase-Based Key Wrap method. The following measures SHOULD be considered where applicable:
PassPhraseベースのキーラップメソッドは、[PKCS-5]のPBKDF2関数に依存して、パスフレーズと塩の弦から暗号化キーを生成する必要があります。PassPhraseベースの暗号化は一般に、PBKDF2で塩と反復数を使用して攻撃の複雑さを高めるにもかかわらず、セキュリティにおいて制限されていることに注意することが重要です。したがって、実装は、PassPhraseベースのキーラップメソッドのセキュリティを強化するために追加の措置を講じる必要があります。該当する場合は、次の措置を考慮する必要があります。
o The passphrase is the same as the one-time password component of the Authentication Code (see Section 3.4.1) for a description of the AC format). The passphrase SHOULD be selected well, and usage guidelines such as the ones in [NIST-PWD] SHOULD be taken into account.
o PassPhraseは、AC形式の説明については、認証コードの1回限りのパスワードコンポーネント（セクション3.4.1を参照）と同じです）。パスフレーズは適切に選択する必要があり、[nist-pwd]のような使用ガイドラインを考慮する必要があります。
o A different passphrase SHOULD be used for every key initialization wherever possible (the use of a global passphrase for a batch of cryptographic modules SHOULD be avoided, for example). One way to achieve this is to use randomly generated passphrases.
o 可能な限り、キーの初期化ごとに別のパスフレーズを使用する必要があります（たとえば、暗号化モジュールのバッチにグローバルパスフレーズを使用することを避ける必要があります）。これを達成する1つの方法は、ランダムに生成されたパスフレーズを使用することです。
o The passphrase SHOULD be protected well if stored on the server and/or on the cryptographic module and SHOULD be delivered to the device's user using secure methods.
o パスフレーズは、サーバーや暗号化モジュールに保存する場合は適切に保護する必要があり、安全な方法を使用してデバイスのユーザーに配信する必要があります。
o User pre-authentication SHOULD be implemented to ensure that K_TOKEN is not delivered to a rogue recipient.
o k_tokenが不正な受信者に配信されないことを確認するために、ユーザーの事前認証を実装する必要があります。
o The iteration count in PBKDF2 SHOULD be high to impose more work for an attacker using brute-force methods (see [PKCS-5] for recommendations). However, it MUST be noted that the higher the count, the more work is required on the legitimate cryptographic module to decrypt the newly delivered K_TOKEN. Servers MAY use relatively low iteration counts to accommodate devices with limited processing power such as some PDA and cell phones when other security measures are implemented and the security of the Passphrase-Based Key Wrap method is not weakened.
o PBKDF2の反復カウントは、ブルートフォース方法を使用して攻撃者により多くの作業を課すために高くなければなりません（推奨については[PKCS-5]を参照）。ただし、カウントが高いほど、新しく配信されたK_TOKENを復号化するために、合法的な暗号化モジュールにより多くの作業が必要であることに注意する必要があります。サーバーは、他のセキュリティ対策が実装され、PassPhraseベースのキーラップメソッドのセキュリティが弱体化しない場合、一部のPDAや携帯電話などの制限された処理能力を持つデバイスに対応するために、比較的低い反復カウントを使用する場合があります。
o TLS [RFC5246] SHOULD be used where possible to protect a two-pass protocol run. Transport level security provides a second layer of protection for the newly generated K_TOKEN.
o TLS [RFC5246]は、可能な限り2パスプロトコルの実行を保護するために使用する必要があります。輸送レベルのセキュリティは、新しく生成されたK_TOKENの2番目の保護層を提供します。
Many protocols need to be algorithm agile. One reason for this is that in the past many protocols had fixed sized fields for information such as hash outputs, keys, etc. This is not the case for DSKPP, except for the key size in the computation of DSKPP-PRF. Another reason was that protocols did not support algorithm negotiation. This is also not the case for DSKPP, except for the use of SHA-256 in the MAC confirmation message. Updating the key size for DSKPP-PRF or the MAC confirmation message algorithm will require a new version of the protocol, which is supported with the Version attribute.
多くのプロトコルは、アルゴリズムアジャイルである必要があります。この理由の1つは、過去に多くのプロトコルがハッシュ出力、キーなどの情報のために固定サイズのフィールドを持っていたことです。これは、DSKPP-PRFの計算のキーサイズを除き、DSKPPの場合ではありません。もう1つの理由は、プロトコルがアルゴリズムの交渉をサポートしていないことです。これは、MAC確認メッセージでSHA-256を使用することを除いて、DSKPPの場合もありません。DSKPP-PRFまたはMAC確認メッセージアルゴリズムのキーサイズを更新するには、バージョン属性でサポートされているプロトコルの新しいバージョンが必要です。
DSKPP is meant for machine-to-machine communications; as such, its elements are tokens not meant for direct human consumption. DSKPP exchanges information using XML. All XML processors are required to understand UTF-8 [RFC3629] encoding, and therefore all DSKPP Clients and servers MUST understand UTF-8 encoded XML. Additionally, DSKPP Servers and clients MUST NOT encode XML with encodings other than UTF-8.
DSKPPは、マシン間通信を対象としています。そのため、その要素は、直接的な人間の消費向けではないトークンです。DSKPPはXMLを使用して情報を交換します。すべてのXMLプロセッサは、UTF-8 [RFC3629]エンコードを理解するために必要であるため、すべてのDSKPPクライアントとサーバーはUTF-8エンコードされたXMLを理解する必要があります。さらに、DSKPPサーバーとクライアントは、UTF-8以外のエンコーディングでXMLをエンコードしてはなりません。
This document requires several IANA registrations, detailed below.
このドキュメントでは、以下に詳述されているいくつかのIANA登録が必要です。
This section registers a new XML namespace, "urn:ietf:params:xml:ns:keyprov:dskpp" per the guidelines in [RFC3688]:
このセクションでは、[rfc3688]のガイドラインに従って、新しいxml名空間「urn：ietf：xml：xml：ns：keyprov：dskpp」を登録します。
URI: urn:ietf:params:xml:ns:keyprov:dskpp
Registrant Contact:
IETF, KEYPROV Working Group (keyprov@ietf.org), Andrea Doherty
(andrea.doherty@rsa.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DSKPP Messages</title>
</head>
<body>
<h1>Namespace for DSKPP Messages</h1>
<h2>urn:ietf:params:xml:ns:keyprov:dskpp</h2>
<p>See RFC 6063</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:ns:keyprov:dskpp Registrant Contact: IETF, KEYPROV Working Group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com) Schema: The XML for this schema can be found as the entirety of Section 8 of this document.
uri：urn：ietf：params：xml：ns：keyprov：keyprov：dskpp登録者連絡先：ietf、keyprovワーキンググループ（keyprov@ietf.org）、アンドレアドハティ（andrea.doherty@rsa.com）スキーマ：このスキーマのためのXMLこのドキュメントのセクション8の全体として見つかります。
This section registers the "application/dskpp+xml" MIME type:
このセクションでは、「アプリケーション/DSKPP XML」MIMEタイプを登録します。
To: ietf-types@iana.org Subject: Registration of MIME media type application/dskpp+xml MIME media type name: application MIME subtype name: dskpp+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See [RFC3023], Section 3.2. Implementations need to support UTF-8 [RFC3629]. Security considerations: This content type is designed to carry protocol data related to key management. Security mechanisms are built into the protocol to ensure that various threats are dealt with. Refer to Section 10 of RFC 6063 for more details Interoperability considerations: None Published specification: RFC 6063. Applications that use this media type: Protocol for key exchange. Additional information: Magic Number(s): (none) File extension(s): .xmls Macintosh File Type Code(s): (none) Person & email address to contact for further information: Andrea Doherty (andrea.doherty@rsa.com) Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC3023], and many of the considerations described there also apply to application/dskpp+xml.
宛先：ietf-types@iana.org件名：MIMEメディアタイプアプリケーションの登録/DSKPP XML MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：DSKPP XML必須パラメーター：（なし）オプションパラメーター：charsetは、囲まれたXMLの文字エンコーディングを示します。考慮事項のエンコーディング：使用する文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。[RFC3023]、セクション3.2を参照してください。実装はUTF-8 [RFC3629]をサポートする必要があります。セキュリティ上の考慮事項：このコンテンツタイプは、主要な管理に関連するプロトコルデータを運ぶように設計されています。セキュリティメカニズムは、さまざまな脅威が対処されるようにプロトコルに組み込まれています。詳細については、相互運用性の考慮事項については、RFC 6063のセクション10を参照してください。追加情報：マジック番号：（なし）ファイル拡張子：.xmls Macintoshファイルタイプコード：（なし）人とメールアドレスを連絡先に詳細については、Andrea Doherty（andrea.doherty@rsa。com）意図された使用法：使用著者/変更コントローラー：IETFその他の情報：このメディアタイプはアプリケーション/XML [RFC3023]の専門化であり、そこに記載されている考慮事項の多くは、アプリケーション/DSKPP XMLにも適用されます。
This section registers status codes included in each DSKPP response message. The status codes are defined in the schema in the <StatusCode> type definition contained in the XML schema in Section 8. The following summarizes the registry:
このセクションは、各DSKPP応答メッセージに含まれるステータスコードを登録します。ステータスコードは、セクション8のXMLスキーマに含まれる<statusCode>タイプ定義のスキーマで定義されています。以下は、レジストリを要約しています。
Related Registry: KEYPROV DSKPP Registries, Status codes for DSKPP
関連レジストリ：keyprov dskppレジストリ、dskppのステータスコード
Defining RFC: RFC 6063. Registration/Assignment Procedures: Following the policies outlined in [RFC3575], the IANA policy for assigning new values for the status codes for DSKPP MUST be "Specification Required" and their meanings MUST be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. No mechanism to mark entries as "deprecated" is envisioned. It is possible to update entries from the registry.
RFCの定義：RFC6063。登録/割り当て手順：[RFC3575]で概説されているポリシーに従うには、DSKPPのステータスコードの新しい値を割り当てるためのIANAポリシーは「必要な仕様」でなければならず、その意味はRFCまたはで文書化する必要があります。独立した実装間の相互運用性が可能であるという十分な詳細で、他の恒久的で容易に入手可能な参照が可能です。エントリを「非推奨」とマークするメカニズムは想定されていません。レジストリからエントリを更新することができます。
Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)
登録者の連絡先：IETF、keyprovワーキンググループ（keyprov@ietf.org）、アンドレアドハティ（andrea.doherty@rsa.com）
This section registers DSKPP version numbers. The registry has the
following structure:
+-------------------------------------------+
| DSKPP Version | Specification |
+-------------------------------------------+
| 1.0 | This document |
+-------------------------------------------+
Standards action is required to define new versions of DSKPP. It is not envisioned to deprecate, delete, or modify existing DSKPP versions.
DSKPPの新しいバージョンを定義するには、標準アクションが必要です。既存のDSKPPバージョンを非難、削除、または変更することは想定されていません。
This specification relies on a cryptographic primitive, called "DSKPP-PRF" that provides a deterministic transformation of a secret key k and a varying length octet string s to a bit string of specified length dsLen. From the point of view of this specification, DSKPP-PRF is a "black-box" function that, given the inputs, generates a pseudorandom value that can be realized by any appropriate and competent cryptographic technique. Section 3.4.2 provides two realizations of DSKPP-PRF, DSKPP-PRF-AES, and DSKPP-PRF-SHA256.
この仕様は、「DSKPP-PRF」と呼ばれる暗号化のプリミティブに依存しており、秘密のキーKとさまざまな長さのオクテットストリングの決定論的変換を、指定された長さDSLENのビットストリングに提供します。この仕様の観点から見ると、DSKPP-PRFは「ブラックボックス」関数であり、入力を考慮して、適切で有能な暗号化手法によって実現できる擬似ランダム値を生成します。セクション3.4.2は、DSKPP-PRF、DSKPP-PRF-AES、およびDSKPP-PRF-SHA256の2つの実現を提供します。
This section registers the identifiers associated with these realizations. PRF Algorithm ID Sub-registries are to be subject to "Specification Required" as per RFC 5226 [RFC5226]. Updates MUST be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible.
このセクションでは、これらの実現に関連付けられた識別子を登録します。PRFアルゴリズムIDサブレジストリは、RFC 5226 [RFC5226]に従って「仕様が必要」の対象となります。更新は、独立した実装間の相互運用性が可能であるという十分な詳細で、RFCまたは他の永続的で容易に利用可能な参照で文書化する必要があります。
Expert approval is required to deprecate a sub-registry. Once deprecated, the PRF Algorithm ID SHOULD NOT be used in any new implementations.
サブレジストリを非難するには、専門家の承認が必要です。廃止されたら、PRFアルゴリズムIDを新しい実装で使用しないでください。
This section registers the following in the IETF XML namespace registry.
このセクションでは、IETF XML Namespaceレジストリで以下を登録します。
Common Name: DSKPP-PRF-AES
一般名：DSKPP-PRF-AES
URI:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
Identifier Definition: The DSKPP-PRF-AES algorithm realization is defined in Appendix D.2.2 of this document.
識別子定義：DSKPP-PRF-AESアルゴリズムの実現は、このドキュメントの付録D.2.2に定義されています。
Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)
登録者の連絡先：IETF、keyprovワーキンググループ（keyprov@ietf.org）、アンドレアドハティ（andrea.doherty@rsa.com）
This section registers the following in the IETF XML namespace registry.
このセクションでは、IETF XML Namespaceレジストリで以下を登録します。
Common Name: DSKPP-PRF-SHA256
一般名：DSKPP-PRF-SHA256
URI:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
Identifier Definition: The DSKPP-PRF-SHA256 algorithm realization is defined in Appendix D.3.2 of this document.
識別子定義：DSKPP-PRF-SHA256アルゴリズムの実現は、このドキュメントの付録D.3.2で定義されています。
Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)
登録者の連絡先：IETF、keyprovワーキンググループ（keyprov@ietf.org）、アンドレアドハティ（andrea.doherty@rsa.com）
This section registers the Key Container type.
このセクションでは、キーコンテナタイプを登録します。
Key Container: The registration name for the Key Container.
キーコンテナ：キーコンテナの登録名。
Specification: Key Container defines a key package format that specifies how a key should be protected using the three key protection methods provided in Section 5.1.
仕様：キーコンテナは、セクション5.1で提供されている3つのキー保護方法を使用してキーを保護する方法を指定するキーパッケージ形式を定義します。
Registration Procedure: Following the policies outlined in [RFC3575], the IANA policy for assigning new values for the status codes for DSKPP MUST be "Specification Required" and their meanings MUST be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible.
登録手順：[RFC3575]で概説されているポリシーに従って、DSKPPのステータスコードの新しい値を割り当てるためのIANAポリシーは「必要な仕様」でなければならず、その意味はRFCまたは他の恒久的で容易に利用可能な参照で文書化する必要があります。独立した実装間の相互運用性が可能であるという十分な詳細が可能です。
Deprecated: TRUE if based on expert approval this entry has been deprecated and SHOULD NOT be used in any new implementations. Otherwise, FALSE.
非推奨：専門家の承認に基づいてこのエントリが非推奨されており、新しい実装では使用されるべきではありません。それ以外の場合、false。
Identifiers: The initial URIs for the Key Container defined for this version of the document are listed here:
識別子：このバージョンのドキュメントのために定義された主要なコンテナの初期URIは、ここにリストされています。
Name: PSKC Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
Specification: [RFC6030]
Deprecated: FALSE
Name: SKPC Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container
Specification: [RFC6031]
Deprecated: FALSE
Name: PKCS12 Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container
Specification: [PKCS-12]
Deprecated: FALSE
Name: PKCS5-XML Key Container
URI: urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container
Specification: [PKCS-5-XML]
Deprecated: FALSE
Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)
登録者の連絡先：IETF、keyprovワーキンググループ（keyprov@ietf.org）、アンドレアドハティ（andrea.doherty@rsa.com）
RSA and RSA Security are registered trademarks or trademarks of RSA Security, Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners.
RSAおよびRSAセキュリティは、米国および/またはその他の国のRSA Security、Inc。の登録商標または商標です。言及されている他の製品やサービスの名前は、それぞれの所有者の商標である可能性があります。
This work is based on information contained in [RFC4758], authored by Magnus Nystrom, with enhancements borrowed from an individual document coauthored by Mingliang Pei and Salah Machani (e.g., user authentication, and support for multiple key package formats).
この作業は、Mingliang PeiとSalah Machaniが共同執筆した個々のドキュメントから借用したマグナスNystromが執筆した[RFC4758]に含まれる情報に基づいています（例：ユーザー認証、複数のキーパッケージ形式のサポート）。
We would like to thank Philip Hoyer for his work in aligning DSKPP and PSKC schemas.
DSKPPとPSKCスキーマを調整した彼の仕事について、フィリップホイヤーに感謝します。
We would also like to thank Hannes Tschofenig and Phillip Hallam-Baker for their reviews, feedback, and text contributions.
また、レビュー、フィードバック、テキストの貢献について、Hannes TschofenigとPhillip Hallam-Bakerに感謝します。
We would like to thank the following for review of previous DSKPP document versions:
以前のDSKPPドキュメントバージョンのレビューについては、以下に感謝します。
o Dr. Ulrike Meyer (Review June 2007) o Niklas Neumann (Review June 2007) o Shuh Chang (Review June 2007) o Hannes Tschofenig (Review June 2007 and again in August 2007) o Sean Turner (Reviews August 2007 and again in July 2008) o John Linn (Review August 2007) o Philip Hoyer (Review September 2007) o Thomas Roessler (Review November 2007) o Lakshminath Dondeti (Comments December 2007) o Pasi Eronen (Comments December 2007) o Phillip Hallam-Baker (Review and Edits November 2008 and again in January 2009) o Alexey Melnikov (Review May 2010) o Peter Saint-Andre (Review May 2010) We would also like to thank the following for their input to selected design aspects of DSKPP:
o Ulrike Meyer博士（2007年6月のレビュー）o Niklas Neumann（2007年6月レビュー）o Shuh Chang（2007年6月レビュー）o Hannes Tschofenig（2007年6月、2007年8月に再び）O Sean Turner（2007年8月および2008年7月のレビュー）oジョン・リン（2007年8月のレビュー）oフィリップ・ホイヤー（2007年9月レビュー）oトーマス・ロスラー（2007年11月レビュー）Oラクシュミナート・ドンデティ（コメント2007年12月）o Pasi Eronen（コメント2007年12月）O Phillip Hallam-Baker（レビューと編集2008年11月と2009年1月に再び）O Alexey Melnikov（2010年5月のレビュー）O Peter Saint-Andre（2010年5月レビュー）DSKPPの選択されたデザインの側面への入力について以下に感謝したいと思います。
o Anders Rundgren (Key Package Format and Client Authentication Data) o Thomas Roessler (HTTP Binding) o Hannes Tschofenig (HTTP Binding) o Phillip Hallam-Baker (Registry for Algorithms) o N. Asokan (original observation of weakness in Authentication Data)
o Anders Rundgren（キーパッケージ形式とクライアント認証データ）o Thomas Roessler（HTTP Binding）o Hannes Tschofenig（HTTP Binding）o Phillip Hallam-Baker（アルゴリズムのレジストリ）O N. Asokan（認証データの弱点の元の観察）
Finally, we would like to thank Robert Griffin for opening communication channels for us with the IEEE P1619.3 Key Management Group, and facilitating our groups in staying informed of potential areas (especially key provisioning and global key identifiers of collaboration) of collaboration.
最後に、IEEE P1619.3の主要な管理グループで私たちのために通信チャネルを開いてくれたRobert Griffinに感謝し、潜在的な領域（特に主要なプロビジョニングとコラボレーションのグローバルな主要な識別子）を維持する際に促進したいと思います。
[FIPS180-SHA] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, February 2004, <http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2withchangenotice.pdf>.
[FIPS180-SHA]国立標準技術研究所、「セキュアハッシュスタンダード」、FIPS 180-2、2004年2月、<http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2withchangenotice.pdfdf>。
[FIPS197-AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001, <http:// csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[FIPS197-AES]国立標準技術研究所、「高度な暗号化標準（AES）の仕様」、FIPS 197、2001年11月、<http：// csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>。
[ISO3309] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure", ISO 3309, 3rd Edition, October 1984.
[ISO3309]国際標準化機関、「ISO情報処理システム - データ通信 - 高レベルのデータリンク制御手順 - フレーム構造」、ISO 3309、3rd Edition、1984年10月。
[PKCS-1] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version 2.1, June 2002, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-1] RSA Laboratories、「RSA Cryptography Standard」、PKCS＃1バージョン2.1、2002年6月、<http://www.rsasecurity.com/rsalabs/pkcs/>。
[PKCS-5] RSA Laboratories, "Password-Based Cryptography Standard", PKCS #5 Version 2.0, March 1999, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-5] RSA Laboratories、「パスワードベースの暗号化標準」、PKCS＃5バージョン2.0、1999年3月、<http://www.rsasecurity.com/rsalabs/pkcs/>。
[PKCS-5-XML] RSA Laboratories, "XML Schema for PKCS #5 Version 2.0", PKCS #5 Version 2.0 Amd.1 (FINAL DRAFT), October 2006, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-5-XML] RSA Laboratories、「PKCS＃5バージョン2.0のXMLスキーマ」、PKCS＃5バージョン2.0 AMD.1（最終ドラフト）、2006年10月、<http://www.rsasecurity.com/rsalabs/PKCS/>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLPREP：ユーザー名とパスワードのStringPrepプロファイル」、RFC 4013、2005年2月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210] Adams、C.、Farrell、S.、Kause、T。、およびT. Mononen、「Internet X.509公開キーインフラストラクチャ証明書管理プロトコル（CMP）」、RFC 4210、2005年9月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272] Schaad、J。およびM. Myers、「CMS（CMC）の証明書管理」、RFC 5272、2008年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[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月。
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010.
[RFC6030] Hoyer、P.、Pei、M。、およびS. Machani、「ポータブル対称キーコンテナ（PSKC）」、RFC 6030、2010年10月。
[UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms", March 2001, <http://www.unicode.org/ unicode/reports/tr15/tr15-21.html>.
[Unicode] Davis、M。and M. Duerst、「Unicode Normalization forms」、2001年3月、<http://www.unicode.org/ unicode/Reports/TR15/TR15-21.html>。
[XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XML] W3C、「拡張可能なマークアップ言語（XML）1.0（第5版）」、W3C推奨、2008年11月、<http://www.w3.org/tr/2006/REC-XML-20060816/>。
[XMLDSIG] W3C, "XML Signature Syntax and Processing", W3C Recommendation, February 2002, <http:// www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
[xmldsig] W3C、「XML Signature Syntax and Processing」、W3C推奨、2002年2月、<http：// www.w3.org/tr/2002/rec-xmldsig-core-20020212/>。
[XMLENC] W3C, "XML Encryption Syntax and Processing", W3C Recommendation, December 2002, <http:// www.w3.org/TR/2002/REC-xmldsig-core-20020212/>.
[XMLENC] W3C、「XML暗号化構文と処理」、W3C推奨、2002年12月、<http：// www.w3.org/tr/2002/rec-xmldsig-core-20020212/>。
[CT-KIP-P11] RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic Token Key Initialization Protocol", PKCS #11 Version 2.20 Amd.2, December 2005, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[CT-KIP-P11] RSA Laboratories、「暗号化トークンキーの初期化プロトコルのPKCS＃11メカニズム」、PKCS＃11バージョン2.20 AMD.2、2005年12月、<http://www.rsasecurity.com/rsalabs/pkcs/>。
[FAQ] RSA Laboratories, "Frequently Asked Questions About Today's Cryptography", Version 4.1, 2000.
[FAQ] RSA Laboratories、「今日の暗号化についてよくある質問」、バージョン4.1、2000。
[NIST-PWD] National Institute of Standards and Technology, "Password Usage", FIPS 112, May 1985, <http://www.itl.nist.gov/fipspubs/fip112.htm>.
[NIST-PWD]国立標準技術研究所、「パスワード使用」、FIPS 112、1985年5月、<http://www.itl.nist.gov/fipspubs/fip112.htm>。
[NIST-SP800-38B] International Organization for Standardization, "Recommendations for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST SP800-38B, May 2005, <http://csrc.nist.gov/ publications/nistpubs/800-38B/SP_800-38B.pdf>.
[NIST-SP800-38B]国際標準化機関、「ブロック暗号運用モードの推奨：認証用のCMACモード」、NIST SP800-38B、2005年5月、<http://csrc.nist.gov/ Publications/nistpubs/800-38b/sp_800-38b.pdf>。
[NIST-SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part I: General (Revised)", NIST 800-57, March 2007, <http: //csrc.nist.gov/publications/nistpubs/800-57/ sp800-57-Part1-revised2_Mar08-2007.pdf>.
[NIST-SP800-57]国立標準技術研究所、「主要管理の推奨 - パートI：一般（改訂）」、NIST 800-57、2007年3月、<http：//csrc.nist.gov/publications/nistpubs/ 800-57/ sp800-57-part1-revized2_mar08-2007.pdf>。
[PKCS-11] RSA Laboratories, "Cryptographic Token Interface Standard", PKCS #11 Version 2.20, June 2004, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS-11] RSA研究所、「暗号化トークンインターフェイス標準」、PKCS＃11バージョン2.20、2004年6月、<http://www.rsasecurity.com/rsalabs/pkcs/>。
[PKCS-12] "Personal Information Exchange Syntax Standard", PKCS #12 Version 1.0, 2005, <ftp:// ftp.rsasecurity.com/pub/pkcs/pkcs-12/ pkcs-12v1.pdf>.
[PKCS-12]「個人情報交換構文標準」、PKCS＃12バージョン1.0、2005、<ftp：// ftp.rsasecurity.com/pub/pkcs/pkcs-12/ pkcs-12v1.pdf>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（ユーザーサービスのリモート認証ダイヤル）のIANAの考慮事項」、RFC 3575、2003年7月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4758] Nystroem, M., "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, November 2006.
[RFC4758] Nystroem、M。、「暗号化トークンキー初期化プロトコル（CT-KIP）バージョン1.0リビジョン1」、RFC 4758、2006年11月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC6031] Turner, S. and R. , "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.
[RFC6031] Turner、S。およびR.、「暗号化メッセージ構文（CMS）対称キーパッケージコンテンツタイプ」、RFC 6031、2010年12月。
[XMLNS] W3C, "Namespaces in XML", W3C Recommendation, January 1999, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XMLNS] W3C、「XMLの名前空間」、W3C推奨、1999年1月、<http://www.w3.org/tr/2009/rec-xml-names-20091208>。
DSKPP is expected to be used to provision symmetric keys to cryptographic modules in a number of different scenarios, each with its own special requirements, as described below. This appendix forms an informative part of the document.
DSKPPは、以下で説明するように、それぞれが独自の要件を備えたさまざまなシナリオで、暗号化モジュールに対称キーを提供するために使用されることが期待されています。この付録は、ドキュメントの有益な部分を形成します。
The usual scenario is that a cryptographic module makes a request for a symmetric key from a provisioning server that is located on the local network or somewhere on the Internet. Depending upon the deployment scenario, the provisioning server may generate a new key on-the-fly or use a pre-generated key, e.g., one provided by a legacy back-end issuance server. The provisioning server assigns a unique key ID to the symmetric key and provisions it to the cryptographic module.
通常のシナリオは、暗号化モジュールがローカルネットワークまたはインターネット上のどこかにあるプロビジョニングサーバーから対称キーをリクエストすることです。展開シナリオに応じて、プロビジョニングサーバーは、新しいキーをオンザフライで生成するか、事前に生成されたキーを使用する場合があります。たとえば、レガシーバックエンドの発行サーバーによって提供されます。Provisioning Serverは、一意のキーIDを対称キーに割り当て、暗号化モジュールに提供します。
A cryptographic module makes multiple requests for symmetric keys from the same provisioning server. The symmetric keys need not be of the same type, i.e., the keys may be used with different symmetric key cryptographic algorithms, including one-time password authentication algorithms, and the AES encryption algorithm.
暗号化モジュールは、同じプロビジョニングサーバーからの対称キーを複数の要求します。対称キーは同じタイプである必要はありません。つまり、キーは、1回限りのパスワード認証アルゴリズムやAES暗号化アルゴリズムなど、異なる対称キー暗号化アルゴリズムで使用できます。
In some deployment scenarios, a key issuer may rely on a third-party provisioning service. In this case, the issuer directs provisioning requests from the cryptographic module to the provisioning service. As such, it is the responsibility of the issuer to authenticate the user through some out-of-band means before granting him rights to acquire keys. Once the issuer has granted those rights, the issuer provides an Authentication Code to the user and makes it available to the provisioning service, so that the user can prove that he is authorized to acquire keys.
いくつかの展開シナリオでは、主要な発行者がサードパーティのプロビジョニングサービスに依存する場合があります。この場合、発行者は暗号化モジュールからプロビジョニングサービスにプロビジョニングリクエストを指示します。そのため、キーを取得する権利を付与する前に、いくつかの帯域外の手段を通じてユーザーを認証することは発行者の責任です。発行者がそれらの権利を付与すると、発行者はユーザーに認証コードを提供し、プロビジョニングサービスを利用できるようにし、ユーザーがキーを取得することを許可されていることを証明できます。
An issuer may provide a time-limited Authentication Code to a user during registration, which the user will input into the cryptographic module to authenticate themselves with the provisioning server. The server will allow a key to be provisioned to the cryptographic module hosted by the user's device when user authentication is required only if the user inputs a valid Authentication Code within the fixed time period established by the issuer.
発行者は、登録中にユーザーに時間制限された認証コードを提供する場合があります。ユーザーは、ユーザーが暗号化モジュールに入力して、プロビジョニングサーバーで自分自身を認証することができます。サーバーは、ユーザーが発行者によって確立された固定期間内に有効な認証コードを入力する場合にのみ、ユーザー認証が必要な場合にユーザーのデバイスによってホストされた暗号化モジュールにキーをプロビジョニングすることができます。
A cryptographic module requests renewal of the symmetric key material attached to a key ID, as opposed to keeping the key value constant and refreshing the metadata. Such a need may occur in the case when a user wants to upgrade her device that houses the cryptographic module or when a key has expired. When a user uses the same cryptographic module for example, to perform strong authentication at multiple Web login sites, keeping the same key ID removes the need for the user to register a new key ID at each site.
暗号化モジュールは、キー値を一定に保ち、メタデータを更新するのではなく、キーIDに接続された対称キー資料の更新を要求します。このようなニーズは、ユーザーが暗号化モジュールを収容するデバイスをアップグレードしたい場合、またはキーの有効期限が切れた場合に発生する可能性があります。たとえば、ユーザーが同じ暗号化モジュールを使用している場合、複数のWebログインサイトで強力な認証を実行すると、同じキーIDを維持すると、ユーザーが各サイトで新しいキーIDを登録する必要があります。
This scenario represents a special case of symmetric key renewal in which a local administrator can authenticate the user procedurally before initiating the provisioning process. It also allows for a device issuer to pre-load a key onto a cryptographic module with a restriction that the key is replaced with a new key prior to use of the cryptographic module. Another variation of this scenario is the organization who recycles devices. In this case, a key issuer would provision a new symmetric key to a cryptographic module hosted on a device that was previously owned by another user.
このシナリオは、プロビジョニングプロセスを開始する前にローカル管理者がユーザーを手続き的に認証できる対称キー更新の特別なケースを表しています。また、デバイス発行者は、暗号モジュールを使用する前にキーが新しいキーに置き換えるという制限を備えた暗号化モジュールにキーを事前にロードすることができます。このシナリオのもう1つのバリエーションは、デバイスをリサイクルする組織です。この場合、キー発行者は、以前は別のユーザーが所有していたデバイスにホストされていた暗号化モジュールに新しい対称キーを提供します。
Note that this usage scenario is essentially the same as the previous scenario wherein the same key ID is used for renewal.
この使用シナリオは、同じキーIDが更新に使用される前のシナリオと本質的に同じであることに注意してください。
A cryptographic module is loaded onto a smart card after the card is issued to a user. The symmetric key for the cryptographic module will then be provisioned using a secure channel mechanism present in many smart card platforms. This allows a direct secure channel to be established between the smart card chip and the provisioning server. For example, the card commands (i.e., Application Protocol Data Units, or APDUs) are encrypted with a pre-issued card manufacturer's key and sent directly to the smart card chip, allowing secure post-issuance in-the-field provisioning. This secure flow can pass Transport Layer Security (TLS) [RFC5246] and other transport security boundaries.
カードがユーザーに発行された後、暗号化モジュールがスマートカードにロードされます。暗号化モジュールの対称キーは、多くのスマートカードプラットフォームに存在する安全なチャネルメカニズムを使用してプロビジョニングされます。これにより、スマートカードチップとプロビジョニングサーバーの間に直接安全なチャネルを確立できます。たとえば、カードコマンド（つまり、アプリケーションプロトコルデータユニット、またはAPDU）は、事前に発行されたカードメーカーのキーで暗号化され、スマートカードチップに直接送信され、フィールド内のプロビジョニングを安全に使用できるようにします。この安全なフローは、輸送層のセキュリティ（TLS）[RFC5246]およびその他の輸送セキュリティ境界を渡すことができます。
Note that two pre-conditions for this usage scenario are for the protocol to be tunneled and the provisioning server to know the correct pre-established manufacturer's key.
この使用法シナリオの2つの事前条件は、プロトコルをトンネリングし、プロビジョニングサーバーが正しい事前に確立されたメーカーのキーを知ることであることに注意してください。
In this scenario, Transport Layer Security does not provide end-to-end protection of keying material transported from the provisioning server to the cryptographic module. For example, TLS may terminate at an application hosted on a PC rather than at the cryptographic module (i.e., the endpoint) located on a data storage device [RFC5246]. Mutually authenticated key agreement provides end-to-end protection, which TLS cannot provide.
このシナリオでは、輸送層のセキュリティは、プロビジョニングサーバーから暗号化モジュールに輸送されるキーイング材料のエンドツーエンドの保護を提供しません。たとえば、TLSは、データストレージデバイス[RFC5246]にある暗号化モジュール（つまり、エンドポイント）ではなくPCでホストされているアプリケーションで終了する場合があります。相互に認証されたキー契約は、TLSが提供できないエンドツーエンドの保護を提供します。
This appendix contains example messages that illustrate parameters, encoding, and semantics in four- and two-pass DSKPP exchanges. The examples are written using XML, and are syntactically correct. MAC and cipher values are fictitious, however. This appendix forms an informative part of the document.
この付録には、4つのパスおよび2パスDSKPP交換のパラメーター、エンコード、およびセマンティクスを示すメッセージが含まれています。例はXMLを使用して記述されており、構文的に正しいです。ただし、Macと暗号の値は架空です。この付録は、ドキュメントの有益な部分を形成します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvTrigger Version="1.0"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
<dskpp:InitializationTrigger>
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID>
<dskpp:TokenPlatformInfo KeyLocation="Hardware"
AlgorithmLocation="Software"/>
<dskpp:AuthenticationData>
<dskpp:ClientID>31300257</dskpp:ClientID>
<dskpp:AuthenticationCodeMac>
<dskpp:IterationCount>512</dskpp:IterationCount>
<dskpp:Mac>4bRJf9xXd3KchKoTenHJiw==</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData>
<dskpp:ServerUrl>keyprovservice.example.com
</dskpp:ServerUrl>
</dskpp:InitializationTrigger>
</dskpp:KeyProvTrigger>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0">
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm>
<dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm>
</dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants>
<dskpp:FourPass/>
</dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages>
</dskpp:KeyProvClientHello>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0">
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:KeyID>SE9UUDAwMDAwMDAx</dskpp:KeyID>
<dskpp:SupportedKeyTypes>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm>
<dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm>
</dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants>
<dskpp:FourPass/>
</dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages>
</dskpp:KeyProvClientHello>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0"
Status="Continue"
SessionID="4114">
<dskpp:KeyType>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:KeyType>
<dskpp:EncryptionAlgorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:MacAlgorithm>
<dskpp:EncryptionKey>
<ds:KeyName>Example-Key1</ds:KeyName>
</dskpp:EncryptionKey>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
<dskpp:Payload>
<dskpp:Nonce>EjRWeJASNFZ4kBI0VniQEg==</dskpp:Nonce>
</dskpp:Payload>
</dskpp:KeyProvServerHello>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerHello
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0"
SessionID="4114"
Status="Continue">
<dskpp:KeyType>
urn:ietf:params:xml:schema:keyprov:otpalg#SecurID-AES
</dskpp:KeyType>
<dskpp:EncryptionAlgorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:EncryptionAlgorithm>
<dskpp:MacAlgorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:MacAlgorithm>
<dskpp:EncryptionKey>
<ds:KeyName>Example-Key1</ds:KeyName>
</dskpp:EncryptionKey>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
<dskpp:Payload>
<dskpp:Nonce>qw2ewasde312asder394jw==</dskpp:Nonce>
</dskpp:Payload>
<dskpp:Mac
MacAlgorithm="urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128">
cXcycmFuZG9tMzEyYXNkZXIzOTRqdw==
</dskpp:Mac>
</dskpp:KeyProvServerHello>
This message contains the nonce chosen by the cryptographic module, R_C, encrypted by the specified encryption key and encryption algorithm.
このメッセージには、指定された暗号化キーと暗号化アルゴリズムによって暗号化された暗号化モジュールR_Cによって選択されたNonCEが含まれています。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientNonce
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
SessionID="4114"
Version="1.0">
<dskpp:EncryptedNonce>
oTvo+S22nsmS2Z/RtcoF8CTwadRa1PVsRXkZnCihHkU1rPueggrd0NpEWVZR
16Rg16+FHuTg33GK1wH3wffDZQ==
</dskpp:EncryptedNonce>
</dskpp:KeyProvClientNonce>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0"
Status="Success"
SessionID="4114">
<dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0001">
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>
TokenVendorAcme
</pskc:Manufacturer>
<pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key
Id="MBK000000001"
Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data>
<pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
151yAR2NqU5dJzETK+SGYqN6sq6DEH5AgHohra3Jpp4=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
The client indicates support for all the Key Transport, Key Wrap, and Passphrase-Based Key Wrap key protection methods:
クライアントは、すべてのキートランスポート、キーラップ、およびパスフレーズベースのキーラップキー保護方法のサポートを示しています。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0">
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm>
<dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm>
</dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#rsa_1_5
</dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants>
<dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp:transport
</dskpp:SupportedKeyProtectionMethod>
<dskpp:Payload>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM
RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD
kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl
Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA
3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx
vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE
Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k
LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln
c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</dskpp:Payload>
</dskpp:TwoPass>
</dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac>
<dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce>
<dskpp:IterationCount>100000</dskpp:IterationCount>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
3eRz51ILqiG+dJW2iLcjuA==
</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData>
</dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by returning a key package in which the provisioning key was encrypted using the Key Transport key protection method.
この例では、サーバーは、キートランスポートキー保護法を使用してプロビジョニングキーが暗号化されたキーパッケージを返すことにより、以前の要求に応答します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0"
Status="Success"
SessionID="4114">
<dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0001">
<pskc:EncryptionKey>
<ds:X509Data>
<ds:X509Certificate>
MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4MQ0wCwYDVQQKEwRJRVRGM
RMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwHhcNMDkwMjE3MD
kxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXl
Qcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/eDsKjsPyFIODsxeKVV/uA
3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJxBKilAM5aW7C+BQ0RvCx
vdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQYJKoZIhvcNAQEFBQADgYE
Ae875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqfrnRuXJRMeZXaaEGmzY1k
LonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w4rnqdkmwZX/NgXg06aln
c2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data>
</pskc:EncryptionKey>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>
TokenVendorAcme
</pskc:Manufacturer>
<pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo>
<pskc:Key
Id="MBK000000001"
Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData>
<xenc:CipherValue>
eyjr23WMy9S2UdKgGnQEbs44T1jmX1TNWEBq48xfS20PK2VWF4ZK1iSctHj/u3uk+7+y8
uKrAzHEm5mujKPAU4DCbb5mSibXMnAbbIoAi2cJW60/l8FlzwaU4EZsZ1LyQ1GcBQKACE
eylG5vK8NTo47vZTatL5UxmbmOX2HvaVQ=
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
</pskc:Secret>
<pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data>
<pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
GHZ0H6Y+KpxdlVZ7zgcJDiDdqc8Gcmlcf+HQi4EUxYU=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
The client sends a request that specifies a shared key to protect the K_TOKEN, and the server responds using the Key Wrap key protection method. Authentication Data in this example is based on an Authentication Code rather than a device certificate.
クライアントは、K_TOKENを保護するために共有キーを指定するリクエストを送信し、サーバーはキーラップキー保護方法を使用して応答します。この例の認証データは、デバイス証明書ではなく認証コードに基づいています。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0">
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm>
<dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm>
</dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#aes128-cbc
</dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants>
<dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp:wrap
</dskpp:SupportedKeyProtectionMethod>
<dskpp:Payload>
<ds:KeyInfo>
<ds:KeyName>Pre-shared-key-1</ds:KeyName>
</ds:KeyInfo>
</dskpp:Payload>
</dskpp:TwoPass>
</dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac>
<dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce>
<dskpp:IterationCount>1</dskpp:IterationCount>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
3eRz51ILqiG+dJW2iLcjuA==
</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData>
</dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by returning a key package in which the provisioning key was encrypted using the Key Wrap key protection method.
この例では、サーバーは、キーラップキー保護方法を使用してプロビジョニングキーが暗号化されたキーパッケージを返すことにより、以前の要求に応答します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0"
Status="Success"
SessionID="4114">
<dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0001">
<pskc:EncryptionKey>
<ds:KeyName>Pre-shared-key-1</ds:KeyName>
</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>
2GTTnLwM3I4e5IO5FkufoMUBJBuAf25hARFv0Z7MFk9Ecdb04PWY/qaeCbrgz7Es
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>
TokenVendorAcme
</pskc:Manufacturer>
<pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key
Id="MBK000000001"
Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8AabC6vr
09sh0QIU+E224S96sZjpV+6nFYgn
6525OoepbPnL/fGuuey64WCYXoqh
Tg==
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>
o+e9xgMVUbYuZH9UHe0W9dIo88A=
</pskc:ValueMAC>
</pskc:Secret>
<pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data>
<pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
l53BmSO6qUzoIgbQegimsKk2es+WRpEl0YFqaOp5PGE=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
The client sends a request similar to that in Appendix B.3.1 with Authentication Data based on an Authentication Code, and the server responds using the Passphrase-Based Key Wrap method to encrypt the provisioning key (note that the encryption is derived from the password component of the Authentication Code). The Authentication Data is set in clear text when it is sent over a secure transport channel such as TLS [RFC5246].
クライアントは、認証コードに基づいた認証データを使用して付録B.3.1のリクエストを送信し、サーバーはPassPhraseベースのキーラップメソッドを使用して応答してプロビジョニングキーを暗号化します（暗号化はパスワードコンポーネントから導出されることに注意してください認証コードの）。認証データは、TLS [RFC5246]などの安全な輸送チャネルに送信されると、クリアテキストで設定されます。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0">
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm>
<dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm>
</dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#rsa_1_5
</dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants>
<dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
</dskpp:SupportedKeyProtectionMethod>
<dskpp:Payload>
<ds:KeyInfo>
<ds:KeyName>Passphrase-1</ds:KeyName>
</ds:KeyInfo>
</dskpp:Payload>
</dskpp:TwoPass>
</dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac>
<dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce>
<dskpp:IterationCount>1</dskpp:IterationCount>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
K4YvLMN6Q1DZvtShoCxQag==
</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData>
</dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by returning a key package in which the provisioning key was encrypted using the Passphrase-Based Key Wrap key protection method.
この例では、サーバーは、PassPhraseベースのキーラップキー保護方法を使用してプロビジョニングキーが暗号化されたキーパッケージを返すことにより、以前の要求に応答します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0"
Status="Success"
SessionID="4114">
<dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0002">
<pskc:EncryptionKey>
<dkey:DerivedKey>
<dkey: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>
</pkcs5:PBKDF2-params>
</dkey:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<dkey:MasterKeyName>
Passphrase1
</dkey:MasterKeyName>
</dkey: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:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key
Id="MBK000000001"
Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/
xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8HX385uMWgJ
myIFMESBmcvtHQXp/6T1TgCS9CsgKtm
cOrF8VoK254tZKnrAjiD5cdw==
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>
pbgEbVYxoYs0x41wdeC7eDRbUEk=
</pskc:ValueMAC>
</pskc:Secret>
<pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data>
<pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
Jc4VsNODYXgfbDmTn9qQZgcL3cKoa//j/NRT7sTpKOM=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
Appendix C. Integration with PKCS #11
付録C. PKCS＃11との統合
A DSKPP Client that needs to communicate with a connected cryptographic module to perform a DSKPP exchange MAY use PKCS #11 [PKCS-11] as a programming interface as described herein. This appendix forms an informative part of the document.
DSKPP交換を実行するために接続された暗号化モジュールと通信する必要があるDSKPPクライアントは、本明細書に記載されているようにプログラミングインターフェイスとしてPKCS＃11 [PKCS-11]を使用する場合があります。この付録は、ドキュメントの有益な部分を形成します。
When performing four-pass DSKPP with a cryptographic module using the PKCS #11 programming interface, the procedure described in [CT-KIP-P11], Appendix B, is RECOMMENDED.
PKCS＃11プログラミングインターフェイスを使用して暗号化モジュールを使用して4パスDSKPPを実行する場合、[CT-KIP-P11]、付録Bで説明されている手順が推奨されます。
A suggested procedure to perform two-pass DSKPP with a cryptographic module through the PKCS #11 interface using the mechanisms defined in [CT-KIP-P11] is as follows:
[CT-KIP-P11]で定義されたメカニズムを使用して、PKCS＃11インターフェイスを介して暗号化モジュールを使用して2パスDSKPPを実行するための推奨される手順は次のとおりです。
a. On the client side,
a. クライアント側では、
1. The client selects a suitable slot and token (e.g., through use of the <DeviceIdentifier> or the <PlatformInfo> element of the DSKPP trigger message).
1. クライアントは、適切なスロットとトークンを選択します（たとえば、<deviceIdentifier>またはDSKPPトリガーメッセージの<PlatformInfo>要素の使用）。
2. A nonce R is generated, e.g., by calling C_SeedRandom and C_GenerateRandom.
2. たとえば、c_seedrandomとc_generaterandomを呼び出すことにより、非ce rが生成されます。
3. The client sends its first message to the server, including the nonce R.
3. クライアントは、NonCe Rを含む最初のメッセージをサーバーに送信します。
b. On the server side,
b. サーバー側では、
1. A generic key K_PROV = K_TOKEN | K_MAC (where '|' denotes concatenation) is generated, e.g., by calling C_GenerateKey (using key type CKK_GENERIC_SECRET). The template for K_PROV MUST allow it to be exported (but only in wrapped form, i.e., CKA_SENSITIVE MUST be set to CK_TRUE and CKA_EXTRACTABLE MUST also be set to CK_TRUE), and also to be used for further key derivation. From K, a token key K_TOKEN of suitable type is derived by calling C_DeriveKey using the PKCS #11 mechanism CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to the first bit of the generic secret key (i.e., set to 0). Likewise, a MAC key K_MAC is derived from K_PROV by calling C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism, this time setting CK_EXTRACT_PARAMS to the length of K_PROV (in bits) divided by two.
1. 一般的なキーk_prov = k_token |k_mac（ここで、 '|'は連結を意味する）が生成されます。たとえば、c_generatekey（キータイプCKK_GENERIC_SECRETを使用）を呼び出します。k_provのテンプレートは、それをエクスポートすることを許可する必要があります（ただし、ラップフォームでのみ、つまりCKA_SENSITITをCK_TRUEに設定する必要があり、CKA_ExtractableもCK_Trueに設定する必要があります）。Kから、適切なタイプのトークンキーK_TOKENは、PKCS＃11メカニズムCKM_EXTRACT_KEY_FROM_KEYを使用してC_DERIVEKEYを呼び出し、CK_EXTRACT_PARAMSをジェネリックシークレットキーの最初のビットに設定することで導出されます（つまり、0に設定されています）。同様に、MACキーK_MACは、CKM_EXTRACT_KEY_FROM_KEYメカニズムを使用してC_DERIVEKEYを呼び出すことによりK_Provから派生します。
2. The server wraps K_PROV with either the public key of the DSKPP Client or device, the pre-shared secret key, or the derived shared secret key by using C_WrapKey. If use of the DSKPP key wrap algorithm has been negotiated, then the CKM_KIP_WRAP mechanism MUST be used to wrap K. When calling C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure MUST be set to NULL_PTR. The pSeed parameter in the CK_KIP_PARAMS structure MUST point to the nonce R provided by the DSKPP Client, and the ulSeedLen parameter MUST indicate the length of R. The hWrappingKey parameter in the call to C_WrapKey MUST be set to refer to the key wrapping key.
2. サーバーは、c_wrapkeyを使用して、dskppクライアントまたはデバイスの公開キー、事前に共有されたシークレットキー、または派生した共有シークレットキーのいずれかでk_provをラップします。DSKPPキーラップアルゴリズムの使用がネゴシエートされている場合、CKM_KIP_WRAPメカニズムを使用してKをラップする必要があります。C_WrapKeyを呼び出す場合、CK_KIP_PARAMS構造のHKEYハンドルはnull_ptrに設定する必要があります。CK_KIP_PARAMS構造のPSEEDパラメーターは、DSKPPクライアントが提供するNonCE Rを指す必要があり、UlSeedlenパラメーターは、C_WrapKeyへの呼び出しのHWrappyKeyパラメーターの長さを、キーラッピングキーを参照するように設定する必要があります。
3. Next, the server needs to calculate a MAC using K_MAC. If use of the DSKPP MAC algorithm has been negotiated, then the MAC is calculated by calling C_SignInit with the CKM_KIP_MAC mechanism followed by a call to C_Sign. In the call to C_SignInit, K_MAC MUST be the signature key, the hKey parameter in the CK_KIP_PARAMS structure MUST be set to NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure MUST be set to NULL_PTR, and the ulSeedLen parameter MUST be set to zero. In the call to C_Sign, the pData parameter MUST be set to the concatenation of the string ServerID and the nonce R, and the ulDataLen parameter MUST be set to the length of the concatenated string. The desired length of the MAC MUST be specified through the pulSignatureLen parameter and MUST be set to the length of R.
3. 次に、サーバーはK_MACを使用してMACを計算する必要があります。DSKPP MACアルゴリズムの使用がネゴシエートされている場合、MacはCKM_KIP_MACメカニズムを使用してC_SignInitを呼び出し、CO_SIGNの呼び出しによって計算されます。c_signinitの呼び出しでは、k_macが署名キーである必要があります。CK_KIP_PARAMS構造のHKEYパラメーターはnull_ptrに設定する必要があり、ct_kip_params構造のpseedパラメーターはnull_ptrに設定する必要があり、ulseedlenパラメーターはゼロに設定する必要があります。C_SIGNの呼び出しでは、PDATAパラメーターを文字列ServerIDおよびNonCE Rの連結に設定する必要があり、Uldatalenパラメーターは連結文字列の長さに設定する必要があります。Macの目的の長さは、Pulsignaturelenパラメーターを介して指定し、Rの長さに設定する必要があります。
4. If the server also needs to authenticate its message (due to an existing K_TOKEN being replaced), the server MUST calculate a second MAC. Again, if use of the DSKPP MAC algorithm has been negotiated, then the MAC is calculated by calling C_SignInit with the CKM_KIP_MAC mechanism followed by a call to C_Sign. In this call to C_SignInit, the K_MAC' existing before this DSKPP run MUST be the signature key (the implementation may specify K_MAC' to be the value of the K_TOKEN that is being replaced, or a version of K_MAC from the previous protocol run), the hKey parameter in the CK_KIP_PARAMS structure MUST be set to NULL, the pSeed parameter of the CT_KIP_PARAMS structure MUST be set to NULL_PTR, and the ulSeedLen parameter MUST be set to zero. In the call to C_Sign, the pData parameter MUST be set to the concatenation of the string ServerID and the nonce R, and the ulDataLen parameter MUST be set to the length of concatenated string. The desired length of the MAC MUST be specified through the pulSignatureLen parameter and MUST be set to the length of R.
4. サーバーがメッセージを認証する必要がある場合（既存のk_tokenが交換されているため）、サーバーは2番目のMacを計算する必要があります。繰り返しますが、DSKPP MACアルゴリズムの使用がネゴシエートされた場合、MacはCKM_KIP_MACメカニズムを使用してC_SIGNINITを呼び出し、CO_SIGNの呼び出しによって計算されます。C_SIGNINITへのこの呼び出しでは、このDSKPPの実行の前に存在するK_MAC 'は署名キーでなければなりません（実装は、K_MAC'が置き換えられているK_TOKENの値、または前のプロトコル実行からのK_MACのバージョンであることを指定することができます）、CK_KIP_PARAMS構造のHKEYパラメーターはnullに設定する必要があり、CT_KIP_PARAMS構造のPSEEDパラメーターはnull_ptrに設定する必要があり、ulseedlenパラメーターはゼロに設定する必要があります。C_SIGNへの呼び出しでは、PDATAパラメーターを文字列serverIDおよびNonCE rの連結に設定する必要があり、ウルダタレンパラメーターは連結された文字列の長さに設定する必要があります。Macの目的の長さは、Pulsignaturelenパラメーターを介して指定し、Rの長さに設定する必要があります。
5. The server sends its message to the client, including the wrapped key K_TOKEN, the MAC and possibly also the authenticating MAC.
5. サーバーは、ラップされたキーK_TOKEN、MAC、場合によっては認証MACを含む、クライアントにメッセージを送信します。
c. On the client side,
c. クライアント側では、
1. The client calls C_UnwrapKey to receive a handle to K. After this, the client calls C_DeriveKey twice: once to derive K_TOKEN and once to derive K_MAC. The client MUST use the same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same mechanism parameters as used by the server above. When calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter MUST be used to set additional key attributes in accordance with local policy and as negotiated and expressed in the protocol. In particular, the value of the <KeyID> element in the server's response message MAY be used as CKA_ID for K_TOKEN. The key K_PROV MUST be destroyed after deriving K_TOKEN and K_MAC.
1. クライアントはc_unwrapkeyに電話してKのハンドルを受け取ります。この後、クライアントはc_derivekeyを2回呼び出します。クライアントは、同じメカニズム（ckm_extract_key_from_key）と上記のサーバーで使用されている同じメカニズムパラメーターを使用する必要があります。C_UNWRAPKEYとC_DERIVEKEYを呼び出す場合、PTEMPLATEパラメーターを使用して、ローカルポリシーに従って追加の重要な属性を設定し、プロトコルで交渉および表現されたものを設定する必要があります。特に、サーバーの応答メッセージの<KeyID>要素の値は、K_TOKENのCKA_IDとして使用できます。キーK_Provは、K_TOKENとK_MACを導き出した後に破壊する必要があります。
2. The MAC is verified in a reciprocal fashion as it was generated by the server. If use of the CKM_KIP_MAC mechanism has been negotiated, then in the call to C_VerifyInit, the hKey parameter in the CK_KIP_PARAMS structure MUST be set to NULL_PTR, the pSeed parameter MUST be set to NULL_PTR, and ulSeedLen MUST be set to 0. The hKey parameter of C_VerifyInit MUST refer to K_MAC. In the call to C_Verify, pData MUST be set to the concatenation of the string ServerID and the nonce R, and the ulDataLen parameter MUST be set to the length of the concatenated string, pSignature to the MAC value received from the server, and ulSignatureLen to the length of the MAC. If the MAC does not verify the protocol session ends with a failure. The token MUST be constructed to not "commit" to the new K_TOKEN or the new K_MAC unless the MAC verifies.
2. Macは、サーバーによって生成されたため、相互に検証されています。CKM_KIP_MACメカニズムの使用がネゴシエートされている場合、C_VerifyInitへの呼び出しで、CK_KIP_PARAMS構造のHKEYパラメーターはnull_PTRに設定する必要があり、PSEEDパラメーターはnull_ptrに設定する必要があり、ulseedlenは0に設定する必要があります。c_verifyinitのk_macを参照する必要があります。c_verifyへの呼び出しでは、pdataを文字列serverIDおよびnonce rの連結に設定する必要があり、ウルダタレンパラメーターは連結された文字列の長さに設定し、サーバーから受信したMac値、およびulsignaturelenに設定する必要があります。Macの長さ。MACがプロトコルセッションが障害で終了することを確認しない場合。トークンは、MACが検証されない限り、新しいK_TOKENまたは新しいK_MACに「コミット」しないように構築する必要があります。
3. If an authenticating MAC was received (REQUIRED if the new K_TOKEN will replace an existing key on the token), then it is verified in a similar vein but using the K_MAC' associated with this server and existing before the protocol run (the implementation may specify K_MAC' to be the value of the K_TOKEN that is being replaced, or a version of K_MAC from the previous protocol run). Again, if the MAC does not verify the protocol session ends with a failure, and the token MUST be constructed not to "commit" to the new K_TOKEN or the new K_MAC unless the MAC verifies.
3. 認証MACが受信された場合（新しいK_TOKENがトークンの既存のキーを置き換える場合に必要）、同様の静脈で検証されますが、このサーバーに関連付けられ、プロトコルの実行前に存在するK_MAC 'を使用します（実装は指定できます。k_mac 'は、置き換えられているk_tokenの価値、または以前のプロトコル実行からのk_macのバージョンであること。繰り返しますが、MACがプロトコルセッションが障害で終了し、トークンを構築して、MACが検証されない限り、新しいK_TOKENまたは新しいK_MACに「コミット」しないようにトークンを構築する必要があります。
This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES] and HMAC [RFC2104]. This appendix forms a normative part of the document.
この例の付録は、AES [FIPS197-AES]およびHMAC [RFC2104]の観点からDSKPP-PRFを定義しています。この付録は、ドキュメントの規範的な部分を形成します。
For cryptographic modules supporting this realization of DSKPP-PRF, the following URN MUST be used to identify this algorithm in DSKPP:
DSKPP-PRFのこの実現をサポートする暗号化モジュールの場合、DSKPPでこのアルゴリズムを識別するために、次のURNを使用する必要があります。
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
When this URN is used to identify the encryption algorithm, the method for encryption of R_C values described in Section 4.2.4 MUST be used.
このURNを使用して暗号化アルゴリズムを識別する場合、セクション4.2.4で説明されているR_C値の暗号化の方法を使用する必要があります。
DSKPP-PRF-AES (k, s, dsLen)
dskpp-prf-aes（k、s、dslen）
Input:
入力：
k Encryption key to use s Octet string consisting of randomizing material. The length of the string s is sLen. dsLen Desired length of the output
k暗号化キーは、材料をランダム化することで構成されるSオクテット文字列を使用します。文字列sの長さはスレンします。dslen出力の長さの希望
Output:
出力：
DS A pseudorandom string, dsLen-octets long
ds擬似ランダム文字列、dslen-ouctets long
Steps:
ステップ：
1. Let bLen be the output block size of AES in octets:
1. ブレンをオクテットのAEの出力ブロックサイズにします：
bLen = (AES output block length in octets)
(normally, bLen = 16)
2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and stop
2. dslen>（2 ** 32-1）*ブレン、出力「派生データが長すぎる」と停止した場合
3. Let n be the number of bLen-octet blocks in the output data, rounding up, and let j be the number of octets in the last block:
3. nを出力データのblen-octetブロックの数とし、丸めて、jを最後のブロックのオクテットの数とします。
n = CEILING( dsLen / bLen)
j = dsLen - (n - 1) * bLen
4. For each block of the pseudorandom string DS, apply the function F defined below to the key k, the string s and the block index to compute the block:
4. 擬似ランダム文字列dsの各ブロックについて、以下に定義する関数fをキーK、文字列S、およびブロックインデックスに適用して、ブロックを計算します。
B1 = F (k, s, 1) , B2 = F (k, s, 2) , ... Bn = F (k, s, n)
b1 = f（k、s、1）、b2 = f（k、s、2）、... bn = f（k、s、n）
The function F is defined in terms of the CMAC construction from [NIST-SP800-38B], using AES as the block cipher:
関数fは、[nist-sp800-38b]からのCMAC構造の観点から定義され、AESをブロック暗号として使用します。
F (k, s, i) = CMAC-AES (k, INT (i) || s)
f（k、s、i）= cmac-aes（k、int（i）|| s）
where INT (i) is a four-octet encoding of the integer i, most significant octet first, and the output length of CMAC is set to bLen.
ここで、int（i）は整数Iの4オクテットのエンコードであり、最初に最も重要なオクテット、およびCMACの出力長がブレンに設定されます。
Concatenate the blocks and extract the first dsLen octets to produce the desired data string DS:
ブロックを連結し、最初のdslenオクテットを抽出して、目的のデータ文字列dsを生成します。
DS = B1 || B2 || ... || Bn<0..j-1>
Output the derived data DS.
派生データdsを出力します。
If we assume that dsLen = 16, then:
dslen = 16と仮定した場合、次のとおりです。
n = 16 / 16 = 1
j = 16 - (1 - 1) * 16 = 16
DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s)
For cryptographic modules supporting this realization of DSKPP-PRF, the following URN MUST be used to identify this algorithm in DSKPP:
DSKPP-PRFのこの実現をサポートする暗号化モジュールの場合、DSKPPでこのアルゴリズムを識別するために、次のURNを使用する必要があります。
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
When this URN is used to identify the encryption algorithm to use, the method for encryption of R_C values described in Section 4.2.4 MUST be used.
このURNを使用して使用する暗号化アルゴリズムを識別する場合、セクション4.2.4で説明されているR_C値の暗号化の方法を使用する必要があります。
DSKPP-PRF-SHA256 (k, s, dsLen)
dskpp-prf-sha256（k、s、dslen）
Input:
入力：
k Encryption key to use s Octet string consisting of randomizing material. The length of the string s is sLen. dsLen Desired length of the output
k暗号化キーは、材料をランダム化することで構成されるSオクテット文字列を使用します。文字列sの長さはスレンします。dslen出力の長さの希望
Output:
出力：
DS A pseudorandom string, dsLen-octets long
ds擬似ランダム文字列、dslen-ouctets long
Steps:
ステップ：
1. Let bLen be the output size of SHA-256 in octets of [FIPS180-SHA] (no truncation is done on the HMAC output):
1. Blenを[FIPS180-SHA]のオクテットのSHA-256の出力サイズとします（HMAC出力では切り捨ては行われません）：
bLen = 32 (normally, bLen = 16)
blen = 32（通常、ブレン= 16）
2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and stop
2. dslen>（2 ** 32-1）*ブレン、出力「派生データが長すぎる」と停止した場合
3. Let n be the number of bLen-octet blocks in the output data, rounding up, and let j be the number of octets in the last block:
3. nを出力データのblen-octetブロックの数とし、丸めて、jを最後のブロックのオクテットの数とします。
n = CEILING( dsLen / bLen)
j = dsLen - (n - 1) * bLen
4. For each block of the pseudorandom string DS, apply the function F defined below to the key k, the string s and the block index to compute the block: B1 = F (k, s, 1), B2 = F (k, s, 2), ... Bn = F (k, s, n)
4. 擬似ランダム文字列dsの各ブロックについて、以下に定義した関数fをキーK、文字列S、およびブロックインデックスに適用してブロックを計算します：b1 = f（k、s、1）、b2 = f（k、s、2）、... bn = f（k、s、n）
The function F is defined in terms of the HMAC construction from [RFC2104], using SHA-256 as the digest algorithm:
関数Fは、SHA-256をダイジェストアルゴリズムとして使用して、[RFC2104]からのHMAC構造の観点から定義されています。
F (k, s, i) = HMAC-SHA256 (k, INT (i) || s)
f（k、s、i）= hmac-sha256（k、int（i）|| s）
where INT (i) is a four-octet encoding of the integer i, most significant octet first, and the output length of HMAC is set to bLen.
ここで、int（i）は整数Iの4オクテットエンコードであり、最初に最も重要なオクテット、およびHMACの出力長がBlenに設定されます。
Concatenate the blocks and extract the first dsLen octets to produce the desired data string DS:
ブロックを連結し、最初のdslenオクテットを抽出して、目的のデータ文字列dsを生成します。
DS = B1 || B2 || ... || Bn<0..j-1>
Output the derived data DS.
派生データdsを出力します。
If we assume that sLen = 256 (two 128-octet long values) and dsLen = 16, then:
Slen = 256（2つの128-OCTET LONG値）とDSLEN = 16と仮定した場合、次のとおりです。
n = CEILING( 16 / 32 ) = 1
j = 16 - (1 - 1) * 32 = 16
B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s)
b1 = f（k、s、1）= hmac-sha256（k、int（1）|| s）
DS = B1<0 ... 15>
That is, the result will be the first 16 octets of the HMAC output.
つまり、結果はHMAC出力の最初の16オクテットになります。
Authors' Addresses
著者のアドレス
Andrea Doherty RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 USA
Andrea Doherty RSA、EMC 174 Middlesex Turnpike Bedford、MA 01730 USAのセキュリティ部門
EMail: andrea.doherty@rsa.com
Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Mingliang Pei Verisign、Inc。487 E. Middlefield Road Mountain View、CA 94043 USA
EMail: mpei@verisign.com
Salah Machani Diversinet Corp. 2225 Sheppard Avenue East, Suite 1801 Toronto, Ontario M2J 5C2 Canada
Salah Machani Diversinet Corp. 2225 Sheppard Avenue East、スイート1801トロント、オンタリオM2J 5C2カナダ
EMail: smachani@diversinet.com
Magnus Nystrom Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA
Magnus Nystrom Microsoft Corp. One Microsoft Way Redmond、WA 98052 USA
EMail: mnystrom@microsoft.com