Internet Engineering Task Force (IETF) M. Pritikin, Ed.
Request for Comments: 7030 Cisco Systems, Inc.
Category: Standards Track P. Yee, Ed.
ISSN: 2070-1721 AKAYLA, Inc.
D. Harkins, Ed.
Aruba Networks
October 2013
Internet Engineering Task Force (IETF) M. Pritikin, Ed.
Request for Comments: 7030 Cisco Systems, Inc.
Category: Standards Track P. Yee, Ed.
ISSN: 2070-1721 AKAYLA, Inc.
D. Harkins, Ed.
Aruba Networks
October 2013
Enrollment over Secure Transport
基于安全传输的注册
Abstract
摘要
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.
本文档通过安全传输为使用CMS证书管理（CMC）消息的客户端配置证书注册。此配置文件称为“通过安全传输注册”（EST），它描述了一个简单但功能强大的证书管理协议，目标是需要获取客户端证书和相关证书颁发机构（CA）证书的公钥基础设施（PKI）客户端。它还支持客户端生成的公钥/私钥对以及CA生成的密钥对。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7030.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7030.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Operational Scenario Overviews ..................................5
2.1. Obtaining CA Certificates ..................................6
2.2. Initial Enrollment .........................................7
2.2.1. Certificate TLS Authentication ......................8
2.2.2. Certificate-Less TLS Authentication .................8
2.2.3. HTTP-Based Client Authentication ....................8
2.3. Client Certificate Reissuance ..............................8
2.4. Server Key Generation ......................................9
2.5. Full PKI Request Messages ..................................9
2.6. Certificate Signing Request (CSR) Attributes Request .......9
3. Protocol Design and Layering ...................................10
3.1. Application Layer .........................................13
3.2. HTTP Layer ................................................14
3.2.1. HTTP Headers for Control ...........................15
3.2.2. HTTP URIs for Control ..............................16
3.2.3. HTTP-Based Client Authentication ...................17
3.2.4. Message Types ......................................19
3.3. TLS Layer .................................................20
3.3.1. TLS-Based Server Authentication ....................20
3.3.2. TLS-Based Client Authentication ....................21
3.3.3. Certificate-Less TLS Mutual Authentication .........21
3.4. Proof-of-Possession .......................................22
3.5. Linking Identity and POP Information ......................22
3.6. Server Authorization ......................................23
3.6.1. Client Use of Explicit TA Database .................24
3.6.2. Client Use of Implicit TA Database .................24
3.7. Client Authorization ......................................24
4. Protocol Exchange Details ......................................25
4.1. Distribution of CA Certificates ...........................25
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Operational Scenario Overviews ..................................5
2.1. Obtaining CA Certificates ..................................6
2.2. Initial Enrollment .........................................7
2.2.1. Certificate TLS Authentication ......................8
2.2.2. Certificate-Less TLS Authentication .................8
2.2.3. HTTP-Based Client Authentication ....................8
2.3. Client Certificate Reissuance ..............................8
2.4. Server Key Generation ......................................9
2.5. Full PKI Request Messages ..................................9
2.6. Certificate Signing Request (CSR) Attributes Request .......9
3. Protocol Design and Layering ...................................10
3.1. Application Layer .........................................13
3.2. HTTP Layer ................................................14
3.2.1. HTTP Headers for Control ...........................15
3.2.2. HTTP URIs for Control ..............................16
3.2.3. HTTP-Based Client Authentication ...................17
3.2.4. Message Types ......................................19
3.3. TLS Layer .................................................20
3.3.1. TLS-Based Server Authentication ....................20
3.3.2. TLS-Based Client Authentication ....................21
3.3.3. Certificate-Less TLS Mutual Authentication .........21
3.4. Proof-of-Possession .......................................22
3.5. Linking Identity and POP Information ......................22
3.6. Server Authorization ......................................23
3.6.1. Client Use of Explicit TA Database .................24
3.6.2. Client Use of Implicit TA Database .................24
3.7. Client Authorization ......................................24
4. Protocol Exchange Details ......................................25
4.1. Distribution of CA Certificates ...........................25
4.1.1. Bootstrap Distribution of CA Certificates ..........25
4.1.2. CA Certificates Request ............................26
4.1.3. CA Certificates Response ...........................26
4.2. Client Certificate Request Functions ......................27
4.2.1. Simple Enrollment of Clients .......................28
4.2.2. Simple Re-enrollment of Clients ....................29
4.2.3. Simple Enroll and Re-enroll Response ...............29
4.3. Full CMC ..................................................30
4.3.1. Full CMC Request ...................................30
4.3.2. Full CMC Response ..................................30
4.4. Server-Side Key Generation ................................31
4.4.1. Server-Side Key Generation Request .................32
4.4.1.1. Requests for Symmetric Key
Encryption of the Private Key .............32
4.4.1.2. Requests for Asymmetric Encryption
of the Private Key ........................33
4.4.2. Server-Side Key Generation Response ................33
4.5. CSR Attributes ............................................35
4.5.1. CSR Attributes Request .............................35
4.5.2. CSR Attributes Response ............................35
5. IANA Considerations ............................................37
6. Security Considerations ........................................39
7. References .....................................................41
7.1. Normative References ......................................41
7.2. Informative References ....................................43
Appendix A. Operational Scenario Example Messages .................45
A.1. Obtaining CA Certificates ..................................45
A.2. CSR Attributes .............................................47
A.3. Enroll/Re-enroll ...........................................47
A.4. Server Key Generation ......................................50
Appendix B. Contributors and Acknowledgements .....................52
4.1.1. Bootstrap Distribution of CA Certificates ..........25
4.1.2. CA Certificates Request ............................26
4.1.3. CA Certificates Response ...........................26
4.2. Client Certificate Request Functions ......................27
4.2.1. Simple Enrollment of Clients .......................28
4.2.2. Simple Re-enrollment of Clients ....................29
4.2.3. Simple Enroll and Re-enroll Response ...............29
4.3. Full CMC ..................................................30
4.3.1. Full CMC Request ...................................30
4.3.2. Full CMC Response ..................................30
4.4. Server-Side Key Generation ................................31
4.4.1. Server-Side Key Generation Request .................32
4.4.1.1. Requests for Symmetric Key
Encryption of the Private Key .............32
4.4.1.2. Requests for Asymmetric Encryption
of the Private Key ........................33
4.4.2. Server-Side Key Generation Response ................33
4.5. CSR Attributes ............................................35
4.5.1. CSR Attributes Request .............................35
4.5.2. CSR Attributes Response ............................35
5. IANA Considerations ............................................37
6. Security Considerations ........................................39
7. References .....................................................41
7.1. Normative References ......................................41
7.2. Informative References ....................................43
Appendix A. Operational Scenario Example Messages .................45
A.1. Obtaining CA Certificates ..................................45
A.2. CSR Attributes .............................................47
A.3. Enroll/Re-enroll ...........................................47
A.4. Server Key Generation ......................................50
Appendix B. Contributors and Acknowledgements .....................52
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) [RFC5272] messages over a secure transport. Enrollment over Secure Transport (EST) describes the use of Transport Layer Security (TLS) 1.1 [RFC4346], 1.2 [RFC5246], or any future version) and Hypertext Transfer Protocol (HTTP) [RFC2616] to provide an authenticated and authorized channel for Simple Public Key Infrastructure (PKI) Requests and Responses [RFC5272].
本文档通过安全传输为使用CMS证书管理（CMC）[RFC5272]消息的客户端配置证书注册。安全传输注册（EST）描述了使用传输层安全（TLS）1.1[RFC4346]、1.2[RFC5246]或任何未来版本）和超文本传输协议（HTTP）[RFC2616]为简单公钥基础设施（PKI）请求和响应[RFC5272]提供经过身份验证和授权的通道。
Architecturally, the EST service is located between a Certification Authority (CA) and a client. It performs several functions traditionally allocated to the Registration Authority (RA) role in a PKI. The nature of communication between an EST server and a CA is not described in this document.
在体系结构上，EST服务位于证书颁发机构（CA）和客户端之间。它执行一些传统上分配给PKI中注册机构（RA）角色的功能。本文档中未描述EST服务器和CA之间通信的性质。
EST adopts the Certificate Management Protocol (CMP) [RFC4210] model for CA certificate rollover, but it does not use the CMP message syntax or protocol. EST servers are extensible in that new functions may be defined to provide additional capabilities not specified in CMC [RFC5272], and this document defines two such extensions: one for requesting Certificate Signing Request attributes and another for requesting server-generated keys.
EST采用证书管理协议（CMP）[RFC4210]模型进行CA证书滚动，但它不使用CMP消息语法或协议。EST服务器是可扩展的，因为可以定义新功能以提供CMC[RFC5272]中未指定的附加功能，本文档定义了两个此类扩展：一个用于请求证书签名请求属性，另一个用于请求服务器生成的密钥。
EST specifies how to transfer messages securely via HTTP over TLS (HTTPS) [RFC2818], where the HTTP headers and media types are used in conjunction with TLS. HTTPS operates over TCP; this document does not specify EST over HTTP/Datagram Transport Layer Security/User Datagram Protocol (HTTP/DTLS/UDP). With a suitable specification for combining HTTP, DTLS, and UDP, there are no EST requirements that would prevent it from working over such a stack. Figure 1 shows how the layers build upon each other.
EST指定如何通过HTTP over TLS（HTTPS）[RFC2818]安全地传输消息，其中HTTP头和媒体类型与TLS一起使用。HTTPS在TCP上运行；本文档未指定HTTP/数据报传输层安全性/用户数据报协议（HTTP/DTLS/UDP）上的EST。对于结合HTTP、DTLS和UDP的合适规范，没有EST要求会阻止它在这样的堆栈上工作。图1显示了这些层是如何相互构建的。
EST Layering:
EST分层：
Protocols:
+--------------------------------------------+
| |
| EST request/response messages |
| |
+--------------------------------------------+
| |
| HTTP for message transfer and signaling |
| |
+--------------------------------------------+
| |
| TLS for transport security |
| |
+--------------------------------------------+
| |
| TCP for transport |
| |
+--------------------------------------------+
Protocols:
+--------------------------------------------+
| |
| EST request/response messages |
| |
+--------------------------------------------+
| |
| HTTP for message transfer and signaling |
| |
+--------------------------------------------+
| |
| TLS for transport security |
| |
+--------------------------------------------+
| |
| TCP for transport |
| |
+--------------------------------------------+
Figure 1
图1
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
It is assumed that the reader is familiar with the terms and concepts described in Public Key Cryptography Standard (PKCS) #10 [RFC2986], HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and TLS [RFC4346].
假设读者熟悉公钥加密标准（PKCS）#10[RFC2986]、HTTPS[RFC2818]、CMP[RFC4210]、CMC[RFC5272][RFC5273][RFC5274]和TLS[RFC4346]中描述的术语和概念。
In addition to the terms defined in the terminology section of CMC [RFC5272], the following terms are defined for clarity:
除CMC[RFC5272]术语部分中定义的术语外，为清晰起见，定义了以下术语：
EST CA: For certificate issuing services, the EST CA is reached through the EST server; the CA could be logically "behind" the EST server or embedded within it.
EST CA：对于证书颁发服务，通过EST服务器访问EST CA；CA可以在逻辑上“位于”EST服务器后面或嵌入其中。
Third-Party Trust Anchor: Any trust anchor (TA) that is not authoritative for the PKI hierarchy for which the EST server is providing services.
第三方信任锚：任何对EST服务器提供服务的PKI层次结构不具有权威性的信任锚（TA）。
Explicit Trust Anchor: Any TA that is explicitly configured on the client or server for use during EST TLS authentication; for example, a TA that is manually configured on the EST client or bootstrapped as described in Section 4.1.1. (See more details in Sections 3.6 and 6.)
显式信任锚：在客户端或服务器上显式配置以在EST TLS身份验证期间使用的任何TA；例如，在EST客户端上手动配置或按照第4.1.1节所述引导的TA。（详见第3.6节和第6节。）
Implicit Trust Anchor: Any third-party TA that is available on the client or server for use during TLS authentication but is not specifically indicated for use during EST TLS authentication; for example, TAs commonly used by web browsers to authenticate web servers or TAs used by servers to authenticate manufacturer-installed client credentials (such as certificates populated into cable modems or routers in the factory). The authorization model for these TAs is different from the authorization model for Explicit Trust Anchors. (See more details in Sections 3.6.1, 3.6.2, and 6).
隐式信任锚：任何第三方TA，可在客户端或服务器上用于TLS身份验证，但未明确指示用于EST TLS身份验证；例如，web浏览器通常使用TA对web服务器进行身份验证，或服务器使用TA对制造商安装的客户端凭据进行身份验证（例如在工厂中填充到电缆调制解调器或路由器中的证书）。这些TA的授权模型不同于显式信任锚的授权模型。（详见第3.6.1、3.6.2和6节）。
Certificate-Less TLS: Certificate-less TLS cipher suites provide a way to perform mutual authentication in situations where neither the client nor server have certificates or are willing to use them. The credential used for authentication is a word, phrase, code, or key that is shared between the client and server. The credential must be uniquely shared between the client and server in order to provide authentication of an individual client to an individual server.
无证书TLS：无证书TLS密码套件提供了一种在客户端和服务器都没有证书或不愿意使用证书的情况下执行相互身份验证的方法。用于身份验证的凭据是在客户端和服务器之间共享的单词、短语、代码或密钥。凭据必须在客户端和服务器之间唯一共享，以便向单个服务器提供单个客户端的身份验证。
This section provides an informative overview of the operational scenarios to better introduce the reader to the protocol discussion.
本节提供操作场景的信息性概述，以便更好地向读者介绍协议讨论。
Both the EST clients and server are configured with information that provides the basis for mutual authentication and for authorization. The specific initialization data depends on the methods available in the client and server, but it can include shared secrets, network service names and locations (e.g., a Uniform Resource Identifier (URI) [RFC3986]), trust anchor information (e.g., a CA certificate or a hash of a TA's certificate), and enrollment keys and certificates. Depending on an enterprise's acquisition and network management practices, some initialization may be performed by the vendor prior to delivery of client hardware and software. In that case, the client vendor may provide data, such as trust anchors, to the enterprise via a secure procedure. The distribution of this initial information is out of scope.
EST客户端和服务器都配置了为相互身份验证和授权提供基础的信息。特定的初始化数据取决于客户端和服务器中可用的方法，但它可以包括共享机密、网络服务名称和位置（例如，统一资源标识符（URI）[RFC3986]）、信任锚信息（例如，CA证书或TA证书的哈希）以及注册密钥和证书。根据企业的采购和网络管理实践，供应商可在交付客户机硬件和软件之前执行一些初始化。在这种情况下，客户供应商可以通过安全过程向企业提供数据，例如信任锚。此初始信息的分发超出范围。
Distribution of trust anchors and other certificates can be effected via the EST server. However, nothing can be inferred about the authenticity of this data until an out-of-band mechanism is used to verify them.
信任锚和其他证书的分发可以通过EST服务器实现。但是，在使用带外机制验证这些数据之前，无法推断这些数据的真实性。
Sections 2.1-2.3 very closely mirror the text of the Scenarios Appendix of [RFC6403] with such modifications as are appropriate for this profile. Sections 2.1-2.6, below, enumerate the set of EST functions (see Figure 5) and provide an informative overview of EST's capabilities.
第2.1-2.3节非常接近于[RFC6403]方案附录的文本，并进行了适用于本概要的修改。下面第2.1-2.6节列举了EST功能集（见图5），并提供了EST功能的信息性概述。
The general client/server interaction proceeds as follows:
常规客户端/服务器交互过程如下所示：
The client initiates a TLS-secured HTTP session with an EST server.
客户端启动与EST服务器的TLS安全HTTP会话。
A specific EST service is requested based on a portion of the URI used for the session.
基于用于会话的URI的一部分请求特定的EST服务。
The client and server authenticate each other.
客户端和服务器相互验证。
The client verifies that the server is authorized to serve this client.
客户端验证服务器是否有权为该客户端提供服务。
The server verifies that the client is authorized to make use of this server and the request that the client has made.
服务器验证客户端是否有权使用此服务器以及客户端发出的请求。
The server acts upon the client request.
服务器根据客户机请求进行操作。
The EST client can request a copy of the current EST CA certificate(s) from the EST server. The EST client is assumed to perform this operation before performing other operations.
EST客户端可以从EST服务器请求当前EST CA证书的副本。假定EST客户端在执行其他操作之前执行此操作。
Throughout this document we assume the EST CA has a certificate that is used by the client to verify signed objects issued by the CA, e.g., certificates and certificate revocation lists (CRLs), and that a different certificate than the one used to verify signatures on certificates and CRLs is used when EST protocol communication requires additional encryption.
在本文档中，我们假设EST CA拥有一个证书，客户端使用该证书来验证CA颁发的签名对象，例如证书和证书撤销列表（CRL），当EST协议通信需要额外加密时，使用不同于用于验证证书和CRL上签名的证书。
The EST client authenticates and verifies the authorization scope of the EST server when requesting the current CA certificate(s). As detailed in Sections 3.3.1 and 3.3.3, available options include:
当请求当前CA证书时，EST客户端验证和验证EST服务器的授权范围。如第3.3.1节和第3.3.3节所述，可用选项包括：
o Verifying the EST server's HTTPS URI against the EST server's certificate using Implicit TAs (similar to a common HTTPS exchange). This allows the EST server and client to leverage existing TAs that might be known to the EST client.
o 使用隐式TA（类似于公共HTTPS交换）根据EST服务器的证书验证EST服务器的HTTPS URI。这允许EST服务器和客户端利用EST客户端可能知道的现有TA。
o The client can leverage a previously distributed trust anchor specific to the EST server. This allows the EST client to use an existing, potentially older, CA certificate to request a current CA certificate.
o 客户机可以利用特定于EST服务器的先前分布式信任锚。这允许EST客户端使用现有的、可能较旧的CA证书来请求当前CA证书。
o For bootstrapping, the EST client can rely upon manual authentication performed by the end-user as detailed in Section 4.1.1.
o 对于引导，EST客户端可以依赖最终用户执行的手动身份验证，详见第4.1.1节。
o The client can leverage the binding of a shared credential to a specific EST server with a certificate-less TLS cipher suite.
o 客户端可以利用无证书TLS密码套件将共享凭证绑定到特定EST服务器。
Client authentication is not required for this exchange, so it is trivially supported by the EST server.
此交换不需要客户端身份验证，因此EST服务器通常支持客户端身份验证。
After authenticating an EST server and verifying that it is authorized to provide services to the client, an EST client can acquire a certificate for itself by submitting an enrollment request to that server.
对EST服务器进行身份验证并验证其有权向客户端提供服务后，EST客户端可以通过向该服务器提交注册请求来为自己获取证书。
The EST server authenticates and authorizes the EST client as specified in Sections 3.3.2, 3.3.3, and 3.7. The methods described in the normative text that are discussed in this overview include:
EST服务器按照第3.3.2节、第3.3.3节和第3.7节的规定对EST客户端进行身份验证和授权。本概述中讨论的规范性文本中描述的方法包括：
o TLS with a previously issued client certificate (e.g., an existing certificate issued by the EST CA);
o 具有先前颁发的客户证书（例如，由EST CA颁发的现有证书）的TLS；
o TLS with a previously installed certificate (e.g., manufacturer-installed certificate or a certificate issued by some other party);
o 具有先前安装证书的TLS（例如，制造商安装的证书或其他方颁发的证书）；
o Certificate-less TLS (e.g., with a shared credential distributed out-of-band);
o 无证书TL（例如，带外分发共享凭证）；
o HTTP-based with a username/password distributed out-of-band.
o 基于HTTP，用户名/密码分布在带外。
If the EST client has a previously installed certificate issued by a third-party CA, this certificate can be used to authenticate the client's request for a certificate from the EST server (if that CA is recognized by the EST server). An EST client responds to the EST server's TLS certificate request message with the existing certificate already held by the client. The EST server will verify the client's existing certificate and authorize the client's request as described in Section 3.3.2.
如果EST客户端具有以前安装的由第三方CA颁发的证书，则该证书可用于验证客户端对来自EST服务器的证书的请求（如果EST服务器识别该CA）。EST客户端使用客户端已持有的现有证书响应EST服务器的TLS证书请求消息。EST服务器将验证客户的现有证书，并按照第3.3.2节所述授权客户的请求。
The EST client and EST server can be mutually authenticated using a certificate-less TLS cipher suite (see Section 3.3.3).
EST客户端和EST服务器可以使用无证书TLS密码套件进行相互身份验证（见第3.3.3节）。
The EST server can optionally also request that the EST client submit a username/password using the HTTP Basic or Digest authentication methods (see Section 3.2.3). This approach is desirable if the EST client cannot be authenticated during the TLS handshake (see Section 3.3.2) or the EST server policy requires additional authentication information; see Section 3.2.3. In all cases, HTTP-based client authentication is only to be performed over a TLS-protected transport (see Section 3.3).
EST服务器还可以选择请求EST客户端使用HTTP基本或摘要身份验证方法提交用户名/密码（见第3.2.3节）。如果在TLS握手过程中无法对EST客户端进行身份验证（参见第3.3.2节），或者EST服务器策略需要额外的身份验证信息，则该方法是可取的；见第3.2.3节。在所有情况下，基于HTTP的客户端身份验证只能通过受TLS保护的传输执行（请参见第3.3节）。
An EST client can renew/rekey its existing client certificate by submitting a re-enrollment request to an EST server.
EST客户端可以通过向EST服务器提交重新注册请求来更新/重新设置其现有客户端证书的密钥。
When the current EST client certificate can be used for TLS client authentication (Section 3.3.2), the client presents this certificate to the EST server for client authentication. When the to be reissued EST client certificate cannot be used for TLS client authentication, any of the authentication methods used for initial enrollment can be used.
当当前EST客户端证书可用于TLS客户端身份验证（第3.3.2节）时，客户端将此证书提交给EST服务器进行客户端身份验证。当要重新颁发的EST客户端证书无法用于TLS客户端身份验证时，可以使用初始注册所使用的任何身份验证方法。
For example, if the client has an alternative certificate issued by the EST CA that can be used for TLS client authentication, then it can be used.
例如，如果客户机具有EST CA颁发的可用于TLS客户机身份验证的替代证书，则可以使用该证书。
The certificate request message includes the same Subject and SubjectAltName as the current certificate. Name changes are requested as specified in Section 4.2.2.
证书请求消息包含与当前证书相同的Subject和SubjectAltName。根据第4.2.2节的规定要求更改名称。
The EST client can request a server-generated certificate and key pair (see Section 4.4).
EST客户端可以请求服务器生成的证书和密钥对（参见第4.4节）。
Full PKI Request [RFC5272] messages can be transported via EST using the Full CMC Request function. This affords access to functions not provided by the Simple Enrollment functions. Full PKI Request messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See Section 4.3 for a discussion of how EST provides a transport for these messages.
完整的PKI请求[RFC5272]消息可以使用完整的CMC请求功能通过EST传输。这提供了对简单注册函数未提供的函数的访问。[RFC5272]第3.2节和第4.2节定义了完整的PKI请求消息。有关EST如何为这些消息提供传输的讨论，请参见第4.3节。
Prior to sending an enrollment request to an EST server, an EST client can query the EST server for a set of additional attributes that the client is requested to use in a subsequent enrollment request.
在向EST服务器发送注册请求之前，EST客户端可以向EST服务器查询一组附加属性，请求客户端在后续注册请求中使用这些属性。
These attributes can provide additional descriptive information that the EST server cannot access itself, such as the Media Access Control (MAC) address of an interface of the EST client. Alternatively, these attributes can indicate the kind of enrollment request, such as a specific elliptic curve or a specific hash function that the client is expected to use when generating the CSR.
这些属性可以提供EST服务器自身无法访问的其他描述性信息，例如EST客户端接口的媒体访问控制（MAC）地址。或者，这些属性可以指示注册请求的类型，例如客户端在生成CSR时预期使用的特定椭圆曲线或特定哈希函数。
Figure 2 provides an expansion of Figure 1, describing how the layers are used. Each aspect is described in more detail in the sections that follow.
图2提供了图1的扩展，描述了如何使用这些层。以下各节将对每个方面进行更详细的描述。
EST Layering:
EST分层：
Protocols and uses:
+----------------------------------------------------+
| |
| Message types: |
| - "Simple PKI" messages |
| (incorporates proof-of-possession) |
| - CA certificate retrieval |
| - "Full PKI" messages (OPTIONAL) |
| (incorporates proof-of-possession) |
| - CSR Attributes Request (OPTIONAL) |
| - Server-generated key request (OPTIONAL) |
| |
+----------------------------------------------------+
| |
| HTTP: |
| - HTTP headers and URIs for control |
| - Content-Type headers specify message type |
| - Headers for control/error messages |
| - URIs for selecting functions |
| - Basic or Digest authentication (OPTIONAL) |
| |
+----------------------------------------------------+
| |
| TLS for transport security: |
| - Authentication of the EST server |
| - Authentication of the EST client (OPTIONAL) |
| - Provides communications integrity |
| and confidentiality |
| - Supplies channel-binding [RFC5929] information |
| to link proof-of-identity with message-based |
| proof-of-possession (OPTIONAL) |
| |
+----------------------------------------------------+
Protocols and uses:
+----------------------------------------------------+
| |
| Message types: |
| - "Simple PKI" messages |
| (incorporates proof-of-possession) |
| - CA certificate retrieval |
| - "Full PKI" messages (OPTIONAL) |
| (incorporates proof-of-possession) |
| - CSR Attributes Request (OPTIONAL) |
| - Server-generated key request (OPTIONAL) |
| |
+----------------------------------------------------+
| |
| HTTP: |
| - HTTP headers and URIs for control |
| - Content-Type headers specify message type |
| - Headers for control/error messages |
| - URIs for selecting functions |
| - Basic or Digest authentication (OPTIONAL) |
| |
+----------------------------------------------------+
| |
| TLS for transport security: |
| - Authentication of the EST server |
| - Authentication of the EST client (OPTIONAL) |
| - Provides communications integrity |
| and confidentiality |
| - Supplies channel-binding [RFC5929] information |
| to link proof-of-identity with message-based |
| proof-of-possession (OPTIONAL) |
| |
+----------------------------------------------------+
Figure 2
图2
Specifying HTTPS as the secure transport for enrollment messages introduces two "layers" to communicate authentication and control messages: TLS and HTTP.
将HTTPS指定为注册消息的安全传输引入了两个“层”来通信身份验证和控制消息：TLS和HTTP。
The TLS layer provides integrity and confidentiality during transport. The proof-of-identity is supplied by TLS handshake authentication and optionally also by the HTTP layer headers. The message type and control/error messages are included in the HTTP headers.
TLS层在传输过程中提供完整性和机密性。身份证明由TLS握手身份验证提供，也可以由HTTP层头提供。消息类型和控制/错误消息包含在HTTP头中。
CMC ([RFC5272], Section 3.1) notes that "the Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included". Since the TLS and HTTP layers can provide proof-of-identity for EST clients and servers, the Simple PKI message types are used.
CMC（[RFC5272]，第3.1节）指出，“如果需要包括身份证明，则不得使用简单PKI请求”。由于TLS和HTTP层可以为EST客户端和服务器提供身份证明，因此使用了简单的PKI消息类型。
The TLS layer certificate exchange provides a method for authorizing client enrollment requests using existing certificates. Such certificates may have been issued by the CA (from which the client is requesting a certificate), or they may have been issued under a distinct PKI (e.g., an IEEE 802.1AR Initial Device Identifier (IDevID) [IDevID] credential).
TLS层证书交换提供了一种使用现有证书授权客户端注册请求的方法。此类证书可能是由CA（客户机正在从CA请求证书）颁发的，或者它们可能是在不同的PKI（例如，IEEE 802.1AR初始设备标识符（IDevID）[IDevID]凭证）下颁发的。
Proof-of-possession (POP) is a distinct issue from proof-of-identity and is included in the Simple PKI message type as described in Section 3.4. A method of linking proof-of-identity and proof-of-possession is described in Section 3.5.
占有证明（POP）是与身份证明不同的问题，包含在第3.4节所述的简单PKI消息类型中。第3.5节描述了将身份证明和占有证明联系起来的方法。
This document also defines transport for CMC [RFC5272] that complies with the CMC Transport Protocols [RFC5273]. CMC's POP and proof-of-identity mechanisms are defined in CMC, but the mechanisms here can also be used in conjunction with those mechanisms in "Full PKI" messages.
本文档还定义了符合CMC传输协议[RFC5273]的CMC[RFC5272]的传输。CMC的POP和身份证明机制在CMC中定义，但此处的机制也可以与“完整PKI”消息中的这些机制结合使用。
During protocol exchanges, different certificates can be used. The following table provides an informative overview. End-entities can have one or more certificates of each type listed in Figure 3 and use one or more trust anchor databases of each type listed in Figure 4.
在协议交换期间，可以使用不同的证书。下表提供了信息性概述。终端实体可以拥有图3中列出的每种类型的一个或多个证书，并使用图4中列出的每种类型的一个或多个信任锚数据库。
Certificates and their corresponding uses:
+--------------+--------------------+-------------------------------+
| Certificate | Issuer | Use and section references |
+==============+====================+===============================+
| EST server | The CA served by | Presented by the EST server |
| certificate | the EST server | during the TLS handshake. |
| | | |
| | | Section 3.3.1 |
+--------------+--------------------+-------------------------------+
| EST server | A CA | Presented by the EST server |
| certificate | authenticatable by | during the TLS handshake. |
| | a third-party TA, | |
| | e.g., a web server | Section 3.3.1 and |
| | CA | Security Considerations |
+--------------+--------------------+-------------------------------+
| Third-party | A CA | Presented by the EST client |
| EST client | authenticatable by | to the EST server by clients |
| certificate | a third-party TA, | that have not yet enrolled. |
| | e.g., a device | |
| | manufacturer | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Presented to the EST server |
| certificate | the EST server | during future EST operations. |
| | | |
| | | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| End-entity | The CA served by | Clients can obtain certs |
| certificate | the EST server | that are intended for |
| | | non-EST uses. This includes |
| | | certs that cannot be used |
| | | for EST operations. |
| | | |
| | | Section 4.2.3 |
+--------------+--------------------+-------------------------------+
Certificates and their corresponding uses:
+--------------+--------------------+-------------------------------+
| Certificate | Issuer | Use and section references |
+==============+====================+===============================+
| EST server | The CA served by | Presented by the EST server |
| certificate | the EST server | during the TLS handshake. |
| | | |
| | | Section 3.3.1 |
+--------------+--------------------+-------------------------------+
| EST server | A CA | Presented by the EST server |
| certificate | authenticatable by | during the TLS handshake. |
| | a third-party TA, | |
| | e.g., a web server | Section 3.3.1 and |
| | CA | Security Considerations |
+--------------+--------------------+-------------------------------+
| Third-party | A CA | Presented by the EST client |
| EST client | authenticatable by | to the EST server by clients |
| certificate | a third-party TA, | that have not yet enrolled. |
| | e.g., a device | |
| | manufacturer | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Presented to the EST server |
| certificate | the EST server | during future EST operations. |
| | | |
| | | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| End-entity | The CA served by | Clients can obtain certs |
| certificate | the EST server | that are intended for |
| | | non-EST uses. This includes |
| | | certs that cannot be used |
| | | for EST operations. |
| | | |
| | | Section 4.2.3 |
+--------------+--------------------+-------------------------------+
Figure 3
图3
Trust anchor databases and their corresponding uses:
+--------------+----------------------------------------------------+
| TA database | Use and section references |
+==============+====================================================+
| EST server | EST servers use this TA database to authenticate |
| Explicit | certificates issued by the EST CA, including EST |
| TA database | client certificates during enroll/re-enroll |
| | operations. |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST server | EST servers use this TA database to authenticate |
| Implicit | certificates issued by third-party TAs; |
| TA database | e.g., EST client certificates issued by a device |
| | manufacturer. |
| | An Implicit TA database can be disabled. |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to authenticate |
| Explicit | certificates issued by the EST CA, including EST |
| TA database | server certificates. |
| | |
| | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to |
| Implicit | authenticate an EST server that uses an externally |
| TA database | issued certificate. |
| | An Implicit TA database can be disabled. |
| | |
| | Sections 3.1, 3.3.1, 3.6.2, and |
| | Security Considerations |
+--------------+----------------------------------------------------+
Trust anchor databases and their corresponding uses:
+--------------+----------------------------------------------------+
| TA database | Use and section references |
+==============+====================================================+
| EST server | EST servers use this TA database to authenticate |
| Explicit | certificates issued by the EST CA, including EST |
| TA database | client certificates during enroll/re-enroll |
| | operations. |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST server | EST servers use this TA database to authenticate |
| Implicit | certificates issued by third-party TAs; |
| TA database | e.g., EST client certificates issued by a device |
| | manufacturer. |
| | An Implicit TA database can be disabled. |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to authenticate |
| Explicit | certificates issued by the EST CA, including EST |
| TA database | server certificates. |
| | |
| | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to |
| Implicit | authenticate an EST server that uses an externally |
| TA database | issued certificate. |
| | An Implicit TA database can be disabled. |
| | |
| | Sections 3.1, 3.3.1, 3.6.2, and |
| | Security Considerations |
+--------------+----------------------------------------------------+
Figure 4
图4
The EST client MUST be capable of generating and parsing Simple PKI messages (see Section 4.2). Generating and parsing Full PKI messages is OPTIONAL (see Section 4.3). The client MUST also be able to request CA certificates from the EST server and parse the returned "bag" of certificates (see Section 4.1). Requesting CSR attributes and parsing the returned list of attributes is OPTIONAL (see Section 4.5).
EST客户端必须能够生成和解析简单的PKI消息（参见第4.2节）。生成和解析完整的PKI消息是可选的（参见第4.3节）。客户端还必须能够从EST服务器请求CA证书，并解析返回的证书“包”（见第4.1节）。请求CSR属性并解析返回的属性列表是可选的（参见第4.5节）。
Details of the EST client application configuration are out of scope of the protocol discussion but are necessary for understanding the prerequisites of initiating protocol operations. The EST client is RECOMMENDED to be configured with TA databases for Section 3.3.1 or with a secret key for Section 3.3.3. Implementations conforming to this standard MUST provide the ability to designate Explicit TAs. For human usability reasons, a "fingerprint" of an Explicit TA database entry can be configured for bootstrapping as discussed in Section 4.1.1. Configuration of an Implicit TA database, perhaps by its inclusion within the EST client distribution or available from the operating system, provides flexibility along with the caveats detailed in Section 6. Implementations conforming to this standard MUST provide the ability to disable use of any Implicit TA database.
EST客户端应用程序配置的详细信息不在协议讨论的范围内，但对于理解启动协议操作的先决条件是必要的。建议为EST客户端配置第3.3.1节的TA数据库或第3.3.3节的密钥。符合本标准的实现必须能够指定明确的TA。出于人的可用性原因，可以配置显式TA数据库条目的“指纹”进行引导，如第4.1.1节所述。隐式TA数据库的配置，可能通过将其包含在EST客户机发行版中或可从操作系统获得，提供了灵活性以及第6节中详述的注意事项。符合本标准的实现必须提供禁用任何隐式TA数据库的能力。
The EST client is configured with sufficient information to form the EST server URI. This can be the full operation path segment (e.g., https://www.example.com/.well-known/est/ or https://www.example.com/.well-known/est/arbitraryLabel1), or the EST client can be configured with a tuple composed of the authority portion of the URI along with the OPTIONAL label (e.g., "www.example.com:80" and "arbitraryLabel1") or just the authority portion of the URI.
EST客户端配置了足够的信息以形成EST服务器URI。这可以是完整的操作路径段（例如。，https://www.example.com/.well-known/est/ 或https://www.example.com/.well-known/est/arbitraryLabel1)，或者EST客户端可以配置一个元组，该元组由URI的权限部分以及可选标签（例如，“www.example.com:80”和“arbitraryLabel1”）组成或者只是URI的授权部分。
HTTP is used to transfer EST messages. URIs are defined for handling each media type (i.e., message type) as described in Section 3.2.2. HTTP is also used for client authentication services when TLS client authentication is not available, due to the lack of a client certificate suitable for use by TLS (see Section 3.2.3). HTTP authentication can also be used in addition to TLS client authentication if the EST server wishes additional authentication information, as noted in Section 2.2.3. Registered media types are used to convey EST messages as specified in Figure 6.
HTTP用于传输EST消息。URI定义用于处理第3.2.2节所述的每种媒体类型（即消息类型）。由于缺少适合TLS使用的客户端证书，当TLS客户端身份验证不可用时，HTTP也用于客户端身份验证服务（见第3.2.3节）。如第2.2.3节所述，如果EST服务器需要额外的身份验证信息，则除了TLS客户端身份验证之外，还可以使用HTTP身份验证。注册的媒体类型用于传递EST消息，如图6所示。
HTTP 1.1 [RFC2616] and above support persistent connections. As described in Section 8.1 of RFC 2616, persistent connections may be used to reduce network and processing loads associated with multiple HTTP requests. EST does not require or preclude persistent HTTP connections.
HTTP 1.1[RFC2616]及以上版本支持持久连接。如RFC 2616第8.1节所述，持久连接可用于减少与多个HTTP请求相关的网络和处理负载。EST不需要或排除持久HTTP连接。
The HTTP Status value is used to communicate success or failure of an EST function. HTTP authentication is used by a client when requested by the server.
HTTP状态值用于传达EST函数的成功或失败。当服务器请求时，客户端使用HTTP身份验证。
The media types specified in the HTTP Content-Type header indicate which EST message is being transferred. Media types used by EST are specified in Section 3.2.4.
HTTP内容类型标头中指定的媒体类型指示正在传输的EST消息。第3.2.4节规定了EST使用的介质类型。
HTTP redirections (3xx status codes) to the same web origin (see [RFC6454]) SHOULD be handled by the client without user input so long as all applicable security checks (Sections 3.3 and 3.6) have been enforced on the initial connection. The client initiates a new TLS connection and performs all applicable security checks when redirected to other web origin servers. Redirections to other web origins require the EST client to obtain user input for non-GET or HEAD requests as specified in [RFC2616]. Additionally, if the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session. Note: the key pair need not be regenerated. These are processing and interface burdens on the client. EST server administrators are advised to take this into consideration.
只要在初始连接上执行了所有适用的安全检查（第3.3节和第3.6节），客户端应在无需用户输入的情况下处理到同一web源的HTTP重定向（3xx状态代码）（请参见[RFC6454]）。客户端启动新的TLS连接，并在重定向到其他web源服务器时执行所有适用的安全检查。按照[RFC2616]中的规定，重定向到其他web源需要EST客户端获取非GET或HEAD请求的用户输入。此外，如果客户端已经生成了包含链接标识和POP信息的CSR（第3.5节），则需要重新创建CSR，以合并新重定向会话中唯一的tls。注意：不需要重新生成密钥对。这些是客户端的处理和接口负担。建议EST服务器管理员考虑这一点。
The EST server MUST support the use of the path-prefix of "/.well-known/" as defined in [RFC5785] and the registered name of "est". Thus, a valid EST server URI path begins with "https://www.example.com/.well-known/est". Each EST operation is indicated by a path-suffix that indicates the intended operation:
EST服务器必须支持使用[RFC5785]中定义的路径前缀“/.well-known/”和注册名称“EST”。因此，有效的EST服务器URI路径以“https://www.example.com/.well-known/est". 每个EST操作由一个路径后缀表示，该后缀表示预期操作：
Operations and their corresponding URIs:
+------------------------+-----------------+-------------------+
| Operation |Operation path | Details |
+========================+=================+===================+
| Distribution of CA | /cacerts | Section 4.1 |
| Certificates (MUST) | | |
+------------------------+-----------------+-------------------+
| Enrollment of | /simpleenroll | Section 4.2 |
| Clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Re-enrollment of | /simplereenroll | Section 4.2.2 |
| Clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Full CMC (OPTIONAL) | /fullcmc | Section 4.3 |
+------------------------+-----------------+-------------------+
| Server-Side Key | /serverkeygen | Section 4.4 |
| Generation (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
| CSR Attributes | /csrattrs | Section 4.5 |
| (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
Operations and their corresponding URIs:
+------------------------+-----------------+-------------------+
| Operation |Operation path | Details |
+========================+=================+===================+
| Distribution of CA | /cacerts | Section 4.1 |
| Certificates (MUST) | | |
+------------------------+-----------------+-------------------+
| Enrollment of | /simpleenroll | Section 4.2 |
| Clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Re-enrollment of | /simplereenroll | Section 4.2.2 |
| Clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Full CMC (OPTIONAL) | /fullcmc | Section 4.3 |
+------------------------+-----------------+-------------------+
| Server-Side Key | /serverkeygen | Section 4.4 |
| Generation (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
| CSR Attributes | /csrattrs | Section 4.5 |
| (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
Figure 5
图5
The operation path (Figure 5) is appended to the path-prefix to form the URI used with HTTP GET or POST to perform the desired EST operation. An example valid URI absolute path for the "/cacerts" operation is "/.well-known/est/cacerts". To retrieve the CA's certificates, the EST client would use the following HTTP request-line:
操作路径（图5）被附加到路径前缀，以形成与HTTPGET或POST一起使用的URI，以执行所需的EST操作。“/cacerts”操作的有效URI绝对路径示例为“/.well-known/est/cacerts”。要检索CA的证书，EST客户端将使用以下HTTP请求行：
GET /.well-known/est/cacerts HTTP/1.1
GET /.well-known/est/cacerts HTTP/1.1
Likewise, to request a new certificate in this example scheme, the EST client would use the following request-line:
同样，要在此示例方案中请求新证书，EST客户端将使用以下请求行：
POST /.well-known/est/simpleenroll HTTP/1.1
POST /.well-known/est/simpleenroll HTTP/1.1
The use of distinct operation paths simplifies implementation for servers that do not perform client authentication when distributing /cacerts responses.
使用不同的操作路径简化了在分发/cacerts响应时不执行客户端身份验证的服务器的实现。
An EST server MAY provide service for multiple CAs as indicated by an OPTIONAL additional path segment between the registered application name and the operation path. To avoid conflict, the CA label MUST NOT be the same as any defined operation path segment. The EST server MUST provide services regardless of whether the additional path segment is present. The following are three example valid URIs:
EST服务器可以为多个CA提供服务，如注册的应用程序名称和操作路径之间的可选附加路径段所示。为避免冲突，CA标签不得与任何定义的操作路径段相同。无论是否存在附加路径段，EST服务器都必须提供服务。以下是三个有效URI示例：
1. https://www.example.com/.well-known/est/cacerts
1. https://www.example.com/.well-known/est/cacerts
2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts
2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts
3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts
3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts
In this specification, the distinction between enroll and renew/rekey is explicitly indicated by the HTTP URI. When requesting /fullcmc operations, CMC [RFC5272] uses the same messages for certificate renewal and certificate rekey.
在本规范中，注册和续订/重新密钥之间的区别由HTTP URI明确表示。当请求/fullcmc操作时，CMC[RFC5272]使用相同的消息进行证书续订和证书重新密钥设置。
An EST server can provide additional services using other URIs.
EST服务器可以使用其他URI提供附加服务。
The EST server MAY request HTTP-based client authentication. This request can be in addition to successful TLS client authentication (Section 3.3.2) if EST server policy requires additional authentication. (For example, the EST server may require that an EST client "knows" a password in addition to "having" an existing client certificate.) Or, HTTP-based client authentication can be an EST server policy-specified fallback in situations where the EST client did not successfully complete the TLS client authentication. (This might arise if the EST client is enrolling for the first time or if the certificates available to an EST client cannot be used for TLS client authentication.)
EST服务器可以请求基于HTTP的客户端身份验证。如果EST服务器策略需要额外的身份验证，则此请求可以是成功的TLS客户端身份验证（第3.3.2节）的补充。（例如，EST服务器可能要求EST客户端除了“拥有”现有客户端证书之外还“知道”密码。）或者，基于HTTP的客户端身份验证可以是EST客户端未成功完成TLS客户端身份验证情况下指定的EST服务器策略回退。（如果EST客户端是第一次注册，或者EST客户端可用的证书无法用于TLS客户端身份验证，则可能会出现这种情况。）
HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST NOT be used because they do not provide confidentiality or support mutual certificate-based or certificate-less authentication, respectively. As specified in "Certificate Management over CMS (CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication". Clients SHOULD support the Basic and Digest authentication mechanism.
HTTP基本和摘要身份验证只能在TLS 1.1[RFC4346]或更高版本上执行。不能使用NULL和anon密码套件，因为它们分别不提供机密性或不支持基于相互证书或无证书的身份验证。如“CMS上的证书管理（CMC）：传输协议”[RFC5273]中所述，服务器“不得假定客户端支持任何类型的HTTP身份验证，如cookie、基本身份验证或摘要身份验证”。客户端应支持基本和摘要身份验证机制。
Servers that wish to use Basic and Digest authentication reject the HTTP request using the HTTP-defined WWW-Authenticate response-header ([RFC2616], Section 14.47). The client is expected to retry the request, including the appropriate Authorization Request header ([RFC2617], Section 3.2.2), if the client is capable of using the Basic or Digest authentication. If the client is not capable of retrying the request or it is not capable of Basic or Digest authentication, then the client MUST terminate the connection.
希望使用基本和摘要身份验证的服务器使用HTTP定义的WWW Authenticate响应头（[RFC2616]，第14.47节）拒绝HTTP请求。如果客户端能够使用基本或摘要身份验证，则客户端将重试请求，包括相应的授权请求标头（[RFC2617]，第3.2.2节）。如果客户端无法重试请求或无法进行基本或摘要身份验证，则客户端必须终止连接。
A client MAY set the username to the empty string ("") if it is presenting a password that is not associated with a username.
如果客户端提供的密码与用户名无关，则可以将用户名设置为空字符串（“”）。
Support for HTTP-based client authentication has security ramifications as discussed in Section 6. The client MUST NOT respond to the server's HTTP authentication request unless the client has authorized the EST server (as per Section 3.6).
对基于HTTP的客户端身份验证的支持具有第6节中讨论的安全后果。除非客户机已授权EST服务器（根据第3.6节），否则客户机不得响应服务器的HTTP身份验证请求。
This document uses existing media types for the messages as specified by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC [RFC5272].
本文档使用FTP和HTTP[RFC2585]、application/pkcs10[RFC5967]和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 and their corresponding media types for each operation are:
每个操作的EST消息及其相应的媒体类型如下：
+--------------------+--------------------------+-------------------+
| Message type | Request media type | Request section(s)|
| | Response media type(s) | Response section |
| (per operation) | Source(s) of types | |
+====================+==========================+===================+
| Distribution of CA | N/A | Section 4.1 |
| Certificates | application/pkcs7-mime | Section 4.1.1 |
| | [RFC5751] | |
| /cacerts | | |
+--------------------+--------------------------+-------------------+
| Client Certificate | application/pkcs10 | Sections 4.2/4.2.1|
| Request Functions | application/pkcs7-mime | Section 4.2.2 |
| | [RFC5967] [RFC5751] | |
| /simpleenroll | | |
| /simplereenroll | | |
+--------------------+--------------------------+-------------------+
| Full CMC | application/pkcs7-mime | Section 4.3.1 |
| | application/pkcs7-mime | Section 4.3.2 |
| /fullcmc | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Server-Side Key | application/pkcs10 | Section 4.4.1 |
| Generation | multipart/mixed | Section 4.4.2 |
| | (application/pkcs7-mime &| |
| | application/pkcs8) | |
| | [RFC5967] [RFC5751] | |
| /serverkeygen | [RFC5958] | |
+--------------------+--------------------------+-------------------+
| CSR Attributes | N/A | Section 4.5.1 |
| | application/csrattrs | Section 4.5.2 |
| | (This document) | |
| /csrattrs | | |
+--------------------+--------------------------+-------------------+
+--------------------+--------------------------+-------------------+
| Message type | Request media type | Request section(s)|
| | Response media type(s) | Response section |
| (per operation) | Source(s) of types | |
+====================+==========================+===================+
| Distribution of CA | N/A | Section 4.1 |
| Certificates | application/pkcs7-mime | Section 4.1.1 |
| | [RFC5751] | |
| /cacerts | | |
+--------------------+--------------------------+-------------------+
| Client Certificate | application/pkcs10 | Sections 4.2/4.2.1|
| Request Functions | application/pkcs7-mime | Section 4.2.2 |
| | [RFC5967] [RFC5751] | |
| /simpleenroll | | |
| /simplereenroll | | |
+--------------------+--------------------------+-------------------+
| Full CMC | application/pkcs7-mime | Section 4.3.1 |
| | application/pkcs7-mime | Section 4.3.2 |
| /fullcmc | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Server-Side Key | application/pkcs10 | Section 4.4.1 |
| Generation | multipart/mixed | Section 4.4.2 |
| | (application/pkcs7-mime &| |
| | application/pkcs8) | |
| | [RFC5967] [RFC5751] | |
| /serverkeygen | [RFC5958] | |
+--------------------+--------------------------+-------------------+
| CSR Attributes | N/A | Section 4.5.1 |
| | application/csrattrs | Section 4.5.2 |
| | (This document) | |
| /csrattrs | | |
+--------------------+--------------------------+-------------------+
Figure 6
图6
TLS provides authentication, which in turn enables authorization decisions. The EST server and EST client are responsible for ensuring that an acceptable cipher suite is negotiated and that mutual authentication has been performed. TLS authentication is most commonly enabled with the use of certificates [RFC5280]. Alternately, certificate-less TLS authentication, where neither the client nor server present a certificate, is also an acceptable method for EST mutual authentication (Section 3.3.3). The EST server MUST be authenticated during the TLS handshake unless the client is requesting Bootstrap Distribution of CA certificates (Section 4.1.1) or Full CMC (Section 4.3).
TLS提供身份验证，从而支持授权决策。EST服务器和EST客户端负责确保协商可接受的密码套件，并执行相互身份验证。TLS身份验证通常通过使用证书启用[RFC5280]。或者，无证书TLS认证（客户端和服务器均不提供证书）也是EST相互认证的可接受方法（第3.3.3节）。在TLS握手期间，必须对EST服务器进行身份验证，除非客户端请求CA证书的引导分发（第4.1.1节）或完整CMC（第4.3节）。
HTTPS [RFC2818] specifies how HTTP messages are carried over TLS. HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be used for all EST communications. TLS session resumption [RFC5077] SHOULD be supported.
HTTPS[RFC2818]指定如何通过TLS传输HTTP消息。必须使用HTTPS。所有EST通信必须使用TLS 1.1[RFC4346]（或更高版本）。应支持TLS会话恢复[RFC5077]。
TLS channel-binding information can be inserted into a certificate request, as detailed in Section 3.5, in order to provide the EST server with assurance that the authenticated TLS client has access to the private key for the certificate being requested. The EST server MUST implement Section 3.5.
如第3.5节所述，可以将TLS通道绑定信息插入到证书请求中，以便向EST服务器提供认证TLS客户端可以访问所请求证书的私钥的保证。EST服务器必须执行第3.5节。
TLS server authentication with certificates MUST be supported.
必须支持带有证书的TLS服务器身份验证。
The EST client authenticates the EST server as defined for the cipher suite negotiated. The following text provides details assuming a certificate-based cipher suite, such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).
EST客户端按照为协商的密码套件定义的方式对EST服务器进行身份验证。以下文本提供了基于证书的密码套件的详细信息，例如TLS 1.1[RFC4346]强制密码套件（TLS_RSA_WITH_3DES_EDE_CBC_SHA）。
Certificate validation MUST be performed as per [RFC5280]. The EST server certificate MUST conform to the [RFC5280] certificate profile.
必须按照[RFC5280]执行证书验证。EST服务器证书必须符合[RFC5280]证书配置文件。
The client validates the TLS server certificate using the EST client Explicit and, if enabled, Implicit TA database(s). The client MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization. The EST client MUST perform authorization checks as specified in Section 3.6.
客户端使用EST客户端显式和隐式TA数据库（如果启用）验证TLS服务器证书。客户端必须在身份验证期间区分显式和隐式TA数据库的使用，以支持正确的授权。EST客户必须按照第3.6节的规定进行授权检查。
If certificate validation fails, the client MAY follow the procedure outlined in Section 4.1.1 for Bootstrap Distribution of CA certificates.
如果证书验证失败，客户机可以按照第4.1.1节中概述的步骤进行CA证书的引导分发。
TLS client authentication is the RECOMMENDED method for identifying EST clients. HTTP-based client authentication (Section 3.2.3) MAY be used.
TLS客户端身份验证是识别EST客户端的推荐方法。可以使用基于HTTP的客户端身份验证（第3.2.3节）。
The EST server authenticates the EST client as defined for the cipher suite negotiated. The following text provides details assuming a certificate-based cipher suite such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST server MUST support certificate-based client authentication.
EST服务器验证为协商的密码套件定义的EST客户端。下文提供了基于证书的密码套件的详细信息，如TLS 1.1[RFC4346]强制密码套件（TLS_RSA_WITH_3DES_EDE_CBC_SHA）。EST服务器必须支持基于证书的客户端身份验证。
Generally, the client will use an existing certificate for renew or rekey operations. If the certificate to be renewed or rekeyed is appropriate for the negotiated cipher suite, then the client MUST use it for the TLS handshake, otherwise the client SHOULD use an alternate certificate that is suitable for the cipher suite and contains the same subject identity information. When requesting an enroll operation, the client MAY use a client certificate issued by a third party to authenticate itself.
通常，客户将使用现有证书进行续订或重新密钥操作。如果要续订或重新设置密钥的证书适用于协商密码套件，则客户端必须将其用于TLS握手，否则客户端应使用适用于密码套件且包含相同主体身份信息的备用证书。当请求注册操作时，客户端可以使用由第三方颁发的客户端证书来认证自身。
Certificate validation MUST be performed as per [RFC5280]. The EST client certificate MUST conform to the [RFC5280] certificate profile.
必须按照[RFC5280]执行证书验证。EST客户端证书必须符合[RFC5280]证书配置文件。
The server validates the TLS client certificate using the EST server Explicit and, if enabled, Implicit TA database(s). The server MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization.
服务器使用EST服务器显式和隐式TA数据库（如果启用）验证TLS客户端证书。服务器必须在身份验证期间区分显式和隐式TA数据库的使用，以支持正确的授权。
The EST server MUST perform authorization checks as specified in Section 3.7.
EST服务器必须按照第3.7节的规定执行授权检查。
If a client does not support TLS client authentication, then it MUST support HTTP-based client authentication (Section 3.2.3) or certificate-less TLS authentication (Section 3.3.3).
如果客户端不支持TLS客户端身份验证，则它必须支持基于HTTP的客户端身份验证（第3.2.3节）或无证书TLS身份验证（第3.3.3节）。
Certificate-less TLS cipher suites provide a way to perform mutual authentication in situations where neither the client nor server have certificates, do not desire to use certificates, or do not have the trust anchors necessary to verify a certificate. The client and server MAY negotiate a certificate-less cipher suite for mutual authentication.
无证书TLS密码套件提供了一种在客户端和服务器都没有证书、不希望使用证书或没有验证证书所需的信任锚的情况下执行相互身份验证的方法。客户端和服务器可以协商无证书密码套件以进行相互身份验证。
When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be based on a protocol that is
在TLS中使用无证书相互身份验证进行注册时，密码套件必须基于
resistant to dictionary attack and MUST be based on a zero knowledge protocol. Transport Layer Security-Secure Remote Password (TLS-SRP) cipher suites, i.e., those with _SRP_ in the name, listed in Section 2.7 of [RFC5054] are suitable for this purpose. Section 6 lists the characteristics of a cipher suite that are suitable for use in certificate-less mutual authentication for enrollment.
抗字典攻击，必须基于零知识协议。传输层安全远程密码（TLS-SRP）密码套件，即[RFC5054]第2.7节中列出的名称中带有_SRP_的密码套件，适用于此目的。第6节列出了适用于注册无证书相互认证的密码套件的特征。
Successful authentication using a certificate-less cipher suite proves knowledge of a pre-shared secret that implicitly authorizes a peer in the exchange.
使用无证书密码套件成功地进行身份验证，证明了预先共享的秘密已为exchange中的对等方隐式授权。
As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP) "refers to a value that can be used to prove that the private key corresponding to the public key is in the possession of and can be used by an end-entity".
如CMC[RFC5272]第2.1节所定义，占有证明（POP）“指可用于证明与公钥相对应的私钥由最终实体占有并可供其使用的值”。
The signed enrollment request provides a signature-based proof-of-possession. The mechanism described in Section 3.5 strengthens this by optionally including "Direct"-based proof-of-possession [RFC5272] by including TLS session-specific information within the data covered by the enrollment request signature (thus linking the enrollment request to the authenticated end point of the TLS connection).
签名的注册请求提供基于签名的占有证明。第3.5节中描述的机制通过在注册请求签名覆盖的数据中包括TLS会话特定信息（从而将注册请求链接到TLS连接的认证端点），选择性地包括基于“直接”的占有证明[RFC5272]，从而加强了这一点。
Server policy will determine whether clients are required to use the mechanism specified in this section. This specification provides a method of linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request. The client can determine if the server requires the linking of identity and POP by examining the CSR Attributes Response (see Section 4.5.2). Regardless of the CSR Attributes Response, clients SHOULD link identity and POP by embedding tls-unique information in the certification request. If tls-unique information is included by the client, the server MUST verify it. The EST server MAY reject requests without tls-unique information as indicated by server policy.
服务器策略将确定客户端是否需要使用本节中指定的机制。本规范通过在签名的认证请求中包含特定于当前已认证TLS会话的信息，提供了一种链接身份和占有证明的方法。客户端可以通过检查CSR属性响应（参见第4.5.2节）来确定服务器是否需要标识和POP的链接。不管CSR属性响应如何，客户端都应该通过在认证请求中嵌入tls唯一信息来链接标识和POP。如果客户端包含tls唯一信息，则服务器必须对其进行验证。EST服务器可以拒绝没有服务器策略指示的tls唯一信息的请求。
Linking identity and proof-of-possession proves to the server that the authenticated TLS client has possession of the private key associated with the certification request, and that the client was able to sign the certification request after the TLS session was established. This is an alternative to the "Linking Identity and POP Information" method defined by Section 6 of [RFC5272] that is available if Full PKI messages are used.
链接身份和占有证明向服务器证明，经过身份验证的TLS客户端拥有与认证请求相关联的私钥，并且客户端能够在TLS会话建立后签署认证请求。这是[RFC5272]第6节定义的“链接身份和POP信息”方法的替代方法，如果使用完整的PKI消息，该方法可用。
The client generating the CSR obtains the tls-unique value from the TLS subsystem as described in Channel Bindings for TLS [RFC5929]. The EST client operations between obtaining the tls-unique value through generation of the CSR that contains the current tls-unique value and the subsequent verification of this value by the EST server are the "phases of the application protocol during which application-layer authentication occurs"; these operations are protected by the synchronization interoperability mechanism described in the "Channel Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929].
生成CSR的客户端从tls子系统获得tls唯一值，如tls的通道绑定[RFC5929]中所述。通过生成包含当前tls唯一值的CSR获得tls唯一值与EST服务器随后验证该值之间的EST客户端操作为“应用层认证发生期间的应用协议阶段”；这些操作受[RFC5929]第3.1节“TLS通道绑定”互操作性说明中描述的同步互操作性机制保护。
When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used.
执行重新协商时，必须使用TLS“安全重新协商”[RFC5746]。
The tls-unique value is base64 encoded as specified in Section 4 of [RFC4648], and the resulting string is placed in the certification request challenge-password field ([RFC2985], Section 5.4.1). The challenge-password field is limited to 255 bytes (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation). If the challenge-password attribute is absent, the client did not include the optional channel-binding information (the presence of the challenge-password attribute indicates the inclusion of tls-unique information).
tls唯一值按照[RFC4648]第4节的规定进行base64编码，生成的字符串放入认证请求质询密码字段（[RFC2985]，第5.4.1节）。质询密码字段限制为255字节（RFC5246第7.4.9节指出，现有密码套件不会导致此限制问题）。如果缺少质询密码属性，则客户端未包含可选通道绑定信息（质询密码属性的存在表示包含tls唯一信息）。
If the EST server makes use of a back-end infrastructure for processing, it is RECOMMENDED that the results of this verification be communicated. (For example, this communication might use the CMC [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message. Or, an EST server might TLS-authenticate an EST client as being a trusted infrastructure element that does not forward invalid requests. A detailed discussion of back-end processing is out of scope.)
如果EST服务器使用后端基础设施进行处理，建议将此验证的结果进行通信。（例如，此通信可能在CMC完整PKI请求消息中使用CMC[RFC5272]“RA POP见证控制”。或者，EST服务器可能TLS将EST客户端验证为不转发无效请求的受信任基础结构元素。后端处理的详细讨论不在范围内。）
When rejecting requests, the EST server response is as described for all enroll responses (Section 4.2.3). If a Full PKI Response is included, the CMCFailInfo MUST be set to popFailed. If a human-readable reject message is included, it SHOULD include an informative text message indicating that the linking of identity and POP information is required.
拒绝请求时，EST服务器响应如所有注册响应所述（第4.2.3节）。如果包含完整的PKI响应，则必须将CMCFailInfo设置为popFailed。如果包含人类可读的拒绝消息，则应包含一条信息性文本消息，指示需要链接身份和POP信息。
The client MUST check EST server authorization before accepting any server responses or responding to HTTP authentication requests.
在接受任何服务器响应或响应HTTP身份验证请求之前，客户端必须检查EST服务器授权。
The EST client authorization method depends on which method was used to authenticate the server. When the Explicit TA database is used to authenticate the EST server, then Section 3.6.1 applies. When the Implicit TA database is used to authenticate the EST server, then
EST客户端授权方法取决于用于验证服务器的方法。当显式TA数据库用于验证EST服务器时，第3.6.1节适用。当隐式TA数据库用于对EST服务器进行身份验证时
Section 3.6.2 applies. Successful authentication using a certificate-less cipher suite implies authorization of the server.
第3.6.2节适用。使用无证书密码套件成功进行身份验证意味着对服务器进行授权。
The client MAY perform bootstrapping as specified in Section 4.1.1 even if these checks fail.
即使这些检查失败，客户机也可以按照第4.1.1节的规定执行引导。
When the EST client Explicit TA database is used to validate the EST server certificate, the client MUST check either the configured URI or the most recent HTTP redirection URI against the server's identity according to the rules specified in [RFC6125], Section 6.4, or the EST server certificate MUST contain the id-kp-cmcRA [RFC6402] extended key usage extension.
当EST客户端显式TA数据库用于验证EST服务器证书时，客户端必须根据[RFC6125]第6.4节中指定的规则，根据服务器的标识检查配置的URI或最新的HTTP重定向URI，或者EST服务器证书必须包含id kp cmcRA[RFC6402]扩展密钥使用扩展。
When the EST client Implicit TA database is used to validate the EST server certificate, the client MUST check the configured URI and each HTTP redirection URI according to the rules specified in [RFC6125], Section 6.4. The provisioned URI or the most recent HTTP redirection URI provides the basis for authorization, and the server's authenticated identity confirms it is the authorized server.
当使用EST客户端隐式TA数据库验证EST服务器证书时，客户端必须根据[RFC6125]第6.4节中指定的规则检查配置的URI和每个HTTP重定向URI。配置的URI或最新的HTTP重定向URI提供了授权的基础，并且服务器的身份验证确认它是授权的服务器。
The decision to issue a certificate to a client is always controlled by local CA policy. The EST server configuration reflects this CA policy. This document does not specify any constraints on such policy. EST provides the EST server access to each client's authenticated identity -- e.g., the TLS client's certificate in addition to any HTTP user authentication credentials -- to help in implementing such policy.
向客户端颁发证书的决定始终由本地CA策略控制。EST服务器配置反映了此CA策略。本文件未规定此类政策的任何约束条件。EST向EST服务器提供对每个客户端的已验证身份的访问，例如，除了任何HTTP用户身份验证凭据之外，还提供TLS客户端的证书，以帮助实现此类策略。
If the client's certificate was issued by the EST CA, and it includes the id-kp-cmcRA [RFC6402] extended key usage extension, then the client is a Registration Authority (RA) as described in [RFC5272] and [RFC6402]. In this case, the EST server SHOULD apply authorization policy consistent with an RA client. For example, when handling /simpleenroll requests, the EST server could be configured to accept POP linking information that does not match the current TLS session because the authenticated EST client RA has verified this information when acting as an EST server (as specified in Section 3.5). More specific RA mechanisms are available if the EST client uses /fullcmc methods.
如果客户机的证书由EST CA颁发，并且它包括id kp cmcRA[RFC6402]扩展密钥使用扩展，则客户机是[RFC5272]和[RFC6402]中所述的注册机构（RA）。在这种情况下，EST服务器应该应用与RA客户端一致的授权策略。例如，在处理/SimplenRoll请求时，可以将EST服务器配置为接受与当前TLS会话不匹配的弹出链接信息，因为经过身份验证的EST客户端RA在充当EST服务器时验证了该信息（如第3.5节所述）。如果EST客户端使用/fullcmc方法，则可以使用更具体的RA机制。
Before processing a request, an EST server determines if the client is authorized to receive the requested services. Likewise, the client determines if it will make requests to the EST server. These authorization decisions are described in the next two sections. Assuming that both sides of the exchange are authorized, then the actual operations are as described in subsequent sections.
在处理请求之前，EST服务器确定客户端是否有权接收请求的服务。同样，客户机确定是否向EST服务器发出请求。这些授权决策将在接下来的两部分中描述。假设交易所双方都获得授权，那么实际操作将在后续章节中进行描述。
The EST client can request a copy of the current CA certificates. This function is generally performed before other EST functions.
EST客户端可以请求当前CA证书的副本。此功能通常在其他EST功能之前执行。
It is possible that the client was not configured with an Implicit TA database that allows a bootstrap installation of the Explicit TA database as described in 4.1.3. This section describes an alternate method by which minimally configured EST clients can populate their Explicit TA database.
客户机可能未配置隐式TA数据库，该数据库允许引导安装4.1.3中所述的显式TA数据库。本节描述了一种替代方法，通过该方法，配置最少的EST客户端可以填充其显式TA数据库。
If the EST client application does not specify either an Explicit TA database or an Implicit TA database, then the initial TLS server authentication and authorization will fail. The client MAY provisionally continue the TLS handshake to completion for the purposes of accessing the /cacerts or /fullcmc method. If the EST client continues with an unauthenticated connection, the client MUST extract the HTTP content data from the response (Sections 4.1.3 or 4.3.2) and engage a human user to authorize the CA certificate using out-of-band data such as a CA certificate "fingerprint" (e.g., a SHA-256 or SHA-512 [SHS] hash on the whole CA certificate). In a /fullcmc response, it is the Publish Trust Anchors control (CMC [RFC5272], Section 6.15) within the Full PKI Response that must be accepted manually. It is incumbent on the user to properly verify the TA information, or to provide the "fingerprint" data during configuration that is necessary to verify the TA information.
如果EST客户端应用程序未指定显式TA数据库或隐式TA数据库，则初始TLS服务器身份验证和授权将失败。为了访问/cacerts或/fullcmc方法，客户端可以临时继续TLS握手直到完成。如果EST客户端继续使用未经验证的连接，客户端必须从响应中提取HTTP内容数据（第4.1.3节或第4.3.2节），并让人工用户使用带外数据（例如CA证书“指纹”（例如，整个CA证书上的SHA-256或SHA-512[SHS]散列）授权CA证书。在/fullcmc响应中，必须手动接受完整PKI响应中的发布信任锚控制（CMC[RFC5272]，第6.15节）。用户有责任正确验证TA信息，或在配置期间提供验证TA信息所需的“指纹”数据。
HTTP authentication requests MUST NOT be responded to if the server has not been authenticated as specified in Section 3.3.1 or if the optional certificate-less authentication is used as specified in Section 3.3.3.
如果服务器未按照第3.3.1节的规定进行身份验证，或者按照第3.3.3节的规定使用可选的无证书身份验证，则不得响应HTTP身份验证请求。
The EST client uses the /cacerts response to establish an Explicit Trust Anchor database for subsequent TLS authentication of the EST server. EST clients MUST NOT engage in any other protocol exchange
EST客户端使用/cacerts响应为EST服务器的后续TLS身份验证建立显式信任锚数据库。EST客户端不得参与任何其他协议交换
until after the /cacerts response has been accepted and a new TLS session has been established (using TLS certificate-based authentication).
直到接受/cacerts响应并建立新的TLS会话（使用基于TLS证书的身份验证）之后。
EST clients request the EST CA TA database information of the CA (in the form of certificates) with an HTTPS GET message using an operation path of "/cacerts". EST clients and servers MUST support the /cacerts function. Clients SHOULD request an up-to-date response before stored information has expired in order to ensure the EST CA TA database is up to date.
EST客户端使用操作路径为“/cacerts”的HTTPS GET消息请求CA的EST CA TA数据库信息（以证书的形式）。EST客户端和服务器必须支持/cacerts功能。客户应在存储的信息过期之前请求最新的响应，以确保EST CA TA数据库是最新的。
The EST server SHOULD NOT require client authentication or authorization to reply to this request.
EST服务器不应要求客户端身份验证或授权来答复此请求。
The client MUST authenticate the EST server, as specified in Section 3.3.1 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the server's authorization as given in Section 3.6, or follow the procedure outlined in Section 4.1.1.
如果使用基于证书的身份验证，则客户机必须按照第3.3.1节的规定对EST服务器进行身份验证，如果使用可选的无证书身份验证，则客户机必须按照第3.3.3节的规定对EST服务器进行身份验证，并按照第3.6节的规定检查服务器的授权，或者按照第4.1.1节概述的程序进行。
If successful, the server response MUST have an HTTP 200 response code. Any other response code indicates an error and the client MUST abort the protocol.
如果成功，服务器响应必须具有HTTP 200响应代码。任何其他响应代码都指示错误，客户端必须中止协议。
A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing the certificates described in the following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of "base64" [RFC2045].
成功的响应必须是[RFC5272]中定义的仅证书CMC简单PKI响应，包含以下段落中描述的证书。使用HTTP内容类型“application/pkcs7 mime”。简单PKI响应以“base64”[RFC2045]的内容传输编码发送。
The EST server MUST include the current root CA certificate in the response. The EST server MUST include any additional certificates the client would need to build a chain from an EST CA-issued certificate to the current EST CA TA. For example, if the EST CA is a subordinate CA, then all the appropriate subordinate CA certificates necessary to build a chain to the root EST CA are included in the response.
EST服务器必须在响应中包含当前根CA证书。EST服务器必须包括客户端构建从EST CA颁发的证书到当前EST CA TA的链所需的任何其他证书。例如，如果EST CA是从属CA，则响应中包括构建到根EST CA的链所需的所有适当从属CA证书。
The EST server SHOULD include the three "Root CA Key Update" certificates OldWithOld, OldWithNew, and NewWithOld in the response chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST client MUST be able to handle these certificates in the response. The EST CA's most recent self-signed certificate (e.g., NewWithNew certificate) is self-signed and has the latest NotAfter date. If the
EST服务器应该在响应链中包含三个“根CA密钥更新”证书OldWithOld、OldWithNew和NewWithOld。这些在CMP[RFC4210]第4.4节中定义。EST客户端必须能够在响应中处理这些证书。EST CA最近的自签名证书（例如，NewWithNew证书）是自签名的，并且具有最新的NotAfter日期。如果
EST server does not include these in the response, then after the current EST CA certificate expires, the EST clients will need to be reinitialized with the PKI using the Bootstrap Distribution of CA certificates (Section 4.1.1) method, which involves user interaction.
EST服务器不在响应中包含这些内容，那么在当前EST CA证书过期后，需要使用涉及用户交互的CA证书引导分发（第4.1.1节）方法使用PKI重新初始化EST客户端。
After out-of-band validation occurs, all the other certificates MUST be validated using normal [RFC5280] certificate path validation (using the most recent CA certificate as the TA) before they can be used to build certificate paths during certificate validation.
带外验证发生后，所有其他证书必须使用正常的[RFC5280]证书路径验证（使用最新的CA证书作为TA）进行验证，然后才能在证书验证期间用于构建证书路径。
The EST client MUST store the extracted EST CA certificate as an Explicit TA database entry for subsequent EST server authentication. The EST client SHOULD disable use of Implicit TA database entries for this EST server now that an Explicit TA database entry is available. If the client disables the Implicit TA database, and if the EST server certificate was verified using an Implicit TA database entry, then the client MUST include the "Trusted CA Indication" extension in future TLS sessions [RFC6066]. This indicates to the server that only an EST server certificate authenticatable by the Explicit TA database entry is now acceptable (otherwise, the EST server might continue to use a server certificate that is only verifiable by a now disabled Implicit TA).
EST客户端必须将提取的EST CA证书存储为显式TA数据库条目，以用于后续EST服务器身份验证。既然显式TA数据库条目可用，EST客户端应该禁用此EST服务器的隐式TA数据库条目的使用。如果客户端禁用隐式TA数据库，并且使用隐式TA数据库条目验证了EST服务器证书，则客户端必须在将来的TLS会话中包含“可信CA指示”扩展[RFC6066]。这向服务器表明，现在仅可接受通过显式TA数据库项进行身份验证的EST服务器证书（否则，EST服务器可能会继续使用仅可通过现已禁用的隐式TA进行验证的服务器证书）。
The EST client SHOULD also make the CA Certificate response information available to the end-entity software for use when validating peer certificates.
EST客户端还应使CA证书响应信息可供终端实体软件在验证对等证书时使用。
EST clients request a certificate from the EST server with an HTTPS POST using the operation path value of "/simpleenroll". EST clients request a renew/rekey of existing certificates with an HTTP POST using the operation path value of "/simplereenroll". EST servers MUST support the /simpleenroll and /simplereenroll functions.
EST客户端使用操作路径值“/SimplenRoll”通过HTTPS POST从EST服务器请求证书。EST客户端使用操作路径值“/simplereenroll”通过HTTP POST请求现有证书的续订/重新密钥。EST服务器必须支持/SimplenRoll和/simplereenroll功能。
It is RECOMMENDED that a client obtain the current CA certificates, as described in Section 4.1, before performing certificate request functions. This ensures that the client will be able to validate the EST server certificate. The client MUST authenticate the EST server as specified in Section 3.3.1 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used. The client MUST verify the authorization of the EST server as specified in Section 3.6.
建议客户端在执行证书请求功能之前，如第4.1节所述，获取当前CA证书。这将确保客户端能够验证EST服务器证书。如果使用基于证书的身份验证，则客户端必须按照第3.3.1节的规定对EST服务器进行身份验证；如果使用可选的无证书身份验证，则客户端必须按照第3.3.3节的规定对EST服务器进行身份验证。客户必须按照第3.6节的规定验证EST服务器的授权。
The server MUST authenticate the client as specified in Section 3.3.2 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used. The server MUST verify client authorization as specified in Section 3.7. The EST
如果使用基于证书的身份验证，则服务器必须按照第3.3.2节的规定对客户端进行身份验证；如果使用可选的无证书身份验证，则服务器必须按照第3.3.3节的规定对客户端进行身份验证。服务器必须按照第3.7节的规定验证客户端授权。最
server MUST check the tls-unique value, as described in Section 3.5, if one is submitted by the client.
如果客户提交了tls唯一值，则服务器必须检查tls唯一值，如第3.5节所述。
The server MAY accept a certificate request for manual authorization checking by an administrator. (Section 4.2.3 describes the use of an HTTP 202 response to the EST client if this occurs.)
服务器可以接受管理员手动授权检查的证书请求。（第4.2.3节描述了如果出现这种情况，对EST客户端使用HTTP 202响应。）
When HTTPS POSTing to /simpleenroll, the client MUST include a Simple PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS #10 Certification Request [RFC2986]).
当HTTPS发布到/SimplenRoll时，客户端必须包含CMC[RFC5272]第3.1节中规定的简单PKI请求（即PKCS#10认证请求[RFC2986]）。
The Certification Signing Request (CSR) signature provides proof-of-possession of the client-possessed private key to the EST server. If the CSR KeyUsage extension indicates that the private key can be used to generate digital signatures, then the client MUST generate the CSR signature using the private key. If the key can be used to generate digital signatures but the requested CSR KeyUsage extension prohibits generation of digital signatures, then the CSR signature MAY still be generated using the private key, but the key MUST NOT be used for any other signature operations (this is consistent with the recommendations concerning submission of proof-of-possession to an RA or CA as described in [SP-800-57-Part-1]). The use of /fullcmc operations provides access to more advanced proof-of-possession methods that are used when the key pair cannot be used for digital signature generation (see Section 4.3).
证书签名请求（CSR）签名为EST服务器提供拥有客户端拥有的私钥的证据。如果CSR KeyUsage扩展指示私钥可用于生成数字签名，则客户端必须使用私钥生成CSR签名。如果密钥可用于生成数字签名，但请求的CSR密钥使用扩展禁止生成数字签名，则仍可使用私钥生成CSR签名，但密钥不得用于任何其他签名操作（这与[SP-800-57-Part-1]中所述的向RA或CA提交占有证明的建议一致。使用/fullcmc操作可以访问更高级的占有证明方法，这些方法在密钥对无法用于数字签名生成时使用（参见第4.3节）。
The HTTP content-type of "application/pkcs10" is used here. The format of the message is as specified in [RFC5967] with a Content-Transfer-Encoding of "base64" [RFC2045].
这里使用HTTP内容类型“application/pkcs10”。消息的格式如[RFC5967]所述，内容传输编码为“base64”[RFC2045]。
If the EST client authenticated using a previously installed certificate issued by a third-party CA (see Section 2.2.1), the client MAY include the ChangeSubjectName attribute, as defined in [RFC6402], in the CSR to request that the subjectName and SubjectAltName be changed in the new certificate.
如果EST客户端使用先前安装的第三方CA颁发的证书进行身份验证（参见第2.2.1节），则客户端可在CSR中包含[RFC6402]中定义的ChangeSubjectName属性，以请求在新证书中更改subjectName和SubjectAltName。
The EST client MAY request additional certificates even when using an existing certificate in the TLS client authentication. For example, the client can use an existing certificate for TLS client authentication when requesting a certificate that cannot be used for TLS client authentication.
即使在TLS客户端身份验证中使用现有证书，EST客户端也可以请求附加证书。例如，当请求不能用于TLS客户端身份验证的证书时，客户端可以使用现有证书进行TLS客户端身份验证。
EST clients renew/rekey certificates with an HTTPS POST using the operation path value of "/simplereenroll".
EST客户端使用操作路径值“/simplereenroll”使用HTTPS POST更新/重新设置证书密钥。
A certificate request employs the same format as the "simpleenroll" request, using the same HTTP content-type. The request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed/rekeyed. The ChangeSubjectName attribute, as defined in [RFC6402], MAY be included in the CSR to request that these fields be changed in the new certificate.
证书请求使用与“SimplenRoll”请求相同的格式，使用相同的HTTP内容类型。request Subject字段和SubjectAltName扩展名必须与正在续订/重新设置密钥的证书中的相应字段相同。[RFC6402]中定义的ChangeSubjectName属性可以包含在CSR中，以请求在新证书中更改这些字段。
If the Subject Public Key Info in the certification request is the same as the current client certificate, then the EST server renews the client certificate. If the public key information in the certification request is different than the current client certificate, then the EST server rekeys the client certificate.
如果认证请求中的使用者公钥信息与当前客户端证书相同，则EST服务器续订客户端证书。如果证书请求中的公钥信息不同于当前客户端证书，则EST服务器将为客户端证书重新设置密钥。
If the enrollment is successful, the server response MUST contain an HTTP 200 response code with a content-type of "application/pkcs7-mime".
如果注册成功，服务器响应必须包含内容类型为“application/pkcs7 mime”的HTTP 200响应代码。
A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing only the certificate that was issued. The HTTP content-type of "application/pkcs7-mime" with an smime-type parameter "certs-only" is used, as specified in [RFC5273].
成功的响应必须是[RFC5272]中定义的仅证书CMC简单PKI响应，仅包含已颁发的证书。如[RFC5273]中所述，使用带有smime类型参数“certs only”的HTTP内容类型“application/pkcs7 mime”。
The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. A Simple PKI Response with an HTTP content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be included in the response data to convey an error response. If the content-type is not set, the response data MUST be a plaintext human-readable error message containing explanatory information describing why the request was rejected (for example, indicating that CSR attributes are incomplete).
出现问题时，服务器必须使用合适的4xx或5xx HTTP[RFC2616]错误代码进行应答。响应数据中可能包含HTTP内容类型为“application/pkcs7 mime”（见第4.3.2节）的简单PKI响应，以传递错误响应。如果未设置内容类型，则响应数据必须是纯文本的人类可读错误消息，其中包含描述请求被拒绝原因的解释性信息（例如，指示CSR属性不完整）。
If the server responds with an HTTP [RFC2616] 202, this indicates that the request has been accepted for processing but that a response is not yet available. The server MUST include a Retry-After header as defined for HTTP 503 responses. The server also MAY include informative human-readable content. The client MUST wait at least the specified "retry-after" time before repeating the same request. The client repeats the initial enrollment request after the appropriate "retry-after" interval has expired. The client SHOULD log or inform the end-user of this event. The server is responsible
如果服务器使用HTTP[RFC2616]202进行响应，则表示请求已被接受以进行处理，但响应尚不可用。服务器必须包含为HTTP 503响应定义的Retry After标头。服务器还可以包括信息性的人类可读内容。客户端必须至少等待指定的“重试后”时间，然后才能重复相同的请求。客户端在适当的“重试后”间隔过期后重复初始注册请求。客户端应记录或通知最终用户此事件。服务器负责
for maintaining all states necessary to recognize and handle retry operations as the client is stateless in this regard; it simply sends the same request repeatedly until it receives a different response code. All other return codes are handled as specified in HTTP [RFC2616].
维护识别和处理重试操作所需的所有状态，因为客户端在这方面是无状态的；它只是重复发送相同的请求，直到收到不同的响应代码。所有其他返回代码按照HTTP[RFC2616]中的规定进行处理。
If the client closes the TLS connections while waiting for the Retry-After time to expire, then the client initiates a new TLS connection and performs all applicable security checks. If the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session. Note: the key pair need not be regenerated. These are processing and interface burdens on the client. EST server administrators are advised to take this into consideration.
如果客户端在等待时间到期后重试时关闭TLS连接，则客户端将启动新的TLS连接并执行所有适用的安全检查。如果客户端已生成包含链接标识和POP信息的CSR（第3.5节），则需要重新创建CSR，以合并新重定向会话中唯一的tls。注意：不需要重新生成密钥对。这些是客户端的处理和接口负担。建议EST服务器管理员考虑这一点。
The EST client MAY also make the certificate response, and associated private key, available to end-entity software for use as an end-entity certificate.
EST客户端还可以使证书响应和相关私钥可供终端实体软件用作终端实体证书。
An EST client can request a certificate from an EST server with an HTTPS POST using the operation path value of "/fullcmc". Support for the /fullcmc function is OPTIONAL for both clients and servers.
EST客户端可以使用操作路径值“/fullcmc”通过HTTPS POST从EST服务器请求证书。对/fullcmc功能的支持对于客户端和服务器都是可选的。
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the server MUST reject the message. The HTTP content-type used is "application/pkcs7-mime" with an smime-type parameter "CMC-request", as specified in [RFC5273]. The body of the message is the binary value of the encoding of the PKI Request with a Content-Transfer-Encoding of "base64" [RFC2045].
如果HTTP POST to/fullcmc不是有效的完整PKI请求，则服务器必须拒绝该消息。使用的HTTP内容类型为“application/pkcs7 mime”，带有smime类型参数“CMC request”，如[RFC5273]中所述。消息体是PKI请求编码的二进制值，内容传输编码为“base64”[RFC2045]。
If the enrollment is successful, the server response MUST include an HTTP 200 response code with a content-type of "application/pkcs7-mime" as specified in [RFC5273]. The response data includes either the Simple PKI Response with an smime-type parameter of "certs-only" or the Full PKI Response with an smime-type parameter "CMC-response", as specified in Section 3.2.1 of [RFC5751]. The body of the message is the binary value of the encoding of the PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
如果注册成功，服务器响应必须包括HTTP 200响应代码，内容类型为[RFC5273]中指定的“application/pkcs7 mime”。响应数据包括具有smime类型参数“仅证书”的简单PKI响应或具有smime类型参数“CMC响应”的完整PKI响应，如[RFC5751]第3.2.1节所述。消息体是PKI响应编码的二进制值，内容传输编码为“base64”[RFC2045]。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error. A CMC response with the content-type of "application/pkcs7-mime" MUST be included in the response data for any CMC error response.
拒绝请求时，服务器必须指定HTTP 4xx错误或HTTP 5xx错误。对于任何CMC错误响应，响应数据中必须包含内容类型为“application/pkcs7 mime”的CMC响应。
All other return codes are handled as specified in Section 4.2.3 or HTTP [RFC2616]. For example, a client interprets an HTTP 404 or 501 response to indicate that this service is not implemented.
所有其他返回代码按照第4.2.3节或HTTP[RFC2616]的规定进行处理。例如，客户机解释HTTP 404或501响应以指示未实现此服务。
An EST client may request a private key and associated certificate from an EST server using an HTTPS POST with an operation path value of "/serverkeygen". Support for the /serverkeygen function is OPTIONAL.
EST客户端可以使用操作路径值为“/serverkeygen”的HTTPS POST从EST服务器请求私钥和相关证书。对/serverkeygen功能的支持是可选的。
A client MUST authenticate an EST server, as specified in Section 3.3.1 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the server's authorization as given in Section 3.6.
客户端必须按照第3.3.1节（如果使用基于证书的身份验证）或第3.3.3节（如果使用可选的无证书身份验证）的规定对EST服务器进行身份验证，并按照第3.6节的规定检查服务器的授权。
The EST server MUST authenticate the client, as specified in Section 3.3.2 if certificate-based authenticated is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the client's authorization as given in Section 3.7. The EST server applies whatever authorization or logic it chooses to determine if the private key and certificate should be provided.
EST服务器必须按照第3.3.2节（如果使用基于证书的身份验证）或第3.3.3节（如果使用可选的无证书身份验证）的规定对客户端进行身份验证，并按照第3.7节的规定检查客户端的授权。EST服务器应用它选择的任何授权或逻辑来确定是否应该提供私钥和证书。
Cipher suites that have a NULL confidentiality algorithm MUST NOT be used as they will disclose the contents of an unprotected private key.
不得使用具有空保密算法的密码套件，因为它们将泄露未受保护的私钥的内容。
Proper random number and key generation [RFC4086] is a server implementation responsibility, and server archiving of generated keys is determined by CA policy. The key pair and certificate are transferred over the TLS session. The cipher suite used to return the private key and certificate MUST offer confidentiality commensurate with the private key being delivered to the client.
正确的随机数和密钥生成[RFC4086]是服务器实现的责任，生成密钥的服务器存档由CA策略决定。密钥对和证书通过TLS会话传输。用于返回私钥和证书的密码套件必须提供与交付给客户端的私钥相称的机密性。
The EST client MAY request additional certificates even when using an existing certificate in the TLS client authentication. For example, the client can use an existing certificate for TLS client authentication when requesting a certificate that cannot be used for TLS client authentication.
即使在TLS客户端身份验证中使用现有证书，EST客户端也可以请求附加证书。例如，当请求不能用于TLS客户端身份验证的证书时，客户端可以使用现有证书进行TLS客户端身份验证。
The certificate request is HTTPS POSTed and is the same format as for the "/simpleenroll" and "/simplereenroll" path extensions with the same content-type and transfer encoding.
证书请求是HTTPS发布的，其格式与“/simpleenroll”和“/simpleenroll”路径扩展相同，具有相同的内容类型和传输编码。
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 re-use of existing codebases for generating and parsing such requests.
在所有方面，服务器应将CSR视为任何注册或重新注册CSR；这里唯一的区别是服务器必须忽略CSR中的公钥值和签名。请求中包含这些代码只是为了允许重用现有的代码库来生成和解析这些请求。
If the client desires to receive the private key with encryption that exists outside of and in addition to that of the TLS transport used by EST or if server policy requires that the key be delivered in such a form, the client MUST include an attribute in the CSR indicating the encryption key to be used. Both symmetric and asymmetric encryption are supported as described in the following subsections. The client MUST also include an SMIMECapabilities attribute ([RFC2633], Section 2.5) in the CSR to indicate the key encipherment algorithms the client is willing to use.
如果客户端希望通过EST使用的TLS传输之外的加密接收私钥，或者如果服务器策略要求以这种形式交付密钥，则客户端必须在CSR中包含指示要使用的加密密钥的属性。对称和非对称加密均受支持，如下小节所述。客户机还必须在CSR中包含SMIMECapabilities属性（[RFC2633]，第2.5节），以指示客户机愿意使用的密钥加密算法。
It is strongly RECOMMENDED that the clients request that the returned private key be afforded the additional security of the Cryptographic Message Syntax (CMS) EnvelopedData in addition to the TLS-provided security to protect against unauthorized disclosure.
强烈建议客户端请求为返回的私钥提供加密消息语法（CMS）信封数据的额外安全性，以及TLS提供的防止未经授权泄露的安全性。
To specify a symmetric encryption key to be used to encrypt the server-generated private key, the client MUST include a DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of [RFC4108]) specifying the identifier of the secret key to be used by the server to encrypt the private key. While that attribute was originally designated for specifying a firmware encryption key, it exactly mirrors the requirements for specifying a secret key to encrypt a private key. If the server does not have a secret key matching the identifier specified by the client, the request MUST be terminated and an error returned to the client. Distribution of the key specified by the DecryptKeyIdentifier to the key generator and the client is outside the scope of this document.
要指定用于加密服务器生成的私钥的对称加密密钥，客户端必须包含DecryptKeyIdentifier属性（如[RFC4108]第2.2.5节中的定义），该属性指定服务器用于加密私钥的密钥标识符。虽然该属性最初指定用于指定固件加密密钥，但它完全反映了指定密钥以加密私钥的要求。如果服务器没有与客户端指定的标识符匹配的密钥，则必须终止请求并向客户端返回错误。将DecryptKeyIdentifier指定的密钥分发给密钥生成器和客户端超出了本文档的范围。
To specify an asymmetric encryption key to be used to encrypt the server-generated private key, the client MUST include an AsymmetricDecryptKeyIdentifier attribute. The AsymmetricDecryptKeyIdentifier attribute is defined as:
要指定用于加密服务器生成的私钥的非对称加密密钥，客户端必须包含AsymmetricDecryptKeyIdentifier属性。AsymmetricKeyIdentifier属性定义为：
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
id-aa 54 }
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
id-aa 54 }
The asymmetric-decrypt-key-identifier attribute values have ASN.1 type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in [X.680])::
不对称解密密钥标识符属性值具有ASN.1类型的AsymmetricDecryptKeyIdentifier（其中ASN.1在[X.680]中定义）：
AsymmetricDecryptKeyIdentifier ::= OCTET STRING
AsymmetricDecryptKeyIdentifier ::= OCTET STRING
If the server does not have a public key matching the identifier specified by the client, the request MUST be terminated and an error returned to the client. Distribution of the key specified by the AsymmetricDecryptKeyIdentifier to the key generator and the client is outside the scope of this document. If the key identified is bound to an X.509 certificate, then the key MUST either explicitly support keyTransport or keyAgreement or its use MUST be unrestricted.
如果服务器没有与客户端指定的标识符匹配的公钥，则必须终止请求并向客户端返回错误。将AsymmetricDecryptKeyIdentifier指定的密钥分发给密钥生成器和客户端超出了本文档的范围。如果标识的密钥绑定到X.509证书，则该密钥必须明确支持keyTransport或keyAgreement，或者其使用必须不受限制。
If the request is successful, the server response MUST have an HTTP 200 response code with a content-type of "multipart/mixed" consisting of two parts: one part is the private key data and the other part is the certificate data.
如果请求成功，服务器响应必须具有HTTP 200响应代码，其内容类型为“multipart/mixed”，由两部分组成：一部分是私钥数据，另一部分是证书数据。
The format in which the private key data part is returned is dependent on whether the private key is being returned with additional encryption on top of that provided by TLS.
私钥数据部分返回的格式取决于私钥是否在TLS提供的加密基础上使用附加加密返回。
If additional encryption is not being employed, the private key data MUST be placed in an "application/pkcs8". An "application/pkcs8" part consists of the base64-encoded DER-encoded [X.690] PrivateKeyInfo with a Content-Transfer-Encoding of "base64" [RFC2045].
如果未使用其他加密，则必须将私钥数据放入“应用程序/pkcs8”中。“应用程序/pkcs8”部分由base64编码的DER编码的[X.690]PrivateKeyInfo组成，内容传输编码为“base64”[RFC2045]。
If additional encryption is being employed, the private key is placed inside of a CMS SignedData. The SignedData is signed by the party that generated the private key, which may or may not be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData, as described in Section 4 of [RFC5958]. The following list shows how the EncryptedData is used, depending on the type of protection key specified by the client.
如果采用了额外的加密，私钥将放在CMS SignedData中。签名数据由生成私钥的一方签名，私钥可能是EST服务器或EST CA，也可能不是。如[RFC5958]第4节所述，通过将签名数据放在CMS信封数据中，进一步保护签名数据。下面的列表显示如何使用EncryptedData，具体取决于客户端指定的保护密钥类型。
o If the client specified a symmetric encryption key to protect the server-generated private key, the EnvelopedData content is encrypted using the secret key identified in the request. The EnvelopedData RecipientInfo field MUST indicate the key-encryption kekri key management technique. The values are as follows: version is set to 4, key-encryption key identifier (kekid) is set to the value of the DecryptKeyIdentifier from Section 4.4.1.1; keyEncryptionAlgorithm is set to one of the key wrap algorithms that the client included in the SMIMECapabilities accompanying the request; and encryptedKey is the encrypted key.
o 如果客户端指定了对称加密密钥来保护服务器生成的私钥，则使用请求中标识的密钥对EnvelopedData内容进行加密。EnvelopedData RecipientInfo字段必须指明密钥加密kekri密钥管理技术。值如下：版本设置为4，密钥加密密钥标识符（kekid）设置为第4.4.1.1节中解密密钥标识符的值；keyEncryptionAlgorithm被设置为客户机在请求附带的SMIMECapabilities中包含的密钥包裹算法之一；encryptedKey是加密的密钥。
o If the client specified an asymmetric encryption key suitable for key transport operations to protect the server-generated private key, the EnvelopedData content is encrypted using a randomly generated symmetric encryption key. The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the client-specified asymmetric key. The EnvelopedData RecipientInfo field MUST indicate the KeyTransRecipientInfo (ktri) key management technique. In KeyTransRecipientInfo, the RecipientIdentifier (rid) is either the subjectKeyIdentifier copied from the attribute defined in Section 4.4.1.2 or the server determines an associated issuerAndSerialNumber from the attribute; version is derived from the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one of the key wrap algorithms that the client included in the SMIMECapabilities accompanying the request, and encryptedKey is the encrypted key.
o 如果客户端指定了适用于密钥传输操作的非对称加密密钥以保护服务器生成的私钥，则使用随机生成的对称加密密钥对EnvelopedData内容进行加密。对称加密密钥的加密强度应等于客户端指定的非对称密钥。EnvelopedData RecipientInfo字段必须指明KeyTransRecipientInfo（ktri）密钥管理技术。在KeyTransRecipientInfo中，RecipientIdentifier（rid）是从第4.4.1.2节中定义的属性复制的subjectKeyIdentifier，或者服务器从该属性确定关联的issuerAndSerialNumber；版本是从rid[RFC5652]的选择中派生出来的，keyEncryptionAlgorithm被设置为客户端包含在随请求而来的SMIMECapabilities中的密钥包装算法之一，encryptedKey是加密密钥。
o If the client specified an asymmetric encryption key suitable for key agreement operations to protect the server-generated private key, the EnvelopedData content is encrypted using a randomly generated symmetric encryption key. The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the client-specified asymmetric key. The EnvelopedData RecipientInfo field MUST indicate the KeyAgreeRecipientInfo (kari) key management technique. In the KeyAgreeRecipientInfo type, version, originator, and user keying material (ukm) are as in [RFC5652], and keyEncryptionAlgorithm is set to one of the key wrap algorithms that the client included in the SMIMECapabilities accompanying the request. The recipient's key identifier is either copied from the attribute defined in Section 4.4.1.2 to subjectKeyIdentifier or the server determines an IssuerAndSerialNumber that corresponds to the value provided in the attribute.
o 如果客户端指定了适用于密钥协议操作的非对称加密密钥以保护服务器生成的私钥，则使用随机生成的对称加密密钥对EnvelopedData内容进行加密。对称加密密钥的加密强度应等于客户端指定的非对称密钥。EnvelopedData RecipientInfo字段必须指明KeyAgreeRecipientInfo（kari）密钥管理技术。在KeyAgreeRecipientInfo中，类型、版本、发起者和用户密钥材料（ukm）如[RFC5652]所示，并且keyEncryptionAlgorithm被设置为客户端在请求的SMIMECapabilities中包含的密钥封装算法之一。收件人的密钥标识符从第4.4.1.2节中定义的属性复制到subjectKeyIdentifier，或者服务器确定与属性中提供的值相对应的IssuerAndSerialNumber。
In all three additional encryption cases, the EnvelopedData is returned in the response as an "application/pkcs7-mime" part with an smime-type parameter of "server-generated-key" and a Content-Transfer-Encoding of "base64".
在所有三种额外的加密情况下，EnvelopedData在响应中作为“application/pkcs7 mime”部分返回，smime类型参数为“server generated key”，内容传输编码为“base64”。
The certificate data part is an "application/pkcs7-mime" and exactly matches the certificate response to /simpleenroll.
证书数据部分是一个“application/pkcs7 mime”，与/simplenloll的证书响应完全匹配。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error. If the content-type is not set, the response data MUST be a plaintext human-readable error message.
拒绝请求时，服务器必须指定HTTP 4xx错误或HTTP 5xx错误。如果未设置内容类型，则响应数据必须是纯文本的人类可读错误消息。
CA policy may allow inclusion of client-provided attributes in certificates that it issues, and some of these attributes may describe information that is not available to the CA. In addition, a CA may desire to certify a certain type of public key and a client may not have a priori knowledge of that fact. Therefore, clients SHOULD request a list of expected attributes that are required, or desired, by the CA in an enrollment request or if dictated by local policy.
CA策略可能允许在其颁发的证书中包含客户端提供的属性，其中一些属性可能描述CA不可用的信息。此外，CA可能希望认证某种类型的公钥，而客户端可能不具备该事实的先验知识。因此，客户机应该请求CA在注册请求中要求或期望的预期属性列表，或者如果由本地策略指定的话。
The EST server SHOULD NOT require client authentication or authorization to reply to this request.
EST服务器不应要求客户端身份验证或授权来答复此请求。
Requesting CSR attributes is optional, but clients are advised that CAs may refuse enrollment requests that are not encoded according to the CA's policy.
请求CSR属性是可选的，但建议客户端CAs可以拒绝未根据CA策略编码的注册请求。
The EST client requests a list of CA-desired CSR attributes from the CA by sending an HTTPS GET message to the EST server with an operations path of "/csrattrs".
EST客户端通过向EST服务器发送HTTPS GET消息（操作路径为“/csrattrs”），从CA请求CA所需CSR属性的列表。
If locally configured policy for an authenticated EST client indicates a CSR Attributes Response is to be provided, the server response MUST include an HTTP 200 response code. An HTTP response code of 204 or 404 indicates that a CSR Attributes Response is not available. Regardless of the response code, the EST server and CA MAY reject any subsequent enrollment requests for any reason, e.g., incomplete CSR attributes in the request.
如果为经过身份验证的EST客户端本地配置的策略指示要提供CSR属性响应，则服务器响应必须包括HTTP 200响应代码。HTTP响应代码204或404表示CSR属性响应不可用。无论响应代码如何，EST服务器和CA都可能出于任何原因拒绝任何后续注册请求，例如，请求中的CSR属性不完整。
Responses to attribute request messages MUST be encoded as the content-type of "application/csrattrs" with a Content-Transfer-Encoding of "base64" [RFC2045]. The syntax for application/csrattrs body is as follows:
对属性请求消息的响应必须编码为“应用程序/csrattrs”的内容类型，内容传输编码为“base64”[RFC2045]。application/csrattrs正文的语法如下：
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
An EST server includes zero or more OIDs or attributes [RFC2986] that it requests the client to use in the certification request. The client MUST ignore any OID or attribute it does not recognize. When the server encodes CSR Attributes as an empty SEQUENCE, it means that the server has no specific additional information it desires in a client certification request (this is functionally equivalent to an HTTP response code of 204 or 404).
EST服务器包含零个或多个OID或属性[RFC2986]，它请求客户端在认证请求中使用这些OID或属性。客户端必须忽略它无法识别的任何OID或属性。当服务器将CSR属性编码为空序列时，这意味着服务器在客户端认证请求中没有它想要的特定附加信息（这在功能上相当于HTTP响应代码204或404）。
If the CA requires a particular crypto system or use of a particular signature scheme (e.g., certification of a public key based on a certain elliptic curve, or signing using a certain hash algorithm) it MUST provide that information in the CSR Attribute Response. If an EST server requires the linking of identity and POP information (see Section 3.5), it MUST include the challengePassword OID in the CSR Attributes Response.
如果CA需要特定密码系统或使用特定签名方案（例如，基于特定椭圆曲线的公钥认证，或使用特定哈希算法签名），则必须在CSR属性响应中提供该信息。如果EST服务器需要标识和POP信息的链接（参见第3.5节），则必须在CSR属性响应中包含challengePassword OID。
The structure of the CSR Attributes Response SHOULD, to the greatest extent possible, reflect the structure of the CSR it is requesting. Requests to use a particular signature scheme (e.g. using a particular hash function) are represented as an OID to be reflected in the SignatureAlgorithm of the CSR. Requests to use a particular crypto system (e.g., certification of a public key based on a certain elliptic curve) are represented as an attribute, to be reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type indicating the algorithm and the values indicating the particular parameters specific to the algorithm. Requests for descriptive information from the client are made by an attribute, to be represented as Attributes of the CSR, with a type indicating the [RFC2985] extensionRequest and the values indicating the particular attributes desired to be included in the resulting certificate's extensions.
CSR属性响应的结构应尽可能反映其请求的CSR的结构。使用特定签名方案（例如，使用特定哈希函数）的请求表示为OID，以反映在CSR的SignatureAlgorithm中。使用特定密码系统的请求（例如，基于特定椭圆曲线的公钥认证）表示为属性，反映为SubjectPublicKeyInfo的算法标识符，类型指示算法，值指示特定于算法的特定参数。客户端对描述性信息的请求由一个属性发出，该属性表示为CSR的属性，其类型表示[RFC2985]扩展请求，值表示希望包含在结果证书扩展中的特定属性。
The sequence is Distinguished Encoding Rules (DER) encoded [X.690] and then base64 encoded (Section 4 of [RFC4648]). The resulting text forms the application/csrattr body, without headers.
序列采用区分编码规则（DER）编码[X.690]，然后采用base64编码（RFC4648第4节）。结果文本构成应用程序/csrattr正文，不带标题。
For example, if a CA requests a client to submit a certification request containing the challengePassword (indicating that linking of identity and POP information is requested; see Section 3.5), an extensionRequest with the Media Access Control (MAC) address ([RFC2307]) of the client, and to use the secp384r1 elliptic curve and to sign with the SHA384 hash function. Then, it takes the following:
例如，如果CA请求客户端提交包含challengePassword（指示请求身份和POP信息的链接；请参见第3.5节）的认证请求，则请求客户端的媒体访问控制（MAC）地址（[RFC2307]）的扩展请求，以及使用secp384r1椭圆曲线并使用SHA384哈希函数签名。然后，采取以下措施：
OID: challengePassword (1.2.840.113549.1.9.7)
OID:challengePassword（1.2.840.113549.1.9.7）
Attribute: type = extensionRequest (1.2.840.113549.1.9.14) value = macAddress (1.3.6.1.1.1.1.22)
属性：type=extensionRequest（1.2.840.113549.1.9.14）value=macAddress（1.3.6.1.1.1.1.22）
Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) value = secp384r1 (1.3.132.0.34)
属性：type=id ecPublicKey（1.2.840.10045.2.1）value=secp384r1（1.3.132.0.34）
OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)
OID:ECDSAWITHSA384（1.2.840.10045.4.3.3）
and encodes them into an ASN.1 SEQUENCE to produce:
并将其编码为ASN.1序列以生成：
30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 03
30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 86 f7 0d 01 09 0e 31 09 06 07 2b 01 01 16 06 08 2a 86 48 ce 3d 04 03
and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
然后base64对生成的ASN.1序列进行编码，以生成：
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ BgcrBgEBAQEWBggqhkjOPQQDAw==
会议SQGSIB3DQEJBZASBGCQHKJOPQIBMQCGBSUBBAAIMBYGGCSQGSIB3DQEJDJEJ BGCRBGEBAQEWBGQHKJOPQQDAW==
Section 4.4.1.2 defines an OID that has been registered in an arc delegated by the IANA to the PKIX working group.
第4.4.1.2节定义了已在IANA委托给PKIX工作组的arc中注册的OID。
IANA has registered the following:
IANA注册了以下内容：
IANA updated the well-known URI registry with the following filled-in template from [RFC5785].
IANA使用[RFC5785]中的以下填充模板更新了著名的URI注册表。
URI suffix: est
URI后缀：est
Change controller: IETF
更改控制器：IETF
IANA has updated the "Application Media Types" registry with the following filled-in templates from [RFC6838].
IANA已使用[RFC6838]中的以下填充模板更新了“应用程序媒体类型”注册表。
The media subtype for CSR attributes in a CSR Attributes Response is application/csrattrs.
CSR属性响应中CSR属性的媒体子类型为application/csrattrs。
Type name: application
类型名称：应用程序
Subtype name: csrattrs
子类型名称：csrattrs
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: binary;
编码考虑：二进制；
Security Considerations:
安全考虑：
Clients request a list of attributes that servers wish to be in certification requests. The request/response is normally done in a TLS-protected tunnel.
客户端请求服务器希望在认证请求中包含的属性列表。请求/响应通常在TLS保护的隧道中完成。
Interoperability considerations: None
互操作性注意事项：无
Published specification: This memo.
发布规范：本备忘录。
Applications which use this media type: Enrollment over Secure Transport (EST)
使用此媒体类型的应用程序：通过安全传输注册（EST）
Additional information:
其他信息：
Magic number(s): None
幻数：无
File extension: .csrattrs
文件扩展名：.csr
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Dan Harkins <dharkins@arubanetworks.com>
Dan Harkins <dharkins@arubanetworks.com>
Restrictions on usage: None
使用限制：无
Author: Dan Harkins <dharkins@arubanetworks.com>
Author: Dan Harkins <dharkins@arubanetworks.com>
Intended usage: COMMON
预期用途：普通
Change controller: The IESG <iesg@ietf.org>
Change controller: The IESG <iesg@ietf.org>
The application/pkcs7-mime content-type defines the optional "smime-type" parameter [RFC5751] with a set of specific values. This document adds another value, "server-generated-key", as the parameter value for Server-side Key Generation Response.
application/pkcs7 mime内容类型使用一组特定值定义可选的“smime类型”参数[RFC5751]。本文档添加了另一个值“服务器生成的密钥”，作为服务器端密钥生成响应的参数值。
Support for Basic authentication, as specified in HTTP [RFC2617], allows the server access to a client's cleartext password. This provides support for legacy username/password databases but requires exposing the plaintext password to the EST server. Use of a PIN or one-time password can help mitigate such exposure, but it is RECOMMENDED that EST clients use such credentials only once to obtain a client certificate (that will be used during future interactions with the EST server).
HTTP[RFC2617]中指定的对基本身份验证的支持允许服务器访问客户端的明文密码。这提供了对传统用户名/密码数据库的支持，但需要向EST服务器公开明文密码。使用PIN或一次性密码有助于减少此类暴露，但建议EST客户端仅使用此类凭据一次以获取客户端证书（将在将来与EST服务器交互时使用）。
When a client uses the Implicit TA database for certificate validation (see Section 3), then authorization proceeds as specified in Section 3.6.2. In this situation, the client has validated the server as being a responder that is certified by a third party for the URI configured, but it cannot verify that the responder is authorized to act as an RA for the PKI in which the client is trying to enroll. Clients using an Implicit Trust Anchor database are RECOMMENDED to use only TLS-based client authentication (to prevent exposing HTTP-based client authentication information). It is RECOMMENDED that such clients include "Linking Identity and POP Information" (Section 3.5) in requests (to prevent such requests from being forwarded to a real EST server by a man in the middle). It is RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication be carefully managed to reduce the chance of a third-party CA with poor certification practices from being trusted. Disabling the Implicit Trust Anchor database after successfully receiving the Distribution of CA certificates response (Section 4.1.3) limits any vulnerability to the first TLS exchange.
当客户机使用隐式TA数据库进行证书验证（见第3节）时，授权将按照第3.6.2节的规定进行。在这种情况下，客户端已验证服务器是由第三方针对配置的URI认证的响应者，但无法验证响应者是否被授权作为客户端尝试注册的PKI的RA。建议使用隐式信任锚数据库的客户端仅使用基于TLS的客户端身份验证（以防止公开基于HTTP的客户端身份验证信息）。建议此类客户端在请求中包含“链接身份和POP信息”（第3.5节）（以防止中间人将此类请求转发到真正的EST服务器）。建议仔细管理用于EST服务器身份验证的隐式信任锚数据库，以减少认证实践不佳的第三方CA被信任的机会。在成功接收CA证书分发响应（第4.1.3节）后禁用隐式信任锚数据库可限制对第一个TLS交换的任何漏洞。
Certificate-less TLS cipher suites that maintain security and perform the mutual authentication necessary for enrollment have the following properties:
维护安全性并执行注册所需的相互身份验证的无证书TLS密码套件具有以下属性：
o the only information leaked by an active attack is whether or not a single guess of the secret is correct.
o 主动攻击泄露的唯一信息是对秘密的猜测是否正确。
o any advantage an adversary gains is through interaction and not computation.
o 对手获得的任何优势都是通过互动而不是计算。
o it is possible to perform countermeasures, such as exponential backoff after a certain number of failed attempts, to frustrate repeated active attacks.
o 可以执行对策，例如在一定次数的尝试失败后进行指数退避，以挫败重复的主动攻击。
Using a certificate-less cipher suite that does not have the properties listed above would render the results of enrollment void and potentially result in certificates being issued to unauthenticated and/or unauthorized entities.
使用不具有上述属性的无证书密码套件将导致注册结果无效，并可能导致向未经验证和/或未经授权的实体颁发证书。
When using a certificate-less TLS cipher suite, the shared secret used for authentication and authorization cannot be shared with an entity that is not a party to the exchange: someone other than the client and the server. Any additional sharing of secrets voids the security afforded by a certificate-less cipher suite. Exposure of a shared secret used by a certificate-less cipher suite to a third party enables client impersonation that can result in corruption of a client's trust anchor database.
当使用无证书TLS密码套件时，用于身份验证和授权的共享机密不能与非交换方的实体共享：客户机和服务器以外的人。任何额外的秘密共享都会使无证书密码套件提供的安全性无效。将无证书密码套件所使用的共享秘密公开给第三方可进行客户端模拟，从而导致客户端的信任锚数据库损坏。
TLS cipher suites that include "_EXPORT_" and "_DES_" in their names MUST NOT be used. These ciphers do not offer a sufficient level of protection; 40-bit crypto in 2013 doesn't offer acceptable protection, and the use of DES is deprecated.
不得使用名称中包含“\u EXPORT”和“\u DES”的TLS密码套件。这些密码没有提供足够的保护级别；2013年的40位加密无法提供可接受的保护，DES的使用也不受欢迎。
As described in CMC, Section 6.7 of [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". The inclusion of tls-unique within the certification request links the proof-of-possession to the TLS proof-of-identity by enforcing that the POP operation occurred while the TLS session was active. This implies to the server that the authenticated client currently has access to the private key. If the authenticated client is known to have specific capabilities, such as hardware protection for authentication credentials and key storage, this implication is strengthened but not proven.
如CMC[RFC5272]第6.7节所述，“对于可用作签名密钥的密钥，使用私钥对认证请求进行签名将作为该密钥对上的POP”。在认证请求中包含tls unique，通过强制执行POP操作在tls会话处于活动状态时发生，将占有证明与tls身份证明联系起来。这对服务器意味着经过身份验证的客户端当前可以访问私钥。如果已知经过身份验证的客户端具有特定的功能，例如对身份验证凭据和密钥存储的硬件保护，则这一含义将得到加强，但尚未得到证实。
The server-side key generation method allows keys to be transported over the TLS connection to the client without any application-layer protection. The distribution of private key material is inherently risky. Private key distribution 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 as specified in [RFC5958] as encryption of the private key beyond that provided by TLS is optional. It is RECOMMENDED that EST servers not support this operation by default. It is RECOMMENDED that clients not request this service unless there is a compelling operational benefit. Use of an Implicit Trust Anchor database is NOT RECOMMENDED when server-side key generation is employed. The use of an encrypted CMS Server-Side Key Generation Response is RECOMMENDED.
服务器端密钥生成方法允许通过TLS连接将密钥传输到客户端，而无需任何应用层保护。私钥材料的分发本身就有风险。私钥分发使用协商TLS密码套件的加密模式。密钥不受首选密钥包装方法的保护，如AES密钥包装[RFC3394]或[RFC5958]中的规定，因为超出TLS提供的私钥加密是可选的。默认情况下，建议EST服务器不支持此操作。建议客户不要请求此服务，除非有令人信服的运营效益。当使用服务器端密钥生成时，不建议使用隐式信任锚数据库。建议使用加密的CMS服务器端密钥生成响应。
Regarding the CSR attributes that the CA may list for inclusion in an enrollment request, there are no real inherent security issues with the content being conveyed, but an adversary who is able to interpose
关于CA可能列出以包含在注册请求中的CSR属性，所传送的内容不存在真正的固有安全问题，而是存在能够介入的对手
herself into the conversation could exclude attributes that a server may want, include attributes that a server may not want, and render meaningless other attributes that a server may want.
她自己参与对话可能会排除服务器可能需要的属性，包括服务器可能不需要的属性，并使服务器可能需要的其他属性变得毫无意义。
ASN.1 encoding rules (e.g., DER and BER) have a type-length-value structure, and it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions. ASN.1 encoding rules allow for arbitrary levels of nesting, which may make it possible to construct malicious content that will cause a stack overflow. Interpreters of ASN.1 structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular, and malicious content in general.
ASN.1编码规则（如DER和BER）具有类型-长度-值结构，很容易使用无效长度字段构造恶意内容，从而导致缓冲区溢出情况。ASN.1编码规则允许任意级别的嵌套，这可能导致构建恶意内容，从而导致堆栈溢出。ASN.1结构的解释器应了解这些问题，并应采取适当措施防止缓冲区溢出和堆栈溢出，尤其是恶意内容。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108]Housley，R.“使用加密消息语法（CMS）保护固件包”，RFC 4108，2005年8月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[RFC5273]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）：传输协议”，RFC 5273，2008年6月。
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[RFC5274]Schaad，J.和M.Myers，“CMS上的证书管理消息（CMC）：合规性要求”，RFC 5274，2008年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年2月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，2010年4月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929]Altman，J.，Williams，N.，和L.Zhu，“TLS的通道绑定”，RFC 59292010年7月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，2010年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, November 2011.
[RFC6402]Schaad，J.，“CMS（CMC）更新的证书管理”，RFC6402，2011年11月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008, <http://www.itu.int/rec/T-REC-X.680-200811-I/en>.
[X.680]ITU-T建议X.680（2008）| ISO/IEC 8824-1:2008，“抽象语法符号一（ASN.1）：基本符号规范”，2008年11月<http://www.itu.int/rec/T-REC-X.680-200811-I/en>.
[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008, <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.
[X.690]ITU-T建议X.690（2008）| ISO/IEC 8825-1:2008，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，2008年11月<http://www.itu.int/rec/T-REC-X.690-200811-I/en>.
[IDevID] IEEE Standards Association, "IEEE 802.1AR Secure Device Identifier", December 2009, <http://standards.ieee.org/ findstds/standard/802.1AR-2009.html>.
[IDevID]IEEE标准协会，“IEEE 802.1AR安全设备标识符”，2009年12月<http://standards.ieee.org/ findstds/standard/802.1AR-2009.html>。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[RFC2307]Howard，L.，“将LDAP用作网络信息服务的方法”，RFC 2307，1998年3月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[RFC2985]Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 29852000年11月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007.
[RFC5054]Taylor，D.，Wu，T.，Mavrogiannopoulos，N.，和T.Perrin，“使用安全远程密码（SRP）协议进行TLS身份验证”，RFC 5054，2007年11月。
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, August 2010.
[RFC5967]Turner，S.，“应用程序/pkcs10媒体类型”，RFC 59672010年8月。
[RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of Certificate Management over CMS", RFC 6403, November 2011.
[RFC6403]Zieglar，L.，Turner，S.，和M.Peck，“CMS上证书管理的套件B配置文件”，RFC 6403，2011年11月。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard Publication 180-4, March 2012, <http://csrc.nist.gov/publications/fips/ fips180-4/fips-180-4.pdf>.
[SHS]国家标准与技术研究所，“安全哈希标准（SHS）”，联邦信息处理标准出版物180-42012年3月<http://csrc.nist.gov/publications/fips/ fips180-4/fips-180-4.pdf>。
[SP-800-57-Part-1] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revision 3)", July 2012, <http://csrc.nist.gov/publications/nistpubs/800-57/ sp800-57_part1_rev3_general.pdf>.
[SP-800-57-Part-1]国家标准与技术研究所，“关键管理建议-第1部分：概述（第3版）”，2012年7月<http://csrc.nist.gov/publications/nistpubs/800-57/ sp800-57\u part1\u rev3\u general.pdf>。
(Informative)
（资料性）
This section expands on the Operational Scenario Overviews by providing detailed examples of the messages at each TLS layer.
本节通过提供每个TLS层的消息的详细示例来扩展操作场景概述。
The following is an example of a valid /cacerts exchange.
以下是有效/cacerts交换的示例。
During the initial TLS handshake, the client can ignore the optional server-generated "certificate request" and can instead proceed with the HTTP GET request:
在初始TLS握手过程中，客户端可以忽略可选的服务器生成的“证书请求”，而是继续执行HTTP GET请求：
GET /.well-known/est/cacerts HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*
GET /.well-known/est/cacerts HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*
In response, the server provides the current CA certificates:
作为响应，服务器提供当前CA证书：
HTTP/1.1 200 OK Status: 200 OK Content-Type: application/pkcs7-mime Content-Transfer-Encoding: base64 Content-Length: 4246
HTTP/1.1 200正常状态：200正常内容类型：应用程序/pkcs7 mime内容传输编码：base64内容长度：4246
MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
+zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx
WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO
HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P
K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1
EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8
3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril
9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB
Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B
Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6
uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7
KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo
X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA
KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA
x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD
MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w
bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
+zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx
WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO
HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P
K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1
EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8
3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril
9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB
Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B
Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6
uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7
KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo
X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA
KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA
x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD
MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w
bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C
loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt
9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u
btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto
CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU
lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw
HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy
oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH
q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv
zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd
sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI
R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY
GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF
XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl
c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow
GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v
2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn
4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr
EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P
7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE
pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/
BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW
gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp
BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK
2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy
iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK
cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU
DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3
c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF
ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX
DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X
Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa
Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed
SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx
PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7
NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA
AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5
arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn
GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8
9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c
VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+
OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j
NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq
jM0MAGNDEW+1oQAxAA==
VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C
loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt
9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u
btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto
CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU
lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw
HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy
oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH
q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv
zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd
sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI
R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY
GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF
XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl
c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow
GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v
2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn
4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr
EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P
7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE
pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/
BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW
gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp
BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK
2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy
iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK
cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU
DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3
c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF
ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX
DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X
Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa
Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed
SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx
PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7
NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA
AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5
arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn
GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8
9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c
VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+
OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j
NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq
jM0MAGNDEW+1oQAxAA==
The following is an example of a valid /csrattrs exchange. During this exchange, the EST client authenticates itself using an existing certificate issued by the CA for which the EST server provides services.
下面是一个有效/csrattrs交换的示例。在此交换过程中，EST客户端使用EST服务器为其提供服务的CA颁发的现有证书进行身份验证。
The initial TLS handshake is identical to the enrollment example handshake. The HTTP GET request:
初始TLS握手与注册示例握手相同。HTTP GET请求：
GET /.well-known/est/csrattrs HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*
GET /.well-known/est/csrattrs HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*
In response, the server provides suggested attributes that are appropriate for the authenticated client. In this example, the EST server also includes two example attributes that the client would ignore unless the attribute type is known to the client:
作为响应，服务器提供适合已验证客户端的建议属性。在此示例中，EST服务器还包括两个示例属性，除非客户机知道属性类型，否则客户机将忽略这两个示例属性：
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/csrattrs
Content-Transfer-Encoding: base64
Content-Length: 171
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/csrattrs
Content-Transfer-Encoding: base64
Content-Length: 171
MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC
MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC
The following is an example of a valid /simpleenroll exchange. The data messages for /simplereenroll are similar.
下面是一个有效的/simplenRoll交换示例。/simplereenroll的数据消息类似。
During this exchange, the EST client uses an out-of-band distributed username/password to authenticate itself to the EST server. This is the normal HTTP WWW-Authenticate behavior and is included here for informative purposes. When an existing TLS client certificate is used, the server might skip requesting the HTTP WWW-Authenticate header, such as during a /simplereenroll operation.
在此交换期间，EST客户端使用带外分布式用户名/密码向EST服务器进行身份验证。这是正常的HTTP WWW身份验证行为，此处包含此行为是为了提供信息。使用现有TLS客户端证书时，服务器可能会跳过HTTP WWW Authenticate标头的请求，例如在/simplereenroll操作期间。
During the initial TLS handshake, the client can ignore the optional server-generated "certificate request" and can instead proceed with the HTTP POST request. In response to the initial HTTP POST attempt,
在初始TLS握手期间，客户机可以忽略可选的服务器生成的“证书请求”，而可以继续HTTP POST请求。作为对初始HTTP POST尝试的响应，
the server requests WWW-Authenticate from the client (this might occur even if the client used a client certificate, as detailed in the normative text above):
服务器从客户机请求WWW身份验证（即使客户机使用了客户机证书，也可能发生这种情况，如上面的规范性文本所述）：
HTTP/1.1 401 Unauthorized
Content-Length: 0
WWW-Authenticate: Digest qop="auth", realm="estrealm",
nonce="1368141352"
HTTP/1.1 401 Unauthorized
Content-Length: 0
WWW-Authenticate: Digest qop="auth", realm="estrealm",
nonce="1368141352"
In the subsequent HTTP POST, the username/password is included, along with the complete application/pkcs10 content:
在随后的HTTP帖子中，包含用户名/密码以及完整的应用程序/pkcs10内容：
POST /.well-known/est/simpleenroll HTTP/1.1
Authorization: Digest username="estuser", realm="estrealm", nonc
e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M
TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e
b16db20f75f22"
Host: 192.0.2.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
Content-Length: 882
POST /.well-known/est/simpleenroll HTTP/1.1
Authorization: Digest username="estuser", realm="estrealm", nonc
e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M
TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e
b16db20f75f22"
Host: 192.0.2.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
Content-Length: 882
MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3
eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/
XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y
MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y
hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK
tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB
AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B
AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq
wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c
VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur
5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh
cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n
PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==
MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3
eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/
XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y
MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y
hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK
tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB
AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B
AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq
wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c
VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur
5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh
cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n
PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==
The EST server uses the username/password to perform authentication/authorization and responds with the issued certificate:
EST服务器使用用户名/密码执行身份验证/授权，并使用颁发的证书进行响应：
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
Content-Length: 1122
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
Content-Length: 1122
MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
R4POrT2xz8ChADEA
MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
R4POrT2xz8ChADEA
The following is an example of a valid /serverkeygen exchange. During this exchange, the EST client authenticates itself using an existing certificate issued by the CA the EST server provides services for.
以下是有效的/serverkeygen交换示例。在此交换过程中，EST客户端使用EST服务器为其提供服务的CA颁发的现有证书进行身份验证。
The initial TLS handshake is identical to the enrollment example handshake. An example HTTP POSTed message is:
初始TLS握手与注册示例握手相同。HTTP发布的消息示例如下：
POST /.well-known/est/serverkeygen HTTP/1.1
Host: 192.0.2.1:8085
Accept: */*
Expect: 100-continue
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
Content-Length: 963
POST /.well-known/est/serverkeygen HTTP/1.1
Host: 192.0.2.1:8085
Accept: */*
Expect: 100-continue
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
Content-Length: 963
MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll
bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn
ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/
3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo
RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS
sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz
4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2
5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V
ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2
cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu
L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6
GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA
gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH
veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j
M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==
MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll
bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn
ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/
3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo
RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS
sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz
4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2
5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V
ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2
cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu
L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6
GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA
gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH
veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j
M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==
Because the DecryptKeyIdentifier attribute is not included in this request, the response does not include additional encryption beyond the TLS session. The EST server response is:
由于DecryptKeyIdentifier属性不包括在此请求中，因此响应不包括TLS会话之外的其他加密。EST服务器响应为：
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
Content-Length: 3219
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
Content-Length: 3219
This is the preamble. It is to be ignored, though it is a handy place for estServer to include an explanatory note, including contact or support information. --estServerExampleBoundary Content-Type: application/pkcs8 Content-Transfer-Encoding: base64
这是序言。尽管它是estServer包含解释性说明（包括联系方式或支持信息）的一个方便的地方，但可以忽略它--estServerExampleBoundary内容类型：应用程序/pkcs8内容传输编码：base64
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+
Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU
F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9
rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z
IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0
Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK
FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo
KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm
BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3
JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL
IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79
GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe
p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw
SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW
fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer
srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/
BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI
RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw
vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo
eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp
wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3
Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4
zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx
4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa
fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX
pM7PYH/x4BiBmgQ3bhOqTp4H
--estServerExampleBoundary
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+
Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU
F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9
rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z
IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0
Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK
FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo
KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm
BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3
JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL
IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79
GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe
p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw
SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW
fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer
srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/
BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI
RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw
vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo
eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp
wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3
Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4
zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx
4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa
fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX
pM7PYH/x4BiBmgQ3bhOqTp4H
--estServerExampleBoundary
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8 mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ 9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4 MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC 1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA== --estServerExampleBoundary-- This is the epilogue. It is also to be ignored.
Miidrqyjkozihvcnaqc3RFEGFT CGXLQ0EGTNDOMB4TEZMDUWOTIZMJU1NLODHDHMCGG是一个非常好的例子，它是一个很好的例子，因为它是一个很好的例子VOGKucvP2zj+WUKKFYVMNTPFQHPNX3CKJ/WXEOR1BF3UUTLXJN1FJW58PUD t/BVKDHPY2240K7NEPCQRFVHC5HRGGPZMTANCCSQ2MVAW+BUDJIVPWGVYVKYVKYE8 MC2WfW0G6XEDLA0A9HOFDLEPNK8POP5C+WJPOWSCHOFTUZZZZOW6QBKW6QBKW6QBKW6QBZZYL3KW7BK7BK0T7V7V7V7V8IBL7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7UdaobgNvH8Baf8Baf8Ebam8Ebam8Ebam8Ebam8Ebam8Ebam8Ebam8Ebaf8Eqgsib3Qebqua a4IbaqHlmrakrantapqBobDm9IQDQpuww+fW1gYwZKlSm/IwiwhhezL1IGXHPJJJ RF4QPIKIKKAOXAO8Pfnix0/lZM9FQSM/J89CuF5dMoaQWw8J8BqW8Bq8Xu9LZm9LZm9F8Hb9Hb9Hvc8Hvc8Hb9Fvc6Ww6Ww6W9F9F8Hb9F9Fx8Fx8Fx8Fx8Fx8Ww6Ww9FxHb9Fx8W9W9W9W9FE7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoyjtymn4v5kb3rt+m s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC 1o9qt0gyj6sxaykigtoxk6jmddoqaa=--estServerExampleBoundary——这是结束语。这也是不容忽视的。
The editors would like to thank Stephen Kent, Vinod Arjun, Jan Vilhuber, Sean Turner, Russ Housley, and others for their feedback and prototypes of early versions of this document. Our thanks also go the authors of [RFC6403], around whose document we structured part of this specification.
编辑们要感谢Stephen Kent、Vinod Arjun、Jan Vilhuber、Sean Turner、Russ Housley和其他人对本文件早期版本的反馈和原型。我们还要感谢[RFC6403]的作者，我们围绕他们的文档构建了本规范的一部分。
Authors' Addresses
作者地址
Max Pritikin (editor) Cisco Systems, Inc. 510 McCarthy Drive Milpitas, CA 95035 USA
Max Pritikin（编辑）思科系统公司，美国加利福尼亚州米尔皮塔斯麦卡锡大道510号，邮编95035
EMail: pritikin@cisco.com
EMail: pritikin@cisco.com
Peter E. Yee (editor) AKAYLA, Inc. 7150 Moorland Drive Clarksville, MD 21029 USA
Peter E.Yee（编辑）AKAYLA，Inc.美国马里兰州克拉克斯维尔摩尔兰大道7150号，邮编：21029
EMail: peter@akayla.com
EMail: peter@akayla.com
Dan Harkins (editor) Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 USA
Dan Harkins（编辑）美国加利福尼亚州桑尼维尔市克罗斯曼大道1322号阿鲁巴网络公司94089-1113
EMail: dharkins@arubanetworks.com
EMail: dharkins@arubanetworks.com