Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 8295 sn3rd
Category: Standards Track January 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 8295 sn3rd
Category: Standards Track January 2018
ISSN: 2070-1721
EST (Enrollment over Secure Transport) Extensions
EST（通过安全传输注册）扩展
Abstract
摘要
The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.
EST（通过安全传输注册）协议定义了众所周知的URI（统一资源标识符）-/.Well-Known/EST，以及客户端用于PKI（公钥基础设施）服务的许多其他路径组件，即证书注册（例如/simpleenroll）。本文档将许多其他PKI服务定义为额外的路径组件——具体来说，固件和信任锚以及对称、非对称和加密密钥。本文档还指定了PAL（软件包可用性列表），这是一个XML（可扩展标记语言）文件或JSON（JavaScript对象表示法）对象，客户机使用它来检索可用和授权的软件包。本文档扩展了EST服务器路径组件以提供这些附加服务。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8295.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8295.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Definitions ................................................6
1.2. Authentication and Authorization ...........................7
1.3. TLS Cipher Suites ..........................................7
1.4. URI Configuration ..........................................7
1.5. Message Types ..............................................8
1.6. Key Words .................................................10
2. Locate Available Packages ......................................10
2.1. PAL Format ................................................12
2.1.1. PAL Package Types ..................................14
2.1.2. PAL XML Schema .....................................19
2.1.3. PAL JSON Object ....................................23
2.2. Request PAL ...............................................23
2.3. Provide PAL ...............................................24
3. Distribute EE Certificates .....................................25
3.1. EE Certificate Request ....................................25
3.2. EE Certificate Response ...................................26
4. Distribute CRLs and ARLs .......................................26
4.1. CRL Request ...............................................26
4.2. CRL Response ..............................................26
5. Symmetric Keys, Receipts, and Errors ...........................27
5.1. Symmetric Keys ............................................27
5.1.1. Distribute Symmetric Keys ..........................28
5.1.2. Symmetric Key Response .............................28
5.2. Symmetric Key Receipts and Errors .........................29
5.2.1. Provide Symmetric Key Receipt or Error .............30
5.2.2. Symmetric Key Receipt or Error Response ............31
1. Introduction ....................................................4
1.1. Definitions ................................................6
1.2. Authentication and Authorization ...........................7
1.3. TLS Cipher Suites ..........................................7
1.4. URI Configuration ..........................................7
1.5. Message Types ..............................................8
1.6. Key Words .................................................10
2. Locate Available Packages ......................................10
2.1. PAL Format ................................................12
2.1.1. PAL Package Types ..................................14
2.1.2. PAL XML Schema .....................................19
2.1.3. PAL JSON Object ....................................23
2.2. Request PAL ...............................................23
2.3. Provide PAL ...............................................24
3. Distribute EE Certificates .....................................25
3.1. EE Certificate Request ....................................25
3.2. EE Certificate Response ...................................26
4. Distribute CRLs and ARLs .......................................26
4.1. CRL Request ...............................................26
4.2. CRL Response ..............................................26
5. Symmetric Keys, Receipts, and Errors ...........................27
5.1. Symmetric Keys ............................................27
5.1.1. Distribute Symmetric Keys ..........................28
5.1.2. Symmetric Key Response .............................28
5.2. Symmetric Key Receipts and Errors .........................29
5.2.1. Provide Symmetric Key Receipt or Error .............30
5.2.2. Symmetric Key Receipt or Error Response ............31
6. Firmware, Receipts, and Errors .................................31
6.1. Firmware ..................................................31
6.1.1. Distribute Firmware ................................32
6.1.2. Firmware Response ..................................32
6.2. Firmware Receipts and Errors ..............................33
6.2.1. Provide Firmware Receipt or Error ..................33
6.2.2. Firmware Receipt or Error Response .................33
7. Trust Anchor Management Protocol ...............................34
7.1. TAMP Status Query, Trust Anchor Update,
Apex Trust Anchor Update, Community Update,
and Sequence Number Adjust ................................34
7.1.1. Request TAMP Packages ..............................34
7.1.2. Return TAMP Packages ...............................35
7.2. TAMP Responses, Confirms, and Errors ......................35
7.2.1. Provide TAMP Responses, Confirms, or Errors ........36
7.2.2. TAMP Responses, Confirms, and Error Responses ......36
8. Asymmetric Keys, Receipts, and Errors ..........................36
8.1. Asymmetric Key Encapsulation ..............................37
8.2. Asymmetric Key Package Receipts and Errors ................38
8.3. PKCS #12 ..................................................39
8.3.1. Server-Side Key Generation Request .................39
8.3.2. Server-Side Key Generation Response ................39
9. PAL and Certificate Enrollment .................................40
10. Security Considerations .......................................43
11. IANA Considerations ...........................................44
11.1. PAL Name Space ...........................................44
11.2. PAL XML Schema ...........................................44
11.3. PAL Package Types ........................................44
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................50
Appendix A. Example Use of PAL ....................................51
Appendix B. Additional CSR Attributes .............................53
Acknowledgements ..................................................54
Author's Address ..................................................54
6. Firmware, Receipts, and Errors .................................31
6.1. Firmware ..................................................31
6.1.1. Distribute Firmware ................................32
6.1.2. Firmware Response ..................................32
6.2. Firmware Receipts and Errors ..............................33
6.2.1. Provide Firmware Receipt or Error ..................33
6.2.2. Firmware Receipt or Error Response .................33
7. Trust Anchor Management Protocol ...............................34
7.1. TAMP Status Query, Trust Anchor Update,
Apex Trust Anchor Update, Community Update,
and Sequence Number Adjust ................................34
7.1.1. Request TAMP Packages ..............................34
7.1.2. Return TAMP Packages ...............................35
7.2. TAMP Responses, Confirms, and Errors ......................35
7.2.1. Provide TAMP Responses, Confirms, or Errors ........36
7.2.2. TAMP Responses, Confirms, and Error Responses ......36
8. Asymmetric Keys, Receipts, and Errors ..........................36
8.1. Asymmetric Key Encapsulation ..............................37
8.2. Asymmetric Key Package Receipts and Errors ................38
8.3. PKCS #12 ..................................................39
8.3.1. Server-Side Key Generation Request .................39
8.3.2. Server-Side Key Generation Response ................39
9. PAL and Certificate Enrollment .................................40
10. Security Considerations .......................................43
11. IANA Considerations ...........................................44
11.1. PAL Name Space ...........................................44
11.2. PAL XML Schema ...........................................44
11.3. PAL Package Types ........................................44
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................50
Appendix A. Example Use of PAL ....................................51
Appendix B. Additional CSR Attributes .............................53
Acknowledgements ..................................................54
Author's Address ..................................................54
The EST (Enrollment over Secure Transport) protocol [RFC7030] defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- to support selected services related to the PKI (Public Key Infrastructure), with such PCs (path components) as simple enrollment with /simpleenroll, rekey or renew with /simplereenroll, etc. A server that wishes to support additional PKI-related services and other security-related packages could use the same .well-known URI by defining additional PCs. This document defines six such PCs:
EST（通过安全传输注册）协议[RFC7030]定义了众所周知的URI（统一资源标识符）-/.Well-Known/EST-以支持与PKI（公钥基础设施）相关的选定服务，PC（路径组件）包括使用/simpleenroll进行简单注册、使用/simpleenroll重新注册或续订，等。希望支持其他PKI相关服务和其他安全相关包的服务器可以通过定义其他PC使用相同的众所周知的URI。本文档定义了六个此类PC：
o /pal - The PAL (Package Availability List) provides a list of all known packages available and authorized for a client. By accessing the service provided by this PC first, the client can walk through the PAL and download all the packages necessary to begin operating securely. The PAL essentially points to other PCs, including the PCs defined in this document as well as those defined in [RFC7030] (e.g., /cacerts, /simpleenroll, /simplereenroll, /fullcmc, /serverkeygen, and /csrattrs). The /pal PC is described in Section 2.
o /pal-pal（软件包可用性列表）提供了所有已知的可供客户使用和授权的软件包的列表。通过首先访问这台电脑提供的服务，客户端可以浏览PAL并下载开始安全运行所需的所有软件包。PAL基本上指向其他PC，包括本文档中定义的PC以及[RFC7030]中定义的PC（例如，/cacerts、/simpleenroll、/simplerenroll、/fullcmc、/serverkeygen和/csratts）。第2节介绍了/pal PC。
o /eecerts - EE (End-Entity) certificates [RFC5280] are needed by the client when they invoke a security protocol for communicating with a peer (i.e., they become operational and do something meaningful as opposed to just communicating with the infrastructure). If the infrastructure knows the certificate(s) needed by the client, then providing the peer's certificate avoids the client having to discover the peer's certificate. This service is not meant to be a general-purpose repository to which clients query a "repository" and then get a response; this is purely a push mechanism. The /eecerts PC is described in Section 3.
o /eecerts-当客户端调用安全协议与对等方通信时，客户端需要EE（终端实体）证书[RFC5280]（即，它们可以运行并执行有意义的操作，而不仅仅是与基础设施通信）。如果基础结构知道客户端需要的证书，那么提供对等方的证书可以避免客户端不得不发现对等方的证书。这项服务并不意味着是一个通用的存储库，客户可以查询“存储库”，然后得到响应；这纯粹是一种推动机制。第3节介绍了/eecerts PC。
o /crls - CRLs (Certificate Revocation Lists) and ARLs (Authority Revocation Lists) [RFC5280] are also needed by the client when they validate certificate paths. CRLs (and ARLs) from TAs (Trust Anchors) and intermediate CAs (Certification Authorities) are needed to validate the certificates used to generate the client's certificate or the peer's certificate, which is provided by the /eecerts PC, and providing them saves the client from having to "discover" them and then retrieve them. CRL "discovery" is greatly aided by the inclusion of the CRL Distribution Point certificate extension [RFC5280], but this extension is not always present in certificates and requires another connection to retrieve them. Like the /eecerts PC, this service is not meant to be a general-purpose repository to which clients query a repository and then get a response; this is purely a push mechanism. The /crls PC is described in Section 4.
o /CRL-CRL（证书撤销列表）和ARL（授权撤销列表）[RFC5280]在验证证书路径时，客户端也需要它们。需要来自TA（信任锚）和中间CA（证书颁发机构）的CRL（和ARL）来验证用于生成客户端证书或对等方证书的证书，这些证书由/eecerts PC提供，提供这些证书可以使客户端不必“发现”它们，然后检索它们。CRL分发点证书扩展[RFC5280]的加入大大有助于CRL“发现”，但该扩展并不总是存在于证书中，需要另一个连接来检索它们。与/eecerts PC一样，该服务并不意味着是一个通用存储库，客户可以查询存储库，然后获得响应；这纯粹是一种推动机制。第4节介绍了/crls PC。
o /symmetrickeys - In some cases, clients use symmetric keys [RFC6031] when communicating with their peers. If the client's peers are known by the server a priori, then providing them saves the client or an administrator from later having to find, retrieve, and install them. Like the /eecerts and /crls PCs, this service is not meant to be a general-purpose repository to which clients query a repository and then get a response; this is purely a push mechanism for the keys themselves. However, things do not always go as planned, and clients need to inform the server about any errors. If things did go well, then the client, if requested, needs to provide a receipt [RFC7191]. The /symmetrickeys and /symmetrickeys/return PCs are described in Section 5.
o /symmetrickeys—在某些情况下，客户端在与对等方通信时使用对称密钥[RFC6031]。如果服务器事先知道客户机的对等点，那么提供它们可以避免客户机或管理员以后不得不查找、检索和安装它们。与/eecerts和/crls PC一样，该服务并不意味着是一个通用存储库，客户可以查询存储库，然后获得响应；这纯粹是按键本身的推动机制。但是，事情并非总是按计划进行，客户机需要将任何错误通知服务器。如果事情进展顺利，那么客户需要提供收据[RFC7191]。第5节介绍了/symmetrickeys和/symmetrickeys/返回PC。
o /firmware - Some client firmware and software support automatic update mechanisms, and some do not. For those that do not, the /firmware PC provides a mechanism for the infrastructure to inform the client that firmware and software updates [RFC4108] are available. Because updates do not always go as planned and because sometimes the server needs to know whether the firmware was received and processed, this PC also provides a mechanism to return errors and receipts. The /firmware and /firmware/return PCs are defined in Section 6.
o /固件-有些客户端固件和软件支持自动更新机制，有些则不支持。对于那些没有的，固件PC为基础设施提供了一种机制，通知客户端固件和软件更新[RFC4108]可用。由于更新并不总是按计划进行，而且有时服务器需要知道固件是否已接收和处理，因此此PC还提供了一种返回错误和收据的机制。第6节定义了/固件和/固件/返回PC。
o /tamp - To control the TAs in client TA databases, servers use the /tamp PC to request that clients retrieve TAMP (Trust Anchor Management Protocol) query, update, and adjust packages [RFC5934], and clients use the /tamp/return PC to return TAMP responses, confirms, and errors [RFC5934]. The /tamp and /tamp/return PCs are defined in Section 7.
o /tamp-为了控制客户端TA数据库中的TA，服务器使用/tamp PC请求客户端检索tamp（信任锚管理协议）查询、更新和调整包[RFC5934]，客户端使用/tamp/return PC返回tamp响应、确认和错误[RFC5934]。第7节定义了/夯实和/夯实/返回PCs。
This document also extends the /est/serverkeygen PC [RFC7030] to support the following (see Section 8):
本文档还扩展了/est/serverkeygen PC[RFC7030]以支持以下内容（参见第8节）：
o Returning asymmetric key package receipts and errors [RFC7191].
o 返回非对称密钥包收据和错误[RFC7191]。
o Encapsulating returned asymmetric keys in additional CMS (Cryptographic Message Syntax) content types [RFC7193].
o 将返回的非对称密钥封装在其他CMS（加密消息语法）内容类型中[RFC7193]。
o Returning server-generated public key pairs encapsulated in PKCS #12 (Public Key Cryptography Standard #12) [RFC7292].
o 返回封装在PKCS#12（公钥加密标准#12）[RFC7292]中的服务器生成的公钥对。
While the motivation is to provide packages to clients during enrollment so that they can perform securely after enrollment, the services defined in this specification can be used after enrollment.
虽然动机是在注册期间向客户端提供包，以便它们在注册后能够安全地执行，但本规范中定义的服务可以在注册后使用。
Familiarity with the following specifications is assumed:
假设熟悉以下规范：
o "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages" [RFC4108]
o “使用加密消息语法（CMS）保护固件包”[RFC4108]
o "Certificate Management over CMS (CMC)" [RFC5272]
o “CMS（CMC）上的证书管理”[RFC5272]
o "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type" [RFC6032]
o “加密消息语法（CMS）加密密钥包内容类型”[RFC6032]
o "Cryptographic Message Syntax (CMS)" [RFC5652]
o “加密消息语法（CMS）”[RFC5652]
o "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)" [RFC6268]
o “使用X.509（PKIX）的加密消息语法（CMS）和公钥基础设施的附加新ASN.1模块”[RFC6268]
o "Trust Anchor Management Protocol (TAMP)" [RFC5934]
o “信任锚管理协议（TAMP）”[RFC5934]
o "Cryptographic Message Syntax (CMS) Content Constraints Extension" [RFC6010]
o “加密消息语法（CMS）内容约束扩展”[RFC6010]
o "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type" [RFC6031]
o “加密消息语法（CMS）对称密钥包内容类型”[RFC6031]
o "Enrollment over Secure Transport" [RFC7030]
o “通过安全传输注册”[RFC7030]
o "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types" [RFC7191]
o “加密消息语法（CMS）密钥包接收和错误内容类型”[RFC7191]
Also, familiarity with the CMS protecting content types signed-data and encrypted-data [RFC5652] is assumed. The CMS encrypted key package is defined in [RFC6032].
此外，假设熟悉CMS保护内容类型签名数据和加密数据[RFC5652]。CMS加密密钥包在[RFC6032]中定义。
In addition to the definitions found in [RFC7030], the following definitions are used in this document:
除[RFC7030]中的定义外，本文件中还使用了以下定义：
Agent: An entity that performs functions on behalf of a client. Agents can service a) one or more clients on the same network as the server, b) clients on non-IP-based networks, or c) clients that have a non-electronic air gap [RFC4949] between themselves and the server. Interactions between the agent and client in the last two cases are beyond the scope of this document. Before an agent can service clients, the agent must have a trust relationship with the server (i.e., be authorized to act on behalf of clients).
代理：代表客户执行功能的实体。代理可以服务于a）与服务器位于同一网络上的一个或多个客户端，b）非基于IP的网络上的客户端，或c）其自身与服务器之间存在非电子气隙[RFC4949]的客户端。在最后两种情况下，代理和客户端之间的交互超出了本文档的范围。在代理可以为客户端提供服务之前，代理必须与服务器具有信任关系（即，被授权代表客户端行事）。
Client: A device that ultimately consumes and uses the packages to enable communications. In other words, the client is the endpoint for the packages, and an agent may have one or more clients. To avoid confusion, this document henceforth uses the term "client" to refer to both agents and clients.
客户端：最终使用和使用包来实现通信的设备。换句话说，客户端是包的端点，代理可以有一个或多个客户端。为避免混淆，本文件此后使用术语“客户”来指代代理和客户。
Package: An object that contains one or more content types. There are numerous types of packages, e.g., packages for asymmetric keys, symmetric keys, encrypted keys, CRLs, firmware, and TAMP. See Section 2.1.1. All of these packages are digitally signed by their creator and encapsulated in a CMS signed-data [RFC5652] [RFC6268] (except the public key certificates and CRLs that are already digitally signed by a CA): firmware receipts and errors; TAMP responses, confirms, and errors; and "key package" receipts and errors that can be optionally signed. Certificates and CRLs are included in a package that uses signed-data, which is often referred to as a "degenerate CMS", or as a "certs-only" [RFC5751] [RFC6268] or "crls-only" message (see Section 4.2), but no signature or content is present -- hence the names "certs-only" and "crls-only".
包：包含一个或多个内容类型的对象。有许多类型的包，例如不对称密钥包、对称密钥包、加密密钥包、CRL包、固件包和TAMP包。见第2.1.1节。所有这些包都由其创建者进行数字签名，并封装在CMS签名数据[RFC5652][RFC6268]中（公钥证书和CRL除外，这些证书和CRL已经由CA进行数字签名）：固件接收和错误；夯实响应、确认和错误；以及可选择性签名的“密钥包”收据和错误。证书和CRL包含在使用签名数据的包中，该数据通常被称为“退化CMS”，或“仅证书”[RFC5751][RFC6268]或“仅CRL”消息（见第4.2节），但不存在签名或内容，因此名称为“仅证书”和“仅CRL”。
Note: As per [RFC7030], the creator may or may not be the EST server or the EST CA.
注：根据[RFC7030]，创建者可能是也可能不是EST服务器或EST CA。
Client and server authentication as well as client and server authorization are as defined in [RFC7030]. The requirements for each are discussed in the "request" and "response" sections (e.g., Sections 3.1 and 3.2 of this document) of each of the PCs defined herein.
客户机和服务器身份验证以及客户机和服务器授权的定义见[RFC7030]。各PCs的要求在本文定义的各PCs的“请求”和“响应”章节（如本文件第3.1节和第3.2节）中讨论。
The requirements for the TA databases are as specified in [RFC7030] as well.
TA数据库的要求也在[RFC7030]中规定。
TLS (Transport Layer Security) cipher suites and issues associated with them are as defined in [RFC7030].
TLS（传输层安全）密码套件及其相关问题如[RFC7030]所述。
As specified in Section 3.1 of [RFC7030], the client is configured with sufficient information to form the server URI [RFC3986]. Like EST, this configuration mechanism is beyond the scope of this document.
如[RFC7030]第3.1节所述，客户机配置有足够的信息以形成服务器URI[RFC3986]。与EST一样，此配置机制超出了本文档的范围。
This document uses existing media types for the messages as specified by "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP" [RFC2585], "The application/pkcs10 Media Type" [RFC5967], and "Certificate Management over CMS (CMC)" [RFC5272].
本文档使用“Internet X.509公钥基础设施操作协议：FTP和HTTP”[RFC2585]、“应用程序/pkcs10媒体类型”[RFC5967]和“CMS上的证书管理（CMC）”[RFC5272]中指定的消息的现有媒体类型。
For consistency with [RFC5273], each distinct EST message type uses an HTTP Content-Type header with a specific media type.
为了与[RFC5273]保持一致，每个不同的EST消息类型都使用具有特定媒体类型的HTTP内容类型头。
The EST messages, their corresponding media types for each operation, and the sections that provide request and response information are as follows:
EST消息、每个操作对应的媒体类型以及提供请求和响应信息的部分如下所示：
+-------------------+---------------------------------+---------------+
| Message type | Request media type | Request |
| | Response media type(s) | Response |
| (per operation) | Source(s) of types | |
+===================+=================================+===============+
| Locate Available | N/A | Section 2.2 |
| Packages | application/xml or | Section 2.3 |
| | application/json | |
| | [RFC7303] [RFC8259] | |
| /pal | | |
+===================+=================================+===============+
| Distribute EE | N/A | Section 3.1 |
| Certificates | application/pkcs7-mime | Section 3.2 |
| | [RFC5751] | |
| /eecerts | | |
+===================+=================================+===============+
| Distribute CRLs | N/A | Section 4.1 |
| | application/pkcs7-mime | Section 4.2 |
| | [RFC5751] | |
| /crls | | |
+===================+=================================+===============+
| Symmetric Key | N/A | Section 5.1.1 |
| Distribution | application/cms | Section 5.1.2 |
| | [RFC7193] | |
| /symmetrickeys | | |
+===================+=================================+===============+
| Return Symmetric | application/cms | Section 5.2.1 |
| Key | N/A | Section 5.2.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /symmetrickeys/ | | |
| return | | |
+-------------------+---------------------------------+---------------+
| Message type | Request media type | Request |
| | Response media type(s) | Response |
| (per operation) | Source(s) of types | |
+===================+=================================+===============+
| Locate Available | N/A | Section 2.2 |
| Packages | application/xml or | Section 2.3 |
| | application/json | |
| | [RFC7303] [RFC8259] | |
| /pal | | |
+===================+=================================+===============+
| Distribute EE | N/A | Section 3.1 |
| Certificates | application/pkcs7-mime | Section 3.2 |
| | [RFC5751] | |
| /eecerts | | |
+===================+=================================+===============+
| Distribute CRLs | N/A | Section 4.1 |
| | application/pkcs7-mime | Section 4.2 |
| | [RFC5751] | |
| /crls | | |
+===================+=================================+===============+
| Symmetric Key | N/A | Section 5.1.1 |
| Distribution | application/cms | Section 5.1.2 |
| | [RFC7193] | |
| /symmetrickeys | | |
+===================+=================================+===============+
| Return Symmetric | application/cms | Section 5.2.1 |
| Key | N/A | Section 5.2.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /symmetrickeys/ | | |
| return | | |
+===================+=================================+===============+
| Firmware | N/A | Section 6.1.1 |
| Distribution | application/cms | Section 6.1.2 |
| | [RFC7193] | |
| /firmware | | |
+===================+=================================+===============+
| Return Firmware | application/cms | Section 6.2.1 |
| Receipts/Errors | N/A | Section 6.2.2 |
| | [RFC7193] | |
| /firmware/return | | |
+===================+=================================+===============+
| Trust Anchor | N/A | Section 7.1.1 |
| Management | application/ | Section 7.1.2 |
| | tamp-status-query | |
| | tamp-update | |
| | tamp-apex-update | |
| | tamp-community-update | |
| | tamp-sequence-adjust | |
| | [RFC5934] | |
| /tamp | | |
+===================+=================================+===============+
| Return TAMP | application/ | Section 7.2.1 |
| Responses/ | tamp-status-response | |
| Confirms/ | tamp-update-confirm | |
| Errors | tamp-apex-update-confirm | |
| | tamp-community-update-confirm | |
| | tamp-sequence-adjust-confirm | |
| | tamp-error | |
| | N/A | Section 7.2.2 |
| | [RFC5934] | |
| /tamp/return | | |
+===================+=================================+===============+
| Server-Side Key | application/pkcs10 with | Section 8.1 |
| Generation | content type attribute | |
| | CSR* | |
| | application/cms | Section 8.1 |
| /serverkeygen | [RFC5967] [RFC7193] [RFC7030] | |
+===================+=================================+===============+
| Firmware | N/A | Section 6.1.1 |
| Distribution | application/cms | Section 6.1.2 |
| | [RFC7193] | |
| /firmware | | |
+===================+=================================+===============+
| Return Firmware | application/cms | Section 6.2.1 |
| Receipts/Errors | N/A | Section 6.2.2 |
| | [RFC7193] | |
| /firmware/return | | |
+===================+=================================+===============+
| Trust Anchor | N/A | Section 7.1.1 |
| Management | application/ | Section 7.1.2 |
| | tamp-status-query | |
| | tamp-update | |
| | tamp-apex-update | |
| | tamp-community-update | |
| | tamp-sequence-adjust | |
| | [RFC5934] | |
| /tamp | | |
+===================+=================================+===============+
| Return TAMP | application/ | Section 7.2.1 |
| Responses/ | tamp-status-response | |
| Confirms/ | tamp-update-confirm | |
| Errors | tamp-apex-update-confirm | |
| | tamp-community-update-confirm | |
| | tamp-sequence-adjust-confirm | |
| | tamp-error | |
| | N/A | Section 7.2.2 |
| | [RFC5934] | |
| /tamp/return | | |
+===================+=================================+===============+
| Server-Side Key | application/pkcs10 with | Section 8.1 |
| Generation | content type attribute | |
| | CSR* | |
| | application/cms | Section 8.1 |
| /serverkeygen | [RFC5967] [RFC7193] [RFC7030] | |
+===================+=================================+===============+
| Return Asymmetric | application/cms | Section 8.2 |
| Key | N/A | Section 8.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /serverkeygen/ | | |
| return | | |
+===================+=================================+===============+
| Server-Side Key | application/pkcs10 | Section 8.3.1 |
| Generation: | application/pkcs12 | Section 8.3.2 |
| PKCS #12 | [RFC5967] [RFC7193] [RFC7030] | |
| | | |
| /serverkeygen | | |
+===================+=================================+===============+
+===================+=================================+===============+
| Return Asymmetric | application/cms | Section 8.2 |
| Key | N/A | Section 8.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /serverkeygen/ | | |
| return | | |
+===================+=================================+===============+
| Server-Side Key | application/pkcs10 | Section 8.3.1 |
| Generation: | application/pkcs12 | Section 8.3.2 |
| PKCS #12 | [RFC5967] [RFC7193] [RFC7030] | |
| | | |
| /serverkeygen | | |
+===================+=================================+===============+
* Certificate Signing Request
* 证书签名请求
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The PAL (Package Availability List) is either an XML (Extensible Markup Language) [XML] or JSON (JavaScript Object Notation) [RFC8259] object available through the /pal PC, which furnishes the following information to clients:
PAL（软件包可用性列表）是通过/PAL PC提供的XML（可扩展标记语言）[XML]或JSON（JavaScript对象表示法）[RFC8259]对象，它向客户端提供以下信息：
o Advertisements for available packages that can be retrieved from the server;
o 可从服务器检索的可用包的播发；
o Notifications to begin public key certificate management or to return package receipts and errors; and
o 开始公钥证书管理或返回包收据和错误的通知；和
o Advertisement for another PAL.
o 另一个朋友的广告。
After being configured (see Section 1.4), the client can use this service to retrieve its PAL (see Section 2.1), which, if properly constructed (see Section 2.3), allows the client to determine some or all of the security-related packages needed for bootstrapping. Each PAL entry refers to other PCs (as defined in this document and in [RFC7030]) that clients use to a) retrieve packages that are available to them (e.g., CA certificates, firmware, trust anchors, symmetric keys, and asymmetric keys) or b) receive notifications to
配置后（参见第1.4节），客户机可以使用此服务检索其PAL（参见第2.1节），如果构造正确（参见第2.3节），则允许客户机确定引导所需的部分或全部安全相关包。每个PAL条目都指客户端用于a）检索其可用软件包（例如CA证书、固件、信任锚、对称密钥和非对称密钥）或b）接收通知的其他PC（如本文档和[RFC7030]中的定义）
initiate public key certificate enrollment. PAL entries can also be used to notify clients that they are to return receipts or errors for certain packages (see Section 2.1.1). Placing these entries after entries that clients used to retrieve the packages is the same as requesting receipts in the originally distributed package. Figure 1 provides a ladder diagram for the /pal PC protocol flow. Appendix A provides a detailed example.
启动公钥证书注册。PAL条目也可用于通知客户，他们将返回某些软件包的收据或错误（见第2.1.1节）。将这些条目放在客户端用于检索包的条目之后，与在最初分发的包中请求收据相同。图1提供了/pal PC协议流的梯形图。附录A提供了一个详细的示例。
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Request package by |
| specified URI |
| (HTTP GET or POST |
| Request) |
|--------------------->|
|<---------------------|
| Deliver requested |
| CMS package product |
| (HTTP GET or POST |
| Response) |
| |
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Request package by |
| specified URI |
| (HTTP GET or POST |
| Request) |
|--------------------->|
|<---------------------|
| Deliver requested |
| CMS package product |
| (HTTP GET or POST |
| Response) |
| |
Repeat as necessary.
必要时重复。
Figure 1: /pal Message Sequence
图1:/pal消息序列
PALs are designed to support an arbitrary number of entries, but for PALs that need to be divided for any reason, there is a special PAL entry type that constitutes a collection of "PAL package types". Package type 0001 ("Additional PAL value present") refers to another PAL. See Sections 2.1 and 2.1.1. If present, the 0001 package type is always last because other entries after it are ignored. Also, in order to avoid needlessly dereferencing URIs, the 0001 package type cannot be the only PAL entry. In addition to using the PAL during bootstrapping, clients can be configured to periodically poll the server to determine if updated packages are available for them. Note that the mechanism to configure how often clients poll the server is beyond the scope of this document. However, there are some services
PAL被设计为支持任意数量的条目，但是对于出于任何原因需要划分的PAL，有一种特殊的PAL条目类型，它构成了“PAL包类型”的集合。包装类型0001（“存在额外PAL值”）指另一PAL。参见第2.1节和第2.1.1节。如果存在，0001包类型始终是最后一个，因为它后面的其他条目将被忽略。此外，为了避免不必要地取消对URI的引用，0001包类型不能是唯一的PAL条目。除了在引导过程中使用PAL之外，还可以将客户端配置为定期轮询服务器，以确定更新的包是否可供其使用。请注意，配置客户端轮询服务器的频率的机制超出了本文档的范围。然而，也有一些服务
that support indicating when a client should retry its request (e.g., simple enrollment and re-enroll responses include the Retry-After header [RFC7030]).
指示客户端何时应重试其请求的支持（例如，简单注册和重新注册响应包括retry After标头[RFC7030]）。
As noted earlier, the PAL supports two variants: XML and JSON. Clients include the HTTP Accept header [RFC7231] when they connect to the server to indicate whether they support XML or JSON.
如前所述，PAL支持两种变体：XML和JSON。客户端在连接到服务器时包含HTTP Accept头[RFC7231]，以指示它们是支持XML还是支持JSON。
The client MUST authenticate the server as specified in [RFC7030], and the client MUST check the server's authorization as specified in [RFC7030].
客户端必须按照[RFC7030]中的规定对服务器进行身份验证，并且客户端必须按照[RFC7030]中的规定检查服务器的授权。
The server MUST authenticate the client as specified in [RFC7030], and the server MUST check the client's authorization as specified in [RFC7030].
服务器必须按照[RFC7030]中的规定对客户端进行身份验证，并且服务器必须按照[RFC7030]中的规定检查客户端的授权。
PAL support is OPTIONAL. It is shown in figures throughout this document, but clients need not support the PAL to access services offered by the server.
PAL支持是可选的。本文档中的图中显示了PAL，但是客户端不需要支持PAL来访问服务器提供的服务。
Each PAL is composed of zero or more entries. Each entry is composed of four fields -- type, date, size, and info -- whose semantics follow:
每个PAL由零个或多个条目组成。每个条目由四个字段组成——类型、日期、大小和信息——其语义如下：
Note: Both XML elements and JSON values are described below. XML elements are enclosed in angle brackets (<>), and JSON values are enclosed in single quotes (''). When described together, they are enclosed in square brackets ([]) separated by a vertical bar (|).
注意：下面描述了XML元素和JSON值。XML元素用尖括号（<>）括起来，JSON值用单引号（“”）括起来。当一起描述时，它们被括在方括号（[]）中，由竖条（|）分隔。
o [<type> | 'type'] uniquely identifies each package that a client may retrieve from the server with a 4-digit string. [<type> | 'type'] MUST be present. The PAL package types are defined in Section 2.1.1.
o [<type>|“type”]使用4位字符串唯一标识客户端可以从服务器检索的每个包。[<type>|“type”]必须存在。PAL包类型在第2.1.1节中定义。
o [<date> | 'date'] indicates one of the following:
o [<date>|“date”]表示以下情况之一：
* The date and time that the client last successfully downloaded the identified package from the server. [<date> | 'date'] MUST be represented as Generalized Time with 20 characters: YYYY-MM-DDTHH:MM:SSZ; <date> matches the dateTime production in "canonical representation" [XMLSCHEMA]; 'date' is a string. Implementations SHOULD NOT rely on time resolution finer than seconds and MUST NOT generate time instants that specify leap seconds.
* 客户端上次从服务器成功下载标识的包的日期和时间。[<date>|“date']必须用20个字符表示为广义时间：YYYY-MM-DDTHH:MM:SSZ<date>与“规范表示”[XMLSCHEMA]中的dateTime产品相匹配；'“日期”是一个字符串。实现不应依赖于小于秒的时间分辨率，并且不得生成指定闰秒的时间瞬间。
* The omission of [<date> | 'date'] indicates the following:
* 省略[<date>|“date”]表示以下内容：
- There is no indication that the client has successfully downloaded the identified package, or
- 没有迹象表明客户端已成功下载识别的软件包，或
- The PAL entry corresponds to a pointer to the next PAL, or the server is requesting a package from the client (e.g., certification request, receipt, error).
- PAL条目对应于指向下一个PAL的指针，或者服务器正在从客户端请求包（例如，认证请求、收据、错误）。
o [<size> | 'size'] indicates the size in bytes of the package; <size> is a nonNegativeInteger, and 'size' is a number. A package size of zero (i.e., "0" without the quotes) indicates that the client needs to begin a transaction, return an error, or return a receipt. [<size> | 'size'] MUST be present.
o [<size>|“size']表示包的大小（以字节为单位）<size>是一个非负整数，“size”是一个数字。包大小为零（即不带引号的“0”）表示客户端需要开始交易、返回错误或返回收据。[<size>|“size”]必须存在。
o [<info> | 'info'] provides an SKI (Subject Key Identifier), a DN
(Distinguished Name), an Issuer and Serial Number tuple, or a URI,
i.e., it is a choice between these four items, all of which are
defined in [RFC5280]. When a URI [RFC3986] is included,
[<uri> | 'uri'] indicates the location where the identified
package can be retrieved. When a DN, an SKI, or an Issuer Name
and Serial Number tuple is included, it points to a certificate
that is the subject of the notification (i.e., the certificate to
be rekeyed or renewed); [<dn> | 'dn'] is encoded as a string with
the format defined in [RFC4514]; <ski> is a hexBinary, and 'ski'
is a string of hex digits (i.e., 0-9, a-f, and A-F);
[<iasn> | 'iasn'] includes both [<issuer> | 'issuer'] and
[<serial> | 'serial'] as a complexType in XML and an object in
JSON. [<issuer> | 'issuer'] is a DN encoded as a string with the
format defined in [RFC4514]; <serial> is a positiveInteger, and
'serial' is a number. [<info> | 'info'] MUST be present, and
[<info> | 'info'] MUST include exactly one [<dn> | 'dn'],
[<ski> | 'ski'], [<iasn> | 'iasn'], or [<uri> | 'uri'].
o [<info> | 'info'] provides an SKI (Subject Key Identifier), a DN
(Distinguished Name), an Issuer and Serial Number tuple, or a URI,
i.e., it is a choice between these four items, all of which are
defined in [RFC5280]. When a URI [RFC3986] is included,
[<uri> | 'uri'] indicates the location where the identified
package can be retrieved. When a DN, an SKI, or an Issuer Name
and Serial Number tuple is included, it points to a certificate
that is the subject of the notification (i.e., the certificate to
be rekeyed or renewed); [<dn> | 'dn'] is encoded as a string with
the format defined in [RFC4514]; <ski> is a hexBinary, and 'ski'
is a string of hex digits (i.e., 0-9, a-f, and A-F);
[<iasn> | 'iasn'] includes both [<issuer> | 'issuer'] and
[<serial> | 'serial'] as a complexType in XML and an object in
JSON. [<issuer> | 'issuer'] is a DN encoded as a string with the
format defined in [RFC4514]; <serial> is a positiveInteger, and
'serial' is a number. [<info> | 'info'] MUST be present, and
[<info> | 'info'] MUST include exactly one [<dn> | 'dn'],
[<ski> | 'ski'], [<iasn> | 'iasn'], or [<uri> | 'uri'].
Clients are often limited by the size of objects they can consume; the PAL is not immune to these limitations. As opposed to picking a limit for all clients, a special package type (0001) is defined (see Section 2.1.1) to indicate that another PAL is available. Servers can use this value to limit the size of the PALs provided to clients. The mechanism for servers to know client PAL size limits is beyond the scope of this document; one possible solution is through provisioned information.
客户经常受到他们可以消费的物品大小的限制；PAL不能不受这些限制。与为所有客户选择限制不同，定义了一种特殊的包类型（0001）（见第2.1.1节），以指示另一个PAL可用。服务器可以使用此值限制提供给客户端的PAL的大小。服务器了解客户端PAL大小限制的机制超出了本文档的范围；一种可能的解决方案是通过提供信息。
Table 1 lists the PAL package types that are defined by this document:
表1列出了本文档定义的PAL包类型：
Package Package Description
Number
-------- ---------------------------------------------------
0000 Reserved
0001 Additional PAL value present
0002 X.509 CA certificate
0003 X.509 EE certificate
0004 X.509 ARL
0005 X.509 CRL
0006 Start DS certificate enrollment with CSR attribute
0007 Start DS certificate enrollment
0008 DS certificate enrollment (success)
0009 DS certificate enrollment (failure)
0010 Start DS certificate re-enrollment
0011 DS certificate re-enrollment (success)
0012 DS certificate re-enrollment (failure)
0013 Start KE certificate enrollment with CSR attribute
0014 Start KE certificate enrollment
0015 KE certificate enrollment (success)
0016 KE certificate enrollment (failure)
0017 Start KE certificate re-enrollment
0018 KE certificate re-enrollment (success)
0019 KE certificate re-enrollment (failure)
0020 Asymmetric Key Package (PKCS #8)
0021 Asymmetric Key Package (CMS)
0022 Asymmetric Key Package (PKCS #12)
0023 Asymmetric Key Package Receipt or Error
0024 Symmetric Key Package
0025 Symmetric Key Package Receipt or Error
0026 Firmware Package
0027 Firmware Package Receipt or Error
0028 TAMP Status Query
0029 TAMP Status Query Response or Error
0030 Trust Anchor Update
0031 Trust Anchor Update Confirm or Error
0032 Apex Trust Anchor Update
0033 Apex Trust Anchor Update Confirm or Error
0034 Community Update
0035 Community Update Confirm or Error
0036 Sequence Number Adjust
0037 Sequence Number Adjust Confirm or Error
Package Package Description
Number
-------- ---------------------------------------------------
0000 Reserved
0001 Additional PAL value present
0002 X.509 CA certificate
0003 X.509 EE certificate
0004 X.509 ARL
0005 X.509 CRL
0006 Start DS certificate enrollment with CSR attribute
0007 Start DS certificate enrollment
0008 DS certificate enrollment (success)
0009 DS certificate enrollment (failure)
0010 Start DS certificate re-enrollment
0011 DS certificate re-enrollment (success)
0012 DS certificate re-enrollment (failure)
0013 Start KE certificate enrollment with CSR attribute
0014 Start KE certificate enrollment
0015 KE certificate enrollment (success)
0016 KE certificate enrollment (failure)
0017 Start KE certificate re-enrollment
0018 KE certificate re-enrollment (success)
0019 KE certificate re-enrollment (failure)
0020 Asymmetric Key Package (PKCS #8)
0021 Asymmetric Key Package (CMS)
0022 Asymmetric Key Package (PKCS #12)
0023 Asymmetric Key Package Receipt or Error
0024 Symmetric Key Package
0025 Symmetric Key Package Receipt or Error
0026 Firmware Package
0027 Firmware Package Receipt or Error
0028 TAMP Status Query
0029 TAMP Status Query Response or Error
0030 Trust Anchor Update
0031 Trust Anchor Update Confirm or Error
0032 Apex Trust Anchor Update
0033 Apex Trust Anchor Update Confirm or Error
0034 Community Update
0035 Community Update Confirm or Error
0036 Sequence Number Adjust
0037 Sequence Number Adjust Confirm or Error
Table 1: PAL Package Types
表1:PAL包类型
Note: "CSR" is Certificate Signing Request, "DS" is Digital Signature, and "KE" is Key Establishment.
注意：“CSR”是证书签名请求，“DS”是数字签名，“KE”是密钥建立。
PAL package types are essentially hints about the type of package the client is about to retrieve or is asked to return. Savvy clients can parse the packages to determine what has been provided, but in some instances it is better to know before retrieving the package. The hint provided here does not obviate the need for clients to check the type of package provided before they store it, possibly in specially allocated locations (i.e., some clients might store Root ARLs separately from intermediate CRLs). For packages provided by the client, the server is asking the client to provide an enrollment package, receipt, response, confirm, or error.
PAL包类型本质上是关于客户端将要检索或要求返回的包类型的提示。精明的客户机可以解析包以确定提供了什么，但在某些情况下，最好在检索包之前知道。此处提供的提示并不排除客户端在存储包之前检查所提供包的类型的需要，可能是在专门分配的位置（即，一些客户端可能将根ARL与中间CRL分开存储）。对于客户端提供的包，服务器要求客户端提供注册包、收据、响应、确认或错误。
The PAL package types have the following meanings:
PAL包类型具有以下含义：
Note: The semantics behind Codes 0002 and 0006-0021 are defined in [RFC7030].
注：代码0002和0006-0021背后的语义在[RFC7030]中定义。
0000 Reserved: Reserved for future use.
0000保留：保留供将来使用。
0001 Additional PAL value present: Indicates that this PAL entry refers to another PAL by referring to another /pal URI, which is defined in this section. This PAL package type limits the size of PALs to a more manageable size for clients. If this PAL package type appears, it MUST be the last entry in the PAL.
0001存在其他PAL值：表示此PAL条目通过引用本节中定义的另一个/PAL URI引用另一个PAL。这种PAL包类型将PAL的大小限制为客户端更易于管理的大小。如果出现此PAL包类型，则它必须是PAL中的最后一个条目。
Additionally, in order to avoid needlessly dereferencing URIs, this PAL package type MUST NOT be the only entry.
此外，为了避免不必要地取消对URI的引用，此PAL包类型不能是唯一的条目。
0002 X.509 CA certificate: Indicates that one or more CA certificates [RFC5280] are available for the client by pointing to a /cacerts URI, which is defined in [RFC7030].
0002 X.509 CA证书：通过指向[RFC7030]中定义的a/cacerts URI，指示一个或多个CA证书[RFC5280]可用于客户端。
0003 X.509 EE certificate: Indicates that one or more EE certificates [RFC5280] are available for the client by pointing to an /eecerts URI, which is defined in Section 3.
0003 X.509 EE证书：通过指向第3节中定义的/eecerts URI，表示客户端可以使用一个或多个EE证书[RFC5280]。
0004 X.509 ARL: Indicates that one or more ARLs (Authority Revocation Lists) [RFC5280] are available for the client by pointing to a /crls URI, which is defined in Section 4.
0004 X.509 ARL：通过指向第4节中定义的a/crls URI，表示客户端可以使用一个或多个ARL（权限撤销列表）[RFC5280]。
0005 X.509 CRL: Indicates that one or more CRLs (Certificate Revocation Lists) [RFC5280] are available for the client by pointing to a /crls URI, which is defined in Section 4.
0005 X.509 CRL：通过指向第4节中定义的a/CRLs URI，表示客户端可以使用一个或多个CRL（证书撤销列表）[RFC5280]。
Note: See Section 9 for additional information about PAL and certificate enrollment interaction. See Appendix B for additional informative information.
注：有关PAL和证书注册交互的更多信息，请参见第9节。更多信息请参见附录B。
0006 Start DS certificate enrollment with CSR: Indicates that the client needs to begin enrolling its DS certificate (i.e., any certificate for which the key usage extension will have a digital signature set), using a template provided by the server with a CSR (Certificate Signing Request) attribute (see Appendix B). The PAL entry points to a /csrattrs URI, which is defined in [RFC7030].
0006使用CSR启动DS证书注册：表示客户端需要使用服务器提供的具有CSR（证书签名请求）属性的模板开始注册其DS证书（即密钥使用扩展将具有数字签名集的任何证书）（参见附录B）。PAL入口指向a/csrattrs URI，该URI在[RFC7030]中定义。
0007 Start DS certificate enrollment: Indicates that the client needs to begin enrolling its DS certificate. The PAL entry points to a /simpleenroll URI, which is defined in [RFC7030].
0007开始DS证书注册：表示客户端需要开始注册其DS证书。PAL入口指向[RFC7030]中定义的/SimplenRoll URI。
0008 DS certificate enrollment (success): Indicates that the client needs to retrieve a successful certification response. The PAL entry points to a /simpleenroll or a /fullcmc URI, both of which are defined in [RFC7030].
0008 DS证书注册（成功）：表示客户端需要检索成功的证书响应。PAL入口指向/simplenRoll或/fullcmc URI，这两个URI都在[RFC7030]中定义。
0009 DS certificate enrollment (failure): Indicates that the client needs to retrieve a failed certification response for a DS certificate. This PAL entry points to a /simpleenroll or a /fullcmc URI.
0009 DS证书注册（失败）：表示客户端需要检索DS证书的失败证书响应。此PAL入口指向/simplenRoll或/fullcmc URI。
0010 Start DS certificate re-enrollment: Indicates that the client needs to rekey or renew a DS certificate. The PAL entry points to a /simplereenroll or a /fullcmc URI.
0010启动DS证书重新注册：表示客户端需要重新注册或续订DS证书。PAL入口指向/simplereenroll或/fullcmc URI。
0011 DS certificate re-enrollment (success): See PAL package type 0008.
0011 DS证书重新注册（成功）：请参阅PAL包类型0008。
0012 DS certificate re-enrollment (failure): See PAL package type 0009.
0012 DS证书重新注册（失败）：请参阅PAL包类型0009。
Note: The KE (Key Establishment) responses that follow use the same URIs as DS certificates, except that the certificates' key usage extension is set to only key agreement or key transport.
注意：后面的KE（密钥建立）响应使用与DS证书相同的URI，但证书的密钥使用扩展设置为仅密钥协议或密钥传输。
0013 Start KE certificate enrollment with CSR: See PAL package type 0006.
0013使用CSR启动KE证书注册：请参阅PAL包类型0006。
0014 Start KE certificate enrollment: See PAL package type 0007.
0014开始KE证书注册：请参阅PAL包类型0007。
0015 KE certificate enrollment (success): See PAL package type 0008.
0015 KE证书注册（成功）：请参阅PAL包类型0008。
0016 KE certificate enrollment (failure): See PAL package type 0009.
0016 KE证书注册（失败）：请参阅PAL包类型0009。
0017 Start KE certificate re-enrollment: See PAL package type 0010.
0017开始KE证书重新注册：参见PAL包类型0010。
0018 KE certificate re-enrollment (success): See PAL package type 0008.
0018 KE证书重新注册（成功）：参见PAL包类型0008。
0019 KE certificate re-enrollment (failure): See PAL package type 0009.
0019 KE证书重新注册（失败）：请参阅PAL包类型0009。
Note: The variations in the asymmetric key packages are due to the number of CMS content types that can be used to protect the asymmetric key; the syntax for the asymmetric key is the same, but additional ASN.1 is needed to include it in a signed-data (i.e., the ASN.1 needs to be a CMS content type and not the private key info type). See Section 8 of this document for additional information.
注意：非对称密钥包的变化是由于可用于保护非对称密钥的CMS内容类型的数量造成的；非对称密钥的语法相同，但需要额外的ASN.1将其包含在签名数据中（即，ASN.1需要是CMS内容类型，而不是私钥信息类型）。更多信息请参见本文件第8节。
0020 Asymmetric Key Package (PKCS #8): Indicates that an asymmetric key generated by the server is available for the client; the package is an asymmetric key without additional encryption as specified in Section 4.4.2 of [RFC7030]. The PAL entry points to a /serverkeygen or a /fullcmc URI, which are defined in [RFC7030].
0020非对称密钥包（PKCS#8）：表示服务器生成的非对称密钥可用于客户端；该包是一个非对称密钥，没有[RFC7030]第4.4.2节规定的额外加密。PAL入口指向[RFC7030]中定义的/serverkeygen或/fullcmc URI。
0021 Asymmetric Key Package (CMS): See PAL package type 0020 (the difference being that the package available is an asymmetric key package [RFC5958] that is signed and encapsulated in a signed-data content type, as specified in Section 4.4.2 of [RFC7030]). Also, see Section 8.1 of this document.
0021非对称密钥包（CMS）：参见PAL包类型0020（区别在于可用的包是一个非对称密钥包[RFC5958]，按照[RFC7030]第4.4.2节的规定，该非对称密钥包被签名并封装在签名数据内容类型中）。此外，请参见本文件第8.1节。
0022 Asymmetric Key Package (PKCS #12): See PAL package type 0020 (the difference being that the package available is the PKCS #12 [RFC7292] content type). See Section 8.3 of this document.
0022非对称密钥包（PKCS#12）：参见PAL包类型0020（区别在于可用的包是PKCS#12[RFC7292]内容类型）。见本文件第8.3节。
0023 Asymmetric Key Package Receipt or Error: Indicates that the server wants the client to return a key package receipt or error [RFC7191] to the /serverkeygen/return URI, which is defined in Section 8.
0023非对称密钥包回执或错误：表示服务器希望客户端将密钥包回执或错误[RFC7191]返回到第8节中定义的/serverkeygen/return URI。
0024 Symmetric Key Package: Indicates that a symmetric key package [RFC6031] is available for the client by pointing to a /symmetrickeys URI, which is defined in Section 5.
0024对称密钥包：通过指向第5节中定义的/symmetrickeys URI，指示对称密钥包[RFC6031]可用于客户端。
0025 Symmetric Key Package Receipt or Error: Indicates that the server wants the client to return a key package receipt or error [RFC7191] to the /symmetrickeys/return URI, which is defined in Section 5.
0025对称密钥包回执或错误：表示服务器希望客户端将密钥包回执或错误[RFC7191]返回到第5节中定义的/symmetrickeys/return URI。
0026 Firmware Package: Indicates that a firmware package [RFC4108] is available for the client, using the /firmware URI, which is defined in Section 6.
0026固件包：表示固件包[RFC4108]可用于客户端，使用第6节中定义的/Firmware URI。
0027 Firmware Package Receipt or Error: Indicates that the server wants the client to return a firmware package load receipt or error [RFC4108] to the /firmware/return URI, which is defined in Section 6.
0027固件包接收或错误：表示服务器希望客户端将固件包加载接收或错误[RFC4108]返回到第6节中定义的/Firmware/return URI。
Note: The /tamp and tamp/return URIs are defined in Section 7.
注：第7节定义了/tamp和tamp/返回URI。
0028 TAMP Status Query: Indicates that a TAMP Status Query package [RFC5934] is available for the client, using the /tamp URI.
0028 TAMP Status Query：表示使用/TAMP URI为客户端提供TAMP状态查询包[RFC5934]。
0029 TAMP Status Query Response or Error: Indicates that the server wants the client to return a TAMP Status Query Response or Error [RFC5934] to the /tamp/return URI.
0029 TAMP状态查询响应或错误：表示服务器希望客户端将TAMP状态查询响应或错误[RFC5934]返回到/TAMP/return URI。
0030 Trust Anchor Update: Indicates that a Trust Anchor Update package [RFC5934] is available for the client, using the /tamp URI.
0030信任锚更新：表示使用/tamp URI为客户端提供信任锚更新包[RFC5934]。
0031 Trust Anchor Update Confirm or Error: Indicates that the server wants the client to return a Trust Anchor Update Confirm or Error [RFC5934] to the /tamp/return URI.
0031信任锚更新确认或错误：表示服务器希望客户端向/tamp/return URI返回信任锚更新确认或错误[RFC5934]。
0032 Apex Trust Anchor Update: Indicates that an Apex Trust Anchor Update package [RFC5934] is available for the client, using the /tamp URI.
0032 Apex Trust Anchor Update：表示使用/tamp URI为客户端提供Apex Trust Anchor更新包[RFC5934]。
0033 Apex Trust Anchor Update Confirm or Error: Indicates that the server wants the client to return an Apex Trust Anchor Update Confirm or Error [RFC5934] to the /tamp/return URI.
0033 Apex Trust Anchor Update Confirm或Error：表示服务器希望客户端将Apex Trust Anchor Update Confirm或Error[RFC5934]返回到/tamp/return URI。
0034 Community Update: Indicates that a Community Update package [RFC5934] is available for the client, using the /tamp URI.
0034社区更新：表示使用/tamp URI为客户端提供社区更新包[RFC5934]。
0035 Community Update Confirm or Error: Indicates that the server wants the client to return a Community Update Confirm or Error [RFC5934] to the /tamp/return URI.
0035社区更新确认或错误：表示服务器希望客户端向/tamp/return URI返回社区更新确认或错误[RFC5934]。
0036 Sequence Number Adjust: Indicates that a Sequence Number Adjust package [RFC5934] is available for the client, using the /tamp URI.
0036序号调整：表示使用/tamp URI为客户端提供序号调整包[RFC5934]。
0037 Sequence Number Adjust Confirm or Error: Indicates that the server wants the client to return a Sequence Number Adjust Confirm or Error [RFC5934] to the /tamp/return URI.
0037序号调整确认或错误：表示服务器希望客户端将序号调整确认或错误[RFC5934]返回到/tamp/返回URI。
The namespace is specified in Section 11.1. The fields in the schema were discussed earlier, in Sections 2.1 and 2.1.1.
名称空间在第11.1节中指定。模式中的字段在前面的第2.1节和第2.1.1节中进行了讨论。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:pal="urn:ietf:params:xml:ns:pal"
targetNamespace="urn:ietf:params:xml:ns:pal"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<xsd:annotation>
<xsd:documentation>
This schema defines the types and elements needed
to retrieve client packages from the server or for the
client to post packages to the server.
</xsd:documentation>
</xsd:annotation>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:pal="urn:ietf:params:xml:ns:pal"
targetNamespace="urn:ietf:params:xml:ns:pal"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<xsd:annotation>
<xsd:documentation>
This schema defines the types and elements needed
to retrieve client packages from the server or for the
client to post packages to the server.
</xsd:documentation>
</xsd:annotation>
<!-- ===== Element Declarations ===== -->
<!-- ===== Element Declarations ===== -->
<xsd:element name="pal" type="pal:PAL" />
<xsd:element name="pal" type="pal:PAL" />
<!-- ===== Complex Data Element Type Definitions ===== -->
<!-- ===== Complex Data Element Type Definitions ===== -->
<xsd:complexType name="PAL">
<xsd:annotation>
<xsd:documentation>
This type defines the Package Availability List (PAL).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="message" type="pal:PALEntry"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
This item contains information about the package
and a link that the client uses to download or post
the package.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PAL">
<xsd:annotation>
<xsd:documentation>
This type defines the Package Availability List (PAL).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="message" type="pal:PALEntry"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
This item contains information about the package
and a link that the client uses to download or post
the package.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PALEntry">
<xsd:annotation>
<xsd:documentation>
This type defines a product in the PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="type" type="pal:PackageType" />
<xsd:element name="date" type="pal:GeneralizedTimeType"
minOccurs="0" />
<xsd:element name="size" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>
This item indicates the package's size.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="info" type="pal:PackageInfoType" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PALEntry">
<xsd:annotation>
<xsd:documentation>
This type defines a product in the PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="type" type="pal:PackageType" />
<xsd:element name="date" type="pal:GeneralizedTimeType"
minOccurs="0" />
<xsd:element name="size" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>
This item indicates the package's size.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="info" type="pal:PackageInfoType" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PackageInfoType">
<xsd:annotation>
<xsd:documentation>
This type allows a choice of X.500 Distinguished Name,
Subject Key Identifier, Issuer and Serial Number tuple,
or URI.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<xsd:element name="dn" type="pal:DistinguishedName" />
<xsd:element name="ski" type="pal:SubjectKeyIdentifier" />
<xsd:element name="iasn" type="pal:IssuerAndSerialNumber" />
<xsd:element name="uri" type="pal:ThisURI" />
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="PackageInfoType">
<xsd:annotation>
<xsd:documentation>
This type allows a choice of X.500 Distinguished Name,
Subject Key Identifier, Issuer and Serial Number tuple,
or URI.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<xsd:element name="dn" type="pal:DistinguishedName" />
<xsd:element name="ski" type="pal:SubjectKeyIdentifier" />
<xsd:element name="iasn" type="pal:IssuerAndSerialNumber" />
<xsd:element name="uri" type="pal:ThisURI" />
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="IssuerAndSerialNumber">
<xsd:annotation>
<xsd:documentation>
This type holds the issuer Distinguished Name and
serial number of a referenced certificate.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="issuer" type="pal:DistinguishedName" />
<xsd:element name="serial" type="xsd:positiveInteger" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="IssuerAndSerialNumber">
<xsd:annotation>
<xsd:documentation>
This type holds the issuer Distinguished Name and
serial number of a referenced certificate.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="issuer" type="pal:DistinguishedName" />
<xsd:element name="serial" type="xsd:positiveInteger" />
</xsd:sequence>
</xsd:complexType>
<!-- ===== Simple Data Element Type Definitions ===== -->
<!-- ===== Simple Data Element Type Definitions ===== -->
<xsd:simpleType name="PackageType">
<xsd:annotation>
<xsd:documentation>
This type identifies each package that a client may retrieve
from the server with a 4-digit string.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="d{4}" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PackageType">
<xsd:annotation>
<xsd:documentation>
This type identifies each package that a client may retrieve
from the server with a 4-digit string.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="d{4}" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="GeneralizedTimeType">
<xsd:annotation>
<xsd:documentation>
This type indicates the date and time (YYYY-MM-DDTHH:MM:SSZ)
that the client last acknowledged successful receipt of the
package; it is absent if a) there is no indication that the
package has been downloaded or b) the PAL entry corresponds
to a pointer to the next PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".*:d{2}Z" />
<xsd:minInclusive value="2013-05-23T00:00:00Z" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="GeneralizedTimeType">
<xsd:annotation>
<xsd:documentation>
This type indicates the date and time (YYYY-MM-DDTHH:MM:SSZ)
that the client last acknowledged successful receipt of the
package; it is absent if a) there is no indication that the
package has been downloaded or b) the PAL entry corresponds
to a pointer to the next PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".*:d{2}Z" />
<xsd:minInclusive value="2013-05-23T00:00:00Z" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DistinguishedName">
<xsd:annotation>
<xsd:documentation>
This type holds an X.500 Distinguished Name.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DistinguishedName">
<xsd:annotation>
<xsd:documentation>
This type holds an X.500 Distinguished Name.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SubjectKeyIdentifier">
<xsd:annotation>
<xsd:documentation>
This type holds a hex string representing the value of a
certificate's SubjectKeyIdentifier.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:hexBinary">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SubjectKeyIdentifier">
<xsd:annotation>
<xsd:documentation>
This type holds a hex string representing the value of a
certificate's SubjectKeyIdentifier.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:hexBinary">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ThisURI">
<xsd:annotation>
<xsd:documentation>
This type holds a URI but is length limited.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:anyURI">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ThisURI">
<xsd:annotation>
<xsd:documentation>
This type holds a URI but is length limited.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:anyURI">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
</xsd:schema>
The following is an example PAL JSON object. The fields in the object were discussed earlier, in Sections 2.1 and 2.1.1.
下面是一个示例paljson对象。在前面的第2.1节和第2.1.1节中讨论了对象中的字段。
[
{
"type": "0003",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"uri": "https://www.example.com/.well-known/est/eecerts/1234"
}
},
[
{
"type": "0003",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"uri": "https://www.example.com/.well-known/est/eecerts/1234"
}
},
{
"type": "0006",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"iasn":
{
"issuer": "CN=Sean Turner,O=sn3rd,C=US",
"serial": 0
}
}
}
]
{
"type": "0006",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"iasn":
{
"issuer": "CN=Sean Turner,O=sn3rd,C=US",
"serial": 0
}
}
}
]
Clients request their PAL with an HTTP GET [RFC7231], using an operation path of "/pal". Clients indicate whether they would prefer XML or JSON by including the HTTP Accept header [RFC7231] with either "application/xml" or "application/json", respectively.
客户端使用HTTP GET[RFC7231]请求其PAL，操作路径为“/PAL”。客户机通过将HTTP Accept头[RFC7231]分别包含为“application/XML”或“application/JSON”来指示他们是喜欢XML还是喜欢JSON。
If the server has a PAL for the client, the server response MUST contain an HTTP 200 response code with a Content-Type of "application/xml" [RFC7303] or "application/json" [RFC8259].
如果服务器具有用于客户端的PAL，则服务器响应必须包含内容类型为“application/xml”[RFC7303]或“application/json”[RFC8259]的HTTP 200响应代码。
When the server constructs a PAL, an order of precedence for PAL offerings is based on the following rationale:
当服务器构建PAL时，PAL产品的优先顺序基于以下基本原理：
o /cacerts and /crls packages are the most important because they support validation decisions on certificates used to sign and encrypt other listed PAL items.
o /cacerts和/crls包是最重要的，因为它们支持对用于签名和加密其他列出的PAL项的证书进行验证。
o /csrattrs are the next in importance, since they provide information that the server would like the client to include in its certificate enrollment request.
o /CSrattr是第二个重要的，因为它们提供服务器希望客户端在其证书注册请求中包含的信息。
o /simpleenroll, /simplereenroll, and /fullcmc packages are next in importance, since they can impact a certificate used by the client to sign CMS content or a certificate to establish keys for encrypting content exchanged with the client.
o /SimplenRoll、/simplereenroll和/fullcmc软件包是下一个重要的软件包，因为它们可能会影响客户端用于签署CMS内容的证书或用于建立密钥以加密与客户端交换的内容的证书。
* A client engaged in certificate management SHOULD accept and process CA-provided transactions as soon as possible to avoid undue delays that might lead to protocol failure.
* 参与证书管理的客户端应尽快接受并处理CA提供的事务，以避免可能导致协议失败的不当延迟。
o /symmetrickeys, /firmware, /tamp, and /eecerts packages containing keys and other types of products are last. Precedence SHOULD be given to packages that the client has not previously downloaded. The items listed in a PAL may not identify all of the packages available for a device. This can be for any of the following reasons:
o /最后是包含密钥和其他类型产品的symmetrickeys、/firmware、/tamp和/eecerts包。应优先考虑客户端以前未下载的包。PAL中列出的项目可能无法识别设备可用的所有软件包。这可能是由于以下原因之一：
* The server may temporarily withhold some outstanding PAL items to simplify client processing.
* 服务器可能会暂时保留一些未完成的PAL项目，以简化客户端处理。
* If a CA has more than one certificate ready for the client, the server will provide a notice for one at a time. Pending notices will be serviced in order, according to the date when the certificate will be used (earliest date first).
* 如果CA为客户端准备了多个证书，服务器将一次提供一个证书的通知。待决通知将按照证书使用日期（最早日期优先）顺序送达。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器指定HTTP 4xx错误或HTTP 5xx错误。
All other return codes are handled as specified in Section 4.2.3 of [RFC7030] (i.e., 202 handling and all other HTTP response codes).
所有其他返回代码按照[RFC7030]第4.2.3节的规定进行处理（即202处理和所有其他HTTP响应代码）。
Numerous mechanisms exist for clients to query repositories for certificates. The service provided by the /eecerts PC is different in that it is not a general-purpose query for client certificates; instead, it allows the server to provide peer certificates to a client that the server knows through an out-of-band mechanism that the client will be communicating with. For example, a router being provisioned that connects to two peers can be provisioned with not only its certificate but also with the peers' certificates.
客户机可以通过多种机制查询存储库中的证书。/eecerts PC提供的服务不同之处在于，它不是客户端证书的通用查询；相反，它允许服务器向客户端提供对等证书，服务器通过带外机制知道客户端将与之通信。例如，连接到两个对等方的被配置路由器不仅可以配置其证书，还可以配置对等方的证书。
The server need not authenticate or authorize the client for distributing an EE certificate, because the package contents are already signed by a CA (i.e., the certificate(s) in a certs-only message has already been signed by a CA). The message flow is similar to Figure 1, except that the connection need not be HTTPS:
服务器无需对分发EE证书的客户端进行身份验证或授权，因为包内容已由CA签名（即，仅证书消息中的证书已由CA签名）。消息流类似于图1，只是连接不需要是HTTPS:
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Request EE Cert(s) |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver EE Cert(s) |
| (HTTP GET Response) |
| |
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Request EE Cert(s) |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver EE Cert(s) |
| (HTTP GET Response) |
| |
Figure 2: /eecerts Message Sequence
图2:/eecerts消息序列
Clients request EE certificates with an HTTP GET [RFC7231], using an operation path of "/eecerts".
客户端使用HTTP GET[RFC7231]请求EE证书，操作路径为“/eecerts”。
The response and processing of the returned error codes are identical to what is described in Section 4.1.3 of [RFC7030], except that the certificate provided is not the one issued to the client; instead, one or more client's peer certificates are returned in the certs-only message.
返回的错误代码的响应和处理与[RFC7030]第4.1.3节中描述的相同，但提供的证书不是发给客户的证书；相反，一个或多个客户端的对等证书将在“仅证书”消息中返回。
Clients MUST reject EE certificates that do not validate to an authorized TA.
客户端必须拒绝未向授权TA验证的EE证书。
CRLs (and ARLs) are needed in many instances to perform certificate path validation [RFC5280]. They can be obtained from repositories if their location is provided in the certificate. However, the client needs to parse the certificate and perform an additional round trip to retrieve them. Providing CRLs during bootstrapping obviates the need for the client to parse the certificate and aids those clients who might be unable to retrieve the CRL. Clients are free to obtain CRLs on which they rely from sources other than the server (e.g., a local directory). The /crls PC allows servers to distribute CRLs at the same time that clients retrieve their certificate(s) and CA certificate(s) as well as peer certificates.
在许多情况下，需要CRL（和ARL）来执行证书路径验证[RFC5280]。如果证书中提供了它们的位置，则可以从存储库中获取它们。但是，客户端需要解析证书并执行额外的往返来检索它们。在引导过程中提供CRL可以避免客户端解析证书的需要，并帮助那些可能无法检索CRL的客户端。客户端可以从服务器以外的来源（例如，本地目录）免费获取其所依赖的CRL。/crls PC允许服务器在客户端检索其证书和CA证书以及对等证书的同时分发CRL。
The server need not authenticate or authorize the client for distributing a CRL, because the package contents are already signed by a CA (i.e., the CRLs in a crls-only message have already been signed by a CA). The message flow is as depicted in Figure 2 but with "CRL(s)" instead of "EE Cert(s)".
服务器无需对分发CRL的客户端进行身份验证或授权，因为包内容已经由CA签名（即，仅CRLs消息中的CRL已经由CA签名）。消息流如图2所示，但使用“CRL（s）”而不是“EE证书”。
Clients request CRLs with an HTTP GET [RFC7231], using an operation path of "/crls".
客户端使用HTTP GET[RFC7231]请求CRL，操作路径为“/CRLs”。
The response, and the processing of that response, are identical to what is described in Section 4.1.3 of [RFC7030], except that instead of providing the issued certificate one of more CRLs are returned in the crls-only message.
响应和该响应的处理与[RFC7030]第4.1.3节中描述的内容相同，不同之处在于，不提供颁发的证书，而是在仅CRLs消息中返回一个或多个CRL。
Clients MUST reject CRLs that do not validate to an authorized TA.
客户必须拒绝未向授权TA验证的CRL。
In addition to public keys, clients often need one or more symmetric keys to communicate with their peers. The /symmetrickeys PC allows the server to distribute symmetric keys to clients.
除了公钥之外，客户机通常还需要一个或多个对称密钥来与其对等方通信。/symmetrickeys PC允许服务器向客户端分发对称密钥。
Distribution of keys does not always work as planned, and clients need a way to inform the server that something has gone wrong; they also need a way to inform the server, if asked, that the distribution process has successfully completed. The /symmetrickeys/return PC allows clients to provide errors and receipts.
密钥的分发并不总是按计划进行，客户机需要一种方法来通知服务器出了问题；他们还需要一种通知服务器分发过程已成功完成的方法。/symmetrickeys/return PC允许客户端提供错误和收据。
Clients MUST authenticate the server, and clients MUST check the server's authorization.
客户端必须验证服务器，客户端必须检查服务器的授权。
The server MUST authenticate clients, and the server MUST check the client's authorization.
服务器必须对客户端进行身份验证，并且服务器必须检查客户端的授权。
HTTP GET [RFC7231] is used when the server provides the key to the client (see Section 5.1), using the /symmetrickeys PC; HTTP POST [RFC7231] is used when the client provides a receipt (see Section 5.2) or an error (see Section 5.2) to the server with the /symmetrickeys/return PC.
当服务器使用/symmetrickeys PC向客户端提供密钥时（参见第5.1节），使用HTTP GET[RFC7231]；当客户端使用/symmetrickeys/return PC向服务器提供收据（见第5.2节）或错误（见第5.2节）时，使用HTTP POST[RFC7231]。
Servers use /symmetrickeys to provide symmetric keys to clients; the symmetric key package is defined in [RFC6031].
服务器使用/Symmetrickys向客户端提供对称密钥；对称密钥包在[RFC6031]中定义。
As with the /serverkeygen PC defined in [RFC7030], the default method for distributing the symmetric key uses the encryption mode of the negotiated TLS cipher suite. Keys are not protected by preferred key-wrapping methods such as AES Key Wrap [RFC3394] or AES Key Wrap with Padding [RFC5649], because encryption of the symmetric key beyond that provided by TLS is OPTIONAL. Therefore, the cipher suite used to return the symmetric key MUST offer cryptographic strength that is commensurate with the symmetric key being delivered to the client. The cipher suite used MUST NOT have the NULL encryption algorithm, as this will disclose the unprotected symmetric key. It is strongly RECOMMENDED that servers always return encrypted symmetric keys.
与[RFC7030]中定义的/serverkeygen PC一样，分发对称密钥的默认方法使用协商TLS密码套件的加密模式。密钥不受首选密钥包装方法（如AES密钥包装[RFC3394]或带填充的AES密钥包装[RFC5649]）的保护，因为TLS提供的对称密钥加密是可选的。因此，用于返回对称密钥的密码套件必须提供与交付给客户端的对称密钥相称的加密强度。所使用的密码套件不得具有空加密算法，因为这将公开未受保护的对称密钥。强烈建议服务器始终返回加密的对称密钥。
The following depicts the protocol flow:
以下描述了协议流程：
| |
Client | Establish TLS | Server
| Session |
|<--------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|---------------------->|
|<----------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Req Symmetric Key |
| (HTTP GET Request) |
|---------------------->|
|<----------------------|
| Deliver Symmetric Key |
| (HTTP GET Response) |
| |
| |
Client | Establish TLS | Server
| Session |
|<--------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|---------------------->|
|<----------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Req Symmetric Key |
| (HTTP GET Request) |
|---------------------->|
|<----------------------|
| Deliver Symmetric Key |
| (HTTP GET Response) |
| |
Figure 3: /symmetrickeys Message Sequence
图3:/symmetrickeys消息序列
Clients request the symmetric key from the server with an HTTP GET [RFC7231], using an operation path of "/symmetrickeys".
客户端使用HTTP GET[RFC7231]从服务器请求对称密钥，操作路径为“/symmetrickeys”。
If the request is successful, the server response MUST have an HTTP 200 response code with a Content-Type of "application/cms" [RFC7193]. The optional application/cms encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned symmetric key. The returned content varies:
如果请求成功，服务器响应必须具有内容类型为“application/cms”[RFC7193]的HTTP 200响应代码。可选的application/cms封装内容和innerContent参数应包含在内容类型中，以指示为返回的对称密钥提供的保护。返回的内容各不相同：
o If additional encryption is not being employed, the content associated with application/cms is a DER-encoded [X.690] symmetric key package.
o 如果未采用附加加密，则与application/cms相关的内容是DER编码的[X.690]对称密钥包。
o If additional encryption is employed, the content associated with application/cms is DER-encoded enveloped-data that encapsulates a signed-data that further encapsulates a symmetric key package.
o 如果采用附加加密，则与应用程序/cms相关联的内容是DER编码的封装数据，该数据封装了进一步封装对称密钥包的签名数据。
o If additional encryption and origin authentication are employed, the content associated with application/cms is a DER-encoded signed-data that encapsulates an enveloped-data that encapsulates a signed-data that further encapsulates a symmetric key package.
o 如果采用额外的加密和源认证，则与应用/cms相关联的内容是DER编码的签名数据，该签名数据封装了封装数据，该封装数据封装了签名数据，该签名数据进一步封装了对称密钥包。
o If CCC (CMS Content Constraints) [RFC6010] is supported, the content associated with application/cms is a DER-encoded encrypted key package [RFC6032]. The encrypted key package provides three choices to encapsulate keys: EncryptedData, EnvelopedData, and AuthEnvelopedData. Prior to employing one of these three encryption choices, the key package can be encapsulated in a signed-data.
o 如果支持CCC（CMS内容约束）[RFC6010]，则与应用程序/CMS关联的内容是DER编码的加密密钥包[RFC6032]。加密密钥包提供了三种封装密钥的选择：EncryptedData、EnvelopedData和AuthEnvelopedData。在采用这三种加密选择之一之前，密钥包可以封装在签名数据中。
How the server knows whether the client supports the encrypted key package is beyond the scope of this document.
服务器如何知道客户端是否支持加密密钥包超出了本文档的范围。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器指定HTTP 4xx错误或HTTP 5xx错误。
If a symmetric key package (which might be signed) or an encrypted key package (which might be signed before and after encryption) is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA.
如果对对称密钥包（可能已签名）或加密密钥包（可能在加密之前和之后签名）进行了数字签名，则如果数字签名未验证回授权TA，则客户端必须拒绝该签名。
Note: Absent a policy on the client side requiring a signature, a malicious EST server can simply strip the signature, thus bypassing that check. In that case, this requirement is merely a sanity check, serving to detect mis-signed packages or misconfigured clients.
注意：如果客户端没有需要签名的策略，恶意EST服务器可以简单地剥离签名，从而绕过该检查。在这种情况下，此要求只是一个健全性检查，用于检测签名错误的包或配置错误的客户端。
[RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6160], and [RFC6161] provide algorithm details for use when protecting the symmetric key package and encrypted key package.
[RFC3370]、[RFC5753]、[RFC5754]、[RFC6033]、[RFC6160]和[RFC6161]提供了保护对称密钥包和加密密钥包时使用的算法详细信息。
Clients use /symmetrickeys/return to provide symmetric key package receipts; the key package receipt content type is defined in [RFC7191]. Clients can be configured to automatically return receipts after processing a symmetric key package, return receipts based on processing of the key-package-identifier-and-receipt-request attribute [RFC7191], or return receipts when prompted by a PAL entry.
客户使用/symmetrickeys/return提供对称密钥包收据；[RFC7191]中定义了关键包裹收据内容类型。客户机可以配置为在处理对称密钥包后自动返回收据，根据密钥包标识符和收据请求属性[RFC7191]的处理返回收据，或者在PAL条目提示时返回收据。
Servers can indicate that clients return a receipt by including the key-package-identifier-and-receipt-request attribute in a signed-data as a signed attribute. However, this attribute only appears when additional encryption is employed (see Section 5.1.2).
服务器可以通过将密钥包标识符和收据请求属性作为签名属性包含在签名数据中来指示客户端返回收据。但是，该属性仅在采用额外加密时出现（见第5.1.2节）。
Clients also use /symmetrickeys/return to return symmetric key package errors; the key package error content type is defined in [RFC7191]. Clients can be configured to automatically return errors after processing a symmetric key package or based on a PAL entry.
客户端还使用/symmetrickeys/return返回对称密钥包错误；[RFC7191]中定义了密钥包错误内容类型。可以将客户端配置为在处理对称密钥包或基于PAL条目后自动返回错误。
The following depicts the protocol flow:
以下描述了协议流程：
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Return Receipt/Error |
| (HTTP POST Request) |
|--------------------->|
|<---------------------|
| (HTTP POST Response) |
| status code only |
| no content |
| |
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Return Receipt/Error |
| (HTTP POST Request) |
|--------------------->|
|<---------------------|
| (HTTP POST Response) |
| status code only |
| no content |
| |
Figure 4: /symmetrickeys/return Message Sequence
Figure 4: /symmetrickeys/return Message Sequence
Clients return symmetric key receipts and errors to the server with an HTTP POST [RFC7231], using an operation path of "/symmetrickeys/return". The returned content varies:
客户端通过HTTP POST[RFC7231]向服务器返回对称密钥接收和错误，操作路径为“/symmetrickeys/return”。返回的内容各不相同：
o The key package receipt is digitally signed [RFC7191]; the Content-Type is "application/cms" [RFC7193]; and the associated content is signed-data, which encapsulates a key package receipt.
o 密钥包收据是数字签名的[RFC7191]；内容类型为“应用程序/cms”[RFC7193]；关联的内容是签名数据，它封装了一个密钥包收据。
o If the key package error is not digitally signed, the Content-Type is "application/cms" and the associated content is a key package error. If the key package error is digitally signed, the Content-Type is "application/cms" and the associated content is signed-data, which encapsulates a key package error.
o 如果密钥包错误未经数字签名，则内容类型为“应用程序/cms”，相关内容为密钥包错误。如果密钥包错误是数字签名的，则内容类型为“应用程序/cms”，相关内容为签名数据，这封装了密钥包错误。
The optional application/cms encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the receipt or error.
可选应用程序/cms封装内容和innerContent参数应包含在内容类型中，以指示为接收或错误提供的保护。
[RFC3370], [RFC5753], [RFC5754], and [RFC7192] provide algorithm details for use when protecting the key package receipt or key package error.
[RFC3370]、[RFC5753]、[RFC5754]和[RFC7192]提供了保护密钥包接收或密钥包错误时使用的算法详细信息。
If the client successfully provides a receipt or error, the server response has an HTTP 204 response code (i.e., no content is returned).
如果客户端成功提供回执或错误，则服务器响应具有HTTP 204响应代码（即，不返回任何内容）。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器指定HTTP 4xx错误或HTTP 5xx错误。
If a key package receipt or key package error is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
如果对密钥包收据或密钥包错误进行了数字签名，如果数字签名未验证回授权TA，则服务器必须拒绝该签名。
Servers can distribute object code for cryptographic algorithms and software with the firmware package [RFC4108].
服务器可以使用固件包[RFC4108]分发加密算法和软件的目标代码。
Clients MUST authenticate the server, and clients MUST check the server's authorization.
客户端必须验证服务器，客户端必须检查服务器的授权。
The server MUST authenticate the client, and the server MUST check the client's authorization.
服务器必须对客户端进行身份验证，并且服务器必须检查客户端的授权。
The /firmware PC uses an HTTP GET [RFC7231], and the /firmware/return PC uses an HTTP POST [RFC7231]. GET is used when the client retrieves firmware from the server (see Section 6.1); POST is used when the client provides a receipt (see Section 6.2) or an error (see Section 6.2).
/firmware PC使用HTTP GET[RFC7231]，而/firmware/return PC使用HTTP POST[RFC7231]。当客户端从服务器检索固件时使用GET（参见第6.1节）；当客户提供收据（见第6.2节）或错误（见第6.2节）时，使用POST。
The /firmware URI is used by servers to provide firmware packages to clients.
服务器使用/firmware URI向客户端提供固件包。
The message flow is as depicted in Figure 3 modulo replacing "Symmetric Key" with "Firmware Package".
消息流如图3所示，将“对称密钥”替换为“固件包”。
Clients request firmware from the server with an HTTP GET [RFC7231], using an operation path of "/firmware".
客户端使用HTTP GET[RFC7231]从服务器请求固件，操作路径为“/固件”。
If the request is successful, the server response MUST have an HTTP 200 response code with a Content-Type of "application/cms" [RFC7193]. The optional encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned firmware. The returned content varies:
如果请求成功，服务器响应必须具有内容类型为“application/cms”[RFC7193]的HTTP 200响应代码。可选的封装内容和innerContent参数应包含在内容类型中，以指示为返回的固件提供的保护。返回的内容各不相同：
o If the firmware is unprotected, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] firmware package.
o 如果固件未受保护，则内容类型为“应用程序/cms”，内容为DER编码的[X.690]固件包。
o If the firmware is compressed, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] compressed data that encapsulates the firmware package.
o 如果固件已压缩，则内容类型为“应用程序/cms”，内容为封装固件包的DER编码[X.690]压缩数据。
o If the firmware is encrypted, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] encrypted-data that encapsulates the firmware package (which might be compressed prior to encryption).
o 如果固件已加密，则内容类型为“应用程序/cms”，内容为封装固件包的DER编码[X.690]加密数据（可能在加密之前进行压缩）。
o If the firmware is signed, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] signed-data that encapsulates the firmware package (which might be compressed, encrypted, or compressed and then encrypted prior to signature).
o 如果固件已签名，则内容类型为“应用程序/cms”，内容为封装固件包的DER编码[X.690]签名数据（可能是压缩、加密或压缩，然后在签名之前加密）。
How the server knows whether the client supports the unprotected, signed, compressed, and/or encrypted firmware package is beyond the scope of this document.
服务器如何知道客户端是否支持未受保护、签名、压缩和/或加密的固件包超出了本文档的范围。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器指定HTTP 4xx错误或HTTP 5xx错误。
If a firmware package is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA.
如果固件包是数字签名的，如果数字签名未验证回授权TA，则客户端必须拒绝该固件包。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the firmware package.
[RFC3370]、[RFC5753]和[RFC5754]提供了保护固件包时使用的算法详细信息。
Clients use the /firmware/return PC to provide firmware package load receipts and errors [RFC4108]. Clients can be configured to automatically return receipts and errors after processing a firmware package or based on a PAL entry.
客户端使用/firmware/return PC提供固件包加载收据和错误[RFC4108]。客户端可以配置为在处理固件包或基于PAL条目后自动返回收据和错误。
The message flow is as depicted in Figure 4 modulo the receipt or error is for a firmware package.
消息流如图4所示，接收或错误模块用于固件包。
Clients return firmware receipts and errors to the server with an HTTP POST [RFC7231], using an operation path of "/firmware/return". The optional encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned firmware receipt or error. The returned content varies:
客户端通过HTTP POST[RFC7231]向服务器返回固件收据和错误，操作路径为“/固件/返回”。可选的封装内容和innerContent参数应包含在内容类型中，以指示为返回的固件接收或错误提供的保护。返回的内容各不相同：
o If the firmware receipt is not digitally signed, the Content-Type is "application/cms" [RFC7193] and the content is the DER-encoded firmware receipt.
o 如果固件收据未经数字签名，则内容类型为“应用程序/cms”[RFC7193]，内容为DER编码的固件收据。
o If the firmware receipt is digitally signed, the Content-Type is "application/cms" and the content is the DER-encoded signed-data encapsulating the firmware receipt.
o 如果固件收据经过数字签名，则内容类型为“应用程序/cms”，内容为封装固件收据的DER编码签名数据。
o If the firmware error is not digitally signed, the Content-Type is "application/cms" and the content is the DER-encoded firmware error.
o 如果固件错误未经数字签名，则内容类型为“应用程序/cms”，内容为DER编码的固件错误。
o If the firmware error is digitally signed, the Content-Type is "application/cms" and the content is the DER-encoded signed-data encapsulating the firmware error.
o 如果固件错误是数字签名的，则内容类型为“应用程序/cms”，内容为封装固件错误的DER编码签名数据。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the firmware receipt or firmware error.
[RFC3370]、[RFC5753]和[RFC5754]提供了保护固件接收或固件错误时使用的算法详细信息。
If the request is successful, the server response MUST have an HTTP 204 response code (i.e., no content is returned).
如果请求成功，服务器响应必须具有HTTP 204响应代码（即，不返回任何内容）。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器必须指定HTTP 4xx错误或HTTP 5xx错误。
If a firmware receipt or firmware error is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
如果对固件收据或固件错误进行了数字签名，如果数字签名未验证回授权TA，则服务器必须拒绝该收据或固件错误。
Servers distribute TAMP packages to manage TAs in a client's trust anchor databases; TAMP packages are defined in [RFC5934]. TAMP will allow the flexibility for a device to load TAs while maintaining an operational state. Unlike other systems that require new software loads when new PKI Roots are authorized for use, TAMP allows for automated management of roots for provisioning or replacement as needed.
服务器分发TAMP包以管理客户端信任锚数据库中的TA；TAMP包在[RFC5934]中定义。TAMP将允许设备在保持操作状态的同时灵活加载TA。与授权使用新PKI根目录时需要新软件加载的其他系统不同，TAMP允许根据需要自动管理根目录以进行资源调配或替换。
Clients MUST authenticate the server, and clients MUST check the server's authorization.
客户端必须验证服务器，客户端必须检查服务器的授权。
The server MUST authenticate the client, and the server MUST check the client's authorization.
服务器必须对客户端进行身份验证，并且服务器必须检查客户端的授权。
The /tamp PC uses an HTTP GET [RFC7231], and the tamp/return PC uses an HTTP POST [RFC7231]. GET is used when the server requests that the client retrieve a TAMP package (see Section 7.1); POST is used when the client provides a confirm (see Section 7.2), provides a response (see Section 7.2), or provides an error (see Section 7.2) for the TAMP package.
/tamp PC使用HTTP GET[RFC7231]，tamp/return PC使用HTTP POST[RFC7231]。当服务器请求客户端检索TAMP包时使用GET（参见第7.1节）；当客户为TAMP包提供确认（见第7.2节）、响应（见第7.2节）或错误（见第7.2节）时，使用POST。
7.1. TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust
7.1. TAMP状态查询、信任锚更新、Apex信任锚更新、社区更新和序列号调整
Clients use the /tamp PC to retrieve the TAMP packages: TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust. Clients can be configured to periodically poll the server for these packages or contact the server based on a PAL entry.
客户端使用/tamp PC检索tamp包：tamp状态查询、信任锚更新、Apex信任锚更新、社区更新和序列号调整。可以将客户端配置为定期轮询服务器以获取这些包，或者根据PAL条目联系服务器。
The message flow is as depicted in Figure 3 modulo replacing "Symmetric Key" with the appropriate TAMP message.
消息流如图3所示，以适当的TAMP消息替换“对称密钥”。
Clients request the TAMP packages from the server with an HTTP GET [RFC7231], using an operation path of "/tamp".
客户端使用HTTP GET[RFC7231]从服务器请求TAMP包，操作路径为“/TAMP”。
If the request is successful, the server response MUST have an HTTP 200 response code and a Content-Type of:
如果请求成功，服务器响应必须具有HTTP 200响应代码和以下内容类型：
o application/tamp-status-query for TAMP Status Query
o tamp状态查询的应用程序/tamp状态查询
o application/tamp-update for Trust Anchor Update
o 信任锚更新的应用程序/夯实更新
o application/tamp-apex-update for Apex Trust Anchor Update
o apex信任锚更新的应用程序/tamp apex更新
o application/tamp-community-update for Community Update
o 社区更新的应用程序/tamp社区更新
o application/tamp-sequence-adjust for Sequence Number Adjust
o 序号调整的应用/夯实顺序调整
As specified in [RFC5934], these content types are digitally signed and clients must support validating the packages directly signed by TAs. For this specification, clients MUST support validation with a certificate and clients MUST reject it if the digital signature does not validate back to an authorized TA.
如[RFC5934]所述，这些内容类型是数字签名的，客户端必须支持验证由TA直接签名的包。对于此规范，客户端必须支持证书验证，如果数字签名未验证回授权TA，客户端必须拒绝证书验证。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the TAMP packages.
[RFC3370]、[RFC5753]和[RFC5754]提供了保护TAMP包时使用的算法详细信息。
Clients return the TAMP Status Query Response, Trust Anchor Update Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm, Sequence Number Adjust Confirm, and TAMP Error to servers, using the /tamp/return PC. Clients can be configured to automatically return responses, confirms, and errors after processing a TAMP package or based on a PAL entry.
客户端使用/TAMP/return PC向服务器返回TAMP状态查询响应、信任锚更新确认、Apex信任锚更新确认、社区更新确认、序列号调整确认和TAMP错误。客户端可以配置为自动返回响应、确认、，以及处理TAMP包或基于PAL条目后的错误。
The message flow is as depicted in Figure 4 modulo replacing "Receipt/Error" with the appropriate TAMP response, confirm, or error.
消息流如图4所示，以适当的TAMP响应、确认或错误替换“接收/错误”。
Clients provide the TAMP responses, confirms, and errors to the server with an HTTP POST, using an operation path of "/tamp/return". The Content-Type is:
客户端通过HTTP POST向服务器提供TAMP响应、确认和错误，操作路径为“/TAMP/return”。内容类型为：
o application/tamp-status-response for TAMP Status Query Response
o tamp状态查询响应的应用程序/tamp状态响应
o application/tamp-update-confirm for Trust Anchor Update Confirm
o 信任锚更新确认的应用程序/夯实更新确认
o application/tamp-apex-update-confirm for Apex Trust Anchor Update Confirm
o apex信任锚更新确认的应用程序/夯实apex更新确认
o application/tamp-community-update-confirm for Community Update Confirm
o 社区更新确认的应用程序/tamp社区更新确认
o application/tamp-sequence-adjust-confirm for Sequence Number Adjust Confirm
o 申请/夯实顺序调整确认序号调整确认
o application/tamp-error for TAMP Error
o 夯实误差的应用/夯实误差
As specified in [RFC5934], these content types should be signed. If signed, a signed-data encapsulates the TAMP content.
按照[RFC5934]中的规定，这些内容类型应进行签名。如果已签名，则已签名的数据将封装TAMP内容。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the TAMP packages.
[RFC3370]、[RFC5753]和[RFC5754]提供了保护TAMP包时使用的算法详细信息。
If the request is successful, the server response MUST have an HTTP 204 response code (i.e., no content is returned).
如果请求成功，服务器响应必须具有HTTP 204响应代码（即，不返回任何内容）。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器必须指定HTTP 4xx错误或HTTP 5xx错误。
If the package is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
如果对包进行了数字签名，如果数字签名未验证回授权TA，则服务器必须拒绝该包。
[RFC7030] defines the /serverkeygen PC to support server-side generation of asymmetric keys. Keys are returned as either a) an unprotected PKCS #8 when additional security beyond TLS is not employed or b) a CMS asymmetric key package content type that is encapsulated in a signed-data content type that is further encapsulated in an enveloped-data content type when additional security beyond TLS is requested.
[RFC7030]定义/serverkeygen PC以支持服务器端生成非对称密钥。密钥返回为a）未使用TLS之外的附加安全性时的未保护PKCS#8，或b）封装在签名数据内容类型中的CMS非对称密钥包内容类型，当请求TLS之外的附加安全性时，该内容类型进一步封装在封装数据内容类型中。
Some implementations prefer the use of other CMS content types to encapsulate the asymmetric key package. This document extends the content types that can be returned; see Section 8.1.
一些实现更喜欢使用其他CMS内容类型来封装非对称密钥包。此文档扩展了可以返回的内容类型；见第8.1节。
[RFC7191] defines content types for key package receipts and errors. This document defines the /serverkeygen/return PC to add support for returning receipts and errors for asymmetric key packages; see Section 8.2.
[RFC7191]定义关键包收据和错误的内容类型。本文档定义了/serverkeygen/return PC，以添加对非对称密钥包的返回收据和错误的支持；见第8.2节。
PKCS #12 [RFC7292] (sometimes referred to as "PFX" (Personal Information Exchange) or "P12") is often used to distribute asymmetric private keys and associated certificates. This document extends the /serverkeygen PC to allow servers to distribute server-generated asymmetric private keys and the associated certificate to clients using PKCS #12; see Section 8.3.
PKCS#12[RFC7292]（有时称为“PFX”（个人信息交换）或“P12”）通常用于分发非对称私钥和相关证书。本文档扩展了/serverkeygen PC，允许服务器使用PKCS 12将服务器生成的非对称私钥和相关证书分发给客户端；见第8.3节。
CMS supports a number of content types to encapsulate other CMS content types; [RFC7030] includes one such possibility. Note that when only relying on TLS the returned key is not a CMS content type. This document extends the CMS content types that can be returned.
CMS支持多种内容类型来封装其他CMS内容类型；[RFC7030]包括这样一种可能性。请注意，仅依赖TLS时，返回的密钥不是CMS内容类型。本文档扩展了可以返回的CMS内容类型。
If the client supports CCC [RFC6010], then the client can indicate that it supports encapsulated asymmetric keys in the encrypted key package [RFC5958] by including the encrypted key package's OID in a content type attribute [RFC2985] in the CSR (Certificate Signing Request) -- aka the certification request -- that it provides to the server. If the client knows a priori that the server supports the encrypted key package content type, then the client need not include the content type attribute in the CSR.
如果客户端支持CCC[RFC6010]，则客户端可以通过将加密密钥包的OID包含在其提供给服务器的CSR（证书签名请求）（也称为认证请求）的内容类型属性[RFC2985]中来指示其支持加密密钥包[RFC5958]中的封装非对称密钥。如果客户端事先知道服务器支持加密密钥包内容类型，则客户端不需要在CSR中包含内容类型属性。
In all instances defined herein, the Content-Type is "application/cms" [RFC7193]. The optional encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned asymmetric key package.
在本文定义的所有实例中，内容类型为“应用程序/cms”[RFC7193]。可选的封装内容和innerContent参数应包含在内容类型中，以指示为返回的非对称密钥包提供的保护。
If additional encryption and origin authentication are employed, the content associated with application/cms is a DER-encoded signed-data that encapsulates an enveloped-data that encapsulates a signed-data that further encapsulates an asymmetric key package.
如果采用额外的加密和源认证，则与应用/cms相关联的内容是DER编码的签名数据，该签名数据封装了封装的数据，该封装的数据封装了进一步封装非对称密钥包的签名数据。
If CCC is supported and additional encryption is employed, the content associated with application/cms is a DER-encoded encrypted key package [RFC6032] content type that encapsulates a signed-data that further encapsulates an asymmetric key package.
如果支持CCC并且采用了附加加密，则与应用程序/cms相关联的内容是DER编码的加密密钥包[RFC6032]内容类型，该内容类型封装了进一步封装非对称密钥包的签名数据。
If CCC is supported and if additional encryption and additional origin authentication are employed, the content associated with application/cms is a DER-encoded signed-data that encapsulates an encrypted key package content type that encapsulates a signed-data that further encapsulates an asymmetric key package.
如果支持CCC，并且如果采用了附加加密和附加源认证，则与应用程序/cms相关联的内容是DER编码的签名数据，该签名数据封装了加密密钥包内容类型，该加密密钥包内容类型封装了进一步封装非对称密钥包的签名数据。
The encrypted key package [RFC6032] provides three choices to encapsulate keys: EncryptedData, EnvelopedData, and AuthEnvelopedData, with EnvelopedData being the mandatory-to-implement choice.
加密密钥包[RFC6032]提供了三种封装密钥的选择：EncryptedData、EnvelopedData和AuthEnvelopedData，其中EnvelopedData是实现选择所必需的。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
拒绝请求时，服务器指定HTTP 4xx错误或HTTP 5xx错误。
If an asymmetric key package or an encrypted key package is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA.
如果对非对称密钥包或加密密钥包进行了数字签名，如果数字签名未验证回授权TA，则客户端必须拒绝该签名。
Note: Absent a policy on the client side requiring a signature, a malicious EST server can simply strip the signature, thus bypassing that check. In that case, this requirement is merely a sanity check, serving to detect mis-signed packages or misconfigured clients.
注意：如果客户端没有需要签名的策略，恶意EST服务器可以简单地剥离签名，从而绕过该检查。在这种情况下，此要求只是一个健全性检查，用于检测签名错误的包或配置错误的客户端。
[RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6161], and [RFC6162] provide algorithm details for use when protecting the asymmetric key package and encrypted key package.
[RFC3370]、[RFC5753]、[RFC5754]、[RFC6033]、[RFC6161]和[RFC6162]提供了保护非对称密钥包和加密密钥包时使用的算法详细信息。
Clients can be configured to automatically return receipts after processing an asymmetric key package, return receipts based on processing of the key-package-identifier-and-receipt-request attribute [RFC7191], or return receipts when prompted by a PAL entry. Servers can indicate that clients return a receipt by including the key-package-identifier-and-receipt-request attribute [RFC7191] in a signed-data as a signed attribute.
可以将客户端配置为在处理非对称密钥包后自动返回收据，根据密钥包标识符和收据请求属性[RFC7191]的处理返回收据，或者在PAL条目提示时返回收据。服务器可以通过将密钥包标识符和收据请求属性[RFC7191]作为签名属性包含在签名数据中来指示客户端返回收据。
The protocol flow is identical to that depicted in Figure 4 modulo the receipt or error is for asymmetric keys.
协议流程与图4所示的相同，接收或错误模块用于非对称密钥。
The server and client processing is as described in Sections 5.2.1 and 5.2.2 modulo the PC, which, for Asymmetric Key Packages, is "/serverkeygen/return".
服务器和客户端处理如第5.2.1节和第5.2.2节所述，对PC进行模块化，对于非对称密钥包，其为“/serverkeygen/return”。
PFX is widely deployed and supports protecting keys in the same fashion as CMS, but it does so differently.
PFX被广泛部署，并支持以与CMS相同的方式保护密钥，但其方式有所不同。
Similar to the other server-generated asymmetric keys provided through the /serverkeygen PC:
与通过/serverkeygen PC提供的其他服务器生成的非对称密钥类似：
o The certificate request is HTTPS POSTed and is the same format as for the "/simpleenroll" and "/simplereenroll" path extensions with the same content type.
o 证书请求是HTTPS发布的，其格式与具有相同内容类型的“/SimplenRoll”和“/simplereenroll”路径扩展的格式相同。
o In all respects, the server SHOULD treat the CSR as it would any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow the reuse of existing codebases for generating and parsing such requests.
o 在所有方面，服务器应将CSR视为任何注册或重新注册CSR；这里唯一的区别是服务器必须忽略CSR中的公钥值和签名。这些包含在请求中只是为了允许重用现有的代码库来生成和解析这些请求。
PBE (password-based encryption) shrouding of PKCS #12 is supported, and this specification makes no attempt to alter this de facto standard. As such, there is no support of the DecryptKeyIdentifier specified in [RFC7030] for use with PKCS #12 (i.e., "enveloping" is not supported). Note: The use of PBE requires that the password be distributed to the client; methods to distribute this password are beyond the scope of this document.
支持PKCS#12的PBE（基于密码的加密）覆盖，本规范不试图改变这一事实标准。因此，不支持[RFC7030]中指定的用于PKCS#12的DecryptKeyIdentifier（即，不支持“封装”）。注：使用PBE需要将密码分发给客户端；分发此密码的方法超出了本文档的范围。
If the request is successful, the server response MUST have an HTTP 200 response code with a Content-Type of "application/pkcs12" [PKCS12] that consists of a base64-encoded DER-encoded [X.690] PFX [RFC7292].
如果请求成功，服务器响应必须具有内容类型为“application/pkcs12”[pkcs12]的HTTP 200响应代码，该代码由base64编码的DER编码的[X.690]PFX[RFC7292]组成。
Note that this response is different than the response returned as described in Section 4.4.2 of [RFC7030], because here the private key and the certificate are included in the same PFX.
请注意，此响应不同于[RFC7030]第4.4.2节中所述的返回响应，因为此处私钥和证书包含在同一PFX中。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error. The response data's Content-Type MAY be "text/plain" [RFC2046] to convey human-readable error messages.
拒绝请求时，服务器必须指定HTTP 4xx错误或HTTP 5xx错误。响应数据的内容类型可以是“文本/普通”[RFC2046]，以传递人类可读的错误消息。
The /fullcmc PC is defined in [RFC7030]; the CMC (Certificate Management over Cryptographic Message Syntax) requirements and packages are defined in [RFC5272], [RFC5273], [RFC5274], and [RFC6402]. This section describes PAL interactions.
[RFC7030]中定义了/fullcmc PC；CMC（加密消息语法的证书管理）要求和包在[RFC5272]、[RFC5273]、[RFC5274]和[RFC6402]中定义。本节介绍PAL交互。
Under normal circumstances, the client-server interactions for PKI enrollment are as follows:
在正常情况下，PKI注册的客户机-服务器交互如下：
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
If the response is rejected during the same session:
如果响应在同一会话期间被拒绝：
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: empty
HTTPS Status Code
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
<--------------------
POST res: empty
HTTPS Status Code
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
If the request is to be filled later:
如果以后要填写申请：
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: empty
HTTPS Status Code
+ Retry-After
or
POST res: PKIResponse (pending)
Content-Type: application/pkcs7-mime
smime-type=CMC-response
<--------------------
POST res: empty
HTTPS Status Code
+ Retry-After
or
POST res: PKIResponse (pending)
Content-Type: application/pkcs7-mime
smime-type=CMC-response
--------------------->
POST req: PKIRequest (same request)
Content-Type: application/pkcs10
or
POST req: PKIRequest (CMC Status Info only)
Content-Type: application/pkcs7-mime
smime-type=CMC-request
--------------------->
POST req: PKIRequest (same request)
Content-Type: application/pkcs10
or
POST req: PKIRequest (CMC Status Info only)
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
With the PAL, the client begins after pulling the PAL and a Start Issuance PAL package type, essentially adding the following before the request:
对于PAL，客户端在拉取PAL和开始发布PAL包类型之后开始，基本上在请求之前添加以下内容：
Client Server
--------------------->
GET req: PAL
<--------------------
GET res: PAL
Content-Type: application/xml
Client Server
--------------------->
GET req: PAL
<--------------------
GET res: PAL
Content-Type: application/xml
The client then proceeds as above with a simple PKI enrollment or a full CMC enrollment, or it begins enrollment assisted by a CSR:
然后，客户机按照上述方式进行简单的PKI注册或完整的CMC注册，或者在CSR的协助下开始注册：
Client Server
--------------------->
GET req: DS certificate with CSR
Client Server
--------------------->
GET req: DS certificate with CSR
<--------------------
GET res: PAL
Content-Type: application/csrattrs
<--------------------
GET res: PAL
Content-Type: application/csrattrs
For immediately rejected requests, CMC works well. If the server prematurely closes the connection, then the procedures in Section 6.3.1 of [RFC7230] apply. But this might leave the client and server in a different state. The client could merely resubmit the request, but another option, documented herein, is for the client to instead download the PAL to see if the server has processed the request. Clients might also use this process when they are unable to remain connected to the server for the entire enrollment process; if the server does not or is not able to return a PKIData indicating a status of pending, then the client will not know whether the request was received. If a client uses the PAL and reconnects to determine if the certification or rekey or renew request was processed:
对于立即被拒绝的请求，CMC运行良好。如果服务器过早关闭连接，则[RFC7230]第6.3.1节中的程序适用。但这可能会使客户机和服务器处于不同的状态。客户机只能重新提交请求，但本文记录的另一个选项是客户机下载PAL，以查看服务器是否已处理该请求。当客户端无法在整个注册过程中保持与服务器的连接时，也可以使用此过程；如果服务器没有或无法返回指示挂起状态的PKI数据，则客户端将不知道是否收到了请求。如果客户端使用PAL并重新连接以确定是否已处理认证、重新注册或续订请求：
o Clients MUST authenticate the server, and clients MUST check the server's authorization.
o 客户端必须验证服务器，客户端必须检查服务器的授权。
o The server MUST authenticate the client, and the server MUST check the client's authorization.
o 服务器必须对客户端进行身份验证，并且服务器必须检查客户端的授权。
o Clients retrieve the PAL, using the /pal URI.
o 客户端使用/PAL URI检索PAL。
o Clients and servers use the operation path of "/simpleenroll", "simplereenroll", or "/fullcmc", based on the PAL entry, with an HTTP GET [RFC7231] to get the success or failure response.
o 客户机和服务器根据PAL条目使用“/SimplenRoll”、“simplereenroll”或“/fullcmc”的操作路径，并使用HTTP GET[RFC7231]获取成功或失败响应。
Responses are as specified in [RFC7030].
响应如[RFC7030]所述。
This document relies on many other specifications; however, all of the security considerations in [RFC7030] apply. Refer also to the following:
本文件依赖于许多其他规范；但是，[RFC7030]中的所有安全注意事项都适用。另请参阅以下内容：
o For HTTP, HTTPS, and TLS security considerations, see [RFC7231], [RFC2818], and [RFC5246].
o 有关HTTP、HTTPS和TLS安全注意事项，请参阅[RFC7231]、[RFC2818]和[RFC5246]。
o For URI security considerations, see [RFC3986].
o 有关URI安全注意事项，请参阅[RFC3986]。
o For content type security considerations, see [RFC4073], [RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5934], [RFC5958], [RFC6031], [RFC6032], [RFC6268], [RFC6402], [RFC7191], and [RFC7292].
o 有关内容类型安全注意事项，请参阅[RFC4073]、[RFC4108]、[RFC5272]、[RFC5652]、[RFC5751]、[RFC5934]、[RFC5958]、[RFC6031]、[RFC6032]、[RFC6268]、[RFC6402]、[RFC7191]和[RFC7292]。
o For algorithms used to protect packages, see [RFC3370], [RFC5649], [RFC5753], [RFC5754], [RFC5959], [RFC6033], [RFC6160], [RFC6161], [RFC6162], and [RFC7192].
o 有关用于保护包的算法，请参阅[RFC3370]、[RFC5649]、[RFC5753]、[RFC5754]、[RFC5959]、[RFC6033]、[RFC6160]、[RFC6161]、[RFC6162]和[RFC7192]。
o For random numbers, see [RFC4086].
o 有关随机数，请参见[RFC4086]。
o For server-generated asymmetric key pairs, see [RFC7030].
o 有关服务器生成的非对称密钥对，请参阅[RFC7030]。
IANA has created the "PAL Package Types" registry and performed three registrations: PAL Name Space, PAL XML Schema, and PAL Package Types.
IANA创建了“PAL包类型”注册表，并执行了三个注册：PAL名称空间、PAL XML模式和PAL包类型。
This section registers a new XML namespace [XMLNS], "urn:ietf:params:xml:ns:pal", per the guidelines in [RFC3688]:
本节根据[RFC3688]中的指南注册一个新的XML名称空间[XMLNS]，“urn:ietf:params:XML:ns:pal”：
URI: urn:ietf:params:xml:ns:pal
Registrant Contact: Sean Turner (sean@sn3rd.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Package Availability List</title>
</head>
<body>
<h1>Namespace for Package Availability List</h1>
<h2>urn:ietf:params:xml:ns:pal</h2>
<p>See RFC 8295</p>
</body>
</html>
END
URI: urn:ietf:params:xml:ns:pal
Registrant Contact: Sean Turner (sean@sn3rd.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Package Availability List</title>
</head>
<body>
<h1>Namespace for Package Availability List</h1>
<h2>urn:ietf:params:xml:ns:pal</h2>
<p>See RFC 8295</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:schema:pal Registrant Contact: Sean Turner (sean@sn3rd.com) XML: See Section 2.1.2.
URI:urn:ietf:params:xml:schema:pal注册人联系人：肖恩·特纳(sean@sn3rd.com)XML：参见第2.1.2节。
IANA has created a new registry named "PAL Package Types". This registry is for PAL package types whose initial values are found in Section 2.1.1. Future registrations of PAL package types are subject to Expert Review, as defined in RFC 8126 [RFC8126]. Package types MUST be paired with a media type; package types specify the path components to be used that in turn specify the media type used.
IANA创建了一个名为“PAL包类型”的新注册表。该注册表用于PAL包类型，其初始值见第2.1.1节。按照RFC 8126[RFC8126]中的定义，PAL包类型的未来注册将接受专家审查。包类型必须与媒体类型配对；包类型指定要使用的路径组件，这些组件依次指定所使用的媒体类型。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585]Housley，R.和P.Hoffman，“互联网X.509公钥基础设施操作协议：FTP和HTTP”，RFC 2585，DOI 10.17487/RFC2585，1999年5月<https://www.rfc-editor.org/info/rfc2585>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>.
[RFC2985]Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 2985，DOI 10.17487/RFC2985，2000年11月<https://www.rfc-editor.org/info/rfc2985>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, <https://www.rfc-editor.org/info/rfc3370>.
[RFC3370]Housley，R.，“加密消息语法（CMS）算法”，RFC 3370，DOI 10.17487/RFC3370，2002年8月<https://www.rfc-editor.org/info/rfc3370>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC3394]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，DOI 10.17487/RFC3394，2002年9月<https://www.rfc-editor.org/info/rfc3394>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, DOI 10.17487/RFC4073, May 2005, <https://www.rfc-editor.org/info/rfc4073>.
[RFC4073]Housley，R.，“使用加密消息语法（CMS）保护多个内容”，RFC 4073，DOI 10.17487/RFC4073，2005年5月<https://www.rfc-editor.org/info/rfc4073>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.
[RFC4108]Housley，R.“使用加密消息语法（CMS）保护固件包”，RFC 4108，DOI 10.17487/RFC4108，2005年8月<https://www.rfc-editor.org/info/rfc4108>.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, <https://www.rfc-editor.org/info/rfc4514>.
[RFC4514]Zeilenga，K.，编辑，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC 4514，DOI 10.17487/RFC4514，2006年6月<https://www.rfc-editor.org/info/rfc4514>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/info/rfc5272>.
[RFC5272]Schaad，J.和M.Myers，“CMS的证书管理（CMC）”，RFC 5272，DOI 10.17487/RFC5272，2008年6月<https://www.rfc-editor.org/info/rfc5272>.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, <https://www.rfc-editor.org/info/rfc5273>.
[RFC5273]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）：传输协议”，RFC 5273，DOI 10.17487/RFC5273，2008年6月<https://www.rfc-editor.org/info/rfc5273>.
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008, <https://www.rfc-editor.org/info/rfc5274>.
[RFC5274]Schaad，J.和M.Myers，“CMS上的证书管理消息（CMC）：合规性要求”，RFC 5274，DOI 10.17487/RFC5274，2008年6月<https://www.rfc-editor.org/info/rfc5274>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-editor.org/info/rfc5649>.
[RFC5649]Housley，R.和M.Dworkin，“带填充算法的高级加密标准（AES）密钥封装”，RFC 5649，DOI 10.17487/RFC5649，2009年9月<https://www.rfc-editor.org/info/rfc5649>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<https://www.rfc-editor.org/info/rfc5751>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5753]Turner，S.和D.Brown，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 5753，DOI 10.17487/RFC5753，2010年1月<https://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC5754]Turner，S.，“使用具有加密消息语法的SHA2算法”，RFC 5754，DOI 10.17487/RFC5754，2010年1月<https://www.rfc-editor.org/info/rfc5754>.
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, DOI 10.17487/RFC5934, August 2010, <https://www.rfc-editor.org/info/rfc5934>.
[RFC5934]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚管理协议（TAMP）”，RFC 5934，DOI 10.17487/RFC59342010年8月<https://www.rfc-editor.org/info/rfc5934>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，DOI 10.17487/RFC5958，2010年8月<https://www.rfc-editor.org/info/rfc5958>.
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, DOI 10.17487/RFC5959, August 2010, <https://www.rfc-editor.org/info/rfc5959>.
[RFC5959]Turner，S.，“非对称密钥包内容类型的算法”，RFC 5959，DOI 10.17487/RFC5959，2010年8月<https://www.rfc-editor.org/info/rfc5959>.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010, <https://www.rfc-editor.org/info/rfc5967>.
[RFC5967]Turner，S.，“应用程序/pkcs10媒体类型”，RFC 5967，DOI 10.17487/RFC5967，2010年8月<https://www.rfc-editor.org/info/rfc5967>.
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, DOI 10.17487/RFC6010, September 2010, <https://www.rfc-editor.org/info/rfc6010>.
[RFC6010]Housley，R.，Ashmore，S.，和C.Wallace，“加密消息语法（CMS）内容约束扩展”，RFC 6010，DOI 10.17487/RFC6010，2010年9月<https://www.rfc-editor.org/info/rfc6010>.
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, DOI 10.17487/RFC6031, December 2010, <https://www.rfc-editor.org/info/rfc6031>.
[RFC6031]Turner，S.和R.Housley，“加密消息语法（CMS）对称密钥包内容类型”，RFC 6031，DOI 10.17487/RFC60312010年12月<https://www.rfc-editor.org/info/rfc6031>.
[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6032, DOI 10.17487/RFC6032, December 2010, <https://www.rfc-editor.org/info/rfc6032>.
[RFC6032]Turner，S.和R.Housley，“加密消息语法（CMS）加密密钥包内容类型”，RFC 6032，DOI 10.17487/RFC6032，2010年12月<https://www.rfc-editor.org/info/rfc6032>.
[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6033, DOI 10.17487/RFC6033, December 2010, <https://www.rfc-editor.org/info/rfc6033>.
[RFC6033]Turner，S.，“加密消息语法（CMS）加密密钥包内容类型的算法”，RFC 6033，DOI 10.17487/RFC6033，2010年12月<https://www.rfc-editor.org/info/rfc6033>.
[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types", RFC 6160, DOI 10.17487/RFC6160, April 2011, <https://www.rfc-editor.org/info/rfc6160>.
[RFC6160]Turner，S.“对称密钥包内容类型的加密消息语法（CMS）保护算法”，RFC 6160，DOI 10.17487/RFC6160，2011年4月<https://www.rfc-editor.org/info/rfc6160>.
[RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6161, DOI 10.17487/RFC6161, April 2011, <https://www.rfc-editor.org/info/rfc6161>.
[RFC6161]Turner，S.“加密消息语法（CMS）加密密钥包内容类型的椭圆曲线算法”，RFC 6161，DOI 10.17487/RFC6161，2011年4月<https://www.rfc-editor.org/info/rfc6161>.
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type", RFC 6162, DOI 10.17487/RFC6162, April 2011, <https://www.rfc-editor.org/info/rfc6162>.
[RFC6162]Turner，S.“加密消息语法（CMS）非对称密钥包内容类型的椭圆曲线算法”，RFC 6162，DOI 10.17487/RFC6162，2011年4月<https://www.rfc-editor.org/info/rfc6162>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268]Schaad，J.和S.Turner，“加密消息语法（CMS）和使用X.509（PKIX）的公钥基础设施的额外新ASN.1模块”，RFC 6268，DOI 10.17487/RFC6268，2011年7月<https://www.rfc-editor.org/info/rfc6268>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, <https://www.rfc-editor.org/info/rfc6402>.
[RFC6402]Schaad，J.，“CMS（CMC）更新的证书管理”，RFC 6402，DOI 10.17487/RFC6402，2011年11月<https://www.rfc-editor.org/info/rfc6402>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030]Pritikin，M.，Ed.，Yee，P.，Ed.，和D.Harkins，Ed.，“安全传输的注册”，RFC 7030，DOI 10.17487/RFC7030，2013年10月<https://www.rfc-editor.org/info/rfc7030>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.
[RFC7303]Thompson，H.和C.Lilley，“XML媒体类型”，RFC 7303，DOI 10.17487/RFC7303，2014年7月<https://www.rfc-editor.org/info/rfc7303>.
[RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7191, DOI 10.17487/RFC7191, April 2014, <https://www.rfc-editor.org/info/rfc7191>.
[RFC7191]Housley，R.“加密消息语法（CMS）密钥包接收和错误内容类型”，RFC 7191，DOI 10.17487/RFC7191，2014年4月<https://www.rfc-editor.org/info/rfc7191>.
[RFC7192] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7192, DOI 10.17487/RFC7192, April 2014, <https://www.rfc-editor.org/info/rfc7192>.
[RFC7192]Turner，S.“加密消息语法（CMS）密钥包接收和错误内容类型的算法”，RFC 7192，DOI 10.17487/RFC7192，2014年4月<https://www.rfc-editor.org/info/rfc7192>.
[RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/cms Media Type", RFC 7193, DOI 10.17487/RFC7193, April 2014, <https://www.rfc-editor.org/info/rfc7193>.
[RFC7193]Turner，S.，Housley，R.，和J.Schaad，“应用程序/cms媒体类型”，RFC 7193，DOI 10.17487/RFC7193，2014年4月<https://www.rfc-editor.org/info/rfc7193>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.
[RFC7292]Moriarty，K.，Ed.，Nystrom，M.，Parkinson，S.，Rusch，A.，和M.Scott，“PKCS#12：个人信息交换语法v1.1”，RFC 7292，DOI 10.17487/RFC7292，2014年7月<https://www.rfc-editor.org/info/rfc7292>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML]Bray，T.，Paoli，J.，Sperberg McQueen，M.，Maler，E.，和F.Yergeau，“可扩展标记语言（XML）1.0（第五版）”，万维网联盟建议REC-XML-20081126，2008年11月<https://www.w3.org/TR/2008/REC-xml-20081126/>.
[XMLSCHEMA] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XMLSCHEMA]Malhotra，A.和P.Biron，“XML模式第2部分：数据类型第二版”，万维网联盟建议REC-XMLSCHEMA-2-20041028，2004年10月<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
[X.690]ITU-T，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-12015年8月<https://www.itu.int/rec/T-REC-X.690/en>.
[PKCS12] IANA, "PKCS #12", <https://www.iana.org/assignments/ media-types/application/pkcs12>.
[PKCS12]IANA，“PKCS#12”<https://www.iana.org/assignments/ 媒体类型/应用程序/pkcs12>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<https://www.rfc-editor.org/info/rfc4949>.
[XMLNS] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208/, December 2009, <https://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[XMLNS]Bray，T.，Hollander，D.，Layman，A.，Tobin，R.，和H.Thompson，“XML 1.0中的名称空间（第三版）”，万维网联盟建议REC-XML-names-20091208/，2009年12月<https://www.w3.org/TR/2009/REC-xml-names-20091208/>.
This is an informative appendix. It includes examples of protocol flows.
这是一个资料性附录。它包括协议流的示例。
Steps for using a PAL include the following:
使用PAL的步骤包括：
1. Access PAL
1. 访问伙伴
2. Process PAL entries 2.1. Get CA certificates 2.2. Get CRLs 2.3. Get CSR attributes 2.4. Enroll: simple enrollment, re-enrollment, or full CMC 2.5. Get Firmware, TAMP, Symmetric Keys, or EE certificates
2. 处理PAL条目2.1。获取CA证书2.2。获取CRLS2.3。获取CSR属性2.4。注册：简单注册、重新注册或完整CMC 2.5。获取固件、TAMP、对称密钥或EE证书
Client Server
---------------------> -+
GET req: | /pal
<--------------------- |
GET res: PAL |
Content-Type: application/xml |
|
---------------------> -+
GET req: | /cacerts
<--------------------- |
GET res: CA Certificates |
Content-Type: application/pkcs7-smime |
smime-type=certs-only |
|
---------------------> -+
GET req: | /crls
<--------------------- |
GET res: CRLs |
Content-Type: application/pkcs7-smime |
smime-type=crls-only |
|
---------------------> -+
GET req: | /csrattrs
<--------------------- |
GET res: attributes |
Client Server
---------------------> -+
GET req: | /pal
<--------------------- |
GET res: PAL |
Content-Type: application/xml |
|
---------------------> -+
GET req: | /cacerts
<--------------------- |
GET res: CA Certificates |
Content-Type: application/pkcs7-smime |
smime-type=certs-only |
|
---------------------> -+
GET req: | /crls
<--------------------- |
GET res: CRLs |
Content-Type: application/pkcs7-smime |
smime-type=crls-only |
|
---------------------> -+
GET req: | /csrattrs
<--------------------- |
GET res: attributes |
---------------------> -+
POST req: PKIRequest | /simpleenroll and
Content-Type: application/pkcs10 | /simplereenroll
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-request |
|
<-------------------- |
(success or failure) |
POST res: PKIResponse | /simpleenroll
Content-Type: application/pkcs7-mime | /simplereenroll
smime-type=certs-only | /fullcmc
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-response |
|
--------------------> -+
GET req: | /firmware
<-------------------- | /tamp
GET res: Firmware, TAMP Query | /symmetrickeys
+ Updates, Symmetric Keys |
Content-Type: application/cms |
|
---------------------> -+
POST res: Firmware Receipts or Errors, | /firmware/return
TAMP Response or Confirms or Errors, | /tamp/return
Symmetric Key Receipts or Errors | /symmetrickeys/
| return
|
Content-Type: application/cms |
<-------------------- |
POST res: empty |
(success or failure) |
--------------------> -+
GET req: | /eecerts
<-------------------- |
GET res: Other EE certificates |
Content-Type: application/pkcs7-mime |
smime-type=certs-only |
---------------------> -+
POST req: PKIRequest | /simpleenroll and
Content-Type: application/pkcs10 | /simplereenroll
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-request |
|
<-------------------- |
(success or failure) |
POST res: PKIResponse | /simpleenroll
Content-Type: application/pkcs7-mime | /simplereenroll
smime-type=certs-only | /fullcmc
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-response |
|
--------------------> -+
GET req: | /firmware
<-------------------- | /tamp
GET res: Firmware, TAMP Query | /symmetrickeys
+ Updates, Symmetric Keys |
Content-Type: application/cms |
|
---------------------> -+
POST res: Firmware Receipts or Errors, | /firmware/return
TAMP Response or Confirms or Errors, | /tamp/return
Symmetric Key Receipts or Errors | /symmetrickeys/
| return
|
Content-Type: application/cms |
<-------------------- |
POST res: empty |
(success or failure) |
--------------------> -+
GET req: | /eecerts
<-------------------- |
GET res: Other EE certificates |
Content-Type: application/pkcs7-mime |
smime-type=certs-only |
The figure above shows /eecerts after /*/return, but this is for illustrative purposes only.
上图显示了/*/return之后的/eecerts，但这仅用于说明目的。
This is an informative appendix.
这是一个资料性附录。
In some cases, the client is severely limited in its ability to encode and decode ASN.1 objects. If the client knows that a "csr" template is being provided during enrollment, then it can peel the returned CSR attribute, generate its keys, place the public key in the certification request, and then sign the request. To accomplish this, the server returns a pKCS7PDU attribute [RFC2985] in the /csrattrs (the following is "pseudo ASN.1" and is only meant to show the fields needed to accomplish returning a template certification request):
在某些情况下，客户机编码和解码ASN.1对象的能力受到严重限制。如果客户机知道在注册期间提供了“csr”模板，那么它可以剥离返回的csr属性，生成其密钥，将公钥放入认证请求中，然后对请求进行签名。为此，服务器在/csrattrs中返回pKCS7PDU属性[RFC2985]（以下为“pseudo ASN.1”，仅用于显示完成返回模板认证请求所需的字段）：
pKCS7PDU ATTRIBUTE ::= {
WITH SYNTAX ContentInfo
ID pkcs-9-at-pkcs7PDU
}
pKCS7PDU ATTRIBUTE ::= {
WITH SYNTAX ContentInfo
ID pkcs-9-at-pkcs7PDU
}
pkcs-9-at-pkcs7PDU OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
pkcs-9-at(25) 5
}
pkcs-9-at-pkcs7PDU OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
pkcs-9-at(25) 5
}
The ContentInfo is a PKIData:
ContentInfo是一个PKI数据：
PKIData ::= SEQUENCE {
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest
}
PKIData ::= SEQUENCE {
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest
}
Where TaggedRequest is a choice between the PKCS #10 or Certificate Request Message Format (CRMF) requests.
其中TaggedRequest是PKCS#10或证书请求消息格式（CRMF）请求之间的选择。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
}
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
}
Or, the ContentInfo can be a signed-data content type that further encapsulates a PKIData.
或者，ContentInfo可以是进一步封装PKI数据的签名数据内容类型。
Acknowledgements
致谢
Thanks in no particular order go to Alexey Melnikov, Paul Hoffman, Brad McInnis, Max Pritikin, Francois Rousseau, Chris Bonatti, and Russ Housley for taking time to provide comments.
感谢阿列克谢·梅尔尼科夫、保罗·霍夫曼、布拉德·麦金尼斯、马克斯·普里蒂金、弗朗索瓦·卢梭、克里斯·博纳蒂和罗斯·霍斯利花时间发表评论。
Author's Address
作者地址
Sean Turner sn3rd
肖恩·特纳
Email: sean@sn3rd.com
Email: sean@sn3rd.com