[要約] RFC 7030は、証明書のエンロールメントを安全なトランスポート上で行うためのプロトコルを定義しています。その目的は、セキュアな通信チャネルを介して証明書を安全に取得することです。
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）メッセージを介した証明書管理を安全なトランスポート経由で使用するクライアントの証明書登録について説明します。 Enrollment over Secure Transport（EST）と呼ばれるこのプロファイルは、クライアント証明書と関連する認証局（CA）証明書を取得する必要がある公開鍵インフラストラクチャ（PKI）クライアントを対象とする、シンプルでありながら機能的な証明書管理プロトコルを記述します。また、クライアントが生成した公開鍵と秘密鍵のペア、およびCAが生成した鍵のペアもサポートしています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]を使用して、認証および承認されたチャネルを提供します。 Simple Public Key Infrastructure（PKI）Requests and Responses [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はCA証明書のロールオーバーに証明書管理プロトコル（CMP）[RFC4210]モデルを採用していますが、CMPメッセージの構文やプロトコルは使用していません。 ESTサーバーは拡張可能であり、CMC [RFC5272]で指定されていない追加機能を提供するために新しい関数を定義できます。このドキュメントでは、証明書署名要求属性を要求するものとサーバー生成キーを要求するものの2つの拡張機能を定義しています。
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で動作します。このドキュメントでは、EST over HTTP /データグラムトランスポート層セキュリティ/ユーザーデータグラムプロトコル（HTTP / DTLS / UDP）を指定していません。 HTTP、DTLS、およびUDPを組み合わせるための適切な仕様があれば、そのようなスタックで動作することを妨げるEST要件はありません。図1は、レイヤーが相互にどのように構築されるかを示しています。
EST Layering:
ISレイヤー：
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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 CAはESTサーバーを通じて到達します。 CAは、論理的にESTサーバーの「背後」にあるか、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。たとえば、セクション4.1.1で説明されているように、ESTクライアントで手動で構成された、またはブートストラップされた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).
Implicit Trust Anchor：TLS認証中に使用するためにクライアントまたはサーバーで使用可能であるが、EST TLS認証中に使用するように明確に示されていない任意のサードパーティTA。たとえば、WebサーバーがWebサーバーを認証するために一般的に使用するTAや、サーバーがメーカーがインストールしたクライアント資格情報（工場内のケーブルモデムやルーターに入力された証明書など）を認証するために使用する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クライアントとサーバーの両方が、相互認証と承認の基礎を提供する情報で構成されています。特定の初期化データは、クライアントとサーバーで利用可能なメソッドに依存しますが、共有シークレット、ネットワークサービス名と場所（たとえば、Uniform Resource Identifier（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 CA証明書のコピーをESTサーバーに要求できます。 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）など）があり、署名の検証に使用したものとは異なる証明書があると想定しています。証明書とCRLは、ESTプロトコル通信に追加の暗号化が必要な場合に使用されます。
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:
ESTクライアントは、現在のCA証明書を要求するときに、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を使用して、ESTサーバーのHTTPS URIをESTサーバーの証明書と照合します（一般的なHTTPS交換と同様）。これにより、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 以前に発行されたクライアント証明書を使用したTLS（例：EST CAによって発行された既存の証明書）
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 証明書なしのTLS（帯域外に分散された共有資格情報など）
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サーバーからの証明書に対するクライアントの要求を認証できます（そのCAがESTサーバーによって認識されている場合）。 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.
たとえば、クライアントがTLSクライアント認証に使用できるEST CAによって発行された代替証明書を持っている場合は、それを使用できます。
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経由で転送できます。これにより、単純登録機能では提供されない機能にアクセスできます。完全なPKI要求メッセージは、[RFC5272]のセクション3.2および4.2で定義されています。 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クライアントのインターフェースのメディアアクセス制御（MAC）アドレスなど、ESTサーバーがそれ自体にアクセスできない追加の説明情報を提供できます。あるいは、これらの属性は、クライアントが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:
ISレイヤー：
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を指定すると、認証と制御メッセージを通信するための2つの「レイヤー」が導入されます。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層は、転送中に整合性と機密性を提供します。 IDの証明は、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）は、「身元証明を含める必要がある場合は、Simple 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によって発行されたものか、個別の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およびID証明メカニズムは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にリストされている各タイプの1つ以上の証明書を持ち、図4にリストされている各タイプの1つ以上のトラストアンカーデータベースを使用できます。
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 |
+--------------+----------------------------------------------------+
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クライアントは、Simple 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を指定する機能を提供する必要があります。人間の使いやすさの理由から、セクション4.1.1で説明するように、明示的なTAデータベースエントリの「フィンガープリント」をブートストラップ用に構成できます。おそらくESTクライアントディストリビューション内に含めるか、オペレーティングシステムから利用できるようにすることで、暗黙のTAデータベースを構成すると、セクション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の権限部分とOPTIONALラベル（たとえば、 "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メッセージの転送に使用されます。セクション3.2.2で説明するように、URIは各メディアタイプ（メッセージタイプ）を処理するために定義されます。 TLSによる使用に適したクライアント証明書がないために、TLSクライアント認証が利用できない場合、HTTPはクライアント認証サービスにも使用されます（セクション3.2.3を参照）。セクション2.2.3に記載されているように、ESTサーバーが追加の認証情報を必要とする場合は、TLSクライアント認証に加えてHTTP認証も使用できます。登録されたメディアタイプは、図6で指定されているESTメッセージの伝達に使用されます。
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 Content-Typeヘッダーで指定されたメディアタイプは、転送されるESTメッセージを示します。 ESTで使用されるメディアタイプは、セクション3.2.4で指定されています。
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.
同じ接続元（[RFC6454]を参照）へのHTTPリダイレクト（3xxステータスコード）は、該当するすべてのセキュリティチェック（セクション3.3および3.6）が初期接続に適用されている限り、ユーザー入力なしでクライアントによって処理される必要があります（SHOULD）。クライアントは新しいTLS接続を開始し、他のWebオリジンサーバーにリダイレクトされるときに、該当するすべてのセキュリティチェックを実行します。他のWebオリジンへのリダイレクトでは、ESTクライアントが[RFC2616]で指定されている非GETまたはHEADリクエストのユーザー入力を取得する必要があります。さらに、クライアントがリンクIDとPOP情報を含むCSRをすでに生成している場合（セクション3.5）、CSRを再作成して、新しくリダイレクトされたセッションからtls-uniqueを組み込む必要があります。注：鍵ペアを再生成する必要はありません。これらは、クライアントの処理とインターフェイスの負担です。 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) | | |
+------------------------+-----------------+-------------------+
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）がpath-prefixに追加され、HTTP GETまたはPOSTで使用されるURIが形成され、目的のEST操作が実行されます。 「/ cacerts」操作の有効なURI絶対パスの例は、「/。well-known / est / cacerts」です。 CAの証明書を取得するために、ESTクライアントは次のHTTPリクエストラインを使用します。
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 The use of distinct operation paths simplifies implementation for servers that do not perform client authentication when distributing /cacerts responses.
POST /.well-known/est/simpleenroll HTTP / 1.1別個の操作パスを使用すると、/ 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サーバーは、追加のパスセグメントが存在するかどうかに関係なく、サービスを提供する必要があります。以下は、3つの有効なURIの例です。
1. https://www.example.com/.well-known/est/cacerts
1. ｈっｔｐｓ：／／ｗっｗ。えぁｍｐぇ。こｍ／。うぇっｌーｋのｗん／えｓｔ／かせｒｔｓ
2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts
2. ｈっｔｐｓ：／／ｗっｗ。えぁｍｐぇ。こｍ／。うぇっｌーｋのｗん／えｓｔ／あｒびｔらｒｙぁべｌ１／かせｒｔｓ
3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts
3. ｈっｔｐｓ：／／ｗっｗ。えぁｍｐぇ。こｍ／。うぇっｌーｋのｗん／えｓｔ／あｒびｔらｒｙぁべｌ２／かせｒｔｓ
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ベースのクライアント認証を要求してもよい（MAY）。 ESTサーバーポリシーが追加の認証を必要とする場合、この要求は、成功したTLSクライアント認証（セクション3.3.2）に追加できます。 （たとえば、ESTサーバーは、既存のクライアント証明書を「持っている」ことに加えて、ESTクライアントがパスワードを「知っている」ことを要求する場合があります。）または、HTTPベースのクライアント認証は、 ESTクライアントがTLSクライアント認証を正常に完了しませんでした。 （これは、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暗号スイートは、それぞれ機密性を提供しないか、相互の証明書ベースまたは証明書なしの認証をサポートしないため、使用してはなりません（MUST NOT）。 「CMS（CMC）を介した証明書管理：トランスポートプロトコル」[RFC5273]で指定されているように、サーバーは「Cookie、基本認証、ダイジェスト認証など、あらゆる種類のHTTP認証のクライアントサポートを想定してはなりません」。クライアントは、基本認証およびダイジェスト認証メカニズムをサポートする必要があります（SHOULD）。
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応答ヘッダーを使用してHTTPリクエストを拒否します（[RFC2616]、セクション14.47）。クライアントが基本認証またはダイジェスト認証を使用できる場合、クライアントは適切なAuthorization Requestヘッダー（[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.
ユーザー名に関連付けられていないパスワードを提示する場合、クライアントはユーザー名を空の文字列（ ""）に設定できます（MAY）。
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).
セクション6で説明したように、HTTPベースのクライアント認証のサポートにはセキュリティ上の影響があります。クライアントがESTサーバーを承認していない限り、クライアントはサーバーのHTTP認証要求に応答してはなりません（セクション3.6に従って）。
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 Content-Typeヘッダーを使用します。
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 | | |
+--------------------+--------------------------+-------------------+
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）。 ESTサーバーは、クライアントがCA証明書のブートストラップ配布（セクション4.1.1）または完全なCMC（セクション4.3）を要求していない限り、TLSハンドシェイク中に認証される必要があります。
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を使用する必要があります。 TLS 1.1 [RFC4346]（またはそれ以降のバージョン）は、すべてのEST通信に使用する必要があります。 TLSセッション再開[RFC5077]はサポートされるべきです（SHOULD）。
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チャネルバインディング情報を証明書要求に挿入して、認証されたTLSクライアントが要求されている証明書の秘密鍵にアクセスできることをESTサーバーに保証することができます。 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クライアントを使用してTLSサーバー証明書を検証します。明示的で、有効な場合は、暗黙的TAデータベースを検証します。クライアントは、適切な承認をサポートするために、認証中の明示的TAデータベースと暗黙的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.
証明書の検証に失敗した場合、クライアントは、CA証明書のブートストラップ配布のセクション4.1.1で概説されている手順に従うことができます（MAY）。
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ハンドシェイクに使用する必要があります。そうでない場合、クライアントは、暗号スイートに適しており、同じサブジェクトID情報を含む代替証明書を使用する必要があります（SHOULD）。登録操作を要求するとき、クライアントはそれ自身を認証するためにサードパーティによって発行されたクライアント証明書を使用できます。
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サーバーを使用してTLSクライアント証明書を検証します。サーバーは、適切な承認をサポートするために、認証中にExplicit TAデータベースとImplicit 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暗号スイートは、クライアントもサーバーも証明書を持っていない、証明書の使用を望まない、または証明書の検証に必要なトラストアンカーがない状況で相互認証を実行する方法を提供します。クライアントとサーバーは、相互認証のために証明書なしの暗号スイートをネゴシエートしてもよい（MAY）。
When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be based on a protocol that is 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で証明書なしの相互認証を使用する場合、暗号スイートは、辞書攻撃に耐性のあるプロトコルに基づく必要があり、ゼロ知識プロトコルに基づく必要があります。 [RFC5054]のセクション2.7にリストされている、トランスポート層セキュリティ-セキュアリモートパスワード（TLS-SRP）暗号スイート、つまり名前に_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.
証明書なしの暗号スイートを使用した認証が成功すると、事前に共有されたシークレットが認識され、交換のピアが暗黙的に承認されます。
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で説明されているメカニズムは、オプションで「直接」ベースの所有証明[RFC5272]を含めることでこれを強化し、登録要求の署名の対象となるデータ内にTLSセッション固有の情報を含めます（したがって、登録要求を認証済みエンドにリンクします） TLS接続のポイント）。
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属性応答を検査することで、サーバーがIDとPOPのリンクを必要とするかどうかを判断できます（セクション4.5.2を参照）。 CSR属性応答に関係なく、クライアントは、認証リクエストにtls固有の情報を埋め込むことにより、IDとPOPをリンクする必要があります（SHOULD）。 tls-unique情報がクライアントに含まれている場合、サーバーはそれを検証する必要があります。 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.
IDと所有証明をリンクすると、認証されたTLSクライアントが認証要求に関連付けられた秘密鍵を所有していること、およびクライアントがTLSセッションの確立後に認証要求に署名できたことをサーバーに証明します。これは、[RFC5272]のセクション6で定義されている「IDと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のチャネルバインディング[RFC5929]で説明されているように、TLSサブシステムからtls-unique値を取得します。現在のtls-unique値を含むCSRの生成によるtls-unique値の取得と、ESTサーバーによるこの値の後続の検証との間のESTクライアント操作は、「アプリケーション層の認証が行われるアプリケーションプロトコルのフェーズです」 ";これらの操作は、[RFC5929]のセクション3.1の「TLSのチャネルバインディング」相互運用性に関するメモに記載されている同期相互運用性メカニズムによって保護されています。
When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used.
再ネゴシエーションを実行するときは、TLS "secure_renegotiation" [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-unique値は、[RFC4648]のセクション4で指定されているようにbase64でエンコードされ、結果の文字列が認証要求チャレンジパスワードフィールド（[RFC2985]、セクション5.4.1）に配置されます。チャレンジパスワードフィールドは255バイトに制限されています（[RFC5246]のセクション7.4.9は、既存の暗号スイートがこの制限の問題を引き起こさないことを示しています）。 challenge-password属性が存在しない場合、クライアントにはオプションのチャネルバインディング情報が含まれていません（challenge-password属性の存在は、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 [RFC5272] "RA POP Witness Control"をCMC Full PKI Requestメッセージで使用する場合があります。または、ESTサーバーがESTクライアントを無効に転送しない信頼できるインフラストラクチャ要素としてTLS認証する場合がありますバックエンド処理の詳細な説明は範囲外です。）
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が適用されます。 Implicit 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で指定されているようにブートストラップを実行できます（MAY）。
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クライアントのExplicit TAデータベースを使用してESTサーバー証明書を検証する場合、クライアントは、[RFC6125]、セクション6.4、またはセクション6.4で指定されたルールに従って、設定されたURIまたは最新のHTTPリダイレクトURIをサーバーのIDと照合する必要があります。 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は承認の基礎を提供し、サーバーの認証されたIDはそれが承認されたサーバーであることを確認します。
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は、各クライアントの認証済みID（たとえば、HTTPユーザー認証資格情報に加えてTLSクライアントの証明書）へのESTサーバーアクセスを提供して、そのようなポリシーの実装に役立ちます。
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クライアントと整合性のある承認ポリシーを適用する必要があります（SHOULD）。たとえば、/ simpleenrollリクエストを処理する場合、認証済みのESTクライアントRAがESTサーバーとして機能しているときにこの情報を確認するため、現在のTLSセッションと一致しないPOPリンク情報を受け入れるように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サーバーにリクエストを行うかどうかを決定します。これらの承認の決定については、次の2つのセクションで説明します。交換の両側が許可されていると仮定すると、実際の操作は後続のセクションで説明するとおりです。
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.
4.1.3で説明されているように、明示的TAデータベースのブートストラップインストールを可能にする暗黙的TAデータベースでクライアントが構成されていない可能性があります。このセクションでは、最小構成のESTクライアントがExplicit 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ハンドシェイクを完了まで続行できます（MAY）。 ESTクライアントが認証されていない接続を続行する場合、クライアントは応答（セクション4.1.3または4.3.2）からHTTPコンテンツデータを抽出し、次のような帯域外データを使用してCA証明書を承認するように人間のユーザーに働きかけなければなりません（MUST）。 CA証明書の「フィンガープリント」（たとえば、CA証明書全体のSHA-256またはSHA-512 [SHS]ハッシュ）。 / 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認証要求に応答してはなりません（MUST NOT）。
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 until after the /cacerts response has been accepted and a new TLS session has been established (using TLS certificate-based authentication).
ESTクライアントは、/ cacerts応答を使用して、ESTサーバーの後続のTLS認証用の明示的なトラストアンカーデータベースを確立します。 ESTクライアントは、/ cacerts応答が受け入れられ、新しいTLSセッションが確立されるまで（TLS証明書ベースの認証を使用して）、他のプロトコル交換に関与してはなりません（MUST NOT）。
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データベースが最新であることを確認するために、クライアントは、格納された情報が期限切れになる前に最新の応答を要求する必要があります（SHOULD）。
The EST server SHOULD NOT require client authentication or authorization to reply to this request.
ESTサーバーは、この要求に応答するためにクライアント認証または承認を必要としません（SHOULD NOT）。
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に、オプションの証明書なしの認証が使用されている場合はセクション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応答である必要があり、次の段落で説明する証明書が含まれています。 「application / pkcs7-mime」のHTTPコンテンツタイプが使用されます。 Simple PKI Responseは、 "base64" [RFC2045]のContent-Transfer-Encodingで送信されます。
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 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サーバーは、3つの「ルートCAキー更新」証明書OldWithOld、OldWithNew、およびNewWithOldを応答チェーンに含める必要があります（SHOULD）。これらは、CMP [RFC4210]のセクション4.4で定義されています。 ESTクライアントは、応答でこれらの証明書を処理できる必要があります。 EST CAの最新の自己署名証明書（例：NewWithNew証明書）は自己署名されており、最新のNotAfter日付を持っています。 ESTサーバーがこれらを応答に含めない場合、現在のEST CA証明書の有効期限が切れた後、ESTクライアントは、ユーザーを含むCA証明書のブートストラップ配布（セクション4.1.1）メソッドを使用してPKIで再初期化する必要があります。インタラクション。
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]証明書パス検証（TAとして最新のCA証明書を使用）を使用して検証する必要があります。
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サーバー認証のために、抽出されたEST CA証明書を明示的なTAデータベースエントリとして保存する必要があります。明示的なTAデータベースエントリが利用可能になったため、ESTクライアントは、このESTサーバーに対する暗黙のTAデータベースエントリの使用を無効にする必要があります（SHOULD）。クライアントがImplicit TAデータベースを無効にし、ESTサーバー証明書がImplicit TAデータベースエントリを使用して検証された場合、クライアントは将来のTLSセッションに「Trusted CA Indication」拡張を含める必要があります[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証明書の応答情報を利用できるようにする必要があります（SHOULD）。
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クライアントは、 "/ simpleenroll"の操作パス値を使用してHTTPS POSTでESTサーバーに証明書を要求します。 ESTクライアントは、「/ simplereenroll」の操作パス値を使用して、HTTP POSTで既存の証明書の更新/鍵更新を要求します。 ESTサーバーは/ simpleenroll関数と/ 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に、オプションの証明書なしの認証が使用される場合はセクション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で指定されているクライアント認証を検証する必要があります。 EST
server MUST check the tls-unique value, as described in Section 3.5, if one is submitted by the client.
3.5で説明されているように、サーバーがtls-unique値をチェックする必要があります（クライアントから送信された場合）。
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]).
/ simpleenrollへのHTTPS POSTの際、クライアントはCMC [RFC5272]、セクション3.1（つまり、PKCS＃10証明書リクエスト[RFC2986]）で指定されているシンプルなPKIリクエストを含める必要があります。
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 KeyUsage拡張がデジタル署名の生成を禁止している場合、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].
ここでは「application / pkcs10」のHTTPコンテンツタイプが使用されます。メッセージのフォーマットは、[base64]のContent-Transfer-Encodingを持つ[RFC5967]で指定されているとおりです[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を参照）、クライアントは[RFC6402]で定義されているように、CSRに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.
ESTクライアントは、TLSクライアント認証で既存の証明書を使用している場合でも、追加の証明書を要求する場合があります。たとえば、クライアントは、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.
証明書リクエストは、同じHTTPコンテンツタイプを使用して、「simpleenroll」リクエストと同じ形式を採用しています。リクエストの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-typeパラメータが「certs-only」の「application / pkcs7-mime」のHTTPコンテンツタイプが使用されます。
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]エラーコードで応答する必要があります。 "application / pkcs7-mime"（セクション4.3.2を参照）のHTTPコンテンツタイプの単純なPKI応答は、エラー応答を伝えるために応答データに含めることができます（MAY）。 content-typeが設定されていない場合、応答データは、要求が拒否された理由を説明する説明情報（たとえば、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 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] 202で応答する場合、これは、要求が処理のために受け入れられたが、応答がまだ利用できないことを示します。サーバーは、HTTP 503応答に対して定義されたRetry-Afterヘッダーを含める必要があります。サーバーはまた、人間が読める有益なコンテンツを含んでもよい[MAY]。クライアントは、同じ要求を繰り返す前に、少なくとも指定された「再試行後」の時間待機する必要があります。適切な「再試行後」の間隔が経過した後、クライアントは最初の登録要求を繰り返します。クライアントは、このイベントをログに記録するか、エンドユーザーに通知する必要があります（SHOULD）。クライアントはこの点に関してステートレスであるため、サーバーは再試行操作を認識して処理するために必要なすべての状態を維持する責任があります。異なる応答コードを受信するまで、同じ要求を繰り返し送信するだけです。他のすべての戻りコードは、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.
クライアントがRetry-After時間の期限が切れるのを待っている間にTLS接続を閉じると、クライアントは新しいTLS接続を開始し、該当するすべてのセキュリティチェックを実行します。クライアントがリンクIDとPOP情報を含むCSRをすでに生成している場合（セクション3.5）、CSRを再作成して、新しくリダイレクトされたセッションからtls-uniqueを組み込む必要があります。注：鍵ペアを再生成する必要はありません。これらは、クライアントの処理とインターフェイスの負担です。 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].
/ fullcmcへのHTTP POSTが有効なフルPKI要求でない場合、サーバーはメッセージを拒否する必要があります。 [RFC5273]で指定されているように、使用されるHTTPコンテンツタイプは「application / pkcs7-mime」であり、smime-typeパラメータは「CMC-request」です。メッセージの本文は、 "base64" [RFC2045]のContent-Transfer-Encodingを使用したPKI要求のエンコーディングのバイナリ値です。
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].
登録が成功した場合、サーバー応答には、[RFC5273]で指定されているように、コンテンツタイプが「application / pkcs7-mime」のHTTP 200応答コードを含める必要があります。 [RFC5751]のセクション3.2.1で指定されているように、応答データには、smime-typeパラメータが「certs-only」のシンプルPKI応答またはsmime-typeパラメータが「CMC-response」のフルPKI応答が含まれます。メッセージの本文は、 "base64" [RFC2045]のContent-Transfer-Encodingを使用したPKI応答のエンコードのバイナリ値です。
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エラーを指定する必要があります。 content-typeが「application / pkcs7-mime」のCMC応答は、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.
NULL機密性アルゴリズムを持つ暗号スイートは、保護されていない秘密鍵の内容を開示するため、使用してはなりません。
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.
ESTクライアントは、TLSクライアント認証で既存の証明書を使用している場合でも、追加の証明書を要求する場合があります。たとえば、クライアントは、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 POSTされ、同じコンテンツタイプと転送エンコーディングを使用する「/ simpleenroll」および「/ simplereenroll」パス拡張と同じ形式です。
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.
許可されていない開示から保護するために、TLSが提供するセキュリティに加えて、暗号化メッセージ構文（CMS）EnvelopedDataの追加のセキュリティを提供することをクライアントに要求することを強くお勧めします。
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で定義）を含めて、秘密鍵が使用する秘密鍵の識別子を指定する秘密鍵を暗号化するサーバー。その属性は元々ファームウェア暗号化キーを指定するために指定されていましたが、秘密キーを暗号化するための秘密キーを指定するための要件を正確に反映しています。サーバーがクライアントによって指定された識別子と一致する秘密鍵を持たない場合、要求は終了されなければならず、クライアントにエラーが返されなければなりません（MUST）。 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属性を含まなければなりません（MUST）。 AsymmetricDecryptKeyIdentifier属性は次のように定義されます。
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])::
asymmetric-decrypt-key-identifier属性値には、ASN.1タイプのAsymmetricDecryptKeyIdentifierがあります（ASN.1は[X.680]で定義されています）。
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.
要求が成功した場合、サーバーの応答には、2つの部分で構成される "multipart / mixed"のコンテンツタイプを持つHTTP 200応答コードが含まれている必要があります。1つは秘密鍵データ、もう1つは証明書データです。
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].
追加の暗号化が採用されていない場合は、秘密鍵データを「application / pkcs8」に配置する必要があります。 「application / pkcs8」の部分は、base64でエンコードされたDERでエンコードされた[X.690] PrivateKeyInfoと、「base64」[RFC2045]のContent-Transfer-Encodingで構成されています。
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内に配置されます。 SignedDataは、秘密鍵を生成した当事者によって署名されます。秘密鍵は、ESTサーバーまたはEST CAである場合とそうでない場合があります。 [RFC5958]のセクション4で説明されているように、SignedDataはCMS EnvelopedData内に配置することでさらに保護されます。次のリストは、クライアントによって指定された保護キーのタイプに応じて、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鍵管理技術を示さなければなりません（MUST）。値は次のとおりです。バージョンは4に設定され、キー暗号化キー識別子（kekid）はセクション4.4.1.1のDecryptKeyIdentifierの値に設定されます。 keyEncryptionAlgorithmは、クライアントが要求に付随するSMIMECapabilitiesに含めたキーラップアルゴリズムの1つに設定されます。 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コンテンツが暗号化されます。対称暗号化キーの暗号強度は、クライアント指定の非対称キーと同等である必要があります（SHOULD）。 EnvelopedData RecipientInfoフィールドは、KeyTransRecipientInfo（ktri）キー管理手法を示さなければなりません（MUST）。 KeyTransRecipientInfoでは、RecipientIdentifier（rid）は、セクション4.4.1.2で定義された属性からコピーされたsubjectKeyIdentifierであるか、サーバーが属性から関連するissuerAndSerialNumberを決定します。 versionは、rid [RFC5652]の選択から派生し、keyEncryptionAlgorithmは、クライアントが要求に付随するSMIMECapabilitiesに含まれるキーラップアルゴリズムの1つに設定され、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のコンテンツが暗号化されます。対称暗号化キーの暗号強度は、クライアント指定の非対称キーと同等である必要があります（SHOULD）。 EnvelopedData RecipientInfoフィールドは、KeyAgreeRecipientInfo（kari）キー管理手法を示さなければなりません（MUST）。 KeyAgreeRecipientInfoタイプでは、バージョン、オリジネーター、ユーザーキーイングマテリアル（ukm）は[RFC5652]と同様であり、keyEncryptionAlgorithmは、リクエストに付随するSMIMECapabilitiesにクライアントが含めたキーラップアルゴリズムの1つに設定されます。受信者のキー識別子は、セクション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".
3つの追加の暗号化ケースすべてにおいて、EnvelopedDataは、 "server-generated-key"のsmime-typeパラメーターと "base64"のContent-Transfer-Encodingを持つ "application / pkcs7-mime"の部分として応答で返されます。
The certificate data part is an "application/pkcs7-mime" and exactly matches the certificate response to /simpleenroll.
証明書データ部分は「application / pkcs7-mime」であり、/ simpleenrollへの証明書応答と正確に一致します。
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エラーを指定する必要があります。 content-typeが設定されていない場合、応答データはプレーンテキストの人間が読める形式のエラーメッセージでなければなりません。
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が必要とする、または希望する予期される属性のリストを要求する必要があります（SHOULD）、またはローカルポリシーで指示されている場合。
The EST server SHOULD NOT require client authentication or authorization to reply to this request.
ESTサーバーは、この要求に応答するためにクライアント認証または承認を必要としません（SHOULD NOT）。
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属性の要求はオプションですが、クライアントは、CAが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クライアントは、「/ csrattrs」の操作パスを指定してHTTPS GETメッセージをESTサーバーに送信することにより、CAが要求するCSR属性のリストをCAに要求します。
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応答コードを含める必要があります。 204または404のHTTP応答コードは、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:
属性要求メッセージへの応答は、「base64」[RFC2045]のContent-Transfer-Encodingで「application / csrattrs」のコンテンツタイプとしてエンコードする必要があります。 application / csrattrs本文の構文は次のとおりです。
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
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}) }
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または属性を無視する必要があります。サーバーがCSR属性を空のSEQUENCEとしてエンコードする場合、それはサーバーがクライアント認証要求に必要な特定の追加情報を持たないことを意味します（これは、機能的には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サーバーがIDと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の構造を反映する必要があります。特定の署名スキームを使用する（たとえば、特定のハッシュ関数を使用する）要求は、CSRのSignatureAlgorithmに反映されるOIDとして表されます。特定の暗号化システム（たとえば、特定の楕円曲線に基づく公開鍵の認証）を使用する要求は、SubjectPublicKeyInfoのAlgorithmIdentifierとして反映される属性として表され、タイプはアルゴリズムを示し、値は特定のアルゴリズムに固有のパラメーター。クライアントからの説明情報の要求は、[RFC2985] extensionRequestを示すタイプと、結果の証明書の拡張に含めることが望まれる特定の属性を示す値を持つ、CSRの属性として表される属性によって行われます。
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.
シーケンスは、Distinguished Encoding Rules（DER）エンコード[X.690]、次にbase64エンコード（[RFC4648]のセクション4）です。結果のテキストは、ヘッダーなしでapplication / 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（IDとPOP情報のリンクが要求されていることを示す、セクション3.5を参照）を含む証明書要求を送信するよう要求した場合、メディアアクセスコントロール（MAC）アドレス（[RFC2307]）を含むextensionRequestクライアントの、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)
属性：タイプ= extensionRequest（1.2.840.113549.1.9.14）値= 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)
属性：タイプ= id-ecPublicKey（1.2.840.10045.2.1）値= secp384r1（1.3.132.0.34）
OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)
OID：ecdsaWithSHA384（1.2.840.10045.4.3.3）
and encodes them into an ASN.1 SEQUENCE to produce:
それらをASN.1 SEQUENCEにエンコードして、以下を生成します。
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 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
and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
次に、base64は結果のASN.1 SEQUENCEをエンコードして、以下を生成します。
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ BgcrBgEBAQEWBggqhkjOPQQDAw==
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ BgcrBgEBAQEWBggqhkjOPQQDAw ==
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ワーキンググループに委任された弧に登録された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は[Application Media Types]レジストリを更新し、[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)
このメディアタイプを使用するアプリケーション：Enrollment over Secure Transport（EST）
Additional information:
追加情報：
Magic number(s): None
マジックナンバー：なし
File extension: .csrattrs
ファイル拡張子：.csrattrs
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Dan Harkins <dharkins@arubanetworks.com>
Restrictions on usage: None
使用上の制限：なし
Author: Dan Harkins <dharkins@arubanetworks.com>
Intended usage: COMMON
使用目的：COMMON
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 content-typeは、オプションの「smime-type」パラメーター[RFC5751]を一連の特定の値で定義します。このドキュメントでは、サーバー側のキー生成応答のパラメーター値として、「server-generated-key」という別の値を追加しています。
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クライアントは、このような資格情報を1回だけ使用してクライアント証明書を取得することをお勧めします（これは、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.
クライアントが証明書の検証（セクション3を参照）にImplicit TAデータベースを使用する場合、セクション3.6.2で指定されているように承認が行われます。この状況では、クライアントはサーバーが、構成されたURIについてサードパーティによって認定されたレスポンダーであることを検証しましたが、クライアントが試行しているPKIのRAとして機能することが承認されていることを確認できません。登録する。 Implicit Trust Anchorデータベースを使用するクライアントは、TLSベースのクライアント認証のみを使用することをお勧めします（HTTPベースのクライアント認証情報が公開されないようにするため）。このようなクライアントは、リクエストに「リンクIDとPOP情報」（セクション3.5）を含めることをお勧めします（そのようなリクエストが真ん中の男によって実際のESTサーバーに転送されるのを防ぐため）。 ESTサーバー認証に使用されるImplicit Trust Anchorデータベースを慎重に管理して、認定の方法が不十分なサードパーティ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.
名前に「_EXPORT_」と「_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.
[RFC5272]のCMCのセクション6.7で説明されているように、「署名鍵として使用できる鍵の場合、秘密鍵での認証リクエストへの署名は、その鍵ペアのPOPとして機能します」。認証要求にtls-uniqueを含めると、TLSセッションがアクティブな間にPOP操作が実行されるように強制することで、所有証明と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暗号スイートの暗号化モードを使用します。 TLSによって提供されるものを超える秘密鍵の暗号化はオプションであるため、鍵は、AES Key Wrap [RFC3394]などの優先鍵ラッピング方式や[RFC5958]で指定されているように保護されません。 ESTサーバーはデフォルトでこの操作をサポートしないことをお勧めします。説得力のある運用上の利点がない限り、クライアントはこのサービスを要求しないことをお勧めします。 Implicit Trust Anchorデータベースの使用は、サーバー側のキー生成が採用されている場合は推奨されません。暗号化された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 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.
CAが登録要求に含めるためにリストする可能性のあるCSR属性に関しては、伝達されるコンテンツに固有のセキュリティ上の問題はありませんが、会話に介入できる攻撃者は、サーバーが望む属性を除外できます。サーバーが必要としない可能性のある属性を含め、サーバーが必要とする可能性のある他の無意味な属性をレンダリングします。
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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年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 Public Key Infrastructure Operational Protocols：FTP and HTTP」、RFC 2585、1999年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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[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.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B。、「S / MIME Version 3 Message Specification」、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：Certification Request Syntax Specification Version 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、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「Randomness Requirements for Security」、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。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、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、「Internet X.509 Public Key Infrastructure Certificate Management Protocol（CMP）」、RFC 4210、2005年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、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、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、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、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、「The Transport Layer Security（TLS）Protocol Version 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 5272、2008年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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年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、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、2010年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、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、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 5929、2010年7月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、2010年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、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）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, November 2011.
[RFC6402] Schaad、J。、「CMS（CMC）更新による証明書管理」、RFC 6402、2011年11月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]バース、A。、「The Web Origin Concept」、RFC 6454、2011年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、「Abstract Syntax Notation One（ASN.1）：Specification of basic notation」、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エンコードルール：Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（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 Standards Association、「IEEE 802.1AR Secure Device Identifier」、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]ハワードL。、「LDAPをネットワーク情報サービスとして使用するためのアプローチ」、RFC 2307、1998年3月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、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：Selected Object Classes and Attribute Types Version 2.0」、RFC 2985、2000年11月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[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、「Using the Secure Remote Password（SRP）Protocol for TLS Authentication」、RFC 5054、2007年11月。
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, August 2010.
[RFC5967]ターナー、S。、「アプリケーション/ pkcs10メディアタイプ」、RFC 5967、2010年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]国立標準技術研究所、「Secure Hash Standard（SHS）」、連邦情報処理標準出版物180-4、2012年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] National Institute of Standards and Technology、「Recommendation for Key Management-Part 1：General（Revision 3）」、2012年7月、<http://csrc.nist.gov/publications/ nistpubs / 800-57 / sp800-57_part1_rev3_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: */*
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 OKステータス：200 OK Content-Type：application / pkcs7-mime Content-Transfer-Encoding：base64 Content-Length：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
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: */*
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サーバーには、属性タイプがクライアントに認識されていない限りクライアントが無視する2つのサンプル属性も含まれています。
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/csrattrs
Content-Transfer-Encoding: base64
Content-Length: 171
MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC
The following is an example of a valid /simpleenroll exchange. The data messages for /simplereenroll are similar.
以下は、有効な/ simpleenroll交換の例です。 / 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-Authenticateの動作であり、参考のためにここに含まれています。既存のTLSクライアント証明書が使用されている場合、サーバーは/ simplereenroll操作中などにHTTP WWW-Authenticateヘッダーのリクエストをスキップする場合があります。
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, 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):
最初のTLSハンドシェイクの間、クライアントはオプションのサーバー生成の「証明書要求」を無視して、代わりにHTTP POST要求を続行できます。最初のHTTP POST試行に応答して、サーバーはクライアントにWWW-Authenticateを要求します（これは、上記の規範的なテキストで詳述されているように、クライアントがクライアント証明書を使用した場合でも発生する可能性があります）。
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 POSTには、完全なapplication / 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
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:
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 == ESTサーバが発行した認証取得して認証/許可および応答を実行するためにユーザー名/パスワードを使用していますcate：
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
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されたメッセージの例は次のとおりです。
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== 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:
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 == DecryptKeyIdentifier attrのため、このリクエストにはイブテは含まれていません。レスポンスには、TLSセッション以外の追加の暗号化は含まれていません。 ESTサーバーの応答は次のとおりです。
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 Content-Type：application / pkcs8 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.
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 srbcqc7DcPXP6Lw42sx96h4jV WWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf / 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：アプリケーション/ PKCS7 -mime; SMIME型=本命専用コンテンツ転送エンコード：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 XjjXHsL40WuDG6tMPN9vcT8tE3 KSHFX / NEM6 + AaNVSUPTmB33BgYB1Wa E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q / fw1yvjoHoYJtyMn4v5Kb3Rt + M s8Yie1tcfVQrjQutqr34 / IJsKdPziZwi92KZa + 1958A6M9O / p5OI0up9ZXKg2DEC 1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA == --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（編集者）Cisco Systems、Inc. 510 McCarthy Drive Milpitas、CA 95035 USA
EMail: pritikin@cisco.com
Peter E. Yee (editor) AKAYLA, Inc. 7150 Moorland Drive Clarksville, MD 21029 USA
Peter E. Yee（編集者）AKAYLA、Inc. 7150 Moorland Driveクラークスビル、MD 21029米国
EMail: peter@akayla.com
Dan Harkins (editor) Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 USA
Dan Harkins（編集者）Aruba Networks 1322 Crossman Avenue Sunnyvale、CA 94089-1113 USA
EMail: dharkins@arubanetworks.com