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
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.
协议的两种变体支持多种使用场景。对于四次传递变量，密钥由配置服务器和加密模块相互生成；配置的密钥不会通过有线或无线传输。双通道变体可以安全高效地将预生成的对称密钥下载和安装到加密模块。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以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
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
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
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.
基于对称密钥的密码系统（例如，提供一次性密码和质询响应等身份验证机制的系统）比公钥方案具有性能和操作优势。这种使用要求提供对称密钥的机制，该机制提供与公钥基础设施中的证书管理协议（CMP）[RFC4210]和CMS上的证书管理（CMC）[RFC5272]等机制等效的功能。
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）是一个例外[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 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提供了一种开放且可互操作的机制，用于初始化和配置可通过Internet访问的加密模块的对称密钥。该说明基于[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有两种主要的协议变体。四通道协议变体允许建立对称密钥，该密钥包括客户端和服务器提供的随机性。双通道协议只需要一次往返，而不是两次，并允许建立服务器指定的密钥。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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>”。主数字和次数字必须被视为独立的整数，每个数字的增量可以大于一个位数。因此，“DSKPP 2.4”的版本低于“DSKPP 2.13”，而“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.
本文档使用统一资源标识符（URI）[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"
"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"
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#"
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）：用户身份验证码，由设备和服务器已知的十六进制字符字符串组成，至少包含客户端标识符和密码。此ClientID/密码组合仅使用一次，可能有时间限制，然后被丢弃。
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
密钥协议：一种密钥建立协议，其中两个或多个协议方可以就密钥达成一致，从而双方都会影响结果
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
密钥保护方法（KPM）：双通道DSKPP期间使用的密钥传输方法
Key Protection Method List (KPML): The list of key protection methods supported by a cryptographic module
密钥保护方法列表（KPML）：加密模块支持的密钥保护方法列表
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的一次性密码（誓言HOTP）或RSA SecurID身份验证、AES加密等）
Key Wrapping: A method of encrypting keys for key transport [NIST-SP800-57]
密钥包装：密钥传输的密钥加密方法[NIST-SP800-57]
Key Wrapping Key: A symmetric key encrypting key used for key wrapping [NIST-SP800-57]
密钥包装密钥：用于密钥包装的对称密钥加密密钥[NIST-SP800-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)
协议运行：完成涉及一次交换（两次通过）或两次交换（四次通过）的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变体（四次或两次传递）、密钥包格式、密钥类型和加密模块能够支持的加密算法的有效负载
|| 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
||字符串连接[x]可选元素x A^B对字符串A和B的异或操作（其中A和B长度相等）<XMLElement>文本正文中使用的排版惯例DSKPP-PRF（k，s，dsLen）一个带密钥的伪随机函数E（k，m）加密m，密钥k用于加密R_C（k_服务器或k_共享），或在MAC或DSKPP_PRF计算中，K_AC密钥源自认证码，用于用户认证目的K_MAC密钥在DSKPP交换期间衍生用于密钥确认的K_MAC密钥K_MAC'用于服务器认证的第二个密钥K_提供从中派生两个密钥的配置主密钥：DSKPP服务器的K_令牌和K_MAC K_服务器公钥；用于加密四通道协议变体中的R_C
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
在DSKPP客户端和DSKPP服务器之间预先共享的K_共享密钥；用于加密四通协议变体K_令牌密钥中的R_C，该密钥使用由DSKPP客户端选择的DSKPP R伪随机值在加密模块中建立，用于由DSKPP客户端选择的MAC计算R_C伪随机值，并用作生成由客户端选择的K_令牌R_S伪随机值的输入DSKPP服务器，并用作生成K_令牌URL_的DSKPP服务器地址的输入，作为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认证码AD认证数据DSKPP动态对称密钥提供协议HTTP超文本传输协议KP密钥包KPM密钥保护方法KPML密钥保护方法列表MAC消息认证码PC个人计算机PDU协议数据单元PKCS公钥加密标准PRF伪随机函数PSKC便携式对称密钥容器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配置事务有三个实体：
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]，它是在传输机制上分层的，例如HTTP[RFC2616]和HTTP Over TLS[RFC2818]。虽然DSKPP客户机和服务器之间的整个通信非常需要通过提供机密性和完整性保护的传输（如HTTP over transport Layer Security（TLS））进行保护，这种保护不足以保护服务器和加密模块之间的对称密钥数据交换，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元素的方式对DSKPP服务器是透明的。[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
在DSKPP消息流中，用户已获得嵌入加密模块的新硬件或软件设备。DSKPP的目标是向加密模块和密钥管理服务器提供相同的对称密钥和相关信息，以及
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服务器必须对用户进行身份验证，以确保用户有权使用新密钥。
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 |
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.
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连接，验证服务器（即验证证书，并将URL中的主机名与证书进行比较），如[RFC2818]第3.1节所述。
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).
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服务器）之间的确切分工。上图显示了一种可能的情况，但这仅用于说明目的。
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... | |
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.
在第二个消息流中，用户首先使用普通web浏览器和一些现有凭据向web服务器（例如，IT部门的“自助”Intranet页面）进行身份验证。
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服务器将使用<KeyProvTrigger>消息进行回复，该消息包含DSKPP服务器的客户端ID、身份验证代码和URL。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.
然后，DSKPP客户端与DSKPP服务器联系，并以与第一条消息流相同的方式使用客户端ID和身份验证代码（来自<KeyProvTrigger>消息）。
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.
如前一节所述，一旦协议启动，客户端和服务器可以进行两次或四次消息交换。四通和两通协议适用于不同的部署场景。两者之间最大的区别在于，双通道协议支持将现有密钥传输到加密模块，而四通道协议涉及通过密钥协议动态生成密钥。在这两种情况下，两种协议变体都通过在每个协议运行开始时协商加密机制和密钥类型来支持算法灵活性。
The four-pass protocol is needed under one or more of the following conditions:
在以下一个或多个条件下需要四通协议：
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 加密模块由一个设备托管，该设备既没有预先颁发制造商密钥或其他形式的预共享密钥（如智能卡或用户身份模块（SIM）卡），也没有可用于输入密码短语的键盘（如手机上的键盘）。
The two-pass protocol is needed under one or more of the following conditions:
在以下一个或多个条件下需要双通道协议：
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.
格式错误的请求：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.
UnknownCriticalExtension：接收方无法解释标记为“关键”的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.
不支持版本：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.
不支持加密算法：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.
不支持MAC算法：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客户机没有建议所需的协议变体（两次或四次）。此错误仅在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.
初始化失败：给定提供的数据，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以类型长度值（TLV）格式编码。该格式由至少两个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个字符）标识值字段中包含的信息类型的十六进制字符。
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个字符）两个十六进制字符，指示要跟随的值字段的长度。字段值最多可包含255个字符。长度值00可用于指定没有任何字段值的自定义标记。
Value (variable length) A variable-length string of hexadecimal characters containing the instance-specific information for this TLV.
值（可变长度）包含此TLV的实例特定信息的十六进制字符可变长度字符串。
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" } |
+------+------------+-------------+-----------------------------+
+------+------------+-------------------------------------------+
| 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是一个强制TLV，表示请求者的标识符，最大长度为255。该值表示为标识密钥请求的十六进制字符字符串。例如，假设客户端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，包含用户和配置服务器已知的一次性使用共享密钥。密码值是唯一的，应该是一个随机字符串，以使AC更难猜测。字符串只能包含十六进制字符。例如，假设密码设置为“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
尽管本规范建议在应用程序的用户界面层仅对AC使用十六进制字符，并使TLV三元组对用户不透明，如上述示例所述；实现还可以选择在应用程序的用户界面层使用其他可打印的Unicode字符[Unicode]，以满足特定的本地、上下文或可用性要求。当需要非十六进制字符时
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).
用户界面层，例如当使用其他可打印的US-ASCII字符或国际字符时，在将用户输入转换为十六进制字符字符串之前，必须使用SASLprep[RFC4013]规范化用户输入。例如，如果给定的应用程序允许在客户端ID和密码字段中使用任何可打印的US-ASCII字符和扩展ASCII字符，并且客户端ID设置为“myclient！D”，并且相关密码设置为“mYpas&#rD”，则用户通过键盘或其他方式输入客户端ID“myclient！D”，密码为“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！身份证件
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字符U+0063拉丁小写字母C字符U+006C拉丁小写字母L字符U+0069拉丁小写字母I字符U+0065拉丁小写字母E字符U+006E拉丁小写字母N字符U+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转换为：6D 79 63 6C 69 65 6E 74 21 44
The length of the Client ID value in hexadecimal characters is: 14
以十六进制字符表示的客户端ID值的长度为：14
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
原始密码值或用户输入的值为：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+006D拉丁小写字母M字符U+0059拉丁大写字母Y字符U+0070拉丁小写字母P字符
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
U+0061拉丁字母小写字母A字符U+0073拉丁字母小写字母S字符U+0026符号和字符（&）U+0023磅符号字符（#）U+0072拉丁字母小写字母R字符U+0044拉丁字母大号D字符
The UTF-8 conversion of the password value is: 6D 59 70 61 73 26 23 72 44
密码值的UTF-8转换为：6D 59 70 61 73 26 23 72 44
The length of the password value in hexadecimal characters is: 12
以十六进制字符表示的密码值长度为：12
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 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的一般说明见第3.4.2节，DSKPP-PRF-AES的说明见附录D）：
MAC = DSKPP-PRF(K_AC, AC->ClientID||URL_S||R_C||[R_S], 16)
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]:
在四通道DSKPP中，加密模块使用R_C、R_S和URL_S计算MAC，其中URL_S是DSKPP客户端在联系DSKPP服务器时使用的URL。在双通道DSKPP中，加密模块没有访问R_S的权限，因此只有R_C与URL_S结合使用以生成MAC。在任何一种情况下，K_AC都必须从AC->password派生，如下[PKCS-5]：
K_AC = PBKDF2(AC->password, R_C || K, iter_count, 16)
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. 四次传递：*DSKPP服务器（K_服务器）的公钥，或（在预共享密钥变体中）客户端和服务器之间的预共享密钥（K_共享）。B两次通过：*DSKPP客户端的公钥，或设备证书可用时设备的公钥。*客户端和服务器之间的预共享密钥（K_共享）。*由密码短语派生的密钥。
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必须设置为至少100000，但在最后两种情况下（其中K设置为K_共享密钥或密码短语派生密钥）除外，在这种情况下，iter_count必须设置为1。
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和可变长度的八位字节字符串s确定性转换为指定长度的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.
此原语必须满足与键控哈希函数相同的要求：它必须接受任意长度的输入，并生成单向且无冲突的输出（有关这些术语的定义，请参阅，例如[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的示例实现。
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
八位字符串格式的k密钥s长度可变的八位字符串，由变量数据组成，用于区分要导出的特定字符串和输出的所需长度
Output:
输出：
DS pseudorandom string, dsLen octets long
DS伪随机字符串，dsLen八位字节长
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:
在协议运行中发送最后一条消息时，DSKPP服务器生成一个MAC，供客户端用于密钥确认。MAC的计算必须包括事务期间客户端和服务器发送的所有DSKPP消息的散列。要计算给定DSKPP消息序列msg_1，…，msg_n的MAC的消息哈希，必须执行以下操作：
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].
a. 消息序列包含截至但不包括此消息的所有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.
本节描述组成四通道协议变体的方法和消息流。四通道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.
对于四次传递的DSKPP，作为资源调配目标的对称密钥将动态生成，而无需在DSKPP客户端和DSKPP服务器之间传输。数据流和计算如下所述。
A sample data flow showing key generation during the four-pass protocol is shown in Figure 3.
图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
+----------------------+ +----------------------+
| +------------+ | | |
| | 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.
密钥生成中包含的两个随机时值（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
从概念上讲，尽管R_C是一个伪随机字符串，但它可以被视为由两个组件组成，R_C1和R_C2，其中R_C1在协议运行期间生成，R_C2可以预先生成并
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_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_令牌版本。但是，攻击者无法说服合法服务器为K_令牌派生相同的值，因为K_令牌是相关公钥的函数，并且攻击者的公钥必须不同于正确的服务器（否则攻击者将无法解密从客户端接收的信息）。因此，一旦攻击者不再处于“中间”，客户端和服务器将在尝试使用密钥时检测到它们“不同步”。因此，在使用K_服务器加密R_C的情况下，验证K_服务器是否真的是合法服务器的密钥非常重要。一种方法是根据服务器上的验证服务（例如，使用独立于密钥生成所用连接的连接）独立验证新生成的K_令牌。
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:
在四通道DSKPP中，客户机和服务器都通过使用DSKPP-PRF（参考第3.4.2节）从配置密钥（K_PROV）中导出K_令牌和K_MAC来生成K_令牌和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)
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_令牌和K_MAC是从K_PROV派生的，其中
K_PROV = K_MAC || K_TOKEN
K|u PROV=K|u MAC | K|u令牌
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_令牌在被采用为所选类型的密钥之前，可经受依赖于算法的变换。其中一个例子是DES密钥中需要奇偶校验。
Note that this computation pertains to four-pass DSKPP only.
请注意，此计算仅适用于四程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 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.
第一对消息协商加密算法并交换nonce。第二对消息使用相互认证的密钥协议建立对称密钥。
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]
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（标识要替换的密钥）传递给DSKPP服务器。
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客户端的DSKPP服务器URL。
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，以允许DSKPP服务器在完成协议运行之前对用户进行身份验证。
A DeviceID MAY be included to allow a key provisioning application to bind the provisioned key to a specific device.
可以包括设备id以允许密钥供应应用程序将所供应的密钥绑定到特定设备。
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.
可以包括密钥id以允许密钥供应应用程序识别要替换的密钥，例如，在密钥续订的情况下。
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] --->
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>作为其第一条消息发送。客户端还可以发送<KeyProvClientHello>以响应<KeyProvTrigger>。
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）、设备ID和/或密钥ID。
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服务器预先共享的设备ID，以及与先前由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版本、变量（在本例中为四次传递）、密钥包格式、密钥类型和加密算法的可接受组合。如果DSKPP客户端的SAL与DSKPP服务器的功能不匹配，或者不符合密钥设置策略，则DSKPP服务器将把Status属性设置为“Continue”以外的其他属性。否则，状态属性将设置为“继续”。
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）、设备ID和密钥ID。DSKPP服务器不得接受DeviceID，除非服务器在前面的触发消息中发送DeviceID。请注意，DSKPP客户端在没有从服务器收到<KeyProvTrigger>消息的情况下启动DSKPP运行也是合法的，但在这种情况下，DSKPP服务器不得接受任何提供的DeviceID，除非服务器可以访问标识设备的唯一密钥，并且该密钥将在协议中使用。
DSKPP Client DSKPP Server
------------ ------------
<--- SAL, R_S, [K], [MAC]
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版本、变量（在本例中为四次传递）、密钥包格式、密钥类型和加密算法集的可接受组合后，将发送此消息以响应<KeyProvClientHello>消息。如果找不到可接受的组合，则仍将发送消息，但状态为失败。
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服务器使用此消息来传输随机nonce，这是每一方同意相同对称密钥（K_令牌）所必需的。
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版本和变量（在本例中为四次传递）、密钥类型、加密算法和密钥包格式，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.
如果密钥正在续订，则必须存在MAC，以便DSKPP客户端可以确认替换密钥来自受信任的服务器。必须使用DSKPP-PRF（见第3.4.2节）计算该MAC，其中输入参数k必须设置为现有MAC密钥k_MAC’（即，在该协议运行之前存在的MAC密钥的值；实现可能指定k_MAC’为被替换的k_令牌的值），输入参数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客户端如何使用此消息：当Status属性未设置为“Continue”时，这表示失败，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。如果MAC未验证，DSKPP客户端必须终止DSKPP会话，并且必须删除与失败运行相关的任何nonce、密钥和/或机密。
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.
如果Status属性设置为“Continue”，则加密模块使用SAL中指定的加密算法生成随机nonce（R_C）。nonce rc的长度取决于所选的键类型。
Encrypt R_C using K and the encryption algorithm included in the SAL.
使用K和SAL中包含的加密算法加密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].
DSKPP客户端必须使用的加密R#C的方法：如果K等同于K#SERVER（即DSKPP服务器的公钥），则可以使用PKCS#1[PKCS-1]中的RSA加密方案。如果K相当于K_SERVER，则加密模块应在使用服务器证书加密R_C之前验证服务器的证书，如[RFC2818]，第3.1节和[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:
如果K等于K_SHARED，则DSKPP客户端可以使用DSKPP-PRF来避免对其他算法的依赖。在这种情况下，客户端使用K_SHARED作为输入参数K（K_SHARED应仅用于此目的），如下所示：
dsLen = len(R_C), where "len" is the length of R_C
DS = DSKPP-PRF(K_SHARED, "Encryption" || R_S, dsLen)
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。然后可以通过将DS与R_C异或来实现R_C的加密：
E(DS, R_C) = DS ^ R_C
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 --->
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）加密的随机nonce。每一方都需要客户端的随机nonce来同意相同的对称密钥（K_令牌）。
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.
按照第4.2.3节所述进行加密的DSKPP客户端的随机非随机数（R_C）。
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服务器必须将返回代码设置为失败状态。
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）（有关DSKPP客户端如何加密R_C的说明，请参阅第4.2.3节）。
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服务器使用两个随机非随机数R_S和R_C及其加密密钥K的组合计算K_令牌，如第4.1.2节所述。DSKPP-PRF的具体实现（例如，附录D中定义的实现）取决于<KeyProvServerHello>消息中包含的MAC算法。然后，DSKPP服务器生成一个包含密钥使用属性（如到期日期和长度）的密钥包。密钥包不得包含K_令牌，因为在四次传递变量中，K_令牌从未在DSKPP服务器和客户端之间传输。服务器将K_令牌和密钥包与用户帐户一起存储在加密服务器上。
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，客户端将使用该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\u散列）
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash, dsLen)
MAC=DSKPP-PRF（K|u MAC，“MAC 1计算”| msg|u散列，dsLen）
where
哪里
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_散列而形成的字符串来计算。
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
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_令牌和密钥包，并将其与加密服务器上的用户帐户关联。
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_令牌）的生成，并将密钥包中的相关标识符和特定于应用程序的属性（而不是密钥本身）传输给客户端以完成协议。
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
此消息中包含的内容：相当于服务器返回到<KeyProvClientNonce>的代码的状态属性。如果用户身份验证通过，并且服务器成功地计算了K_令牌，生成了密钥包，并将它们与加密服务器上的用户帐户相关联，那么它会将Status属性设置为“Success”。如果Status属性设置为“Success”，则该消息充当“Commit”消息，指示加密模块存储生成的密钥（K_令牌），并将给定的密钥标识符与该密钥关联。因此，此消息中必须包含密钥包（KP），其中包含生成密钥的标识符（但不是密钥本身）和其他配置，例如DSKPP服务器的标识、密钥使用属性等。默认的对称密钥包格式必须为
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.
基于[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客户端如何使用此消息：当Status属性未设置为“Success”时，这表示失败，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.
DSKPP客户端在收到状态为“成功”的<KeyProvServerFinished>消息后，必须验证随此消息发送的密钥确认MAC。如果MAC未验证，DSKPP客户端必须终止DSKPP会话，在这种情况下，还必须删除与协议失败运行相关的任何nonce、密钥和/或机密。
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>具有Status=“Success”，并且MAC已被验证，则DSKPP客户端必须根据两个随机时值R_S和R_C以及服务器加密密钥K的组合计算K_令牌，如第4.1.2节所述。DSKPP-PRF与用于MAC计算的相同。DSKPP客户端将<KeyProvServerFinished>中包含的密钥包与生成的密钥K_令牌关联，并将此数据永久存储在加密模块上。
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].
本节描述组成双通道协议变体的方法和消息流。双通道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.
密钥材料包括设置主密钥K_PROV，DSKPP客户端从中派生两个密钥：将在加密模块中建立的对称密钥K_令牌和用于密钥确认的密钥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服务器使用三种密钥保护方法中的任意一种来加密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客户端和服务器可以协商要使用的密钥保护方法，但实际的密钥保护是在密钥包中执行的。密钥包的格式指定如何使用三种密钥保护方法保护密钥。为DSKPP定义了以下KeyPackage格式：
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密钥容器处的PSKC密钥容器[RFC6030]
o SKPC Key Container [RFC6031] at urn:ietf:params:xml:ns:keyprov:dskpp:skpc-key-container
o urn:ietf:params:xml:ns:keyprov:dskpp:SKPC密钥容器处的SKPC密钥容器[RFC6031]
o PKCS12 Key Container [PKCS-12] at urn:ietf:params:xml:ns:keyprov:dskpp:pkcs12-key-container
o urn:ietf:params:xml:ns:keyprov:dskpp:PKCS12密钥容器处的PKCS12密钥容器[PKCS-12]
o PKCS5-XML Key Container [PKCS-5-XML] at urn:ietf:params:xml:ns:keyprov:dskpp:pkcs5-xml-key-container
o urn:ietf:params:XML:ns:keyprov:dskpp:PKCS5 XML密钥容器处的PKCS5-XML密钥容器[PKCS-5-XML]
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.
本节介绍了双通道变体的三种关键保护方法。其他方法可由外部实体或通过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客户端的私钥部分位于加密模块中。DSKPP客户机解密密钥材料，并使用它派生对称密钥K_令牌。
This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp:transport
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_令牌。
This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp:wrap
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
Refer to id-aes128-wrap in [RFC3394] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
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 KeyWrap with Padding
Refer to id-aes128-wrap-pad in [RFC5649] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES-CBC-128
Refer to [FIPS197-AES] and
http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
AES-CBC-128
Refer to [FIPS197-AES] and
http://www.w3.org/2001/04/xmlenc#aes128-cbc in [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_令牌。
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.
为了保留不向DSKPP服务器和加密模块本身以外的任何其他实体公开K_令牌的属性，仅当设备包含用于直接输入密码短语的设施（例如，键盘）时，才应使用该方法。
This method is identified with the following URN:
urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
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密码的加密方案，标识为http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 在[PKCS-5-XML]中。
* 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]).
* 基于PBKDF2密码短语的密钥派生函数也在[PKCS-5]中定义，并标识为http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2 在[PKCS-5-XML]中。
* 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
Refer to id-aes128-wrap in [RFC3394] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
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 KeyWrap with Padding
Refer to id-aes128-wrap-pad in [RFC5649] and
http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
AES-CBC-128
Refer to [FIPS197-AES] and
http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
AES-CBC-128
Refer to [FIPS197-AES] and
http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
The two-pass protocol flow consists of one exchange:
1: Pass 1 = <KeyProvClientHello>, Pass 2 = <KeyProvServerFinished>
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.2.1节。
DSKPP Client DSKPP Server
------------ ------------
SAL, AD, R_C,
[DeviceID], [KeyID],
KPML --->
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>作为其第一条消息发送。客户端还可以发送<KeyProvClientHello>以响应<KeyProvTrigger>消息。
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版本、协议变体（在本例中为“双过程”）、密钥包格式和密钥保护方法。此外，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时使用该随机nonce。通过将R_C插入DSKPP会话，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>，则此消息还必须包括触发器提供的DeviceID和/或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:KeyInfoType>选项（即<ds:KeyName>、<ds:KeyValue>、<ds:X509Data>或<ds:PGPData>）。当与加密模块上的私钥对应的公钥已被认证时，建议使用<ds:X509Data>备选方案的<ds:X509Certificate>选项。
* 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).
* 基于密码短语的密钥包装必须使用<ds:KeyName>选项，并且密钥名称必须标识服务器将用于生成密钥包装密钥的密码短语。<ds:KeyName>的标识符和密码短语组件必须设置为AD的客户端ID和身份验证代码组件（与此消息中包含的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
DSKPP服务器如何使用此消息：DSKPP服务器将查找DSKPP版本、变量（在本例中为两次传递）、密钥包格式、密钥类型和加密算法的可接受组合。如果DSKPP客户端的SAL与DSKPP服务器的功能不匹配，或者
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服务器将把Status属性设置为“Success”以外的其他属性。否则，状态属性将设置为“成功”。
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.
如果包含在<KeyProvClientHello>中，DSKPP服务器将验证DeviceID和KeyID。DSKPP服务器不得接受DeviceID，除非服务器在前面的触发消息中发送DeviceID。请注意，DSKPP客户端在没有从服务器收到<KeyProvTrigger>消息的情况下启动DSKPP运行也是合法的，但在这种情况下，DSKPP服务器不得接受任何提供的DeviceID，除非服务器可以访问标识设备的唯一密钥，并且该密钥将在协议中使用。
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服务器必须将返回代码设置为失败状态，在这种情况下，还必须删除与协议失败运行相关的任何nonce、密钥和/或机密。
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的权限，K_PROV仅由DSKPP服务器随机生成，其中K_PROV必须由两个长度相等的部分组成，即。，
K_PROV = K_MAC || K_TOKEN
K|u PROV=K|u MAC | K|u令牌
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_令牌的长度（因此也是K_MAC的长度）由K_令牌的类型决定，K_令牌的类型必须是DSKPP客户端支持的密钥类型之一。如果K_令牌的所需密钥长度与底层MAC算法的K_MAC长度不同，则必须选择两者中较大的长度来生成K_PROV。当K_MAC比所需的K_令牌长度长时，在MAC算法中使用实际的MAC密钥时，实际的MAC密钥将从生成的K_MAC中截断。如果K_令牌的长度超过了匹配K_MAC长度所需的长度，则供应服务器和接收客户端必须根据目标密钥算法确定实际密钥长度，并仅存储K_令牌的截断部分。截断必须从K_令牌或K_MAC中获取实际密钥所需长度的起始字节。例如，当供应服务器提供长度为20的基于事件的HOTP密钥和MAC算法DSKPP-PRF-SHA256（附录D）时，K_PROV长度将为64。派生的K_令牌和K_MAC将分别由32个字节组成。实际的HOTP密钥应该是K_令牌的前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中选择一种密钥保护方法，并使用该方法和相应的有效负载来加密K_PROV。DSKPP服务器生成密钥包以传输密钥加密方法信息和加密的配置密钥（K_PROV）。加密数据格式取决于所选密钥包支持的选择。密钥包必须指定并使用选定的密钥保护方法以及在<KeyProvClientHello>中接收到的密钥信息。密钥包还包括密钥使用属性，如到期日期和长度。服务器使用加密服务器上的用户帐户存储密钥包和K_令牌。
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，客户端将使用该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.
此外，如果正在续订现有密钥，服务器将生成第二个MAC，并将其作为服务器身份验证数据（AD）返回给客户端，以便DSKPP客户端可以确认替换密钥来自受信任的服务器。
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\u散列）
MAC = DSKPP-PRF (K_MAC, "MAC 1 computation" || msg_hash || ServerID, dsLen)
MAC=DSKPP-PRF（K|u MAC，“mac1计算”| msg|u 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，并且必须使用现有的MAC密钥K_MAC在（ASCII）字符串“MAC 1计算”、msg_哈希和ServerID上计算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第3.4.3节中定义的消息msg_1，…，msg_n的消息散列。
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_哈希和ServerID的串联组成，并且参数dsLen必须设置为msg_哈希的长度。
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密钥K_MAC（此协议运行之前存在的MAC密钥），在（ASCII）字符串“MAC 2计算”、服务器标识符ServerID和R上计算MAC。注意，实现可以指定K_MAC’为被替换的K_令牌的值。
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和R的串联组成。参数dsLen必须设置为至少16（即，MAC的长度必须至少为16个八位字节）：
dsLen >= 16
dsLen>=16
MAC = DSKPP-PRF (K_MAC', "MAC 2 computation" || ServerID || R, dsLen)
MAC=DSKPP-PRF（K|U MAC'，“MAC 2计算”| |服务器ID | | R，dsLen）
The MAC algorithm MUST be the same as the algorithm used by the DSKPP Server to calculate the key confirmation MAC.
MAC算法必须与DSKPP服务器用于计算密钥确认MAC的算法相同。
DSKPP Client DSKPP Server
------------ ------------
<--- KP, MAC, AD
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_令牌和密钥包，并将其与加密服务器上的用户帐户关联。
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".
此消息中包含的内容：相当于服务器返回到<KeyProvClientHello>的代码的状态属性。如果服务器从客户端的SAL中找到了一组可接受的属性，那么它会将状态设置为“成功”。
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。如前一节所述，使用“mac1计算”计算该密钥确认MAC。
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.
最后，如果要替换现有密钥，则此消息还必须包括服务器身份验证MAC（使用上一节中描述的“MAC 2计算”计算），该MAC作为AD传递给DSKPP客户端。
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客户端如何使用此消息：在收到状态为“成功”的<KeyProvServerFinished>消息后，DSKPP客户端必须验证两个MAC（MAC和AD）。如果MAC未验证，DSKPP客户端必须终止DSKPP运行，在这种情况下，还必须删除与协议失败运行相关的任何nonce、密钥和/或机密。
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>具有Status=“Success”且已验证MAC，则DSKPP客户端必须从提供的密钥包中提取K_PROV，并派生K_令牌。最后，DSKPP客户端使用K_令牌和相应的密钥使用属性初始化加密模块。执行此操作后，除非在稍后的<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
DSKPP被设计为可扩展的。下面的小节定义了DSKPP模式中包含的两个扩展。由于扩展的使用可能会损害互操作性，因此建议协议设计者仔细考虑扩展的使用。例如，如果特定实现依赖于
the presence of a proprietary extension, then it may not be able to interoperate with independent implementations that have no knowledge of this extension.
如果存在专有扩展，则它可能无法与不了解此扩展的独立实现进行互操作。
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.
可以使用ExtensionsType随任何DSKPP消息发送扩展。ExtensionsType类型是包含类型值对的扩展列表，这些类型值对定义了DSKPP客户端或服务器支持的可选功能。通过将扩展的Critical属性设置为“true”，可以将每个扩展标记为Critical。除非扩展被标记为关键扩展，否则接收方不需要能够对其进行解释；接收方始终可以自由忽略任何（非关键）扩展。
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.
ClientInfo扩展可以包含应用程序所需的任何特定于客户端的数据。此扩展名可能出现在<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服务器不需要保留ClientInfo类型数据。
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
应用程序/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时，响应者应：*包括一个设置为“无缓存，无需重新验证，专用”的缓存控制标头字段*包括设置为“无缓存”的Pragma标头字段*不包括验证器，例如上次修改的或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标头字段。应使用第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).
对于四通道DSKPP，协议运行中的消息被绑定在一起。特别是，<KeyProvServerHello>通过在相应的HTTP响应中传输而绑定到前面的<KeyProvClientHello><KeyProvServerHello>必须具有SessionID属性，并且后续<KeyProvClientNonce>消息的SessionID属性必须相同<然后，KeyProvServerFinished>再次通过HTTP（可能还通过SessionID）绑定到rest。
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请求程序执行消息交换的DSKPP HTTP响应程序应返回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 POST时，DSKPP HTTP响应程序必须使用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
如果用户在浏览会话中请求密钥初始化，并且如果该请求具有适当的Accept标头（例如，到特定的DSKPP服务器URL），DSKPP服务器可以通过发送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.
HTTP响应中的初始化消息，内容类型根据第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正常
Cache-Control: no-store
Content-Type: application/dskpp+xml
Content-Length: <some value>
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. Initial request from DSKPP Client:
POST 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>
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正常
Cache-Control: no-cache, no-must-revalidate, private
Pragma: no-cache
Content-Type: application/dskpp+xml
Content-Length: <some value>
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数据（服务器随机nonce、服务器公钥等）
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字符编码[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>
<?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: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="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="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: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: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: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: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: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: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: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="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="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="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: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: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="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="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="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="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="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="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="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="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: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: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: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 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 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="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="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: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>
<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节）
b. MUST implement the two-pass variation of the protocol (Section 5)
b. 必须实施协议的两个过程变化（第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. 必须支持以下关键派生功能：*DSKPP-PRF-AES DSKPP-PRF实现（附录D）*DSKPP-PRF-SHA256 DSKPP-PRF实现（附录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. 必须支持以下加密机制，以保护四通道协议中的客户端nonce:*第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]
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. 必须支持以下非对称密钥操作的加密算法，例如密钥传输：*RSA加密方案[PKCS-1]
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]；必须实现所有三种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客户端必须支持协议的两个过程或四个过程变体。DSKPP客户必须满足第（c）-（j）项中列出的所有要求。
Finally, implementations of DSKPP MUST bind DSKPP messages to HTTP/1.1 as described in Section 7.2.
最后，DSKPP的实现必须将DSKPP消息绑定到HTTP/1.1，如第7.2节所述。
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是一种安全协议，其主要功能之一是仅允许授权方使用新的对称密钥成功初始化加密模块。因此，一个特定的实现可能被配置为与算法和可信权限有关的许多限制中的任何一个，这些限制将阻止通用互操作性。
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客户端上，按照加密模块中的规定生成R_C和K_令牌，则除DSKPP服务器和加密模块之外的任何实体都无权访问生成的K_令牌。即使DSKPP客户端中存在恶意软件，这也适用。但是，如以下小节所述，DSKPP无法抵御中间人攻击和其他形式的攻击造成的某些其他威胁。因此，DSKPP必须在提供机密性和完整性的传输上运行，如HTTP over transport Layer Security（TLS）和合适的密码套件[RFC2818]，当此类威胁受到关注时。请注意，具有匿名密钥交换的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
攻击者还可以修改<KeyProvServerHello>消息。这意味着攻击者可以指示与合法服务器不同的密钥类型、算法或协议版本，例如加密较弱的密钥类型、算法或协议版本。攻击者还可以提供
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.
与合法服务器发送的nonce不同。客户可以通过严格遵守有关允许的算法和协议版本的政策来防范前者。后者（错误的nonce）不会构成安全问题，因为生成的密钥与合法服务器上生成的密钥不匹配。此外，只要DSKPP运行将导致替换现有密钥，<Mac>元素将防止R_的修改。
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当时在服务器上有效。它仍然不允许攻击者学习生成的K_令牌，因为R_C已为合法服务器包装。修改<EncryptedNonce>元素（例如，将其替换为攻击者知道基础R'C的值）不会导致客户端更改其前DSKPP状态，因为服务器将无法在其最终消息中向客户端提供有效的MAC。然而，服务器可能最终存储K'TOKEN而不是K_令牌。如果加密模块已与特定用户关联，则这可能构成安全问题。有关此威胁和可能对策的进一步讨论，请参见下文第10.5节。请注意，如果攻击者可以访问DSKPP客户端（例如，通过恶意软件“特洛伊木马”）[RFC5246]，则使用TLS无法防止此攻击。
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）之前，不得更改其状态（即，“提交”到生成的密钥）。如果服务器执行第10.5节中的建议，则删除的<KeyProvServerFinished>消息不会导致服务器与加密模块处于不一致的状态。
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运行，并建议任何设备标识符。通过使用<KeyProvTrigger>初始化运行的DSKPP，DSKPP服务器实现可能会收到一些保护，以防止无意中初始化密钥或无意中替换现有密钥或将密钥分配给加密模块。<AuthenticationData>元素允许服务器将DSKPP运行与以前的用户验证会话相关联。因此，此方法的安全性取决于保护DSKPP初始化消息中<AuthenticationData>元素的能力。如果窃听者能够捕获此消息，他可能会与合法用户竞争密钥初始化。当这是一个问题时，建议使用提供机密性和完整性的传输上的DSKPP以及第10.5节中的建议。
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.
在四次通过DSKPP期间，将检测到重播先前记录的DSKPP消息的尝试，因为使用nonce可确保双方都处于活动状态。例如，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，因此双通道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.
攻击者可能会尝试对四次通过的DSKPP消息重新排序，但这会被检测到，因为每条消息的类型都是唯一的。注意：消息重排序攻击不能发生在双通道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服务器信任并与之通信的服务器）上的特定用户相关联，则为了防止攻击者用自己的R'C替换客户端提供的加密R_C的威胁（无论是使用DSKPP的公钥变体还是共享秘密变体来加密客户端nonce），服务器不应承诺将生成的K_令牌与给定的加密模块相关联，直到用户同时证明拥有托管包含K_令牌的加密模块的设备和一些带外提供的身份验证信息（例如，身份验证代码）。例如，如果加密模块是一次性密码令牌，则可能需要用户使用加密模块生成的一次性密码和带外提供的身份验证代码进行身份验证，以便服务器“提交”为给定用户生成的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，不适用于双通道DSKPP，因为客户端不向K_令牌提供任何熵。然而，这种攻击（及其对策）仍然适用于双通道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.
在四遍DSKPP中，客户端和服务器都向K_令牌提供随机化材料，其方式允许双方验证它们是否对生成的密钥做出了贡献。在本文定义的双通道DSKPP版本中，只有服务器贡献了K_令牌的熵。这意味着服务器中损坏或受损的（伪）随机数生成器可能会造成比四次传递变体更大的损坏。因此，服务器实现应该非常小心，以确保不会发生这种情况。
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.
四通道DSKPP服务器通过<KeyProvServerFinished>消息中的R_C上的MAC提供密钥确认。在本文描述的两次通过DSKPP变体中，由包括R的MAC使用K_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双通道协议会导致现有K_令牌被K_令牌替换，或者可能发生拒绝服务攻击，即未经授权的DSKPP服务器用另一个密钥替换K_令牌，则DSKPP服务器必须对自己进行身份验证。在双通道DSKPP中，服务器通过包括包含MAC的AuthenticationDataType扩展进行身份验证，如第5节中双通道DSKPP所述。
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双通道协议会导致现有K_令牌被K_令牌替换时，DSKPP客户端和服务器必须执行以下操作，以防止拒绝服务攻击，即未经授权的DSKPP服务器将K_令牌替换为另一密钥：
o The DSKPP Server MUST use the AuthenticationDataType extension to transmit a second MAC, calculated as described in Section 5.2.2.
o DSKPP服务器必须使用AuthenticationDataType扩展来传输第二个MAC，如第5.2.2节所述进行计算。
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_令牌被传递到预期的设备。应考虑采取以下措施：
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值必须足够强，以防止从哈希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.
针对双通道DSKPP的不同用途定义了三种密钥保护方法，必须由密钥包格式支持，如[RFC6030]和[RFC6031]。因此，双通道DSKPP中的密钥保护取决于为协议运行选择的密钥包格式的安全性。下面是基于密码短语的密钥包装方法的一些注意事项。
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
基于密码短语的密钥包装方法应依赖于[PKCS-5]中的PBKDF2函数从密码短语和salt字符串生成加密密钥。需要注意的是，尽管在PBKDF2中使用了salt和迭代计数来增加攻击的复杂性，但基于密码短语的加密通常在其提供的安全性方面受到限制。因此，实现应该
take additional measures to strengthen the security of the Passphrase-Based Key Wrap method. The following measures SHOULD be considered where applicable:
采取其他措施加强基于密码短语的密钥封装方法的安全性。在适用的情况下，应考虑以下措施：
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 密码短语与身份验证代码的一次性密码组件相同（有关AC格式的说明，请参见第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 在可能的情况下，每个密钥初始化都应使用不同的密码短语（例如，应避免对一批加密模块使用全局密码短语）。实现这一点的一种方法是使用随机生成的密码短语。
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_令牌不会传递给恶意收件人。
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_令牌所需的工作就越多。当实施其他安全措施并且基于密码短语的密钥封装方法的安全性未被削弱时，服务器可以使用相对较低的迭代次数来容纳处理能力有限的设备，例如一些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]来保护双通道协议的运行。传输级安全性为新生成的K_令牌提供第二层保护。
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.
许多协议需要算法敏捷。原因之一是，在过去，许多协议都有固定大小的信息字段，如散列输出、密钥等。DSKPP的情况并非如此，DSKPP-PRF计算中的密钥大小除外。另一个原因是协议不支持算法协商。DSKPP也不是这样，除了在MAC确认消息中使用SHA-256。更新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:params: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)
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
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:dskpp注册人联系人：ietf，keyprov工作组(keyprov@ietf.org)，安德里亚·多尔蒂（安德里亚。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必需参数：（无）可选参数：字符集表示封闭xml的字符编码。编码注意事项：使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见[RFC3023]，第3.2节。实现需要支持UTF-8[RFC3629]。安全注意事项：此内容类型旨在承载与密钥管理相关的协议数据。协议中内置了安全机制，以确保应对各种威胁。有关互操作性注意事项的更多详细信息，请参阅RFC 6063第10节：未发布规范：RFC 6063。使用此媒体类型的应用程序：密钥交换协议。其他信息：魔法号码：（无）文件扩展名：.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)，安德里亚·多尔蒂（安德里亚。doherty@rsa.com)
This section registers DSKPP version numbers. The registry has the
following structure:
+-------------------------------------------+
| DSKPP Version | Specification |
+-------------------------------------------+
| 1.0 | This document |
+-------------------------------------------+
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
该规范依赖于称为“DSKPP-PRF”的加密原语，该原语将密钥k和可变长度八位组字符串s确定地转换为指定长度dsLen的位字符串。从本规范的角度来看，DSKPP-PRF是一个“黑箱”函数，给定输入，该函数生成可由任何
appropriate and competent cryptographic technique. Section 3.4.2 provides two realizations of DSKPP-PRF, DSKPP-PRF-AES, and DSKPP-PRF-SHA256.
适当和胜任的密码技术。第3.4.2节提供了DSKPP-PRF、DSKPP-PRF-AES和DSKPP-PRF-SHA256的两种实现。
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命名空间注册表中注册以下内容。
Common Name: DSKPP-PRF-AES
通用名称：DSKPP-PRF-AES
URI:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
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.
标识符定义：本文件附录D.2.2中定义了DSKPP-PRF-AES算法实现。
Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)
注册人联系人：IETF、KEYPROV工作组(keyprov@ietf.org)，安德里亚·多尔蒂（安德里亚。doherty@rsa.com)
This section registers the following in the IETF XML namespace registry.
本节在IETF XML命名空间注册表中注册以下内容。
Common Name: DSKPP-PRF-SHA256
通用名称：DSKPP-PRF-SHA256
URI:
urn:ietf:params:xml:ns:keyprov: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.
标识符定义：本文件附录D.3.2中定义了DSKPP-PRF-SHA256算法实现。
Registrant Contact: IETF, KEYPROV working group (keyprov@ietf.org), Andrea Doherty (andrea.doherty@rsa.com)
注册人联系人：IETF、KEYPROV工作组(keyprov@ietf.org)，安德里亚·多尔蒂（安德里亚。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节中提供的三种密钥保护方法保护密钥。
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.
已弃用：如果基于专家批准，则为TRUE。此条目已弃用，不应在任何新实施中使用。否则，错误。
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: 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: 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: 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
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)，安德里亚·多尔蒂（安德里亚。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 Security是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).
这项工作基于[RFC4758]中包含的信息，由Magnus Nystrom编写，并从Pei Mingliang和Salah Machani合著的单个文档中借用了增强功能（例如，用户身份验证和对多个密钥包格式的支持）。
We would like to thank Philip Hoyer for his work in aligning DSKPP and PSKC schemas.
我们要感谢Philip Hoyer在调整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)
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 John Linn（2007年8月回顾）o Philip Hoyer（2007年9月回顾）o Thomas Roessler（2007年11月回顾）o Lakshminath Dondeti（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月审查）
We would also like to thank the following for their input to selected design aspects of DSKPP:
我们还要感谢以下人员对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绑定）o Hannes Tschofenig（HTTP绑定）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.
最后，我们要感谢Robert Griffin为我们打开与IEEE P1619.3密钥管理小组的沟通渠道，并帮助我们的小组了解协作的潜在领域（特别是密钥供应和全局密钥标识符）。
[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]国家标准与技术研究所，“安全哈希标准”，FIPS180-22004年2月<http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2 WithChangeNotice.pdf>。
[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，第3版，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实验室，“RSA加密标准”，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实验室，“基于密码的加密标准”，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实验室，“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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——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，“高级加密标准（AES）密钥包裹算法”，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配置文件”，RFC40113，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，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年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 52802008年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，“带填充算法的高级加密标准（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 603012010年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.和M.Duerst，“UNICODE规范化形式”，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（第五版）”，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签名语法和处理”，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实验室，“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，“关于当今加密技术的常见问题”，2000年4.1版。
[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/ 出版物/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]国家标准与技术研究所，“关键管理建议——第一部分：总则（修订）”，NIST 800-57，2007年3月，<http://csrc.NIST.gov/publications/nistpubs/800-57/SP800-57-Part1-revised2_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”，RFC2818，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媒体类型”，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，“统一资源标识符（URI）：通用语法”，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，“传输层安全（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 60312010年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.
通常情况下，加密模块从位于本地网络或Internet某处的配置服务器请求对称密钥。根据部署场景，供应服务器可以动态生成新密钥或使用预生成的密钥，例如，由遗留后端发布服务器提供的密钥。设置服务器为对称密钥分配唯一密钥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.
加密模块从同一配置服务器发出多个对称密钥请求。对称密钥不需要具有相同的类型，即，密钥可以与不同的对称密钥加密算法一起使用，包括一次性密码认证算法和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.
此场景表示对称密钥更新的一种特殊情况，在这种情况下，本地管理员可以在启动配置过程之前按程序对用户进行身份验证。它还允许设备颁发者将密钥预加载到加密模块上，并限制在使用加密模块之前用新密钥替换密钥。此场景的另一个变体是回收设备的组织。在这种情况下，密钥颁发者将向托管在先前由另一用户拥有的设备上的加密模块提供新的对称密钥。
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.
请注意，此使用场景的两个先决条件是要对协议进行隧道传输，并且供应服务器要知道正确的预先建立的制造商密钥。
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可以终止于PC上承载的应用程序，而不是位于数据存储设备上的加密模块（即端点）[RFC5246]。相互认证的密钥协议提供端到端保护，而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.
本附录包含示例消息，说明了四通道和两通道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: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: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: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: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>
<?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，该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: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>
<?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>
<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>
<?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>
<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>
<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
<?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>
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>
</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_令牌，服务器使用密钥包装密钥保护方法进行响应。本例中的身份验证数据基于身份验证代码而不是设备证书。
<?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>
<?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>
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"
<?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"
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>
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的请求，请求中包含基于身份验证码的身份验证数据，服务器使用基于密码短语的密钥包装方法对配置密钥进行加密（请注意，加密源于身份验证码的密码组件）。当认证数据通过安全传输通道（如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>
<?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>
<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.
在本例中，服务器通过返回一个密钥包来响应前面的请求，在该密钥包中，使用基于密码短语的密钥包装密钥保护方法对配置密钥进行了加密。
<?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>
<?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>
<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>
</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编程接口对加密模块执行四通DSKPP时，建议采用附录B中[CT-KIP-P11]所述的程序。
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接口使用加密模块执行双通道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. 客户端选择合适的插槽和令牌（例如，通过使用DSKPP触发消息的<DeviceIdentifier>或<PlatformInfo>元素）。
2. A nonce R is generated, e.g., by calling C_SeedRandom and C_GenerateRandom.
2. 例如，通过调用C_SeedRandom和C_generateradom来生成nonce 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|u PROV=K|u令牌| K|u MAC（其中“|”表示串联），例如，通过调用C_GenerateKey（使用密钥类型CKK|u generic_SECRET）。K_PROV的模板必须允许将其导出（但只能以包装形式导出，即CKA_SENSITIVE必须设置为CK_TRUE，CKA_EXTRACTABLE也必须设置为CK_TRUE），并用于进一步的密钥派生。从K中，通过使用PKCS#11机制CKM#u EXTRACT_key_From_key调用C#u DeriveKey并将CK#u EXTRACT_参数设置为通用密钥的第一位（即设置为0），派生出适当类型的令牌密钥K_令牌。同样，通过使用CKM_EXTRACT_key_from_key机制调用C_DeriveKey，从K_PROV派生MAC密钥K_MAC，这一次将CK_EXTRACT_参数设置为K_PROV的长度（以位为单位）除以2。
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. 服务器使用DSKPP客户端或设备的公钥、预共享密钥或使用C_WrapKey导出的共享密钥包装K_PROV。如果已协商使用DSKPP密钥包装算法，则必须使用CKM_KIP_包装机制包装K。调用C_WrapKey时，必须将CK_KIP_PARAMS结构中的hKey句柄设置为NULL_PTR。CK_KIP_PARAMS结构中的pSeed参数必须指向DSKPP客户端提供的nonce R，而ulSeedLen参数必须指示R的长度。对C_WrapKey的调用中的hwrapingkey参数必须设置为引用密钥包装密钥。
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算法，则通过使用CKM_KIP_MAC机制调用C_signit，然后调用C_Sign来计算MAC。在调用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_令牌被替换），则服务器必须计算第二个MAC。同样，如果已协商使用DSKPP MAC算法，则通过使用CKM_KIP_MAC机制调用C_signit，然后调用C_Sign来计算MAC。在对C_SignInit的调用中，此DSKPP运行之前存在的K_MAC'必须是签名密钥（实现可能指定K_MAC'为正在被替换的K_令牌的值，或先前协议运行的K_MAC的版本），CK_KIP_PARAMS结构中的hKey参数必须设置为NULL，CT_KIP_PARAMS结构的pSeed参数必须设置为NULL_PTR，ulSeedLen参数必须设置为零。在对C_Sign的调用中，必须将pData参数设置为字符串ServerID和nonce R的串联，并且必须将ulDataLen参数设置为串联字符串的长度。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_令牌、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两次：一次用于派生K_令牌，一次用于派生K_MAC。客户端必须使用与上述服务器相同的机制（CKM_EXTRACT_KEY_FROM_KEY）和相同的机制参数。调用C_UnwrapKey和C_DeriveKey时，必须使用pTemplate参数根据本地策略以及协议中协商和表达的方式设置其他密钥属性。特别地，服务器的响应消息中的<KeyID>元素的值可以用作K_令牌的CKA_ID。密钥K_PROV必须在派生K_令牌和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的hKey参数必须引用K_MAC。在调用C_Verify时，必须将pData设置为字符串ServerID和nonce R的串联，并且必须将ulDataLen参数设置为串联字符串的长度，将pSignature设置为从服务器接收的MAC值，将ulSignatureLen设置为MAC的长度。如果MAC未验证协议会话以失败结束。令牌必须构造为不“提交”到新K_令牌或新K_MAC，除非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_令牌将替换令牌上的现有密钥，则需要此MAC），则会以类似方式对其进行验证，但使用与此服务器关联且在协议运行之前存在的K_MAC进行验证（实现可能指定K_MAC'为正在被替换的K_令牌的值，或先前协议运行的K_MAC版本）。同样，如果MAC未验证协议会话以失败结束，则必须构造令牌，以不“提交”到新K_令牌或新K_MAC，除非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实现的加密模块，必须使用以下URN在DSKPP中标识此算法：
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
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的长度为sLen。dsLen输出的所需长度
Output:
输出：
DS A pseudorandom string, dsLen-octets long
DS是一个伪随机字符串，dsLen八位字节长
Steps:
步骤：
1. Let bLen be the output block size of AES in octets:
1. 设bLen为AES的输出块大小（以八位字节为单位）：
bLen = (AES output block length in octets)
(normally, bLen = 16)
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）*bLen，则输出“派生数据太长”并停止
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八位字节块数，向上取整，设j为最后一个块中的八位字节数：
n = CEILING( dsLen / bLen)
j = dsLen - (n - 1) * bLen
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的四个八位组编码，最重要的八位组在前，CMAC的输出长度设置为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>
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
n = 16 / 16 = 1
j = 16 - (1 - 1) * 16 = 16
j = 16 - (1 - 1) * 16 = 16
DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s)
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实现的加密模块，必须使用以下URN在DSKPP中标识此算法：
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
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的长度为sLen。dsLen输出的所需长度
Output:
输出：
DS A pseudorandom string, dsLen-octets long
DS是一个伪随机字符串，dsLen八位字节长
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为SHA-256的输出大小，单位为[FIPS180-SHA]的八位字节（HMAC输出上未进行截断）：
bLen = 32 (normally, bLen = 16)
bLen=32（正常情况下，bLen=16）
2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and stop
2. 如果dsLen>（2**32-1）*bLen，则输出“派生数据太长”并停止
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八位字节块数，向上取整，设j为最后一个块中的八位字节数：
n = CEILING( dsLen / bLen)
j = dsLen - (n - 1) * bLen
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 HMAC construction from [RFC2104], using SHA-256 as the digest algorithm:
函数F根据[RFC2104]中的HMAC构造定义，使用SHA-256作为摘要算法：
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的四个八位组编码，最重要的八位组在前，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>
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（两个128八位字节长的值）和dsLen=16，那么：
n = CEILING( 16 / 32 ) = 1
n = CEILING( 16 / 32 ) = 1
j = 16 - (1 - 1) * 32 = 16
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>
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的安全部门，美国马萨诸塞州01730
EMail: andrea.doherty@rsa.com
EMail: andrea.doherty@rsa.com
Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
美国加利福尼亚州米德尔菲尔德路东487号，加利福尼亚州山景城，贝聿铭公司，邮编94043
EMail: mpei@verisign.com
EMail: mpei@verisign.com
Salah Machani Diversinet Corp. 2225 Sheppard Avenue East, Suite 1801 Toronto, Ontario M2J 5C2 Canada
Salah Machani Diversinet Corp.加拿大安大略省多伦多Sheppard大道东2225号1801室M2J 5C2
EMail: smachani@diversinet.com
EMail: smachani@diversinet.com
Magnus Nystrom Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA
美国华盛顿州雷德蒙市微软大道一号Magnus Nystrom微软公司，邮编：98052
EMail: mnystrom@microsoft.com
EMail: mnystrom@microsoft.com