Internet Engineering Task Force (IETF) P. Hoyer
Request for Comments: 6030 ActivIdentity
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign
S. Machani
Diversinet
October 2010
Internet Engineering Task Force (IETF) P. Hoyer
Request for Comments: 6030 ActivIdentity
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign
S. Machani
Diversinet
October 2010
Portable Symmetric Key Container (PSKC)
便携式对称密钥容器（PSKC）
Abstract
摘要
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure.
本文档规定了对称密钥格式，用于向不同类型的加密模块传输和提供对称密钥。例如，一次性密码（OTP）为强身份验证设备共享机密或对称加密密钥。标准密钥传输格式使企业能够部署同类最佳的解决方案，将不同供应商的组件组合到同一基础架构中。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6030.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6030.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Key Words ..................................................4
1.2. Version Support ............................................4
1.3. Namespace Identifiers ......................................5
1.3.1. Defined Identifiers .................................5
1.3.2. Referenced Identifiers ..............................5
2. Terminology .....................................................6
3. Portable Key Container Entities Overview and Relationships ......6
4. <KeyContainer> Element: The Basics ..............................8
4.1. <Key>: Embedding Keying Material and Key-Related
Information ................................................8
4.2. Key Value Encoding ........................................10
4.2.1. AES Key Value Encoding .............................11
4.2.2. Triple-DES Key Value Encoding ......................11
4.3. Transmission of Supplementary Information .................12
4.3.1. <DeviceInfo> Element: Unique Device
Identification .....................................13
4.3.2. <CryptoModuleInfo> Element: CryptoModule
Identification .....................................15
4.3.3. <UserId> Element: User Identification ..............15
4.3.4. <AlgorithmParameters> Element:
Supplementary Information for OTP and CR Algorithms 15
4.4. Transmission of Key Derivation Values .....................17
5. Key Policy .....................................................19
5.1. PIN Algorithm Definition ..................................23
6. Key Protection Methods .........................................23
6.1. Encryption Based on Pre-Shared Keys .......................24
6.1.1. MAC Method .........................................26
6.2. Encryption Based on Passphrase-Based Keys .................27
6.3. Encryption Based on Asymmetric Keys .......................29
1. Introduction ....................................................4
1.1. Key Words ..................................................4
1.2. Version Support ............................................4
1.3. Namespace Identifiers ......................................5
1.3.1. Defined Identifiers .................................5
1.3.2. Referenced Identifiers ..............................5
2. Terminology .....................................................6
3. Portable Key Container Entities Overview and Relationships ......6
4. <KeyContainer> Element: The Basics ..............................8
4.1. <Key>: Embedding Keying Material and Key-Related
Information ................................................8
4.2. Key Value Encoding ........................................10
4.2.1. AES Key Value Encoding .............................11
4.2.2. Triple-DES Key Value Encoding ......................11
4.3. Transmission of Supplementary Information .................12
4.3.1. <DeviceInfo> Element: Unique Device
Identification .....................................13
4.3.2. <CryptoModuleInfo> Element: CryptoModule
Identification .....................................15
4.3.3. <UserId> Element: User Identification ..............15
4.3.4. <AlgorithmParameters> Element:
Supplementary Information for OTP and CR Algorithms 15
4.4. Transmission of Key Derivation Values .....................17
5. Key Policy .....................................................19
5.1. PIN Algorithm Definition ..................................23
6. Key Protection Methods .........................................23
6.1. Encryption Based on Pre-Shared Keys .......................24
6.1.1. MAC Method .........................................26
6.2. Encryption Based on Passphrase-Based Keys .................27
6.3. Encryption Based on Asymmetric Keys .......................29
6.4. Padding of Encrypted Values for Non-Padded
Encryption Algorithms .....................................31
7. Digital Signature ..............................................31
8. Bulk Provisioning ..............................................33
9. Extensibility ..................................................35
10. PSKC Algorithm Profile ........................................36
10.1. HOTP .....................................................36
10.2. PIN ......................................................37
11. XML Schema ....................................................38
12. IANA Considerations ...........................................44
12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.2. XML Schema Registration ..................................45
12.3. URN Sub-Namespace Registration ...........................46
12.4. PSKC Algorithm Profile Registry ..........................46
12.5. PSKC Version Registry ....................................47
12.6. Key Usage Registry .......................................47
13. Security Considerations .......................................48
13.1. PSKC Confidentiality .....................................49
13.2. PSKC Integrity ...........................................50
13.3. PSKC Authenticity ........................................50
14. Contributors ..................................................50
15. Acknowledgements ..............................................50
16. References ....................................................51
16.1. Normative References .....................................51
16.2. Informative References ...................................52
Appendix A. Use Cases ............................................54
A.1. Online Use Cases ..........................................54
A.1.1. Transport of Keys from Server to Cryptographic
Module ................................................54
A.1.2. Transport of Keys from Cryptographic Module to
Cryptographic Module ..................................54
A.1.3. Transport of Keys from Cryptographic Module to
Server ................................................55
A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.2. Offline Use Cases .........................................55
A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
Appendix B. Requirements .........................................56
6.4. Padding of Encrypted Values for Non-Padded
Encryption Algorithms .....................................31
7. Digital Signature ..............................................31
8. Bulk Provisioning ..............................................33
9. Extensibility ..................................................35
10. PSKC Algorithm Profile ........................................36
10.1. HOTP .....................................................36
10.2. PIN ......................................................37
11. XML Schema ....................................................38
12. IANA Considerations ...........................................44
12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.2. XML Schema Registration ..................................45
12.3. URN Sub-Namespace Registration ...........................46
12.4. PSKC Algorithm Profile Registry ..........................46
12.5. PSKC Version Registry ....................................47
12.6. Key Usage Registry .......................................47
13. Security Considerations .......................................48
13.1. PSKC Confidentiality .....................................49
13.2. PSKC Integrity ...........................................50
13.3. PSKC Authenticity ........................................50
14. Contributors ..................................................50
15. Acknowledgements ..............................................50
16. References ....................................................51
16.1. Normative References .....................................51
16.2. Informative References ...................................52
Appendix A. Use Cases ............................................54
A.1. Online Use Cases ..........................................54
A.1.1. Transport of Keys from Server to Cryptographic
Module ................................................54
A.1.2. Transport of Keys from Cryptographic Module to
Cryptographic Module ..................................54
A.1.3. Transport of Keys from Cryptographic Module to
Server ................................................55
A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.2. Offline Use Cases .........................................55
A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
Appendix B. Requirements .........................................56
With the increasing use of symmetric-key-based systems, such as encryption of data at rest or systems used for strong authentication, such as those based on One-Time Password (OTP) and Challenge/Response (CR) mechanisms, there is a need for vendor interoperability and a standard format for importing and exporting (provisioning) symmetric keys. For instance, traditionally, vendors of authentication servers and service providers have used proprietary formats for importing and exporting these keys into their systems, thus making it hard to use tokens from two different vendors.
随着基于对称密钥的系统（如静止数据加密）或用于强身份验证的系统（如基于一次性密码（OTP）和质询/响应（CR）机制的系统）的使用日益增多，需要供应商互操作性以及导入和导出（提供）对称密钥的标准格式。例如，传统上，认证服务器和服务提供商的供应商使用专有格式将这些密钥导入和导出到他们的系统中，因此很难使用来自两个不同供应商的令牌。
This document defines a standardized XML-based key container, called Portable Symmetric Key Container (PSKC), for transporting symmetric keys and key-related metadata. The document also specifies the information elements that are required when the symmetric key is utilized for specific purposes, such as the initial counter in the HMAC-Based One-Time Password (HOTP) [HOTP] algorithm. It also creates an IANA registry for algorithm profiles where algorithms, their metadata and PSKC transmission profile can be recorded for a centralized, standardized reference.
本文档定义了一个标准化的基于XML的密钥容器，称为便携式对称密钥容器（PSKC），用于传输对称密钥和密钥相关元数据。本文件还规定了对称密钥用于特定目的时所需的信息元素，例如基于HMAC的一次性密码（HOTP）[HOTP]算法中的初始计数器。它还为算法配置文件创建IANA注册表，在该注册表中可以记录算法、其元数据和PSKC传输配置文件，以供集中、标准化参考。
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 numbering scheme for PSKC versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "PSKC 2.4" would be a lower version than "PSKC 2.13", which in turn would be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be ignored by recipients and MUST NOT be sent.
PSKC版本的编号方案为“<major><minor>”。主数字和次数字必须被视为独立的整数，每个数字的增量可以大于一个位数。因此，“PSKC 2.4”的版本低于“PSKC 2.13”，而“PSKC 2.13”的版本又低于“PSKC 12.3”。收件人必须忽略前导零（例如，“PSKC 6.01”），并且不得发送。
The major version number should be incremented only if the message format (e.g., element structure) has changed so dramatically that an older version implementation would not be able to interoperate with a newer version. The minor version number indicates new capabilities, and it MUST be ignored by an entity with a smaller minor version number but used for informational purposes by the entity with the larger minor version number.
只有当消息格式（例如，元素结构）发生了巨大变化，旧版本实现无法与新版本交互时，主版本号才应增加。次要版本号表示新功能，次要版本号较小的实体必须忽略它，但次要版本号较大的实体将其用于信息目的。
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to identify resources, algorithms, and semantics.
本文档使用统一资源标识符（URI）[RFC3986]来标识资源、算法和语义。
The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
PSKC版本1.0的XML命名空间[XMLNS]URI为：
"urn:ietf:params:xml:ns:keyprov:pskc"
"urn:ietf:params:xml:ns:keyprov:pskc"
References to qualified elements in the PSKC schema defined in this specification and used in the example use the prefix "pskc" (defined as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"). It is RECOMMENDED to use this namespace in implementations.
本规范中定义并在示例中使用的PSKC模式中对限定元素的引用使用前缀“PSKC”（定义为xmlns:PSKC=“urn:ietf:params:xml:ns:keyprov:PSKC”）。建议在实现中使用此命名空间。
The PSKC syntax presented in this document relies on algorithm identifiers and elements defined in the XML Signature [XMLDSIG] namespace:
本文档中介绍的PSKC语法依赖于XML签名[XMLDSIG]命名空间中定义的算法标识符和元素：
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to the XML Signature namespace are represented by the prefix "ds".
对XML签名命名空间的引用由前缀“ds”表示。
PSKC also relies on algorithm identifiers and elements defined in the XML Encryption [XMLENC] namespace:
PSKC还依赖于XML加密[XMLENC]命名空间中定义的算法标识符和元素：
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the prefix "xenc".
对XML加密命名空间的引用由前缀“xenc”表示。
When protecting keys in transport with passphrase-based keys, PSKC also relies on the derived key element defined in the XML Encryption Version 1.1 [XMLENC11] namespace:
当使用基于密码短语的密钥保护传输中的密钥时，PSKC还依赖于XML加密版本1.1[XMLENC11]命名空间中定义的派生密钥元素：
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
References to the XML Encryption Version 1.1 namespace are represented by the prefix "xenc11".
对XML加密版本1.1命名空间的引用由前缀“xenc11”表示。
When protecting keys in transport with passphrase-based keys, PSKC also relies on algorithm identifiers and elements defined in the PKCS #5 [PKCS5] namespace:
当使用基于密码短语的密钥保护传输中的密钥时，PSKC还依赖于PKCS#5[PKCS5]命名空间中定义的算法标识符和元素：
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
References to the PKCS #5 namespace are represented by the prefix "pkcs5".
对PKCS#5名称空间的引用由前缀“pkcs5”表示。
NOTE: In subsequent sections of the document, we highlight **mandatory** XML elements and attributes. Optional elements and attributes are not explicitly indicated, i.e., if it does not say mandatory, it is optional.
注意：在文档的后续部分中，我们将突出显示**强制**XML元素和属性。可选元素和属性没有明确指出，也就是说，如果它没有说是强制性的，那么它是可选的。
The portable key container is based on an XML schema definition and contains the following main conceptual entities:
可移植密钥容器基于XML模式定义，包含以下主要概念实体：
1. KeyContainer entity - representing the container that carries a number of KeyPackage entities. A valid container MUST carry at least one KeyPackage entity.
1. KeyContainer实体-表示承载多个KeyPackage实体的容器。有效容器必须至少包含一个KeyPackage实体。
2. KeyPackage entity - representing the package of at most one key and its related provisioning endpoint or current usage endpoint, such as a physical or virtual device and a specific CryptoModule.
2. KeyPackage实体—表示最多一个密钥的包及其相关的配置端点或当前使用端点，例如物理或虚拟设备以及特定的加密模块。
3. DeviceInfo entity - representing the information about the device and criteria to identify uniquely the device.
3. DeviceInfo实体—表示有关设备的信息和唯一标识设备的条件。
4. CryptoModuleInfo entity - representing the information about the CryptoModule where the keys reside or to which they are provisioned.
4. CryptoModuleInfo实体-表示密钥所在或配置到的CryptoModule的相关信息。
5. Key entity - representing the key transported or provisioned.
5. 密钥实体-表示传输或配置的密钥。
6. Data entity - representing a list of metadata related to the key, where the element name is the name of the metadata and its associated value is either in encrypted (for example, for <Data> element <Secret>) or plaintext (for example, the <Data> element <Counter>) form.
6. 数据实体-表示与密钥相关的元数据列表，其中元素名称是元数据的名称，其关联值为加密格式（例如，对于<Data>元素<Secret>）或纯文本格式（例如，<Data>元素<Counter>）。
Figure 1 shows the high-level structure of the PSKC data elements.
图1显示了PSKC数据元素的高级结构。
-----------------
| KeyContainer |
|---------------|
| EncryptionKey |
| Signature |
| ... |
-----------------
|
|
/|\ 1..n
---------------- ----------------
| KeyPackage | 0..1| DeviceInfo |
|--------------|--------|--------------|
| |-- | SerialNumber |
---------------- | | Manufacturer |
| | | .... |
| | ----------------
/|\ 0..1 |
---------------- | --------------------
| Key | | 0..1| CryptoModuleInfo |
|--------------| -----|------------------|
| Id | | Id |
| Algorithm | |.... |
| UserId | --------------------
| Policy |
| .... |
----------------
|
|
/|\ 0..n
--------------------------------------- - -
| | |
------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue |
| ValueMAC | ----------------
------------------
-----------------
| KeyContainer |
|---------------|
| EncryptionKey |
| Signature |
| ... |
-----------------
|
|
/|\ 1..n
---------------- ----------------
| KeyPackage | 0..1| DeviceInfo |
|--------------|--------|--------------|
| |-- | SerialNumber |
---------------- | | Manufacturer |
| | | .... |
| | ----------------
/|\ 0..1 |
---------------- | --------------------
| Key | | 0..1| CryptoModuleInfo |
|--------------| -----|------------------|
| Id | | Id |
| Algorithm | |.... |
| UserId | --------------------
| Policy |
| .... |
----------------
|
|
/|\ 0..n
--------------------------------------- - -
| | |
------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue |
| ValueMAC | ----------------
------------------
Figure 1: PSKC Data Elements Relationship Diagram
图1:PSKC数据元素关系图
The following sections describe in detail all the entities and related XML schema elements and attributes.
以下各节详细描述了所有实体以及相关的XML模式元素和属性。
In its most basic form, a PSKC document uses the top-level element <KeyContainer> and a single <KeyPackage> element to carry key information.
在最基本的形式中，PSKC文档使用顶级元素<KeyContainer>和单个<KeyPackage>元素来携带关键信息。
The following example shows a simple PSKC document. We will use it to describe the structure of the <KeyContainer> element and its child elements.
下面的示例显示了一个简单的PSKC文档。我们将使用它来描述<KeyContainer>元素及其子元素的结构。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer-A</Issuer>
<Data>
<Secret>
<PlainValue>MTIzNA==
</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer-A</Issuer>
<Data>
<Secret>
<PlainValue>MTIzNA==
</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 2: Basic PSKC Key Container Example
图2：基本PSKC密钥容器示例
The attributes of the <KeyContainer> element have the following semantics:
<KeyContainer>元素的属性具有以下语义：
'Version': The 'Version' attribute is used to identify the version of the PSKC schema version. This specification defines the initial version ("1.0") of the PSKC schema. This attribute MUST be included.
“版本”：使用“版本”属性标识PSKC架构版本的版本。本规范定义了PSKC模式的初始版本（“1.0”）。必须包含此属性。
'Id': The 'Id' attribute carries a unique identifier for the container. As such, it helps to identify a specific key container in cases in which multiple containers are embedded in larger XML documents.
“Id”：Id属性包含容器的唯一标识符。因此，在大型XML文档中嵌入多个容器的情况下，它有助于识别特定的密钥容器。
The following attributes of the <Key> element MUST be included at a minimum:
必须至少包括<Key>元素的以下属性：
'Id': This attribute carries a unique identifier for the symmetric key in the context of key provisioning exchanges between two parties. This means that if PSKC is used in multiple interactions between a sending and receiving party, using different containers referencing the same keys, the 'Id' attribute of <Key> MUST use the same value (e.g., after initial provisioning, if a system wants to update key metadata values in the other system, the value of the 'Id' attribute of the <Key> where the metadata is to be updated MUST be the same of the original 'Id' attribute value provisioned). The identifier is defined as a string of alphanumeric characters.
“Id”：此属性在双方密钥设置交换的上下文中携带对称密钥的唯一标识符。这意味着，如果在发送方和接收方之间的多个交互中使用PSKC，使用引用相同密钥的不同容器，<Key>的“Id”属性必须使用相同的值（例如，在初始设置之后，如果系统想要更新另一个系统中的键元数据值，则要更新元数据的<key>的“Id”属性值必须与设置的原始“Id”属性值相同）。标识符定义为字母数字字符串。
'Algorithm': This attribute contains a unique identifier for the PSKC algorithm profile. This profile associates specific semantics to the elements and attributes contained in the <Key> element. This document describes profiles for open standards algorithms in Section 10. Additional profiles are defined in the following informative document: [PSKC-ALGORITHM-PROFILES].
“算法”：此属性包含PSKC算法配置文件的唯一标识符。此概要文件将特定语义与<Key>元素中包含的元素和属性相关联。本文档在第10节中描述了开放标准算法的概要。以下资料性文档中定义了其他配置文件：[PSKC-ALGORITHM-profiles]。
The <Key> element has a number of optional child elements. An initial set is described below:
<Key>元素有许多可选的子元素。初始设置如下所述：
<Issuer>: This element represents the name of the party that issued the key. For example, a bank "Foobar Bank, Inc." issuing hardware tokens to their retail banking users may set this element to 'Foobar Bank, Inc.'.
<Issuer>：此元素表示颁发密钥的一方的名称。例如，一家银行“Foobar bank，Inc.”向其零售银行用户发行硬件代币，可将此元素设置为“Foobar bank，Inc.”。
<FriendlyName>: A human-readable name for the secret key for easier reference. This element serves informational purposes only. This element is a language-dependent string; hence, it SHOULD have an attribute xml:lang="xx" where xx is the language identifier as specified in [RFC5646]. If no xml:lang attribute is present, implementations MUST assume the language to be English as defined by setting the attribute value to 'en' (e.g., xml:lang="en").
<FriendlyName>：密钥的可读名称，便于参考。此元素仅用于提供信息。此元素是语言相关的字符串；因此，它应该有一个属性xml:lang=“xx”，其中xx是[RFC5646]中指定的语言标识符。如果不存在xml:lang属性，则实现必须假定该语言为英语，如通过将属性值设置为“en”（例如，xml:lang=“en”）所定义的那样。
<AlgorithmParameters>: This element carries parameters that influence the result of the algorithmic computation, for example, response truncation and format in OTP and CR algorithms. A more detailed discussion of the element can be found in Section 4.3.4.
<AlgorithmParameters>：此元素包含影响算法计算结果的参数，例如，OTP和CR算法中的响应截断和格式。第4.3.4节对该元素进行了更详细的讨论。
<Data>: This element carries data about and related to the key. The following child elements are defined for the <Data> element:
<Data>：此元素包含与键相关的数据。为<Data>元素定义了以下子元素：
<Secret>: This element carries the value of the key itself in a binary representation. Please see Section 4.2 for more details on Key Value Encoding.
<Secret>：此元素以二进制表示形式携带密钥本身的值。有关键值编码的更多详细信息，请参见第4.2节。
<Counter>: This element contains the event counter for event-based OTP algorithms.
<Counter>：此元素包含用于基于事件的OTP算法的事件计数器。
<Time>: This element contains the time for time-based OTP algorithms. (If time intervals are used, this element carries the number of time intervals passed from a specific start point, normally it is algorithm dependent).
<Time>：此元素包含基于时间的OTP算法的时间。（如果使用时间间隔，此元素包含从特定起点经过的时间间隔数，通常取决于算法）。
<TimeInterval>: This element carries the time interval value for time-based OTP algorithms in seconds (a typical value for this would be 30, indicating a time interval of 30 seconds).
<TimeInterval>：此元素以秒为单位携带基于时间的OTP算法的时间间隔值（典型值为30，表示时间间隔为30秒）。
<TimeDrift>: This element contains the device clock drift value for time-based OTP algorithms. The integer value (positive or negative drift) that indicates the number of time intervals that a validation server has established the device clock drifted after the last successful authentication. So, for example, if the last successful authentication established a device time value of 8 intervals from a specific start date but the validation server determines the time value at 9 intervals, the server SHOULD record the drift as -1.
<TimeDrift>：此元素包含基于时间的OTP算法的设备时钟漂移值。整数值（正漂移或负漂移），指示验证服务器在上次成功身份验证后建立设备时钟漂移的时间间隔数。因此，例如，如果上一次成功的身份验证从特定的开始日期起建立了8个间隔的设备时间值，但验证服务器以9个间隔确定时间值，则服务器应将漂移记录为-1。
All the elements listed above (and those defined in the future) obey a simple structure in that they MUST support child elements to convey the data value in either plaintext or encrypted format:
上面列出的所有元素（以及将来定义的元素）都遵循一个简单的结构，因为它们必须支持子元素以明文或加密格式传递数据值：
Plaintext: The <PlainValue> element carries a plaintext value that is typed, for example, to xs:integer.
纯文本：<PlainValue>元素携带一个纯文本值，例如键入到xs:integer。
Encrypted: The <EncryptedValue> element carries an encrypted value.
加密的：<EncryptedValue>元素携带加密的值。
ValueMAC: The <ValueMAC> element is populated with a Message Authentication Code (MAC) generated from the encrypted value in case the encryption algorithm does not support integrity checks. The example shown in Figure 2 illustrates the usage of the <Data> element with two child elements, namely <Secret> and <Counter>. Both elements carry a plaintext value within the <PlainValue> child element.
ValueMAC:<ValueMAC>元素由加密值生成的消息身份验证码（MAC）填充，以防加密算法不支持完整性检查。图2所示的示例说明了<Data>元素与两个子元素的用法，即<Secret>和<Counter>。这两个元素都在<PlainValue>子元素中携带纯文本值。
Two parties receiving the same key value OCTET STRING, resulting in decoding the xs:base64Binary, inside the <PlainValue> or <EncryptedValue> elements, must make use of the key in exactly the same way in order to interoperate. To ensure that, it is necessary to define a correspondence between the OCTET STRING and the notation in the standard algorithm description that defines how the key is
接收相同键值八进制字符串的两方，在<PlainValue>或<EncryptedValue>元素内解码xs:base64二进制，必须以完全相同的方式使用密钥，以便进行互操作。为了确保这一点，有必要定义八位字节字符串与标准算法描述中定义密钥使用方式的符号之间的对应关系
used. The next sections establish that correspondence for the AES algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or Triple DES) [SP800-67]. Unless otherwise specified for a specific algorithm, the OCTET STRING encoding MUST follow the AES Key Value Encoding.
习惯于下一节将确定AES算法[FIPS197]和三重数据加密算法（TDEA或三重DES）[SP800-67]的对应关系。除非对特定算法另有规定，否则八位字节字符串编码必须遵循AES键值编码。
[FIPS197], Section 5.2, titled "Key Expansion", uses the input key as an array of bytes indexed starting at 0. The first octet of the OCTET STRING SHALL become the key byte in the AES, labeled index 0 in [FIPS197]; the succeeding octets of the OCTET STRING SHALL become key bytes in AES, in increasing index order.
[FIPS197]第5.2节标题为“密钥扩展”，将输入密钥用作从0开始索引的字节数组。八位字节字符串的第一个八位字节应成为AES中的关键字节，在[FIPS197]中标记为索引0；八位字节字符串的后续八位字节应以递增的索引顺序成为AES中的关键字节。
Proper parsing and key load of the contents of the OCTET STRING for AES SHALL be determined by using the following value for the <PlainValue> element (binaryBase64-encoded) to generate and match the key expansion test vectors in [FIPS197], Appendix A, for AES
AES八位组字符串内容的正确解析和密钥加载应通过使用<PlainValue>元素（binaryBase64编码）的以下值来确定，以生成并匹配[FIPS197]附录A中AES的密钥扩展测试向量
Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
密码密钥：2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
... <PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue> ...
... <PlainValue>K34VFiiu0qar9xWICc9PPA==</PlainValue>。。。
A Triple-DES key consists of three keys for the cryptographic engine (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 parity bits); the three keys are also collectively referred to as a key bundle [SP800-67]. A key bundle may employ either two or three independent keys. When only two independent keys are employed (called two-key Triple DES), the same value is used for Key1 and Key3.
三重DES密钥由加密引擎的三个密钥（密钥1、密钥2和密钥3）组成，每个密钥为64位（56个密钥位和8个奇偶校验位）；这三个密钥也统称为密钥包[SP800-67]。密钥包可以使用两个或三个独立的密钥。当仅使用两个独立键（称为双键三重DES）时，相同的值用于键1和键3。
Each key in a Triple-DES key bundle is expanded into a key schedule according to a procedure defined in [SP800-67], Appendix A. That procedure numbers the bits in the key from 1 to 64, with number 1 being the leftmost, or most significant bit (MSB). The first octet of the OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. The second octet of the OCTET STRING SHALL be bits 9 through 16 of Key1, and so forth, so that the trailing octet of the OCTET STRING SHALL be bits 57 through 64 of Key3 (or Key2 for two-key Triple DES).
根据附录a[SP800-67]中定义的程序，三重DES密钥束中的每个密钥都被扩展为密钥计划。该程序将密钥中的位从1到64进行编号，数字1为最左边或最高有效位（MSB）。八位字节串的第一个八位字节应为键1的第1位到第8位，第1位为MSB。八位字节串的第二个八位字节应为键1的第9位到第16位，依此类推，因此八位字节串的尾八位字节应为键3的第57位到第64位（或两个键三重编码的键2）。
Proper parsing and key load of the contents of the OCTET STRING for Triple DES SHALL be determined by using the following <PlainValue> element (binaryBase64-encoded) to generate and match the key expansion test vectors in [SP800-67], Appendix B, for the key bundle:
应通过使用以下<PlainValue>元素（binaryBase64编码）为密钥束生成并匹配[SP800-67]附录B中的密钥扩展测试向量，确定三重DES的八位组字符串内容的正确解析和密钥加载：
Key1 = 0123456789ABCDEF
Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01
Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123
Key3 = 456789ABCDEF0123
... <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue> ...
... <PlainValue>ASNFZ4mrze8jRWeJq83vAUVniavN7wEj</PlainValue>。。。
A PSKC document can contain a number of additional information regarding device identification, cryptographic module identification, user identification, and parameters for usage with OTP and CR algorithms. The following example, see Figure 3, is used as a reference for the subsequent sub-sections.
PSKC文档可以包含关于设备标识、加密模块标识、用户标识以及用于OTP和CR算法的参数的许多附加信息。下面的示例（见图3）用作后续小节的参考。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
<UserId>DC=example-bank,DC=net</UserId>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
</Key>
</KeyPackage>
</KeyContainer>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
<UserId>DC=example-bank,DC=net</UserId>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<UserId>UID=jsmith,DC=example-bank,DC=net</UserId>
</Key>
</KeyPackage>
</KeyContainer>
Figure 3: PSKC Key Container Example with Supplementary Data
图3:PSKC密钥容器示例及补充数据
The <DeviceInfo> element uniquely identifies the device to which the <KeyPackage> is provisioned. Since devices can come in different form factors, such as hardware tokens, smart-cards, soft tokens in a mobile phone, or as a PC, this element allows different child element combinations to be used. When combined, the values of the child elements MUST uniquely identify the device. For example, for hardware tokens, the combination of <SerialNo> and <Manufacturer> elements uniquely identifies a device, but the <SerialNo> element alone is insufficient since two different token manufacturers might issue devices with the same serial number (similar to the Issuer Distinguished Name and serial number of a certificate).
<DeviceInfo>元素唯一标识将<KeyPackage>配置到的设备。由于设备可以有不同的形式因素，如硬件令牌、智能卡、移动电话中的软令牌或PC，因此该元素允许使用不同的子元素组合。组合时，子元素的值必须唯一标识设备。例如，对于硬件令牌，<SerialNo>和<Manufacturer>元素的组合唯一地标识一个设备，但是<SerialNo>元素本身是不够的，因为两个不同的令牌制造商可能会发布具有相同序列号的设备（类似于证书的颁发者可分辨名称和序列号）。
The <DeviceInfo> element has the following child elements:
<DeviceInfo>元素具有以下子元素：
<Manufacturer>: This element indicates the manufacturer of the device. Values for the <Manufacturer> element MUST be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN], "oath." MUST be prepended to the value (e.g., "oath.<prefix value from [OATHMAN]>"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.<Organization value from [IANAPENREG]>").
<Manufacturer>：此元素表示设备的制造商。<Manufacturer>元素的值必须取自[OATHMAN]前缀（即左列）或IANA私有企业编号注册表[IANAPENREG]，使用组织值。当值取自[OATHMAN]时，必须在值前面加上“誓言”。（例如，“誓言。<来自[OATHMAN]的前缀值>”）。当值取自[IANAPENREG]时，必须在值前面加上“iana.”（例如，“iana.<Organization value from[IANAPENREG]>”）。
<SerialNo>: This element contains the serial number of the device.
<SerialNo>：此元素包含设备的序列号。
<Model>: This element describes the model of the device (e.g., one-button-HOTP-token-V1).
<Model>：此元素描述设备的型号（例如，one-button-HOTP-token-V1）。
<IssueNo>: This element contains the issue number in case there are devices with the same serial number so that they can be distinguished by different issue numbers.
<IssueNo>：此元素包含问题编号，以防存在具有相同序列号的设备，从而可以通过不同的问题编号对其进行区分。
<DeviceBinding>: This element allows a provisioning server to ensure that the key is going to be loaded into the device for which the key provisioning request was approved. The device is bound to the request using a device identifier, e.g., an International Mobile Equipment Identity (IMEI) for the phone, or an identifier for a class of identifiers, e.g., those for which the keys are protected by a Trusted Platform Module (TPM).
<DeviceBinding>：此元素允许设置服务器确保将密钥加载到已批准密钥设置请求的设备中。使用设备标识符（例如，用于电话的国际移动设备标识（IMEI））或一类标识符（例如，密钥受可信平台模块（TPM）保护的标识符）将设备绑定到请求。
<StartDate> and <ExpiryDate>: These two elements indicate the start and end date of a device (such as the one on a payment card, used when issue numbers are not printed on cards). The date MUST be expressed as a dateTime value in "canonical representation" [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. Keys that reside on the device SHOULD only be used when the current date is after the <StartDate> and before the <ExpiryDate>. Note that usage enforcement of the keys with respect to the dates MAY only happen on the validation server, as some devices such as smart cards do not have an internal clock. Systems thus SHOULD NOT rely upon the device to enforce key usage date restrictions.
<StartDate>和<ExpiryDate>：这两个元素表示设备的开始和结束日期（如支付卡上的日期，当发卡号码未打印在卡上时使用）。日期必须在“规范表示法”[W3C.REC-xmlschema-2-20041028]中表示为日期时间值。实现不应依赖于小于毫秒的时间分辨率，并且不得生成指定闰秒的时间实例。仅当当前日期在<StartDate>之后和<ExpiryDate>之前时，才应使用设备上的密钥。请注意，由于某些设备（如智能卡）没有内部时钟，因此只能在验证服务器上强制使用与日期相关的密钥。因此，系统不应依赖设备强制执行密钥使用日期限制。
Depending on the device type, certain child elements of the <DeviceInfo> element MUST be included in order to uniquely identify a device. This document does not enumerate the different device types and therefore does not list the elements that are mandatory for each type of device.
根据设备类型，必须包含<DeviceInfo>元素的某些子元素才能唯一标识设备。本文件未列举不同的设备类型，因此未列出每种设备类型必须具备的要素。
The <CryptoModuleInfo> element identifies the cryptographic module to which the symmetric keys are or have been provisioned. This allows the identification of the specific cases where a device MAY contain more than one crypto module (e.g., a PC hosting a TPM and a connected token).
<CryptoModuleInfo>元素标识已向其提供对称密钥的加密模块。这允许识别设备可能包含多个加密模块（例如，承载TPM和连接令牌的PC）的特定情况。
The <CryptoModuleInfo> element has a single child element that MUST be included:
<CryptoModuleInfo>元素有一个子元素，必须包括：
<Id>: This element carries a unique identifier for the CryptoModule and is implementation specific. As such, it helps to identify a specific CryptoModule to which the key is being or was provisioned.
<Id>：此元素带有加密模块的唯一标识符，并且是特定于实现的。因此，它有助于识别正在或已向其提供密钥的特定加密模块。
The <UserId> element identifies the user of a distinguished name, as defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net.
<UserId>元素标识可分辨名称的用户，如[RFC4514]中定义的，例如UID=jsmith，DC=example，DC=net。
Although the syntax of the user identifier is defined, there are no semantics associated with this element, i.e., there are no checks enforcing that only a specific user can use this key. As such, this element is for informational purposes only.
尽管定义了用户标识符的语法，但没有与此元素相关的语义，即没有强制执行只有特定用户才能使用此键的检查。因此，此元素仅供参考。
This element may appear in two places, namely as a child element of the <Key> element, where it indicates the user with whom the key is associated, and as a child element of the <DeviceInfo> element, where it indicates the user with whom the device is associated.
该元素可以出现在两个位置，即作为<Key>元素的子元素，其中它表示与该键相关联的用户；作为<DeviceInfo>元素的子元素，其中它表示与该设备相关联的用户。
4.3.4. <AlgorithmParameters> Element: Supplementary Information for OTP and CR Algorithms
4.3.4. <AlgorithmParameters>元素：OTP和CR算法的补充信息
The <AlgorithmParameters> element is a child element of the <Key> element, and this document defines three child elements: <Suite>, <ChallengeFormat>, and <ResponseFormat>.
<AlgorithmParameters>元素是<Key>元素的子元素，本文档定义了三个子元素：<Suite>、<ChallengeFormat>和<ResponseFormat>。
<Suite>:
<Suite>：
The optional <Suite> element defines additional characteristics of the algorithm used, which are algorithm specific. For example, in an HMAC-based (Hashed MAC) OTP algorithm, it could designate the strength of the hash algorithm used (SHA1, SHA256, etc.). Please refer to the algorithm profile section, Section 10, for the exact semantics of the value for each algorithm profile.
可选的<Suite>元素定义了所用算法的其他特征，这些特征是特定于算法的。例如，在基于HMAC的（哈希MAC）OTP算法中，它可以指定所使用的哈希算法的强度（SHA1、SHA256等）。有关每个算法配置文件的值的确切语义，请参阅第10节的算法配置文件部分。
<ChallengeFormat>:
<ChallengeFormat>：
The <ChallengeFormat> element defines the characteristics of the challenge in a CR usage scenario whereby the following attributes are defined:
<ChallengeFormat>元素定义了CR使用场景中质询的特征，其中定义了以下属性：
'Encoding': This attribute, which MUST be included, defines the encoding of the challenge accepted by the device and MUST be one of the following values:
“Encoding”：必须包含此属性，它定义设备接受的质询的编码，并且必须是以下值之一：
DECIMAL: Only numerical digits
十进制：只有数字
HEXADECIMAL: Hexadecimal response
十六进制：十六进制响应
ALPHANUMERIC: All letters and numbers (case sensitive)
字母数字：所有字母和数字（区分大小写）
BASE64: Base-64 encoded, as defined in Section 4 of [RFC4648]
BASE64:Base-64编码，如[RFC4648]第4节所定义
BINARY: Binary data
二进制：二进制数据
'CheckDigit': This attribute indicates whether a device needs to check the appended Luhn check digit, as defined in [ISOIEC7812], contained in a challenge. This is only valid if the 'Encoding' attribute is set to 'DECIMAL'. A value of TRUE indicates that the device will check the appended Luhn check digit in a provided challenge. A value of FALSE indicates that the device will not check the appended Luhn check digit in the challenge.
“CheckDigit”：此属性指示设备是否需要检查质询中包含的[ISOIEC7812]中定义的附加Luhn校验位。这仅在“Encoding”属性设置为“DECIMAL”时有效。值为TRUE表示设备将在提供的质询中检查附加的Luhn校验位。值FALSE表示设备不会检查质询中附加的Luhn校验位。
'Min': This attribute defines the minimum size of the challenge accepted by the device for CR mode and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the minimum number of digits/characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the minimum number of bytes of the unencoded value.
“Min”：此属性定义设备在CR模式下接受的质询的最小大小，必须包括在内。如果“编码”属性设置为“十进制”、“十六进制”或“字母数字”，则该值表示最小位数/字符数。如果“Encoding”属性设置为“BASE64”或“BINARY”，则该值表示未编码值的最小字节数。
'Max': This attribute defines the maximum size of the challenge accepted by the device for CR mode and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the maximum number of digits/characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the maximum number of bytes of the unencoded value.
“Max”：此属性定义设备在CR模式下接受的质询的最大大小，必须包括在内。如果“编码”属性设置为“十进制”、“十六进制”或“字母数字”，则此值表示最大位数/字符数。如果“Encoding”属性设置为“BASE64”或“BINARY”，则此值表示未编码值的最大字节数。
<ResponseFormat>:
<ResponseFormat>：
The <ResponseFormat> element defines the characteristics of the result of a computation and defines the format of the OTP or the response to a challenge. For cases in which the key is a PIN value, this element contains the format of the PIN itself (e.g., DECIMAL, length 4 for a 4-digit PIN). The following attributes are defined:
<ResponseFormat>元素定义计算结果的特征，并定义OTP的格式或对质询的响应。对于键为PIN值的情况，此元素包含PIN本身的格式（例如，十进制，4位PIN的长度为4）。定义了以下属性：
'Encoding': This attribute defines the encoding of the response generated by the device, it MUST be included and MUST be one of the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
“Encoding”：此属性定义设备生成的响应的编码，它必须包括在内，并且必须是以下值之一：十进制、十六进制、字母数字、BASE64或二进制。
'CheckDigit': This attribute indicates whether the device needs to append a Luhn check digit, as defined in [ISOIEC7812], to the response. This is only valid if the 'Encoding' attribute is set to 'DECIMAL'. If the value is TRUE, then the device will append a Luhn check digit to the response. If the value is FALSE, then the device will not append a Luhn check digit to the response.
“CheckDigit”：此属性指示设备是否需要向响应追加[ISOIEC7812]中定义的Luhn校验位。这仅在“Encoding”属性设置为“DECIMAL”时有效。如果该值为TRUE，则设备将在响应中附加一个Luhn校验位。如果该值为FALSE，则设备不会在响应中附加Luhn校验位。
'Length': This attribute defines the length of the response generated by the device and MUST be included. If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or ALPHANUMERIC, this value indicates the number of digits/ characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
“Length”：此属性定义设备生成的响应的长度，必须包括在内。如果“编码”属性设置为“十进制”、“十六进制”或字母数字，则此值表示位数/字符数。如果“Encoding”属性设置为“BASE64”或“BINARY”，则此值表示未编码值的字节数。
<KeyProfileId> element, which is a child element of the <Key> element, carries a unique identifier used between the sending and receiving parties to establish a set of key attribute values that are not transmitted within the container but are agreed upon between the two parties out of band. This element will then represent the unique reference to a set of key attribute values. (For example, a smart card application personalization profile id related to specific attribute values present on a smart card application that have influence when computing a response).
<KeyProfileId>元素是<Key>元素的子元素，它携带一个在发送方和接收方之间使用的唯一标识符，以建立一组密钥属性值，这些密钥属性值不是在容器内传输的，而是在双方带外商定的。然后，该元素将表示对一组关键属性值的唯一引用。（例如，与智能卡应用程序上存在的特定属性值相关的智能卡应用程序个性化配置文件id，该属性值在计算响应时具有影响）。
For example, in the case of MasterCard's Chip Authentication Program [CAP], the sending and the receiving party would agree that KeyProfileId='1' represents a certain set of values (e.g., Internet Authentication Flag (IAF) set to a specific value). During transmission of the <KeyContainer>, these values would not be transmitted as key attributes but would only be referred to via the
例如，在万事达卡的芯片认证程序[CAP]的情况下，发送方和接收方将同意KeyProfileId='1'表示某一组值（例如，设置为特定值的互联网认证标志（IAF））。在传输<KeyContainer>期间，这些值不会作为密钥属性传输，而只能通过
<KeyProfileId> element set to the specific agreed-upon profile (in this case '1'). The receiving party can then associate all relevant key attributes contained in the profile that was agreed upon out of band with the imported keys. Often, this methodology is used between a manufacturing service, run by company A, and the validation service, run by company B, to avoid repeated transmission of the same set of key attribute values.
<KeyProfileId>元素设置为特定的商定配置文件（在本例中为“1”）。然后，接收方可以将在带外商定的配置文件中包含的所有相关密钥属性与导入的密钥相关联。通常，该方法在公司a运行的制造服务和公司B运行的验证服务之间使用，以避免重复传输同一组关键属性值。
The <KeyReference> element contains a reference to an external key to be used with a key derivation scheme. In this case, the parent <Key> element will not contain the <Secret> subelement of <Data>, in which the key value (secret) is transported; only the reference to the external master key is transported (e.g., a PKCS #11 key label).
<KeyReference>元素包含对要与密钥派生方案一起使用的外部密钥的引用。在这种情况下，父<Key>元素将不包含<Data>的<Secret>子元素，在该子元素中传输键值（Secret）；仅传输对外部主密钥的引用（例如，PKCS#11密钥标签）。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<KeyProfileId>keyProfile1</KeyProfileId>
<KeyReference>MasterKeyLabel
</KeyReference>
<Data>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<KeyProfileId>keyProfile1</KeyProfileId>
<KeyReference>MasterKeyLabel
</KeyReference>
<Data>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
Figure 4: Example of a PSKC Document Transmitting an HOTP Key via Key Derivation Values
图4:PSKC文档通过密钥派生值传输HOTP密钥的示例
The key value will be derived using the value of the <SerialNo> element, values agreed upon between the sending and the receiving parties and identified by the <KeyProfile> 'keyProfile1', and an externally agreed-upon key referenced by the label 'MasterKeyLabel'.
键值将使用<SerialNo>元素的值、发送方和接收方之间商定并由<KeyProfile>“keyProfile1”标识的值以及标签“MasterKeyLabel”引用的外部商定的键值导出。
This section illustrates the functionality of the <Policy> element within PSKC, which allows a key usage and key PIN protection policy to be attached to a specific key and its related metadata. This element is a child element of the <Key> element.
本节说明了PSKC中<Policy>元素的功能，该元素允许将密钥使用和密钥PIN保护策略附加到特定密钥及其相关元数据。此元素是<Key>元素的子元素。
If the <Policy> element contains child elements or values within elements/attributes that are not understood by the recipient of the PSKC document, then the recipient MUST assume that key usage is not permitted. This statement ensures that the lack of understanding of certain extensions does not lead to unintended key usage.
如果<Policy>元素包含PSKC文档收件人无法理解的子元素或元素/属性中的值，则收件人必须假定不允许使用密钥。此语句确保对某些扩展的理解不足不会导致意外的密钥使用。
We will start our description with an example that expands the example shown in Figure 3.
我们将从一个扩展图3所示示例的示例开始描述。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
Version="1.0" Id="exampleID1"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<PINPolicy MinLength="4" MaxLength="4"
PINKeyId="123456781" PINEncoding="DECIMAL"
PINUsageMode="Local"/>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="123456781"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:pin">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="4" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNA==</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
</Counter>
</Data>
<Policy>
<PINPolicy MinLength="4" MaxLength="4"
PINKeyId="123456781" PINEncoding="DECIMAL"
PINUsageMode="Local"/>
<KeyUsage>OTP</KeyUsage>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="123456781"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:pin">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="4" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>MTIzNA==</PlainValue>
</Secret>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 5: Non-Encrypted HOTP Secret Key Protected by PIN
图5：受PIN保护的未加密HOTP密钥
This document defines the following <Policy> child elements:
本文档定义了以下<Policy>子元素：
<StartDate> and <ExpiryDate>: These two elements denote the validity period of a key. It MUST be ensured that the key is only used between the start and the end date (inclusive). The date MUST be expressed as a dateTime value in "canonical representation" [W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds. When this element is absent, the current time is assumed as the start time.
<StartDate>和<ExpiryDate>：这两个元素表示密钥的有效期。必须确保密钥仅在开始日期和结束日期（含）之间使用。日期必须在“规范表示法”[W3C.REC-xmlschema-2-20041028]中表示为日期时间值。实现不应依赖于小于毫秒的时间分辨率，并且不得生成指定闰秒的时间实例。如果缺少此元素，则假定当前时间为开始时间。
<NumberOfTransactions>: The value in this element indicates the maximum number of times a key carried within the PSKC document can be used by an application after having received it. When this element is omitted, there is no restriction regarding the number of times a key can be used.
<NumberOfTransactions>：此元素中的值表示应用程序在收到PSKC文档中携带的密钥后可以使用的最大次数。如果省略此元素，则对密钥的使用次数没有限制。
<KeyUsage>: The <KeyUsage> element puts constraints on the intended usage of the key. The recipient of the PSKC document MUST enforce the key usage. Currently, the following tokens are registered by this document:
<KeyUsage>：元素<KeyUsage>对密钥的预期用途进行约束。PSKC文档的收件人必须强制使用密钥。目前，本文档注册了以下令牌：
OTP: The key MUST only be used for OTP generation.
OTP：密钥只能用于生成OTP。
CR: The key MUST only be used for Challenge/Response purposes.
CR：密钥只能用于质询/响应目的。
Encrypt: The key MUST only be used for data encryption purposes.
加密：密钥只能用于数据加密目的。
Integrity: The key MUST only be used to generate a keyed message digest for data integrity or authentication purposes.
完整性：密钥必须仅用于生成用于数据完整性或身份验证目的的密钥消息摘要。
Verify: The key MUST only be used to verify a keyed message digest for data integrity or authentication purposes (this is the opposite key usage of 'Integrity').
验证：该密钥必须仅用于出于数据完整性或身份验证目的验证密钥消息摘要（这与“完整性”的密钥用法相反）。
Unlock: The key MUST only be used for an inverse Challenge/ Response in the case where a user has locked the device by entering a wrong PIN too many times (for devices with PIN-input capability).
解锁：只有在用户多次输入错误PIN锁定设备的情况下（对于具有PIN输入功能的设备），钥匙才能用于反向质询/响应。
Decrypt: The key MUST only be used for data decryption purposes.
解密：密钥只能用于数据解密目的。
KeyWrap: The key MUST only be used for key wrap purposes.
密钥换行：密钥只能用于密钥换行目的。
Unwrap: The key MUST only be used for key unwrap purposes.
展开：密钥只能用于密钥展开目的。
Derive: The key MUST only be used with a key derivation function to derive a new key (see also Section 8.2.4 of [NIST800-57]).
派生：密钥只能与密钥派生函数一起使用，以派生新密钥（另请参见[NIST800-57]第8.2.4节）。
Generate: The key MUST only be used to generate a new key based on a random number and the previous value of the key (see also Section 8.1.5.2.1 of [NIST800-57]).
生成：密钥只能用于根据随机数和密钥的先前值生成新密钥（另请参见[NIST800-57]第8.1.5.2.1节）。
The element MAY also be repeated to allow several key usages to be expressed. When this element is absent, no key usage constraint is assumed, i.e., the key MAY be utilized for every usage.
还可以重复该元素以允许表达几个关键用法。如果不存在该元素，则假定没有密钥使用约束，即密钥可用于每次使用。
<PINPolicy>: The <PINPolicy> element allows policy about the PIN usage to be associated with the key. The following attributes are specified:
<PINPolicy>：元素允许有关PIN使用的策略与密钥相关联。指定了以下属性：
'PINKeyId': This attribute carries the unique 'Id' attribute vale of the <Key> element held within this <KeyContainer> that contains the value of the PIN that protects the key.
“PINKeyId”：此属性携带此<KeyContainer>中包含保护密钥的PIN值的<Key>元素的唯一“Id”属性值。
'PINUsageMode': This mandatory attribute indicates the way the PIN is used during the usage of the key. The following values are defined:
“PINUsageMode”：此强制属性指示在使用密钥期间使用PIN的方式。定义了以下值：
Local: This value indicates that the PIN is checked locally on the device before allowing the key to be used in executing the algorithm.
本地：该值表示在允许在执行算法时使用密钥之前，在设备上本地检查PIN。
Prepend: This value indicates that the PIN is prepended to the algorithm response; hence, it MUST be checked by the party validating the response.
Prepend：该值表示该引脚在算法响应之前；因此，必须由验证响应的一方进行检查。
Append: This value indicates that the PIN is appended to the algorithm response; hence, it MUST be checked by the party validating the response.
追加：该值表示PIN追加到算法响应中；因此，必须由验证响应的一方进行检查。
Algorithmic: This value indicates that the PIN is used as part of the algorithm computation.
Algorithmic：该值表示引脚用作算法计算的一部分。
'MaxFailedAttempts': This attribute indicates the maximum number of times the PIN may be entered wrongly before it MUST NOT be possible to use the key anymore (typical reasonable values are in the positive integer range of at least 2 and no more than 10).
“MaxFailedAttempts”：此属性表示在不能再使用密钥之前，PIN可能被错误输入的最大次数（典型的合理值在至少2到不超过10的正整数范围内）。
'MinLength': This attribute indicates the minimum length of a PIN that can be set to protect the associated key. It MUST NOT be possible to set a PIN shorter than this value. If the 'PINFormat' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/ characters. If the 'PINFormat' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
“MinLength”：此属性表示可设置为保护关联密钥的PIN的最小长度。不能将管脚设置为小于此值。如果“PINFormat”属性设置为“DECIMAL”、“HEXADECIMAL”或“ALPHANUMERIC”，则该值表示位数/字符数。如果“PINFormat”属性设置为“BASE64”或“BINARY”，则该值表示未编码值的字节数。
'MaxLength': This attribute indicates the maximum length of a PIN that can be set to protect this key. It MUST NOT be possible to set a PIN longer than this value. If the 'PINFormat' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the number of digits/
“MaxLength”：此属性表示可设置为保护此密钥的PIN的最大长度。不能将管脚设置为长于此值。如果“PINFormat”属性设置为“十进制”、“十六进制”或“字母数字”，则此值表示位数/
characters. If the 'PINFormat' attribute is set to 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value.
人物。如果“PINFormat”属性设置为“BASE64”或“BINARY”，则该值表示未编码值的字节数。
'PINEncoding': This attribute indicates the encoding of the PIN and MUST be one of the values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY.
“PINEncoding”：此属性表示PIN的编码，并且必须是以下值之一：十进制、十六进制、字母数字、BASE64或二进制。
If the 'PinUsageMode' attribute is set to 'Local', then the device MUST enforce the restriction indicated in the 'MaxFailedAttempts', 'MinLength', 'MaxLength', and 'PINEncoding' attributes; otherwise, it MUST be enforced on the server side.
如果“PinUsageMode”属性设置为“Local”，则设备必须强制执行“MaxFailedAttempts”、“MinLength”、“MaxLength”和“Pinencode”属性中指示的限制；否则，必须在服务器端强制执行。
The PIN algorithm is defined as:
PIN算法定义为：
boolean = comparePIN(K,P)
boolean=comparePIN（K，P）
Where:
哪里：
'K' is the stored symmetric credential (PIN) in binary format.
“K”是以二进制格式存储的对称凭证（PIN）。
'P' is the proposed PIN to be compared in binary format.
“P”是以二进制格式进行比较的建议PIN。
The function comparePIN is a straight octet comparison of K and P. Such a comparison MUST yield a value of TRUE (credentials matched) when the octet length of K is the same as the octet length of P and all octets comprising K are the same as the octets comprising P.
函数comparePIN是K和P的直接八位组比较。当K的八位组长度与P的八位组长度相同，且包含K的所有八位组与包含P的八位组相同时，这种比较必须产生TRUE（凭据匹配）值。
With the functionality described in the previous sections, information related to keys had to be transmitted in cleartext. With the help of the <EncryptionKey> element, which is a child element of the <KeyContainer> element, it is possible to encrypt keys and associated information. The level of encryption is applied to the value of individual elements and the applied encryption algorithm MUST be the same for all encrypted elements. Keys are protected using the following methods: pre-shared keys, passphrase-based keys, and asymmetric keys. When encryption algorithms are used that make use of Initialization Vectors (IVs), for example, AES-128-CBC, a random IV value MUST be generated for each value to be encrypted and it MUST be prepended to the resulting encrypted value as specified in [XMLENC].
使用前面章节中描述的功能，与密钥相关的信息必须以明文形式传输。借助<EncryptionKey>元素（它是<KeyContainer>元素的子元素），可以加密密钥和相关信息。加密级别应用于单个元素的值，并且应用的加密算法必须与所有加密元素相同。使用以下方法保护密钥：预共享密钥、基于密码短语的密钥和非对称密钥。当使用利用初始化向量（IVs）的加密算法时，例如AES-128-CBC，必须为每个要加密的值生成一个随机IV值，并且必须在[XMLENC]中指定的结果加密值之前添加该值。
Figure 6 shows an example that illustrates the encryption of the content of the <Secret> element using AES-128-CBC and PKCS #5 Padding. The plaintext value of <Secret> is '3132333435363738393031323334353637383930'. The name of the pre-shared secret is "Pre-shared-key", as set in the <KeyName> element (which is a child element of the <EncryptionKey> element). The value of the encryption key used is '12345678901234567890123456789012'.
图6显示了使用AES-128-CBC和PKCS#5填充对<Secret>元素内容进行加密的示例。<Secret>的纯文本值为“3132333435363739330313233343536373839330”。预共享密钥的名称是“预共享密钥”，如<KeyName>元素（它是<EncryptionKey>元素的子元素）中所设置的。使用的加密密钥的值为“1234567890012345678901234567890123456789012”。
The IV for the MAC key is '11223344556677889900112233445566', and the IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
MAC密钥的IV为“112233445667788990011223344566”，HOTP密钥的IV为“000102030405060708090a0b0c0d0e0f”。
As AES-128-CBC does not provide integrity checks, a keyed MAC is applied to the encrypted value using a MAC key and a MAC algorithm as declared in the <MACMethod> element (in our example, "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the algorithm and the value of the MAC key is randomly generated, in our case '1122334455667788990011223344556677889900', and encrypted with the above encryption key). The result of the keyed-MAC computation is placed in the <ValueMAC> child element of <Secret>.
由于AES-128-CBC不提供完整性检查，因此使用<MACMethod>元素（在我们的示例中）中声明的MAC密钥和MAC算法将密钥MAC应用于加密值http://www.w3.org/2000/09/xmldsig#hmac-sha1“将用作算法，并且随机生成MAC密钥的值，在我们的示例中为“112233445667788990011223344556677889900”，并使用上述加密密钥进行加密）。键控MAC计算的结果放在<Secret>的<ValueMAC>子元素中。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey>
<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX
</xenc:CipherValue>
</xenc:CipherData>
</MACKey>
</MACMethod>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>Pre-shared-key</ds:KeyName>
</EncryptionKey>
<MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX
</xenc:CipherValue>
</xenc:CipherData>
</MACKey>
</MACMethod>
<KeyPackage>
<DeviceInfo>
<Manufacturer>Manufacturer</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<CryptoModuleInfo>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc=
</ValueMAC>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
<Id>CM_ID_001</Id>
</CryptoModuleInfo>
<Key Id="12345678"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>Su+NvtQfmvfJzF6bmQiJqoLRExc=
</ValueMAC>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1
图6:AES-128-CBC使用HMAC-SHA1加密预共享密钥
When protecting the payload with pre-shared keys, implementations MUST set the name of the specific pre-shared key in the <KeyName> element inside the <EncryptionKey> element. When the encryption method uses a CBC mode that requires an explicit initialization vector (IV), the IV MUST be passed by prepending it to the encrypted value.
使用预共享密钥保护负载时，实现必须在<EncryptionKey>元素内的<KeyName>元素中设置特定预共享密钥的名称。当加密方法使用需要显式初始化向量（IV）的CBC模式时，必须通过将IV前置到加密值来传递IV。
For systems implementing PSKC, it is RECOMMENDED to support AES-128-CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-AES128 requires that the key to be protected must be a multiple of 8 bytes in length. Hence, if keys of a different length have to be protected, then the usage of the key-wrap algorithm with padding, as described in [RFC5649] is RECOMMENDED. Some of the encryption algorithms that can optionally be implemented are:
对于实现PSKC的系统，建议支持AES-128-CBC（URI为http://www.w3.org/2001/04/xmlenc#aes128-cbc）和KW-AES128（URI为http://www.w3.org/2001/04/xmlenc#kw-aes128）。请注意，KW-AES128要求要保护的密钥长度必须是8字节的倍数。因此，如果必须保护不同长度的密钥，则建议使用[RFC5649]中所述的带填充的密钥换行算法。可以选择实施的一些加密算法包括：
Algorithm | Uniform Resource Locator (URL)
---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
Algorithm | Uniform Resource Locator (URL)
---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
When algorithms without integrity checks are used, such as AES-128- CBC, a keyed-MAC value MUST be placed in the <ValueMAC> element of the <Data> element. In this case, the MAC algorithm type MUST be set in the <MACMethod> element of the <KeyContainer> element. The MAC key MUST be a randomly generated key by the sender, be pre-agreed upon between the receiver and the sender, or be set by the application protocol that carries the PSKC document. It is RECOMMENDED that the sender generate a random MAC key. When the sender generates such a random MAC key, the MAC key material MUST be encrypted with the same encryption key specified in <EncryptionKey> element of the key container. The encryption method and encrypted value MUST be set in the <EncryptionMethod> element and the <CipherData> element, respectively, of the <MACKey> element in the <MACMethod> element. The <MACKeyReference> element of the <MACMethod> element MAY be used to indicate a pre-shared MAC key or a provisioning protocol derived MAC key. For systems implementing PSKC, it is RECOMMENDED to implement the HMAC-SHA1 (with the URI of 'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC algorithms that can optionally be implemented are:
当使用没有完整性检查的算法时，例如AES-128-CBC，必须在<Data>元素的<ValueMAC>元素中放置一个键控MAC值。在这种情况下，必须在<KeyContainer>元素的<MACMethod>元素中设置MAC算法类型。MAC密钥必须是由发送方随机生成的密钥，由接收方和发送方预先约定，或者由承载PSKC文档的应用程序协议设置。建议发送方生成随机MAC密钥。当发送方生成此类随机MAC密钥时，必须使用密钥容器的<EncryptionKey>元素中指定的相同加密密钥对MAC密钥材料进行加密。必须分别在<MACMethod>元素的<MACKey>元素的<EncryptionMethod>元素和<CipherData>元素中设置加密方法和加密值。<MACMethod>元素的<MACKeyReference>元素可用于指示预共享的MAC密钥或由供应协议派生的MAC密钥。对于实现PSKC的系统，建议实现HMAC-SHA1（URI为'http://www.w3.org/2000/09/xmldsig#hmac-sha1'）。可以选择实施的一些MAC算法包括：
Algorithm | Uniform Resource Locator (URL)
---------------+-----------------------------------------------------
HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
Algorithm | Uniform Resource Locator (URL)
---------------+-----------------------------------------------------
HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
Figure 7 shows an example that illustrates the encryption of the content of the <Secret> element using passphrase-based key derivation (PBKDF2) to derive the encryption key as defined in [PKCS5]. When using passphrase-based key derivation, the <DerivedKey> element defined in XML Encryption Version 1.1 [XMLENC11] MUST be used to specify the passphrased-based key. A <DerivedKey> element is set as the child element of <EncryptionKey> element of the key container.
图7显示了一个示例，该示例演示了使用基于密码短语的密钥派生（PBKDF2）对<Secret>元素的内容进行加密，以派生[PKCS5]中定义的加密密钥。使用基于密码短语的密钥派生时，必须使用XML加密版本1.1[XMLENC11]中定义的<DerivedKey>元素指定基于密码短语的密钥。<DerivedKey>元素被设置为密钥容器的<EncryptionKey>元素的子元素。
The <DerivedKey> element is used to specify the key derivation function and related parameters. The encryption algorithm, in this example, AES-128-CBC (URI 'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the 'Algorithm' attribute of <EncryptionMethod> element used inside the encrypted data elements.
元素用于指定键派生函数和相关参数。本例中的加密算法是AES-128-CBC（URI'http://www.w3.org/2001/04/xmlenc#aes128-cbc'），必须在加密数据元素内部使用的<EncryptionMethod>元素的“Algorithm”属性中设置。
When PBKDF2 is used, the 'Algorithm' attribute of the <xenc11: KeyDerivationMethod> element MUST be set to the URI 'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The <xenc11:KeyDerivationMethod> element MUST include the <PBKDF2-params> child element to indicate the PBKDF2 parameters, such as salt and iteration count.
使用PBKDF2时，必须将<xenc11:keydrivationmethod>元素的'Algorithm'属性设置为URI'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. 元素必须包含子元素<PBKDF2 params>，以指示PBKDF2参数，例如salt和迭代计数。
When the encryption method uses a CBC mode that uses an explicit initialization vector (IV) other than a derived one, the IV MUST be passed by prepending it to the encrypted value.
当加密方法使用的CBC模式使用的是显式初始化向量（IV）而不是派生向量时，必须通过将IV前置到加密值来传递IV。
In the example below, the following data is used.
在下面的示例中，使用了以下数据。
Password: qwerty
密码：qwerty
Salt: 0x123eff3c4a72129c
盐：0x123eff3c4a72129c
Iteration Count: 1000
迭代次数：1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
OTP Secret: 12345678901234567890
OTP机密：123456789001234567890
The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41". The initialization vector (IV) is "0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to encrypt the randomly chosen MAC key. A different IV can be used, say "0xd864d39cbc0cdc8e1ee483b9164b9fa0", in the example. The encryption with algorithm "AES-128-CBC" follows the specification defined in [XMLENC].
派生的加密密钥是“0x651e63cd57008476af1ff6422cd02e41”。初始化向量（IV）为“0xa13be8f92db69ec992d99fd1b5ca05f0”。该密钥还用于加密随机选择的MAC密钥。可以使用不同的IV，如示例中的“0xd864d39cbc0cdc8e1ee483b9164b9fa0”。算法“AES-128-CBC”的加密遵循[XMLENC]中定义的规范。
<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
<pskc:EncryptionKey>
<xenc11:DerivedKey>
<xenc11:KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params>
<Salt>
<Specified>Ej7/PEpyEpw=</Specified>
</Salt>
<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</pkcs5:PBKDF2-params>
</xenc11:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>
</xenc11:DerivedKey>
</pskc:EncryptionKey>
<pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key Algorithm=
<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Version="1.0">
<pskc:EncryptionKey>
<xenc11:DerivedKey>
<xenc11:KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params>
<Salt>
<Specified>Ej7/PEpyEpw=</Specified>
</Salt>
<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</pkcs5:PBKDF2-params>
</xenc11:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<xenc11:MasterKeyName>My Password 1</xenc11:MasterKeyName>
</xenc11:DerivedKey>
</pskc:EncryptionKey>
<pskc:MACMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp" Id="123456">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
</pskc:ValueMAC>
</pskc:Secret>
</pskc:Data>
</pskc:Key>
</pskc:KeyPackage>
</pskc:KeyContainer>
"urn:ietf:params:xml:ns:keyprov:pskc:hotp" Id="123456">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="8" Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>LP6xMvjtypbfT9PdkJhBZ+D6O4w=
</pskc:ValueMAC>
</pskc:Secret>
</pskc:Data>
</pskc:Key>
</pskc:KeyPackage>
</pskc:KeyContainer>
Figure 7: Example of a PSKC Document Using Encryption Based on Passphrase-Based Keys
图7：使用基于密码短语的密钥加密的PSKC文档示例
When using asymmetric keys to encrypt child elements of the <Data> element, information about the certificate being used MUST be stated in the <X509Data> element, which is a child element of the <EncryptionKey> element. The encryption algorithm MUST be indicated in the 'Algorithm' attribute of the <EncryptionMethod> element. In the example shown in Figure 8, the algorithm is set to 'http://www.w3.org/2001/04/xmlenc#rsa_1_5'.
使用非对称密钥加密<Data>元素的子元素时，必须在<X509Data>元素中说明所使用证书的信息，该元素是<EncryptionKey>元素的子元素。必须在<EncryptionMethod>元素的'algorithm'属性中指示加密算法。在图8所示的示例中，算法设置为'http://www.w3.org/2001/04/xmlenc#rsa_1_5'.
<?xml version="1.0" encoding="UTF-8" ?>
<KeyContainer
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
id="KC0001"
Version="1.0">
<EncryptionKey>
<ds:X509Data>
<?xml version="1.0" encoding="UTF-8" ?>
<KeyContainer
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
id="KC0001"
Version="1.0">
<EncryptionKey>
<ds:X509Data>
<ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M
Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF
Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR
GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data>
</EncryptionKey>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key
Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData>
<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
<ds:X509Certificate>MIIB5zCCAVCgAwIBAgIESZp/vDANBgkqhkiG9w0BAQUFADA4M
Q0wCwYDVQQKEwRJRVRGMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIF
Rlc3QwHhcNMDkwMjE3MDkxMzMyWhcNMTEwMjE3MDkxMzMyWjA4MQ0wCwYDVQQKEwRJRVR
GMRMwEQYDVQQLEwpLZXlQcm92IFdHMRIwEAYDVQQDEwlQU0tDIFRlc3QwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALCWLDa2ItYJ6su80hd1gL4cggQYdyyKK17btt/aS6Q/e
DsKjsPyFIODsxeKVV/uA3wLT4jQJM5euKJXkDajzGGOy92+ypfzTX4zDJMkh61SZwlHNJ
xBKilAM5aW7C+BQ0RvCxvdYtzx2LTdB+X/KMEBA7uIYxLfXH2Mnub3WIh1AgMBAAEwDQY
JKoZIhvcNAQEFBQADgYEAe875m84sYUJ8qPeZ+NG7REgTvlHTmoCdoByU0LBBLotUKuqf
rnRuXJRMeZXaaEGmzY1kLonVjQGzjAkU4dJ+RPmiDlYuHLZS41Pg6VMwY+03lhk6I5A/w
4rnqdkmwZX/NgXg06alnc2pBsXWhL4O7nk0S2ZrLMsQZ6HcsXgdmHo=
</ds:X509Certificate>
</ds:X509Data>
</EncryptionKey>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>987654321</SerialNo>
</DeviceInfo>
<Key
Id="MBK000000001"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData>
<xenc:CipherValue>hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4
xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5fdeV5nqbZApe6dofTqhRwZK6
Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
</KeyContainer>
Figure 8: Example of a PSKC Document Using Encryption Based on Asymmetric Keys
图8：使用基于非对称密钥的加密的PSKC文档示例
For systems implementing PSKC, it is RECOMMENDED to implement the RSA-1.5 algorithm, identified by the URI 'http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
对于实现PSKC的系统，建议实现RSA-1.5算法，该算法由URI的http://www.w3.org/2001/04/xmlenc#rsa-1_5'.
Some of the asymmetric encryption algorithms that can optionally be implemented are:
可以选择实施的一些非对称加密算法包括：
Algorithm | Uniform Resource Locator (URL)
------------------+-------------------------------------------------
RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
Algorithm | Uniform Resource Locator (URL)
------------------+-------------------------------------------------
RSA-OAEP-MGF1P | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
Padding of encrypted values (for example, the key secret value) is required when key protection algorithms are used that do not support embedded padding and the value to be encrypted is not a multiple of the encryption algorithm cipher block length.
如果使用的密钥保护算法不支持嵌入填充，并且要加密的值不是加密算法密码块长度的倍数，则需要填充加密值（例如，密钥机密值）。
For example, when transmitting an HOTP key (20 bytes long) protected with the AES algorithm in CBC mode (8-byte block cipher), padding is required since its length is not a multiple of the 8-byte block length.
例如，在CBC模式（8字节分组密码）下传输受AES算法保护的HOTP密钥（20字节长）时，需要填充，因为其长度不是8字节块长度的倍数。
In these cases, for systems implementing PSKC, it is RECOMMENDED to pad the value before encryption using PKCS #5 padding as described in [PKCS5].
在这些情况下，对于实现PSKC的系统，建议在加密之前使用[PKCS5]中所述的PKCS#5填充来填充值。
PSKC allows a digital signature to be added to the XML document, as a child element of the <KeyContainer> element. The description of the XML digital signature can be found in [XMLDSIG].
PSKC允许将数字签名作为<KeyContainer>元素的子元素添加到XML文档中。XML数字签名的描述可在[XMLDSIG]中找到。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo>
</DeviceInfo>
<Key Id="123"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>0755225266</SerialNo>
</DeviceInfo>
<Key Id="123"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Example-Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
<Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#Device">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>
CN=Example.com,C=US
</ds:X509IssuerName>
<ds:X509SerialNumber>
12345678
</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</ds:KeyInfo>
</Signature>
</KeyContainer>
<ResponseFormat Length="6" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
</Key>
</KeyPackage>
<Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#Device">
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>
CN=Example.com,C=US
</ds:X509IssuerName>
<ds:X509SerialNumber>
12345678
</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</ds:KeyInfo>
</Signature>
</KeyContainer>
Figure 9: Digital Signature Example
图9：数字签名示例
The functionality of bulk provisioning can be accomplished by repeating the <KeyPackage> element multiple times within the <KeyContainer> element, indicating that multiple keys are provided to different devices or cryptographic modules. The <EncryptionKey> element then applies to all <KeyPackage> elements. When provisioning multiple keys to the same device, the <KeyPackage> element is repeated, but the enclosed <DeviceInfo> element will contain the same sub-elements that uniquely identify the single device (for example, the keys for the device identified by SerialNo='9999999' in the example below).
批量供应的功能可以通过在<KeyContainer>元素中多次重复<KeyPackage>元素来实现，这表明向不同的设备或加密模块提供了多个密钥。<EncryptionKey>元素随后应用于所有<KeyPackage>元素。为同一设备提供多个密钥时，<KeyPackage>元素会重复，但封闭的<DeviceInfo>元素将包含唯一标识单个设备的相同子元素（例如，下面示例中由SerialNo='999999'标识的设备密钥）。
Figure 10 shows an example utilizing these capabilities.
图10显示了利用这些功能的示例。
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>654321</SerialNo>
</DeviceInfo>
<Key Id="1"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:pskc">
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>654321</SerialNo>
</DeviceInfo>
<Key Id="1"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>123456</SerialNo>
</DeviceInfo>
<Key Id="2"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="3"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>123456</SerialNo>
</DeviceInfo>
<Key Id="2"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-05-01T00:00:00Z</StartDate>
<ExpiryDate>2006-05-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="3"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-03-01T00:00:00Z</StartDate>
<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="4"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-04-01T00:00:00Z</StartDate>
<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
<Policy>
<StartDate>2006-03-01T00:00:00Z</StartDate>
<ExpiryDate>2006-03-31T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
<KeyPackage>
<DeviceInfo>
<Manufacturer>TokenVendorAcme</Manufacturer>
<SerialNo>9999999</SerialNo>
</DeviceInfo>
<Key Id="4"
Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<Issuer>Issuer</Issuer>
<AlgorithmParameters>
<ResponseFormat Length="8" Encoding="DECIMAL"/>
</AlgorithmParameters>
<Data>
<Secret>
<PlainValue>
MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
</PlainValue>
</Secret>
<Counter>
<PlainValue>0</PlainValue>
</Counter>
</Data>
<Policy>
<StartDate>2006-04-01T00:00:00Z</StartDate>
<ExpiryDate>2006-04-30T00:00:00Z</ExpiryDate>
</Policy>
</Key>
</KeyPackage>
</KeyContainer>
Figure 10: Bulk Provisioning Example
图10：批量供应示例
This section lists a few common extension points provided by PSKC:
本节列出了PSKC提供的几个常见扩展点：
New PSKC Version: Whenever it is necessary to define a new version of this document, a new version number has to be allocated to refer to the new specification. The version number is carried inside the 'Version' attribute, as described in Section 4, the numbering scheme MUST follow Section 1.2, and rules for extensibility are defined in Section 12.
新PSKC版本：每当需要定义本文件的新版本时，必须分配新版本号以参考新规范。版本号包含在“版本”属性中，如第4节所述，编号方案必须遵循第1.2节，扩展性规则在第12节中定义。
New XML Elements: The usage of the XML schema and the available extension points allows new XML elements to be added. Depending on the type of XML element, different ways for extensibility are offered. In some places, the <Extensions> element can be used and elsewhere the "<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>" XML extension point is utilized.
新的XML元素：XML模式和可用扩展点的使用允许添加新的XML元素。根据XML元素的类型，提供了不同的扩展方式。在某些地方，可以使用<Extensions>元素，而在其他地方则使用“<xs:anynamespace=“##other”processContents=“lax”minOccurs=“0”maxocurs=“unbounded”/>”XML扩展点。
New XML Attributes: The XML schema allows new XML attributes to be added where XML extension points have been defined (see "<xs: anyAttribute namespace="##other"/>" in Section 11).
新的XML属性：XML模式允许在定义了XML扩展点的位置添加新的XML属性（请参阅第11节中的“<xs:anyAttribute namespace=“##其他”/>”。
New PSKC Algorithm Profiles: This document defines two PSKC algorithm profiles, see Section 10. The following informational document describes additional profiles [PSKC-ALGORITHM-PROFILES]. Further PSKC algorithm profiles can be registered as described in Section 12.4.
新的PSKC算法配置文件：本文档定义了两个PSKC算法配置文件，请参见第10节。以下信息性文档介绍了其他配置文件[PSKC-ALGORITHM-profiles]。如第12.4节所述，可注册其他PSKC算法配置文件。
Algorithm URIs: Section 6 defines how keys and related data can be protected. A number of algorithms can be used. New algorithms can be used by pointing to a new algorithm URI.
算法URI：第6节定义了如何保护密钥和相关数据。可以使用许多算法。可以通过指向新算法URI来使用新算法。
Policy: Section 5 defines policies that can be attached to a key and keying-related data. The <Policy> element is one such item that allows implementers to restrict the use of the key to certain functions, such as "OTP usage only". Further values may be registered as described in Section 12.
策略：第5节定义了可以附加到密钥和密钥相关数据的策略。<Policy>元素就是这样一个项目，它允许实现者将密钥的使用限制在某些功能上，例如“仅限OTP使用”。如第12节所述，可注册其他值。
Common Name: HOTP
通用名称：HOTP
Class: OTP
类别：OTP
URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp
URI: urn:ietf:params:xml:ns:keyprov:pskc:hotp
Algorithm Definition: [HOTP]
算法定义：[HOTP]
Identifier Definition: (this RFC)
标识符定义：（此RFC）
Registrant Contact: IESG
注册联系人：IESG
Deprecated: FALSE
不推荐：FALSE
Profiling:
剖析：
The <KeyPackage> element MUST be present and the <ResponseFormat> element, which is a child element of the <AlgorithmParameters> element, MUST be used to indicate the OTP length and the value format.
<KeyPackage>元素必须存在，并且<ResponseFormat>元素（它是<AlgorithmParameters>元素的子元素）必须用于指示OTP长度和值格式。
The <Counter> element (see Section 4.1) MUST be provided as metadata for the key.
<Counter>元素（见第4.1节）必须作为密钥的元数据提供。
The following additional constraints apply:
以下附加约束适用：
+ The value of the <Secret> element MUST contain key material with a length of at least 16 octets (128 bits), if it is present.
+ <Secret>元素的值必须包含长度至少为16个八位字节（128位）的密钥材料（如果存在）。
+ The <ResponseFormat> element MUST have the 'Format' attribute set to "DECIMAL", and the 'Length' attribute MUST indicate a length value between 6 and 9 (inclusive).
+ <ResponseFormat>元素的“Format”属性必须设置为“DECIMAL”，而“Length”属性必须指示介于6和9（包括6和9）之间的长度值。
+ The <PINPolicy> element MAY be present, but the 'PINUsageMode' attribute cannot be set to "Algorithmic".
+ <PINPolicy>元素可能存在，但不能将“PINUsageMode”属性设置为“Algorithmic”。
An example can be found in Figure 3.
图3给出了一个示例。
Common Name: PIN
通用名称：PIN
Class: Symmetric static credential comparison
类：对称静态凭据比较
URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
URI: urn:ietf:params:xml:ns:keyprov:pskc:pin
Algorithm Definition: (this RFC) Section 5.1
算法定义：（本RFC）第5.1节
Identifier Definition (this RFC)
标识符定义（此RFC）
Registrant Contact: IESG
注册联系人：IESG
Deprecated: FALSE
不推荐：FALSE
Profiling:
剖析：
The <Usage> element MAY be present, but no attribute of the <Usage> element is required. The <ResponseFormat> element MAY be used to indicate the PIN value format.
<Usage>元素可能存在，但不需要<Usage>元素的属性。<ResponseFormat>元素可用于指示PIN值格式。
The <Secret> element (see Section 4.1) MUST be provided.
必须提供<Secret>元素（见第4.1节）。
See the example in Figure 5
请参见图5中的示例
This section defines the XML schema for PSKC.
本节定义了PSKC的XML模式。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:complexType name="KeyContainerType">
<xs:sequence>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="MACMethod"
type="pskc:MACMethodType" minOccurs="0"/>
<xs:element name="KeyPackage"
type="pskc:KeyPackageType" maxOccurs="unbounded"/>
<xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version"
type="pskc:VersionType" use="required"/>
<xs:attribute name="Id"
type="xs:ID" use="optional"/>
</xs:complexType>
<xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:pskc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:complexType name="KeyContainerType">
<xs:sequence>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="MACMethod"
type="pskc:MACMethodType" minOccurs="0"/>
<xs:element name="KeyPackage"
type="pskc:KeyPackageType" maxOccurs="unbounded"/>
<xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version"
type="pskc:VersionType" use="required"/>
<xs:attribute name="Id"
type="xs:ID" use="optional"/>
</xs:complexType>
<xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="KeyType">
<xs:sequence>
<xs:element name="Issuer"
type="xs:string" minOccurs="0"/>
<xs:element name="AlgorithmParameters"
type="pskc:AlgorithmParametersType"
minOccurs="0"/>
<xs:element name="KeyProfileId"
type="xs:string" minOccurs="0"/>
<xs:element name="KeyReference"
type="xs:string" minOccurs="0"/>
<xs:element name="FriendlyName"
type="xs:string" minOccurs="0"/>
<xs:element name="Data"
type="pskc:KeyDataType" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Policy"
type="pskc:PolicyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Id"
type="xs:string" use="required"/>
<xs:attribute name="Algorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="KeyUsage"
type="pskc:KeyUsageType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="NumberOfTransactions"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyDataType">
<xs:sequence>
</xs:simpleType>
<xs:complexType name="KeyType">
<xs:sequence>
<xs:element name="Issuer"
type="xs:string" minOccurs="0"/>
<xs:element name="AlgorithmParameters"
type="pskc:AlgorithmParametersType"
minOccurs="0"/>
<xs:element name="KeyProfileId"
type="xs:string" minOccurs="0"/>
<xs:element name="KeyReference"
type="xs:string" minOccurs="0"/>
<xs:element name="FriendlyName"
type="xs:string" minOccurs="0"/>
<xs:element name="Data"
type="pskc:KeyDataType" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Policy"
type="pskc:PolicyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Id"
type="xs:string" use="required"/>
<xs:attribute name="Algorithm"
type="pskc:KeyAlgorithmType" use="optional"/>
</xs:complexType>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="PINPolicy"
type="pskc:PINPolicyType" minOccurs="0"/>
<xs:element name="KeyUsage"
type="pskc:KeyUsageType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="NumberOfTransactions"
type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:any namespace="##other"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyDataType">
<xs:sequence>
<xs:element name="Secret"
type="pskc:binaryDataType" minOccurs="0"/>
<xs:element name="Counter"
type="pskc:longDataType" minOccurs="0"/>
<xs:element name="Time"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeInterval"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeDrift"
type="pskc:intDataType" minOccurs="0"/>
<xs:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="binaryDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:base64Binary"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="intDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:int"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="stringDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:string"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
<xs:element name="Secret"
type="pskc:binaryDataType" minOccurs="0"/>
<xs:element name="Counter"
type="pskc:longDataType" minOccurs="0"/>
<xs:element name="Time"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeInterval"
type="pskc:intDataType" minOccurs="0"/>
<xs:element name="TimeDrift"
type="pskc:intDataType" minOccurs="0"/>
<xs:any namespace="##other"
processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="binaryDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue"
type="xs:base64Binary"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="intDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:int"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="stringDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:string"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="longDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:long"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PINPolicyType">
<xs:attribute name="PINKeyId"
type="xs:string" use="optional"/>
<xs:attribute name="PINUsageMode"
type="pskc:PINUsageModeType"/>
<xs:attribute name="MaxFailedAttempts"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MinLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MaxLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="PINEncoding"
type="pskc:ValueFormatType" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<xs:simpleType name="PINUsageModeType">
<xs:restriction base="xs:string">
<xs:enumeration value="Local"/>
<xs:enumeration value="Prepend"/>
<xs:enumeration value="Append"/>
<xs:enumeration value="Algorithmic"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="KeyUsageType">
<xs:restriction base="xs:string">
<xs:enumeration value="OTP"/>
<xs:enumeration value="CR"/>
<xs:enumeration value="Encrypt"/>
<xs:enumeration value="Integrity"/>
<xs:enumeration value="Verify"/>
<xs:enumeration value="Unlock"/>
<xs:enumeration value="Decrypt"/>
<xs:enumeration value="KeyWrap"/>
<xs:enumeration value="Unwrap"/>
<xs:enumeration value="Derive"/>
<xs:enumeration value="Generate"/>
</xs:complexType>
<xs:complexType name="longDataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:long"/>
<xs:element name="EncryptedValue"
type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PINPolicyType">
<xs:attribute name="PINKeyId"
type="xs:string" use="optional"/>
<xs:attribute name="PINUsageMode"
type="pskc:PINUsageModeType"/>
<xs:attribute name="MaxFailedAttempts"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MinLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="MaxLength"
type="xs:unsignedInt" use="optional"/>
<xs:attribute name="PINEncoding"
type="pskc:ValueFormatType" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
<xs:simpleType name="PINUsageModeType">
<xs:restriction base="xs:string">
<xs:enumeration value="Local"/>
<xs:enumeration value="Prepend"/>
<xs:enumeration value="Append"/>
<xs:enumeration value="Algorithmic"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="KeyUsageType">
<xs:restriction base="xs:string">
<xs:enumeration value="OTP"/>
<xs:enumeration value="CR"/>
<xs:enumeration value="Encrypt"/>
<xs:enumeration value="Integrity"/>
<xs:enumeration value="Verify"/>
<xs:enumeration value="Unlock"/>
<xs:enumeration value="Decrypt"/>
<xs:enumeration value="KeyWrap"/>
<xs:enumeration value="Unwrap"/>
<xs:enumeration value="Derive"/>
<xs:enumeration value="Generate"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeviceInfoType">
<xs:sequence>
<xs:element name="Manufacturer"
type="xs:string" minOccurs="0"/>
<xs:element name="SerialNo"
type="xs:string" minOccurs="0"/>
<xs:element name="Model"
type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo"
type="xs:string" minOccurs="0"/>
<xs:element name="DeviceBinding"
type="xs:string" minOccurs="0"/>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptoModuleInfoType">
<xs:sequence>
<xs:element name="Id" type="xs:string"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyPackageType">
<xs:sequence>
<xs:element name="DeviceInfo"
type="pskc:DeviceInfoType" minOccurs="0"/>
<xs:element name="CryptoModuleInfo"
type="pskc:CryptoModuleInfoType" minOccurs="0"/>
<xs:element name="Key"
type="pskc:KeyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AlgorithmParametersType">
<xs:choice>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeviceInfoType">
<xs:sequence>
<xs:element name="Manufacturer"
type="xs:string" minOccurs="0"/>
<xs:element name="SerialNo"
type="xs:string" minOccurs="0"/>
<xs:element name="Model"
type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo"
type="xs:string" minOccurs="0"/>
<xs:element name="DeviceBinding"
type="xs:string" minOccurs="0"/>
<xs:element name="StartDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="UserId"
type="xs:string" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptoModuleInfoType">
<xs:sequence>
<xs:element name="Id" type="xs:string"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyPackageType">
<xs:sequence>
<xs:element name="DeviceInfo"
type="pskc:DeviceInfoType" minOccurs="0"/>
<xs:element name="CryptoModuleInfo"
type="pskc:CryptoModuleInfoType" minOccurs="0"/>
<xs:element name="Key"
type="pskc:KeyType" minOccurs="0"/>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AlgorithmParametersType">
<xs:choice>
<xs:element name="Suite" type="xs:string" minOccurs="0"/>
<xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Min"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="Max"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="ResponseFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Length"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="ExtensionsType">
<xs:sequence>
<xs:any namespace="##other"
processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="definition"
type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:simpleType name="KeyAlgorithmType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="ValueFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="DECIMAL"/>
<xs:enumeration value="HEXADECIMAL"/>
<xs:enumeration value="ALPHANUMERIC"/>
<xs:enumeration value="BASE64"/>
<xs:enumeration value="BINARY"/>
<xs:element name="Suite" type="xs:string" minOccurs="0"/>
<xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Min"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="Max"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="ResponseFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Encoding"
type="pskc:ValueFormatType"
use="required"/>
<xs:attribute name="Length"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="Extensions"
type="pskc:ExtensionsType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="ExtensionsType">
<xs:sequence>
<xs:any namespace="##other"
processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="definition"
type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:simpleType name="KeyAlgorithmType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="ValueFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="DECIMAL"/>
<xs:enumeration value="HEXADECIMAL"/>
<xs:enumeration value="ALPHANUMERIC"/>
<xs:enumeration value="BASE64"/>
<xs:enumeration value="BINARY"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="MACMethodType">
<xs:sequence>
<xs:choice>
<xs:element name="MACKey"
type="xenc:EncryptedDataType" minOccurs="0"/>
<xs:element name="MACKeyReference"
type="xs:string" minOccurs="0"/>
</xs:choice>
<xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>
</xs:schema>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="MACMethodType">
<xs:sequence>
<xs:choice>
<xs:element name="MACKey"
type="xenc:EncryptedDataType" minOccurs="0"/>
<xs:element name="MACKeyReference"
type="xs:string" minOccurs="0"/>
</xs:choice>
<xs:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>
</xs:schema>
This specification contains the registration of a new media type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].
本规范包含根据RFC 4288[RFC4288]的程序和RFC 3023[RFC3023]中的指南注册新媒体类型。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: pskc+xml
MIME子类型名称：pskc+xml
Required parameters: There is no required parameter.
必需参数：没有必需的参数。
Optional parameters: charset
可选参数：字符集
Indicates the character encoding of enclosed XML.
指示封闭XML的字符编码。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2.
编码注意事项：使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 3023[RFC3023]，第3.2节。
Security considerations: Please refer to Section 13 of RFC 6030.
安全注意事项：请参考RFC 6030第13节。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 6030.
已发布规范：RFC 6030。
Applications which use this media type: This media type is being used as a symmetric key container format for transport and provisioning of symmetric keys (One-Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. As such, it is used for key provisioning systems.
使用此媒体类型的应用程序：此媒体类型用作对称密钥容器格式，用于向不同类型的强身份验证设备传输和提供对称密钥（一次性密码（OTP）共享密钥或对称加密密钥）。因此，它用于密钥供应系统。
Additional information:
其他信息：
Magic Number: None
神奇数字：无
File Extension: .pskcxml
文件扩展名：.pskcxml
Macintosh file type code: 'TEXT'
Macintosh文件类型代码：“文本”
Personal and email address to contact for further information: Philip Hoyer, Philip.Hoyer@actividentity.com
欲了解更多信息，请联系个人和电子邮件地址：Philip Hoyer，Philip。Hoyer@actividentity.com
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: None
使用限制：无
Author: This specification is a work item of the IETF KEYPROV working group, with mailing list address <keyprov@ietf.org>.
作者：本规范是IETF KEYPROV工作组的工作项，具有邮件列表地址<keyprov@ietf.org>.
Change controller: The IESG <iesg@ietf.org>
Change controller: The IESG <iesg@ietf.org>
This section registers an XML schema as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:schema:keyprov:pskc
URI: urn:ietf:params:xml:schema:keyprov:pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com).
注册人联系人：IETF KEYPROV工作组，Philip Hoyer（Philip。Hoyer@actividentity.com).
XML Schema: The XML schema to be registered is contained in Section 11. Its first line is
XML模式：要注册的XML模式包含在第11节中。它的第一行是
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
最后一行是
</xs:schema>
</xs:schema>
This section registers a new XML namespace, "urn:ietf:params:xml:ns:keyprov:pskc", per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册了一个新的XML名称空间“urn:ietf:params:XML:ns:keyprov:pskc”。
URI: urn:ietf:params:xml:ns:keyprov:pskc
URI: urn:ietf:params:xml:ns:keyprov:pskc
Registrant Contact: IETF KEYPROV Working Group, Philip Hoyer (Philip.Hoyer@actividentity.com).
注册人联系人：IETF KEYPROV工作组，Philip Hoyer（Philip。Hoyer@actividentity.com).
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>PSKC Namespace</title>
</head>
<body>
<h1>Namespace for PSKC</h1>
<h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6030.txt">
RFC 6030</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>PSKC Namespace</title>
</head>
<body>
<h1>Namespace for PSKC</h1>
<h2>urn:ietf:params:xml:ns:keyprov:pskc</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6030.txt">
RFC 6030</a>.</p>
</body>
</html>
END
IANA has created a registry for PSKC algorithm profiles in accordance with the principles set out in RFC 5226 [RFC5226].
IANA已根据RFC 5226[RFC5226]中规定的原则为PSKC算法配置文件创建了一个注册表。
As part of this registry, IANA maintains the following information:
作为本登记册的一部分，IANA保留以下信息：
Common Name: The name by which the PSKC algorithm profile is generally referred.
通用名称：PSKC算法配置文件通常引用的名称。
Class: The type of PSKC algorithm profile registry entry being created, such as encryption, Message Authentication Code (MAC), One-Time Password (OTP), Digest.
类：正在创建的PSKC算法配置文件注册表项的类型，例如加密、消息身份验证码（MAC）、一次性密码（OTP）、摘要。
URI: The URI to be used to identify the profile.
URI：用于标识配置文件的URI。
Identifier Definition: IANA will add a pointer to the specification containing information about the PSKC algorithm profile registration.
标识符定义：IANA将添加一个指向规范的指针，该规范包含有关PSKC算法配置文件注册的信息。
Algorithm Definition: A reference to the stable document in which the algorithm being used with the PSKC is defined.
算法定义：对稳定文档的引用，其中定义了与PSKC一起使用的算法。
Registrant Contact: Contact information about the party submitting the registration request.
注册人联系人：提交注册请求的一方的联系信息。
Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE.
已弃用：如果此条目已根据专家批准弃用，并且不应在任何新实施中使用，则为TRUE。否则，错误。
PSKC Profiling: Information about PSKC XML elements and attributes being used (or not) with this specific profile of PSKC.
PSKC配置文件：有关PSKC XML元素和属性正在（或未）与此特定PSKC配置文件一起使用的信息。
PSKC algorithm profile identifier registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
PSKC算法配置文件标识符注册应符合RFC 5226[RFC5226]要求的规范。只能在专家批准的基础上提供更新。根据专家批准，可以将条目标记为“已弃用”。IESG将任命一名指定专家。
IANA has added two initial values to the registry based on the algorithm profiles described in Section 10.
IANA根据第10节中描述的算法配置文件向注册表添加了两个初始值。
IANA has created a registry for PSKC version numbers. The registry has the following structure:
IANA已经为PSKC版本号创建了一个注册表。注册表具有以下结构：
PSKC Version | Specification
+---------------------------+----------------
| 1.0 | RFC 6030
PSKC Version | Specification
+---------------------------+----------------
| 1.0 | RFC 6030
Standards action is required to define new versions of PSKC. It is not envisioned to deprecate, delete, or modify existing PSKC versions.
需要标准行动来定义PSKC的新版本。不打算弃用、删除或修改现有的PSKC版本。
IANA has created a registry for key usage. A description of the <KeyUsage> element can be found in Section 5.
IANA已经为密钥使用创建了一个注册表。<KeyUsage>元素的描述见第5节。
As part of this registry IANA will maintain the following information:
作为本登记册的一部分，IANA将保存以下信息：
Key Usage: The identifier of the Key Usage.
密钥用法：密钥用法的标识符。
Specification: IANA will add a pointer to the specification containing information about the semantics of a new Key Usage registration.
规范：IANA将添加一个指向规范的指针，该规范包含有关新密钥使用注册语义的信息。
Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE.
已弃用：如果此条目已根据专家批准弃用，并且不应在任何新实施中使用，则为TRUE。否则，错误。
IANA has added these initial values to the registry:
IANA已将这些初始值添加到注册表中：
Key Usage | Specification | Deprecated
+---------------+------------------------------+-----------
| OTP | [Section 5 of this document] | FALSE
| CR | [Section 5 of this document] | FALSE
| Encrypt | [Section 5 of this document] | FALSE
| Integrity | [Section 5 of this document] | FALSE
| Verify | [Section 5 of this document] | FALSE
| Unlock | [Section 5 of this document] | FALSE
| Decrypt | [Section 5 of this document] | FALSE
| KeyWrap | [Section 5 of this document] | FALSE
| Unwrap | [Section 5 of this document] | FALSE
| Derive | [Section 5 of this document] | FALSE
| Generate | [Section 5 of this document] | FALSE
+---------------+------------------------------+-----------
Key Usage | Specification | Deprecated
+---------------+------------------------------+-----------
| OTP | [Section 5 of this document] | FALSE
| CR | [Section 5 of this document] | FALSE
| Encrypt | [Section 5 of this document] | FALSE
| Integrity | [Section 5 of this document] | FALSE
| Verify | [Section 5 of this document] | FALSE
| Unlock | [Section 5 of this document] | FALSE
| Decrypt | [Section 5 of this document] | FALSE
| KeyWrap | [Section 5 of this document] | FALSE
| Unwrap | [Section 5 of this document] | FALSE
| Derive | [Section 5 of this document] | FALSE
| Generate | [Section 5 of this document] | FALSE
+---------------+------------------------------+-----------
Key Usage Registry registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Expert Review is required to define new Key Usage values. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". A designated expert will be appointed by the IESG.
密钥使用注册应符合RFC 5226[RFC5226]要求的规范。需要专家评审来定义新的关键使用值。只能在专家批准的基础上提供更新。根据专家批准，可以将条目标记为“已弃用”。IESG将任命一名指定专家。
The portable symmetric key container (PSKC) carries sensitive information (e.g., cryptographic keys) and may be transported across the boundaries of one secure perimeter to another. For example, a container residing within the secure perimeter of a back-end provisioning server in a secure room may be transported across the Internet to an end-user device attached to a personal computer. This means that special care MUST be taken to ensure the confidentiality, integrity, and authenticity of the information contained within.
便携式对称密钥容器（PSKC）携带敏感信息（例如，加密密钥），并且可以跨越一个安全周界的边界传输到另一个安全周界。例如，驻留在安全房间中后端供应服务器的安全周界内的容器可以通过因特网传输到连接到个人计算机的最终用户设备。这意味着必须特别小心，以确保其中包含的信息的机密性、完整性和真实性。
By design, the container allows two main approaches to guaranteeing the confidentiality of the information it contains while transported.
根据设计，容器允许两种主要方法来保证其在传输时所包含信息的机密性。
First, the container key data payload may be encrypted.
首先，可以对容器密钥数据有效载荷进行加密。
In this case, no transport layer security is required. However, standard security best practices apply when selecting the strength of the cryptographic algorithm for key data payload encryption. A symmetric cryptographic cipher SHOULD be used -- the longer the cryptographic key, the stronger the protection. Please see Section 6.1 for recommendations of key data payload protection using symmetric cryptographic ciphers. In cases where the exchange of key encryption keys between the sender and the receiver is not possible, asymmetric encryption of the key data payload may be employed, see Section 6.3. Similar to symmetric key cryptography, the stronger the asymmetric key, the more secure the protection.
在这种情况下，不需要传输层安全性。但是，在为密钥数据有效负载加密选择加密算法的强度时，标准安全最佳做法适用。应该使用对称密码——加密密钥越长，保护越强。请参阅第6.1节，了解使用对称密码保护关键数据有效负载的建议。在发送方和接收方之间无法交换密钥加密密钥的情况下，可采用密钥数据有效载荷的非对称加密，见第6.3节。与对称密钥加密类似，非对称密钥越强，保护就越安全。
If the key data payload is encrypted with a method that uses one of the password-based encryption methods (PBE methods) detailed in Section 6.2, the key data payload may be subjected to password dictionary attacks to break the encryption password and recover the information. Standard security best practices for selection of strong encryption passwords apply.
如果使用第6.2节详述的基于密码的加密方法（PBE方法）之一对密钥数据有效载荷进行加密，则密钥数据有效载荷可能会受到密码字典攻击，以破坏加密密码并恢复信息。选择强加密密码的标准安全最佳做法适用。
Additionally, it is strongly RECOMMENDED that practical implementations use PBESalt and PBEIterationCount when PBE encryption is used. A different PBESalt value per PSKC SHOULD be used for best protection.
此外，强烈建议实际实现在使用PBE加密时使用PBESalt和PBEIterationCount。每个PSKC应使用不同的PBESalt值以获得最佳保护。
The second approach to protecting the confidentiality of the key data is based on using lower-layer security mechanisms (e.g., [TLS], [IPsec]). The secure connection established between the source secure perimeter (the provisioning server from the example above) and the target perimeter (the device attached to the end-user computer) utilizes encryption to protect the messages that travel across that connection. No key data payload encryption is required in this mode. Secure connections that encrypt and digest each message provide an extra measure of security.
第二种保护密钥数据机密性的方法是基于使用较低层的安全机制（例如，[TLS]、[IPsec]）。在源安全周界（上例中的供应服务器）和目标周界（连接到最终用户计算机的设备）之间建立的安全连接利用加密来保护通过该连接传输的消息。在此模式下不需要密钥数据有效负载加密。加密和摘要每条消息的安全连接提供了额外的安全措施。
Because of the fact that the plaintext PSKC is protected only by the transport layer security, practical implementation MUST ensure protection against man-in-the-middle attacks. Authenticating the secure channel endpoints is critically important for eliminating intruders that may compromise the confidentiality of the PSKC.
由于明文PSKC仅受传输层安全保护，因此实际实现必须确保防止中间人攻击。验证安全通道端点对于消除可能危及PSKC机密性的入侵者至关重要。
The PSKC provides means to guarantee the integrity of the information it contains through the use of digital signatures. It is RECOMMENDED that for best security practices, the digital signature of the container encompasses the entire PSKC. This provides assurances for the integrity of all attributes. It also allows verification of the integrity of a given PSKC even after the container is delivered through the communication channel to the target perimeter and channel message integrity check is no longer possible.
PSKC提供了通过使用数字签名保证其所包含信息完整性的方法。对于最佳安全实践，建议容器的数字签名包含整个PSKC。这为所有属性的完整性提供了保证。它还允许验证给定PSKC的完整性，即使在容器通过通信通道交付到目标周边并且通道消息完整性检查不再可行之后也是如此。
The digital signature of the PSKC is the primary way of showing its authenticity. The recipient of the container SHOULD use the public key associated with the signature to assert the authenticity of the sender by tracing it back to a pre-loaded public key or certificate. Note that the digital signature of the PSKC can be checked even after the container has been delivered through the secure channel of communication.
PSKC的数字签名是显示其真实性的主要方式。容器的接收方应使用与签名关联的公钥，通过将其追溯到预加载的公钥或证书来断言发送方的真实性。请注意，即使容器已通过安全通信通道交付，也可以检查PSKC的数字签名。
Authenticity guarantee may be provided by [TLS] or [IPsec]. However, no authenticity verification is possible once the container is delivered at the recipient end. Since the TLS endpoints could differ from the key provisioning endpoints, this solution is weaker than the previous solution that relies on a digital signature of the PSKC.
真实性保证可由[TLS]或[IPsec]提供。但是，一旦容器在接收方端交付，就不可能进行真实性验证。由于TLS端点可能不同于密钥供应端点，因此此解决方案比以前依赖于PSKC数字签名的解决方案更弱。
We would like Hannes Tschofenig for his text contributions to this document.
我们希望Hannes Tschofenig为本文件提供文本。
The authors of this document would like to thank the following people for their feedback: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart Bajaj, Stu Vaeth, Kevin Lewis, Philip Hallam-Baker, Andrea Doherty, Magnus Nystrom, Tim Moses, Anders Rundgren, Sean Turner, and especially Robert Philpott.
本文件的作者要感谢以下人士的反馈：Apostol Vassilev、Shuh Chang、Jon Martinson、Siddhart Bajaj、Stu Vaeth、Kevin Lewis、Philip Hallam Baker、Andrea Doherty、Magnus Nystrom、Tim Moses、Anders Rundgren、Sean Turner，尤其是Robert Philpott。
We would like to thank Sean Turner for his review in January 2009. We would also like to thank Anders Rundgren for triggering the discussion regarding to the selection of encryption algorithms (KW-AES-128 vs. AES-128-CBC) and his input on the keyed message digest computation.
我们要感谢肖恩·特纳（Sean Turner）在2009年1月发表的评论。我们还要感谢Anders Rundgren引发了关于加密算法选择（KW-AES-128 vs.AES-128-CBC）的讨论，以及他对密钥消息摘要计算的投入。
This work is based on earlier work by the members of OATH (Initiative for Open AuTHentication), see [OATH], to specify a format that can be freely distributed to the technical community.
这项工作是基于誓言（开放认证倡议）成员的早期工作，参见[誓言]，以指定可自由分发给技术社区的格式。
[FIPS197] National Institute of Standards, "FIPS Pub 197: Advanced Encryption Standard (AES)", November 2001.
[FIPS197]国家标准研究所，“FIPS Pub 197:高级加密标准（AES）”，2001年11月。
[HOTP] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[HOTP]M'Raihi，D.，Bellare，M.，Hoornaert，F.，Naccache，D.，和O.Ranen，“HOTP：基于HMAC的一次性密码算法”，RFC 42262005年12月。
[IANAPENREG] IANA, "Private Enterprise Numbers", <http://www.iana.org>.
[IANAPENREG]IANA，“私营企业编号”<http://www.iana.org>.
[ISOIEC7812] ISO, "ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system", October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812]ISO，“ISO/IEC 7812-1:2006识别卡——发卡机构的识别——第1部分：编号系统”，2006年10月<http://www.iso.org/iso/iso_catalogue/ catalog\u tc/catalog\u detail.htm？csnumber=39698>。
[OATHMAN] OATH, "List of OATH Manufacturer Prefixes (omp)", April 2009, <http://www.openauthentication.org/oath-id/prefixes/>.
[OATHMAN]宣誓，“宣誓制造商前缀列表（omp）”，2009年4月<http://www.openauthentication.org/oath-id/prefixes/>.
[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography Standard", Version 2.0, March 1999, <http://www.rsasecurity.com/rsalabs/pkcs/>.
[PKCS5]RSA实验室，“PKCS#5：基于密码的加密标准”，2.0版，1999年3月<http://www.rsasecurity.com/rsalabs/pkcs/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[RFC5649]Housley，R.和M.Dworkin，“带填充算法的高级加密标准（AES）密钥封装”，RFC 5649，2009年9月。
[SP800-67] National Institute of Standards, "NIST Special Publication 800-67 Version 1.1: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", NIST Special Publication 800-67, May 2008.
[SP800-67]国家标准研究所，“NIST特别出版物800-67第1.1版：三重数据加密算法（TDEA）分组密码建议”，NIST特别出版物800-67，2008年5月。
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028]Malhotra，A.和P.Biron，“XML模式第2部分：数据类型第二版”，万维网联盟建议REC-xmlschema-2-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XMLDSIG] Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[XMLDSIG]Solo，D.，Reagle，J.，和D.Eastlake，“XML签名语法和处理”，万维网联盟第一版REC-XMLDSIG-core-20020212，2002年2月<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLENC]Eastlake，D.，“XML加密语法和处理”，《W3C建议》，2002年12月<http://www.w3.org/TR/xmlenc-core/>.
[XMLENC11] Reagle, J. and D. Eastlake, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium WD WD-xmlenc-core1-20090730, July 2009, <http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>.
[XMLENC11]Reagle，J.和D.Eastlake，“XML加密语法和处理版本1.1”，万维网联盟WD WD-xmlenc-core1-20090730，2009年7月<http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730>.
[CAP] MasterCard International, "Chip Authentication Program Functional Architecture", September 2004.
[CAP]万事达卡国际，“芯片认证程序功能架构”，2004年9月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "NIST Special Publication 800-57, Recommendation for Key Management Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[NIST 800-57]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“NIST特别出版物800-57，关键管理建议第1部分：概述（修订）”，NIST特别出版物800-57，2007年3月。
[OATH] "Initiative for Open AuTHentication", <http://www.openauthentication.org>.
[誓言]“开放认证倡议”<http://www.openauthentication.org>.
[PSKC-ALGORITHM-PROFILES] Hoyer, P., Pei, M., Machani, S., and A. Doherty, "Additional Portable Symmetric Key Container (PSKC) Algorithm Profiles", Work in Progress, May 2010.
[PSKC-ALGORITHM-PROFILES]Hoyer，P.，Pei，M.，Machani，S.，和A.Doherty，“附加便携式对称密钥容器（PSKC）算法配置文件”，正在进行的工作，2010年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[XMLNS]Hollander，D.，Bray，T.，和A.Layman，“XML中的名称空间”，万维网联盟第一版REC-XML-names-19990114，1999年1月<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
This section describes a comprehensive list of use cases that inspired the development of this specification. These requirements were used to derive the primary requirement that drove the design. These requirements are covered in the next section.
本节描述了激发本规范开发灵感的用例的综合列表。这些需求用于导出驱动设计的主要需求。下一节将介绍这些要求。
These use cases also help in understanding the applicability of this specification to real-world situations.
这些用例也有助于理解本规范对实际情况的适用性。
This section describes the use cases related to provisioning the keys using an online provisioning protocol.
本节描述与使用在线设置协议设置密钥相关的用例。
For example, a mobile device user wants to obtain a symmetric key for use with a cryptographic module on the device. The cryptographic module from vendor A initiates the provisioning process against a provisioning system from vendor B using a standards-based provisioning protocol. The provisioning entity delivers one or more keys in a standard format that can be processed by the mobile device.
例如，移动设备用户希望获得对称密钥，以便与设备上的加密模块一起使用。供应商A的加密模块使用基于标准的供应协议针对供应商B的供应系统启动供应过程。供应实体以标准格式交付一个或多个密钥，移动设备可以处理这些密钥。
For example, in a variation of the above, instead of the user's mobile phone, a key is provisioned in the user's soft token application on a laptop using a network-based online protocol. As before, the provisioning system delivers a key in a standard format that can be processed by the soft token on the PC.
例如，在上述的变体中，使用基于网络的在线协议在膝上型计算机上的用户的软令牌应用中提供密钥，而不是用户的移动电话。与以前一样，供应系统以标准格式提供密钥，可由PC上的软令牌处理。
For example, the end user or the key issuer wants to update or configure an existing key in the cryptographic module and requests a replacement key container. The container may or may not include a new key and may include new or updated key attributes such as a new counter value in HOTP key case, a modified response format or length, a new friendly name, etc.
例如，最终用户或密钥颁发者希望更新或配置加密模块中的现有密钥，并请求替换密钥容器。容器可以包括也可以不包括新密钥，并且可以包括新的或更新的密钥属性，例如HOTP密钥大小写中的新计数器值、修改的响应格式或长度、新的友好名称等。
A.1.2. Transport of Keys from Cryptographic Module to Cryptographic Module
A.1.2. 密钥从加密模块传输到加密模块
For example, a user wants to transport a key from one cryptographic module to another. There may be two cryptographic modules, one on a computer and one on a mobile phone, and the user wants to transport a key from the computer to the mobile phone. The user can export the key and related data in a standard format for input into the other cryptographic module.
例如，用户希望将密钥从一个加密模块传输到另一个加密模块。可能有两个密码模块，一个在计算机上，一个在移动电话上，用户希望将密钥从计算机传输到移动电话。用户可以以标准格式导出密钥和相关数据，以便输入到其他加密模块中。
For example, a user wants to activate and use a new key and related data against a validation system that is not aware of this key. This key may be embedded in the cryptographic module (e.g., a Secure Digital (SD) card, USB drive) that the user has purchased at the local electronics retailer. Along with the cryptographic module, the user may get the key on a CD or a floppy in a standard format. The user can now upload via a secure online channel or import this key and related data into the new validation system and start using the key.
例如，用户希望针对不知道该密钥的验证系统激活并使用新密钥和相关数据。该密钥可嵌入用户在当地电子产品零售商处购买的加密模块（例如，安全数字（SD）卡、USB驱动器）中。与加密模块一起，用户可以获得标准格式的CD或软盘上的密钥。用户现在可以通过安全的在线渠道上传或将此密钥和相关数据导入新的验证系统，并开始使用密钥。
From time to time, a key management system may be required to import or export keys in bulk from one entity to another.
有时，可能需要密钥管理系统将密钥从一个实体批量导入或导出到另一个实体。
For example, instead of importing keys from a manufacturer using a file, a validation server may download the keys using an online protocol. The keys can be downloaded in a standard format that can be processed by a validation system.
例如，验证服务器可以使用在线协议下载密钥，而不是使用文件从制造商导入密钥。密钥可以以标准格式下载，并由验证系统进行处理。
For example, in a variation of the above, an Over-The-Air (OTA) key provisioning gateway that provisions keys to mobile phones may obtain key material from a key issuer using an online protocol. The keys are delivered in a standard format that can be processed by the key provisioning gateway and subsequently sent to the mobile phone of the end user.
例如，在上述的一种变体中，向移动电话提供密钥的空中（OTA）密钥提供网关可以使用在线协议从密钥颁发者获得密钥材料。密钥以标准格式交付，可由密钥供应网关处理，随后发送至最终用户的移动电话。
This section describes the use cases relating to offline transport of keys from one system to another, using some form of export and import model.
本节介绍使用某种形式的导出和导入模型将密钥从一个系统脱机传输到另一个系统的相关用例。
For example, cryptographic modules, such as OTP authentication tokens, may have their symmetric keys initialized during the manufacturing process in bulk, requiring copies of the keys and algorithm data to be loaded into the authentication system through a file on portable media. The manufacturer provides the keys and related data in the form of a file containing records in standard format, typically on a CD. Note that the token manufacturer and the vendor for the validation system may be the same or different. Some crypto modules will allow local PIN management (the device will have a PIN pad); hence, random initial PINs set at manufacturing should be transmitted together with the respective keys they protect.
例如，诸如OTP认证令牌之类的密码模块可在批量制造过程中初始化其对称密钥，从而要求通过便携式介质上的文件将密钥和算法数据的副本加载到认证系统中。制造商以文件的形式提供密钥和相关数据，该文件包含标准格式的记录，通常在CD上。请注意，验证系统的令牌制造商和供应商可能相同或不同。一些加密模块将允许本地PIN管理（设备将具有PIN焊盘）；因此，在制造时设置的随机初始引脚应与其保护的相应密钥一起传输。
For example, an enterprise wants to port keys and related data from an existing validation system A into a different validation system B. The existing validation system provides the enterprise with a functionality that enables export of keys and related data (e.g., for OTP authentication tokens) in a standard format. Since the OTP tokens are in the standard format, the enterprise can import the token records into the new validation system B and start using the existing tokens. Note that the vendors for the two validation systems may be the same or different.
例如，企业希望将现有验证系统A中的密钥和相关数据移植到不同的验证系统B中。现有验证系统为企业提供了一种功能，允许以标准格式导出密钥和相关数据（例如，用于OTP身份验证令牌）。由于OTP令牌采用标准格式，企业可以将令牌记录导入新的验证系统B，并开始使用现有令牌。请注意，两个验证系统的供应商可能相同或不同。
This section outlines the most relevant requirements that are the basis of this work. Several of the requirements were derived from use cases described above.
本节概述了作为本工作基础的最相关要求。一些需求是从上面描述的用例中派生出来的。
R1: The format MUST support the transport of multiple types of symmetric keys and related attributes for algorithms including HOTP, other OTP, Challenge/Response, etc.
R1：格式必须支持传输多种类型的对称密钥和算法的相关属性，包括HOTP、其他OTP、质询/响应等。
R2: The format MUST handle the symmetric key itself as well of attributes that are typically associated with symmetric keys. Some of these attributes may be
R2：格式必须处理对称密钥本身以及通常与对称密钥关联的属性。其中一些属性可能是
* Unique Key Identifier
* 唯一密钥标识符
* Issuer information
* 发行人信息
* Algorithm ID
* 算法ID
* Algorithm mode
* 算法模式
* Issuer Name
* 发行人名字
* Key friendly name
* 关键字友好名称
* Event counter value (moving factor for OTP algorithms)
* 事件计数器值（OTP算法的移动因子）
* Time value
* 时间价值
R3: The format SHOULD support both offline and online scenarios. That is, it should be serializable to a file as well as it should be possible to use this format in online provisioning protocols.
R3：该格式应支持离线和在线场景。也就是说，它应该可以序列化为文件，并且应该可以在在线资源调配协议中使用这种格式。
R4: The format SHOULD allow bulk representation of symmetric keys.
R4：该格式应允许对称密钥的批量表示。
R5: The format SHOULD allow bulk representation of PINs related to specific keys.
R5：该格式应允许批量表示与特定键相关的管脚。
R6: The format SHOULD be portable to various platforms. Furthermore, it SHOULD be computationally efficient to process.
R6：该格式应可移植到各种平台。此外，它应该是计算效率的过程。
R7: The format MUST provide an appropriate level of security in terms of data encryption and data integrity.
R7：格式必须在数据加密和数据完整性方面提供适当级别的安全性。
R8: For online scenarios, the format SHOULD NOT rely on transport layer security (e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS)) for core security requirements.
R8：对于在线场景，格式不应依赖传输层安全性（例如，安全套接字层/传输层安全性（SSL/TLS））来满足核心安全要求。
R9: The format SHOULD be extensible. It SHOULD enable extension points allowing vendors to specify additional attributes in the future.
R9：格式应该是可扩展的。它应该启用扩展点，允许供应商在将来指定其他属性。
R10: The format SHOULD allow for distribution of key derivation data without the actual symmetric key itself. This is to support symmetric key management schemes that rely on key derivation algorithms based on a pre-placed master key. The key derivation data typically consists of a reference to the key, rather than the key value itself.
R10：该格式应允许在不使用实际对称密钥的情况下分发密钥派生数据。这是为了支持依赖于基于预先放置的主密钥的密钥派生算法的对称密钥管理方案。密钥派生数据通常包括对密钥的引用，而不是密钥值本身。
R11: The format SHOULD allow for additional life cycle management operations such as counter resynchronization. Such processes require confidentiality between client and server, thus could use a common secure container format, without the transfer of key material.
R11：该格式应允许额外的生命周期管理操作，如计数器重新同步。这样的过程需要客户机和服务器之间的保密性，因此可以使用通用的安全容器格式，而无需传输密钥材料。
R12: The format MUST support the use of pre-shared symmetric keys to ensure confidentiality of sensitive data elements.
R12：格式必须支持使用预共享对称密钥，以确保敏感数据元素的机密性。
R13: The format MUST support a password-based encryption (PBE) [PKCS5] scheme to ensure security of sensitive data elements. This is a widely used method for various provisioning scenarios.
R13:格式必须支持基于密码的加密（PBE）[PKCS5]方案，以确保敏感数据元素的安全性。这是一种广泛用于各种资源调配场景的方法。
R14: The format SHOULD support asymmetric encryption algorithms such as RSA to ensure end-to-end security of sensitive data elements. This is to support scenarios where a pre-set shared key encryption key is difficult to use.
R14：该格式应支持RSA等非对称加密算法，以确保敏感数据元素的端到端安全。这是为了支持预设共享密钥加密密钥难以使用的场景。
Authors' Addresses
作者地址
Philip Hoyer ActivIdentity, Inc. 117 Waterloo Road London, SE1 8UL UK
Philip Hoyer ActivIdentity，Inc.英国伦敦滑铁卢路117号
Phone: +44 (0) 20 7960 0220
EMail: phoyer@actividentity.com
Phone: +44 (0) 20 7960 0220
EMail: phoyer@actividentity.com
Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
美国加利福尼亚州米德尔菲尔德路东487号，加利福尼亚州山景城，贝聿铭公司，邮编94043
Phone: +1 650 426 5173
EMail: mpei@verisign.com
Phone: +1 650 426 5173
EMail: mpei@verisign.com
Salah Machani Diversinet, Inc. 2225 Sheppard Avenue East Suite 1801 Toronto, Ontario M2J 5C2 Canada
Salah Machani Diversinet，Inc.加拿大安大略省多伦多谢泼德大道东2225号1801室M2J 5C2
Phone: +1 416 756 2324 Ext. 321
EMail: smachani@diversinet.com
Phone: +1 416 756 2324 Ext. 321
EMail: smachani@diversinet.com