[要約] RFC 8295は、EST（Enrollment over Secure Transport）拡張機能に関する仕様であり、証明書の登録と管理を安全に行うためのプロトコルを提供します。目的は、セキュアな通信チャネルを確立し、証明書のエンロールメントプロセスを保護することです。
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 8295 sn3rd
Category: Standards Track January 2018
ISSN: 2070-1721
EST (Enrollment over Secure Transport) Extensions
EST（Enrollment over Secure Transport）拡張機能
Abstract
概要
The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.
EST（Enrollment over Secure Transport）プロトコルは、既知のURI（Uniform Resource Identifier）-/.well-known/est-と、クライアントがPKI（公開鍵インフラストラクチャ）サービスに使用する他の多くのパスコンポーネントを定義しますつまり、証明書の登録（/ simpleenrollなど）。このドキュメントでは、その他の多数のPKIサービスを追加のパスコンポーネントとして定義しています。具体的には、ファームウェアアンカーとトラストアンカー、対称キー、非対称キー、および暗号化キーです。このドキュメントでは、PAL（パッケージ利用可能リスト）も指定します。これは、クライアントが使用可能で承認されたパッケージを取得するために使用するXML（Extensible Markup Language）ファイルまたはJSON（JavaScript Object Notation）オブジェクトです。このドキュメントでは、ESTサーバーパスコンポーネントを拡張して、これらの追加サービスを提供します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8295.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8295で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Definitions ................................................6
1.2. Authentication and Authorization ...........................7
1.3. TLS Cipher Suites ..........................................7
1.4. URI Configuration ..........................................7
1.5. Message Types ..............................................8
1.6. Key Words .................................................10
2. Locate Available Packages ......................................10
2.1. PAL Format ................................................12
2.1.1. PAL Package Types ..................................14
2.1.2. PAL XML Schema .....................................19
2.1.3. PAL JSON Object ....................................23
2.2. Request PAL ...............................................23
2.3. Provide PAL ...............................................24
3. Distribute EE Certificates .....................................25
3.1. EE Certificate Request ....................................25
3.2. EE Certificate Response ...................................26
4. Distribute CRLs and ARLs .......................................26
4.1. CRL Request ...............................................26
4.2. CRL Response ..............................................26
5. Symmetric Keys, Receipts, and Errors ...........................27
5.1. Symmetric Keys ............................................27
5.1.1. Distribute Symmetric Keys ..........................28
5.1.2. Symmetric Key Response .............................28
5.2. Symmetric Key Receipts and Errors .........................29
5.2.1. Provide Symmetric Key Receipt or Error .............30
5.2.2. Symmetric Key Receipt or Error Response ............31
6. Firmware, Receipts, and Errors .................................31
6.1. Firmware ..................................................31
6.1.1. Distribute Firmware ................................32
6.1.2. Firmware Response ..................................32
6.2. Firmware Receipts and Errors ..............................33
6.2.1. Provide Firmware Receipt or Error ..................33
6.2.2. Firmware Receipt or Error Response .................33
7. Trust Anchor Management Protocol ...............................34
7.1. TAMP Status Query, Trust Anchor Update,
Apex Trust Anchor Update, Community Update,
and Sequence Number Adjust ................................34
7.1.1. Request TAMP Packages ..............................34
7.1.2. Return TAMP Packages ...............................35
7.2. TAMP Responses, Confirms, and Errors ......................35
7.2.1. Provide TAMP Responses, Confirms, or Errors ........36
7.2.2. TAMP Responses, Confirms, and Error Responses ......36
8. Asymmetric Keys, Receipts, and Errors ..........................36
8.1. Asymmetric Key Encapsulation ..............................37
8.2. Asymmetric Key Package Receipts and Errors ................38
8.3. PKCS #12 ..................................................39
8.3.1. Server-Side Key Generation Request .................39
8.3.2. Server-Side Key Generation Response ................39
9. PAL and Certificate Enrollment .................................40
10. Security Considerations .......................................43
11. IANA Considerations ...........................................44
11.1. PAL Name Space ...........................................44
11.2. PAL XML Schema ...........................................44
11.3. PAL Package Types ........................................44
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................50
Appendix A. Example Use of PAL ....................................51
Appendix B. Additional CSR Attributes .............................53
Acknowledgements ..................................................54
Author's Address ..................................................54
The EST (Enrollment over Secure Transport) protocol [RFC7030] defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- to support selected services related to the PKI (Public Key Infrastructure), with such PCs (path components) as simple enrollment with /simpleenroll, rekey or renew with /simplereenroll, etc. A server that wishes to support additional PKI-related services and other security-related packages could use the same .well-known URI by defining additional PCs. This document defines six such PCs:
EST（Enrollment over Secure Transport）プロトコル[RFC7030]は、既知のURI（Uniform Resource Identifier）-/.well-known/est-を定義して、PKI（公開鍵インフラストラクチャ）に関連する選択されたサービスをサポートします。 / simpleenroll、rekey、または/ simplereenrollなどを使用した更新による単純な登録としてのPC（パスコンポーネント）。追加のPKI関連サービスおよびその他のセキュリティ関連パッケージをサポートすることを望むサーバーは、追加のPC。このドキュメントでは、このようなPCを6つ定義しています。
o /pal - The PAL (Package Availability List) provides a list of all known packages available and authorized for a client. By accessing the service provided by this PC first, the client can walk through the PAL and download all the packages necessary to begin operating securely. The PAL essentially points to other PCs, including the PCs defined in this document as well as those defined in [RFC7030] (e.g., /cacerts, /simpleenroll, /simplereenroll, /fullcmc, /serverkeygen, and /csrattrs). The /pal PC is described in Section 2.
o / pal-PAL（パッケージ利用可能リスト）は、クライアントが利用可能で承認されているすべての既知のパッケージのリストを提供します。このPCが最初に提供するサービスにアクセスすることで、クライアントはPALをウォークスルーし、安全な操作を開始するために必要なすべてのパッケージをダウンロードできます。 PALは基本的に、このドキュメントで定義されているPCや[RFC7030]で定義されているPC（/ cacerts、/ simpleenroll、/ simplereenroll、/ fullcmc、/ serverkeygen、/ csrattrsなど）を含む他のPCを指します。 / pal PCについては、セクション2で説明します。
o /eecerts - EE (End-Entity) certificates [RFC5280] are needed by the client when they invoke a security protocol for communicating with a peer (i.e., they become operational and do something meaningful as opposed to just communicating with the infrastructure). If the infrastructure knows the certificate(s) needed by the client, then providing the peer's certificate avoids the client having to discover the peer's certificate. This service is not meant to be a general-purpose repository to which clients query a "repository" and then get a response; this is purely a push mechanism. The /eecerts PC is described in Section 3.
o / eecerts-クライアントがピアと通信するためのセキュリティプロトコルを呼び出すときに、クライアントはEE（エンドエンティティ）証明書[RFC5280]を必要とします（つまり、インフラストラクチャと通信するだけではなく、動作して意味のあることを行います）。インフラストラクチャがクライアントに必要な証明書を知っている場合、ピアの証明書を提供することで、クライアントがピアの証明書を発見する必要がなくなります。このサービスは、クライアントが「リポジトリ」にクエリを送信してから応答を受け取る汎用リポジトリであることを意図したものではありません。これは純粋にプッシュメカニズムです。 / eecerts PCについては、セクション3で説明します。
o /crls - CRLs (Certificate Revocation Lists) and ARLs (Authority Revocation Lists) [RFC5280] are also needed by the client when they validate certificate paths. CRLs (and ARLs) from TAs (Trust Anchors) and intermediate CAs (Certification Authorities) are needed to validate the certificates used to generate the client's certificate or the peer's certificate, which is provided by the /eecerts PC, and providing them saves the client from having to "discover" them and then retrieve them. CRL "discovery" is greatly aided by the inclusion of the CRL Distribution Point certificate extension [RFC5280], but this extension is not always present in certificates and requires another connection to retrieve them. Like the /eecerts PC, this service is not meant to be a general-purpose repository to which clients query a repository and then get a response; this is purely a push mechanism. The /crls PC is described in Section 4.
o / crls-CRL（証明書失効リスト）とARL（機関失効リスト）[RFC5280]も、証明書パスを検証するときにクライアントに必要です。 / eecerts PCによって提供されるクライアントの証明書またはピアの証明書を生成するために使用される証明書を検証し、それらを提供してクライアントを保存するには、TA（信頼アンカー）および中間CA（認証局）からのCRL（およびARL）が必要です。それらを「発見」してから取得する必要がなくなります。 CRLの「発見」は、CRL配布ポイントの証明書拡張[RFC5280]を含めることで大幅に促進されますが、この拡張は常に証明書に存在するわけではなく、証明書を取得するために別の接続が必要です。 / eecerts PCと同様に、このサービスは、クライアントがレポジトリをクエリして応答を受け取る汎用レポジトリではありません。これは純粋にプッシュメカニズムです。 / crls PCについては、セクション4で説明します。
o /symmetrickeys - In some cases, clients use symmetric keys [RFC6031] when communicating with their peers. If the client's peers are known by the server a priori, then providing them saves the client or an administrator from later having to find, retrieve, and install them. Like the /eecerts and /crls PCs, this service is not meant to be a general-purpose repository to which clients query a repository and then get a response; this is purely a push mechanism for the keys themselves. However, things do not always go as planned, and clients need to inform the server about any errors. If things did go well, then the client, if requested, needs to provide a receipt [RFC7191]. The /symmetrickeys and /symmetrickeys/return PCs are described in Section 5.
o / symmetrickeys-場合によっては、クライアントはピアと通信するときに対称キー[RFC6031]を使用します。クライアントのピアがサーバーによって事前に認識されている場合、それらを提供すると、クライアントまたは管理者が後でそれらを見つけて取得してインストールする必要がなくなります。 / eecertsおよび/ crls PCと同様に、このサービスは、クライアントがリポジトリーを照会してから応答を受け取る汎用リポジトリーであることを意図していません。これは純粋にキー自体のプッシュメカニズムです。ただし、常に計画どおりに進行するとは限らず、クライアントはエラーをサーバーに通知する必要があります。うまくいった場合、クライアントは、要求された場合、領収書[RFC7191]を提供する必要があります。 / symmetrickeysおよび/ symmetrickeys / return PCについては、セクション5で説明します。
o /firmware - Some client firmware and software support automatic update mechanisms, and some do not. For those that do not, the /firmware PC provides a mechanism for the infrastructure to inform the client that firmware and software updates [RFC4108] are available. Because updates do not always go as planned and because sometimes the server needs to know whether the firmware was received and processed, this PC also provides a mechanism to return errors and receipts. The /firmware and /firmware/return PCs are defined in Section 6.
o / firmware-一部のクライアントファームウェアとソフトウェアは自動更新メカニズムをサポートしていますが、サポートしていないものもあります。そうでない場合のために、/ firmware PCは、インフラストラクチャがファームウェアとソフトウェアの更新[RFC4108]が利用可能であることをクライアントに通知するメカニズムを提供します。更新が常に予定どおりに行われるとは限らず、サーバーがファームウェアを受信して処理したかどうかを確認する必要がある場合があるため、このPCはエラーと受信を返すメカニズムも備えています。 / firmwareおよび/ firmware / return PCはセクション6で定義されています。
o /tamp - To control the TAs in client TA databases, servers use the /tamp PC to request that clients retrieve TAMP (Trust Anchor Management Protocol) query, update, and adjust packages [RFC5934], and clients use the /tamp/return PC to return TAMP responses, confirms, and errors [RFC5934]. The /tamp and /tamp/return PCs are defined in Section 7.
o / tamp-クライアントTAデータベースのTAを制御するために、サーバーは/ tamp PCを使用して、クライアントがTAMP（Trust Anchor Management Protocol）クエリを取得、更新、および調整するように要求します[RFC5934]。クライアントは/ tamp / return PCを使用しますTAMP応答、確認、およびエラーを返すには[RFC5934]。 / tampおよび/ tamp / return PCはセクション7で定義されています。
This document also extends the /est/serverkeygen PC [RFC7030] to support the following (see Section 8):
このドキュメントは、/ est / serverkeygen PC [RFC7030]も拡張して、以下をサポートします（セクション8を参照）。
o Returning asymmetric key package receipts and errors [RFC7191].
o 非対称キーパッケージの領収書とエラーを返す[RFC7191]。
o Encapsulating returned asymmetric keys in additional CMS (Cryptographic Message Syntax) content types [RFC7193].
o 返された非対称キーを追加のCMS（暗号化メッセージ構文）コンテンツタイプでカプセル化する[RFC7193]。
o Returning server-generated public key pairs encapsulated in PKCS #12 (Public Key Cryptography Standard #12) [RFC7292].
o PKCS＃12（Public Key Cryptography Standard＃12）[RFC7292]にカプセル化されたサーバー生成の公開鍵ペアを返します。
While the motivation is to provide packages to clients during enrollment so that they can perform securely after enrollment, the services defined in this specification can be used after enrollment.
登録後にクライアントにパッケージを提供して登録後に安全に実行できるようにすることが動機ですが、この仕様で定義されているサービスは登録後に使用できます。
Familiarity with the following specifications is assumed:
以下の仕様に精通していることを前提としています。
o "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages" [RFC4108]
o 「暗号化メッセージ構文（CMS）を使用したファームウェアパッケージの保護」[RFC4108]
o "Certificate Management over CMS (CMC)" [RFC5272]
o 「CMSを介した証明書管理（CMC）」[RFC5272]
o "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type" [RFC6032]
o 「Cryptographic Message Syntax（CMS）Encrypted Key Package Content Type」[RFC6032]
o "Cryptographic Message Syntax (CMS)" [RFC5652]
o 「暗号メッセージ構文（CMS）」[RFC5652]
o "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)" [RFC6268]
o 「X.509（PKIX）を使用した暗号化メッセージ構文（CMS）および公開鍵インフラストラクチャのための追加の新しいASN.1モジュール」[RFC6268]
o "Trust Anchor Management Protocol (TAMP)" [RFC5934]
o 「信頼アンカー管理プロトコル（TAMP）」[RFC5934]
o "Cryptographic Message Syntax (CMS) Content Constraints Extension" [RFC6010]
o 「Cryptographic Message Syntax（CMS）Content Constraints Extension」[RFC6010]
o "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type" [RFC6031]
o 「暗号化メッセージ構文（CMS）対称鍵パッケージのコンテンツタイプ」[RFC6031]
o "Enrollment over Secure Transport" [RFC7030]
o 「セキュアなトランスポートを介した登録」[RFC7030]
o "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types" [RFC7191]
o 「暗号化メッセージ構文（CMS）キーパッケージの受信とエラーコンテンツタイプ」[RFC7191]
Also, familiarity with the CMS protecting content types signed-data and encrypted-data [RFC5652] is assumed. The CMS encrypted key package is defined in [RFC6032].
また、コンテンツタイプの署名済みデータと暗号化データを保護するCMSに精通していることを前提としています[RFC5652]。 CMS暗号化キーパッケージは[RFC6032]で定義されています。
In addition to the definitions found in [RFC7030], the following definitions are used in this document:
[RFC7030]で定義されている定義に加えて、このドキュメントでは次の定義が使用されています。
Agent: An entity that performs functions on behalf of a client. Agents can service a) one or more clients on the same network as the server, b) clients on non-IP-based networks, or c) clients that have a non-electronic air gap [RFC4949] between themselves and the server. Interactions between the agent and client in the last two cases are beyond the scope of this document. Before an agent can service clients, the agent must have a trust relationship with the server (i.e., be authorized to act on behalf of clients).
エージェント：クライアントに代わって機能を実行するエンティティ。エージェントは、a）サーバーと同じネットワーク上の1つ以上のクライアント、b）非IPベースのネットワーク上のクライアント、またはc）サーバーとの間に非電子的エアギャップ[RFC4949]を持つクライアントにサービスを提供できます。最後の2つのケースにおけるエージェントとクライアント間の相互作用は、このドキュメントの範囲外です。エージェントがクライアントにサービスを提供する前に、エージェントはサーバーとの信頼関係を持っている必要があります（つまり、クライアントに代わって行動することを許可されている）。
Client: A device that ultimately consumes and uses the packages to enable communications. In other words, the client is the endpoint for the packages, and an agent may have one or more clients. To avoid confusion, this document henceforth uses the term "client" to refer to both agents and clients.
クライアント：通信を可能にするためにパッケージを最終的に消費および使用するデバイス。つまり、クライアントはパッケージのエンドポイントであり、エージェントは1つ以上のクライアントを持つことができます。以降、混乱を避けるために、このドキュメントでは「クライアント」という用語を使用して、エージェントとクライアントの両方を指します。
Package: An object that contains one or more content types. There are numerous types of packages, e.g., packages for asymmetric keys, symmetric keys, encrypted keys, CRLs, firmware, and TAMP. See Section 2.1.1. All of these packages are digitally signed by their creator and encapsulated in a CMS signed-data [RFC5652] [RFC6268] (except the public key certificates and CRLs that are already digitally signed by a CA): firmware receipts and errors; TAMP responses, confirms, and errors; and "key package" receipts and errors that can be optionally signed. Certificates and CRLs are included in a package that uses signed-data, which is often referred to as a "degenerate CMS", or as a "certs-only" [RFC5751] [RFC6268] or "crls-only" message (see Section 4.2), but no signature or content is present -- hence the names "certs-only" and "crls-only".
パッケージ：1つ以上のコンテンツタイプを含むオブジェクト。パッケージには、非対称キー、対称キー、暗号化キー、CRL、ファームウェア、TAMPなど、さまざまなタイプのパッケージがあります。セクション2.1.1を参照してください。これらのパッケージはすべて、作成者によってデジタル署名され、CMS署名データ[RFC5652] [RFC6268]にカプセル化されます（CAによって既にデジタル署名されている公開鍵証明書とCRLを除く）：ファームウェアの領収書とエラー。 TAMPの応答、確認、およびエラー。また、オプションで署名できる「キーパッケージ」の領収書とエラー。証明書とCRLは、「縮退CMS」または「証明書のみ」[RFC5751] [RFC6268]または「crls-only」メッセージと呼ばれる署名付きデータを使用するパッケージに含まれています（セクションを参照） 4.2）しかし、署名やコンテンツは存在しません-したがって、「certs-only」および「crls-only」という名前になります。
Note: As per [RFC7030], the creator may or may not be the EST server or the EST CA.
注：[RFC7030]に従い、作成者はESTサーバーまたはEST CAである場合とそうでない場合があります。
Client and server authentication as well as client and server authorization are as defined in [RFC7030]. The requirements for each are discussed in the "request" and "response" sections (e.g., Sections 3.1 and 3.2 of this document) of each of the PCs defined herein.
クライアントとサーバーの認証、およびクライアントとサーバーの承認は、[RFC7030]で定義されています。それぞれの要件は、ここで定義されている各PCの「要求」セクションと「応答」セクション（このドキュメントのセクション3.1と3.2など）で説明されています。
The requirements for the TA databases are as specified in [RFC7030] as well.
TAデータベースの要件は、[RFC7030]でも指定されています。
TLS (Transport Layer Security) cipher suites and issues associated with them are as defined in [RFC7030].
TLS（Transport Layer Security）暗号スイートとそれに関連する問題は、[RFC7030]で定義されています。
As specified in Section 3.1 of [RFC7030], the client is configured with sufficient information to form the server URI [RFC3986]. Like EST, this configuration mechanism is beyond the scope of this document.
[RFC7030]のセクション3.1で指定されているように、クライアントはサーバーURI [RFC3986]を形成するのに十分な情報で構成されています。 ESTと同様に、この構成メカニズムはこのドキュメントの範囲外です。
This document uses existing media types for the messages as specified by "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP" [RFC2585], "The application/pkcs10 Media Type" [RFC5967], and "Certificate Management over CMS (CMC)" [RFC5272].
このドキュメントでは、「インターネットX.509公開鍵インフラストラクチャ運用プロトコル：FTPおよびHTTP」[RFC2585]、「application / pkcs10メディアタイプ」[RFC5967]、および「CMSによる証明書管理（ CMC）」[RFC5272]。
For consistency with [RFC5273], each distinct EST message type uses an HTTP Content-Type header with a specific media type.
[RFC5273]との一貫性を保つために、各ESTメッセージタイプは、特定のメディアタイプのHTTP Content-Typeヘッダーを使用します。
The EST messages, their corresponding media types for each operation, and the sections that provide request and response information are as follows:
ESTメッセージ、各操作に対応するメディアタイプ、および要求と応答の情報を提供するセクションは次のとおりです。
+-------------------+---------------------------------+---------------+
| Message type | Request media type | Request |
| | Response media type(s) | Response |
| (per operation) | Source(s) of types | |
+===================+=================================+===============+
| Locate Available | N/A | Section 2.2 |
| Packages | application/xml or | Section 2.3 |
| | application/json | |
| | [RFC7303] [RFC8259] | |
| /pal | | |
+===================+=================================+===============+
| Distribute EE | N/A | Section 3.1 |
| Certificates | application/pkcs7-mime | Section 3.2 |
| | [RFC5751] | |
| /eecerts | | |
+===================+=================================+===============+
| Distribute CRLs | N/A | Section 4.1 |
| | application/pkcs7-mime | Section 4.2 |
| | [RFC5751] | |
| /crls | | |
+===================+=================================+===============+
| Symmetric Key | N/A | Section 5.1.1 |
| Distribution | application/cms | Section 5.1.2 |
| | [RFC7193] | |
| /symmetrickeys | | |
+===================+=================================+===============+
| Return Symmetric | application/cms | Section 5.2.1 |
| Key | N/A | Section 5.2.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /symmetrickeys/ | | |
| return | | |
+===================+=================================+===============+
| Firmware | N/A | Section 6.1.1 |
| Distribution | application/cms | Section 6.1.2 |
| | [RFC7193] | |
| /firmware | | |
+===================+=================================+===============+
| Return Firmware | application/cms | Section 6.2.1 |
| Receipts/Errors | N/A | Section 6.2.2 |
| | [RFC7193] | |
| /firmware/return | | |
+===================+=================================+===============+
| Trust Anchor | N/A | Section 7.1.1 |
| Management | application/ | Section 7.1.2 |
| | tamp-status-query | |
| | tamp-update | |
| | tamp-apex-update | |
| | tamp-community-update | |
| | tamp-sequence-adjust | |
| | [RFC5934] | |
| /tamp | | |
+===================+=================================+===============+
| Return TAMP | application/ | Section 7.2.1 |
| Responses/ | tamp-status-response | |
| Confirms/ | tamp-update-confirm | |
| Errors | tamp-apex-update-confirm | |
| | tamp-community-update-confirm | |
| | tamp-sequence-adjust-confirm | |
| | tamp-error | |
| | N/A | Section 7.2.2 |
| | [RFC5934] | |
| /tamp/return | | |
+===================+=================================+===============+
| Server-Side Key | application/pkcs10 with | Section 8.1 |
| Generation | content type attribute | |
| | CSR* | |
| | application/cms | Section 8.1 |
| /serverkeygen | [RFC5967] [RFC7193] [RFC7030] | |
+===================+=================================+===============+
| Return Asymmetric | application/cms | Section 8.2 |
| Key | N/A | Section 8.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /serverkeygen/ | | |
| return | | |
+===================+=================================+===============+
| Server-Side Key | application/pkcs10 | Section 8.3.1 |
| Generation: | application/pkcs12 | Section 8.3.2 |
| PKCS #12 | [RFC5967] [RFC7193] [RFC7030] | |
| | | |
| /serverkeygen | | |
+===================+=================================+===============+
* Certificate Signing Request
* 証明書署名リクエスト
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The PAL (Package Availability List) is either an XML (Extensible Markup Language) [XML] or JSON (JavaScript Object Notation) [RFC8259] object available through the /pal PC, which furnishes the following information to clients:
PAL（パッケージ可用性リスト）は、XML（Extensible Markup Language）[XML]またはJSON（JavaScript Object Notation）[RFC8259]オブジェクトのいずれかであり、/ pal PCを通じて利用できます。これにより、次の情報がクライアントに提供されます。
o Advertisements for available packages that can be retrieved from the server;
o サーバーから取得できる利用可能なパッケージの広告。
o Notifications to begin public key certificate management or to return package receipts and errors; and
o 公開鍵証明書の管理を開始するか、パッケージの受領とエラーを返すための通知。そして
o Advertisement for another PAL.
o 別のPALの広告。
After being configured (see Section 1.4), the client can use this service to retrieve its PAL (see Section 2.1), which, if properly constructed (see Section 2.3), allows the client to determine some or all of the security-related packages needed for bootstrapping. Each PAL entry refers to other PCs (as defined in this document and in [RFC7030]) that clients use to a) retrieve packages that are available to them (e.g., CA certificates, firmware, trust anchors, symmetric keys, and asymmetric keys) or b) receive notifications to initiate public key certificate enrollment. PAL entries can also be used to notify clients that they are to return receipts or errors for certain packages (see Section 2.1.1). Placing these entries after entries that clients used to retrieve the packages is the same as requesting receipts in the originally distributed package. Figure 1 provides a ladder diagram for the /pal PC protocol flow. Appendix A provides a detailed example.
構成後（セクション1.4を参照）、クライアントはこのサービスを使用してPAL（セクション2.1を参照）を取得できます。適切に構成されている場合（セクション2.3を参照）、クライアントはセキュリティ関連パッケージの一部またはすべてを決定できます。ブートストラップに必要です。各PALエントリは、クライアントが使用する他のPC（このドキュメントと[RFC7030]で定義されている）を参照します。a）使用可能なパッケージ（CA証明書、ファームウェア、トラストアンカー、対称キー、非対称キーなど）を取得します。またはb）公開鍵証明書の登録を開始する通知を受け取ります。 PALエントリは、特定のパッケージのレシートまたはエラーを返すことをクライアントに通知するためにも使用できます（セクション2.1.1を参照）。クライアントがパッケージを取得するために使用したエントリの後にこれらのエントリを配置することは、最初に配布されたパッケージでレシートを要求することと同じです。図1に、/ pal PCプロトコルフローのラダー図を示します。付録Aに詳細な例を示します。
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Request package by |
| specified URI |
| (HTTP GET or POST |
| Request) |
|--------------------->|
|<---------------------|
| Deliver requested |
| CMS package product |
| (HTTP GET or POST |
| Response) |
| |
Repeat as necessary.
必要に応じて繰り返します。
Figure 1: /pal Message Sequence
図1：/ palメッセージシーケンス
PALs are designed to support an arbitrary number of entries, but for PALs that need to be divided for any reason, there is a special PAL entry type that constitutes a collection of "PAL package types". Package type 0001 ("Additional PAL value present") refers to another PAL. See Sections 2.1 and 2.1.1. If present, the 0001 package type is always last because other entries after it are ignored. Also, in order to avoid needlessly dereferencing URIs, the 0001 package type cannot be the only PAL entry. In addition to using the PAL during bootstrapping, clients can be configured to periodically poll the server to determine if updated packages are available for them. Note that the mechanism to configure how often clients poll the server is beyond the scope of this document. However, there are some services that support indicating when a client should retry its request (e.g., simple enrollment and re-enroll responses include the Retry-After header [RFC7030]).
PALは任意の数のエントリをサポートするように設計されていますが、何らかの理由で分割する必要があるPALには、「PALパッケージタイプ」のコレクションを構成する特別なPALエントリタイプがあります。パッケージタイプ0001（「追加のPAL値が存在する」）は、別のPALを参照しています。セクション2.1および2.1.1を参照してください。存在する場合、0001パッケージタイプは、それ以降のエントリが無視されるため、常に最後になります。また、不必要にURIを逆参照しないようにするために、0001パッケージタイプを唯一のPALエントリにすることはできません。ブートストラップ中にPALを使用することに加えて、クライアントは定期的にサーバーをポーリングして、更新されたパッケージが利用可能かどうかを判断するように構成できます。クライアントがサーバーをポーリングする頻度を構成するメカニズムは、このドキュメントの範囲外であることに注意してください。ただし、クライアントがリクエストを再試行するタイミングを示すことをサポートするサービスがいくつかあります（たとえば、単純な登録応答と再登録応答にはRetry-Afterヘッダー[RFC7030]が含まれます）。
As noted earlier, the PAL supports two variants: XML and JSON. Clients include the HTTP Accept header [RFC7231] when they connect to the server to indicate whether they support XML or JSON.
前述のように、PALはXMLとJSONの2つのバリアントをサポートしています。クライアントは、サーバーに接続するときにHTTP Acceptヘッダー[RFC7231]を含めて、XMLまたはJSONをサポートするかどうかを示します。
The client MUST authenticate the server as specified in [RFC7030], and the client MUST check the server's authorization as specified in [RFC7030].
クライアントは[RFC7030]で指定されているようにサーバーを認証しなければならず（MUST）、クライアントは[RFC7030]で指定されているようにサーバーの承認をチェックしなければなりません（MUST）。
The server MUST authenticate the client as specified in [RFC7030], and the server MUST check the client's authorization as specified in [RFC7030].
サーバーは[RFC7030]で指定されているようにクライアントを認証しなければならず（MUST）、サーバーは[RFC7030]で指定されているようにクライアントの承認をチェックしなければなりません（MUST）。
PAL support is OPTIONAL. It is shown in figures throughout this document, but clients need not support the PAL to access services offered by the server.
PALサポートはオプションです。このドキュメント全体で図に示されていますが、クライアントは、サーバーが提供するサービスにアクセスするためにPALをサポートする必要はありません。
Each PAL is composed of zero or more entries. Each entry is composed of four fields -- type, date, size, and info -- whose semantics follow:
各PALは0個以上のエントリで構成されています。各エントリは、タイプ、日付、サイズ、情報の4つのフィールドで構成され、その意味は次のとおりです。
Note: Both XML elements and JSON values are described below. XML elements are enclosed in angle brackets (<>), and JSON values are enclosed in single quotes (''). When described together, they are enclosed in square brackets ([]) separated by a vertical bar (|).
注：XML要素とJSON値の両方について以下で説明します。 XML要素は山括弧（<>）で囲まれ、JSON値は一重引用符（ ''）で囲まれます。一緒に説明する場合は、縦棒（|）で区切られた大括弧（[]）で囲まれています。
o [<type> | 'type'] uniquely identifies each package that a client may retrieve from the server with a 4-digit string. [<type> | 'type'] MUST be present. The PAL package types are defined in Section 2.1.1.
o [<タイプ> | 'type']は、クライアントが4桁の文字列でサーバーから取得できる各パッケージを一意に識別します。 [<タイプ> | 'type']が存在する必要があります。 PALパッケージタイプはセクション2.1.1で定義されています。
o [<date> | 'date'] indicates one of the following:
o [<日付> | 'date']は、次のいずれかを示します。
* The date and time that the client last successfully downloaded the identified package from the server. [<date> | 'date'] MUST be represented as Generalized Time with 20 characters: YYYY-MM-DDTHH:MM:SSZ; <date> matches the dateTime production in "canonical representation" [XMLSCHEMA]; 'date' is a string. Implementations SHOULD NOT rely on time resolution finer than seconds and MUST NOT generate time instants that specify leap seconds.
* クライアントが識別されたパッケージをサーバーから最後に正常にダウンロードした日時。 [<日付> | 「日付」] 20文字の一般化された時刻として表現する必要があります。YYYY-MM-DDTHH：MM：SSZ; <date>は、 "正規表現" [XMLSCHEMA]のdateTime生成と一致します。 「日付」は文字列です。実装は、秒よりも細かい時間分解能に依存してはならず（SHOULD NOT）、うるう秒を指定する瞬間を生成してはなりません（MUST NOT）。
* The omission of [<date> | 'date'] indicates the following:
* [<date>の省略| 'date']は以下を示します。
- There is no indication that the client has successfully downloaded the identified package, or
- クライアントが識別されたパッケージを正常にダウンロードしたことを示すものがない、または
- The PAL entry corresponds to a pointer to the next PAL, or the server is requesting a package from the client (e.g., certification request, receipt, error).
- PALエントリは、次のPALへのポインタに対応するか、サーバーがクライアントからのパッケージを要求しています（たとえば、認証要求、受信、エラー）。
o [<size> | 'size'] indicates the size in bytes of the package; <size> is a nonNegativeInteger, and 'size' is a number. A package size of zero (i.e., "0" without the quotes) indicates that the client needs to begin a transaction, return an error, or return a receipt. [<size> | 'size'] MUST be present.
o [<サイズ> | 'size']は、パッケージのサイズをバイト単位で示します。 <size>はnonNegativeIntegerであり、「size」は数値です。パッケージサイズがゼロ（引用符なしの「0」）は、クライアントがトランザクションを開始するか、エラーを返すか、または領収書を返す必要があることを示します。 [<サイズ> | 'サイズ']が存在しなければなりません。
o [<info> | 'info'] provides an SKI (Subject Key Identifier), a DN
(Distinguished Name), an Issuer and Serial Number tuple, or a URI,
i.e., it is a choice between these four items, all of which are
defined in [RFC5280]. When a URI [RFC3986] is included,
[<uri> | 'uri'] indicates the location where the identified
package can be retrieved. When a DN, an SKI, or an Issuer Name
and Serial Number tuple is included, it points to a certificate
that is the subject of the notification (i.e., the certificate to
be rekeyed or renewed); [<dn> | 'dn'] is encoded as a string with
the format defined in [RFC4514]; <ski> is a hexBinary, and 'ski'
is a string of hex digits (i.e., 0-9, a-f, and A-F);
[<iasn> | 'iasn'] includes both [<issuer> | 'issuer'] and
[<serial> | 'serial'] as a complexType in XML and an object in
JSON. [<issuer> | 'issuer'] is a DN encoded as a string with the
format defined in [RFC4514]; <serial> is a positiveInteger, and
'serial' is a number. [<info> | 'info'] MUST be present, and
[<info> | 'info'] MUST include exactly one [<dn> | 'dn'],
[<ski> | 'ski'], [<iasn> | 'iasn'], or [<uri> | 'uri'].
Clients are often limited by the size of objects they can consume; the PAL is not immune to these limitations. As opposed to picking a limit for all clients, a special package type (0001) is defined (see Section 2.1.1) to indicate that another PAL is available. Servers can use this value to limit the size of the PALs provided to clients. The mechanism for servers to know client PAL size limits is beyond the scope of this document; one possible solution is through provisioned information.
クライアントは、消費できるオブジェクトのサイズによって制限されることがよくあります。 PALはこれらの制限の影響を受けません。すべてのクライアントの制限を選択するのではなく、特別なパッケージタイプ（0001）が定義され（セクション2.1.1を参照）、別のPALが使用可能であることを示します。サーバーはこの値を使用して、クライアントに提供されるPALのサイズを制限できます。サーバーがクライアントPALのサイズ制限を認識するメカニズムは、このドキュメントの範囲外です。 1つの可能な解決策は、プロビジョニングされた情報を使用することです。
Table 1 lists the PAL package types that are defined by this document:
表1に、このドキュメントで定義されているPALパッケージタイプを示します。
Package Package Description
Number
-------- ---------------------------------------------------
0000 Reserved
0001 Additional PAL value present
0002 X.509 CA certificate
0003 X.509 EE certificate
0004 X.509 ARL
0005 X.509 CRL
0006 Start DS certificate enrollment with CSR attribute
0007 Start DS certificate enrollment
0008 DS certificate enrollment (success)
0009 DS certificate enrollment (failure)
0010 Start DS certificate re-enrollment
0011 DS certificate re-enrollment (success)
0012 DS certificate re-enrollment (failure)
0013 Start KE certificate enrollment with CSR attribute
0014 Start KE certificate enrollment
0015 KE certificate enrollment (success)
0016 KE certificate enrollment (failure)
0017 Start KE certificate re-enrollment
0018 KE certificate re-enrollment (success)
0019 KE certificate re-enrollment (failure)
0020 Asymmetric Key Package (PKCS #8)
0021 Asymmetric Key Package (CMS)
0022 Asymmetric Key Package (PKCS #12)
0023 Asymmetric Key Package Receipt or Error
0024 Symmetric Key Package
0025 Symmetric Key Package Receipt or Error
0026 Firmware Package
0027 Firmware Package Receipt or Error
0028 TAMP Status Query
0029 TAMP Status Query Response or Error
0030 Trust Anchor Update
0031 Trust Anchor Update Confirm or Error
0032 Apex Trust Anchor Update
0033 Apex Trust Anchor Update Confirm or Error
0034 Community Update
0035 Community Update Confirm or Error
0036 Sequence Number Adjust
0037 Sequence Number Adjust Confirm or Error
Table 1: PAL Package Types
表1：PALパッケージタイプ
Note: "CSR" is Certificate Signing Request, "DS" is Digital Signature, and "KE" is Key Establishment.
注：「CSR」は証明書署名要求、「DS」はデジタル署名、「KE」は鍵の確立です。
PAL package types are essentially hints about the type of package the client is about to retrieve or is asked to return. Savvy clients can parse the packages to determine what has been provided, but in some instances it is better to know before retrieving the package. The hint provided here does not obviate the need for clients to check the type of package provided before they store it, possibly in specially allocated locations (i.e., some clients might store Root ARLs separately from intermediate CRLs). For packages provided by the client, the server is asking the client to provide an enrollment package, receipt, response, confirm, or error.
PALパッケージタイプは、基本的に、クライアントが取得しようとしている、または返すように要求されているパッケージのタイプに関するヒントです。精通したクライアントは、パッケージを解析して提供されているものを判別できますが、場合によっては、パッケージを取得する前に知っておく方がよい場合もあります。ここで提供されるヒントは、クライアントが提供するパッケージのタイプを、特別に割り当てられた場所に保管する前にチェックする必要をなくしません（つまり、一部のクライアントはルートARLを中間CRLとは別に保管する場合があります）。クライアントが提供するパッケージの場合、サーバーはクライアントに登録パッケージ、受領、応答、確認、またはエラーを提供するように要求しています。
The PAL package types have the following meanings:
PALパッケージタイプには次の意味があります。
Note: The semantics behind Codes 0002 and 0006-0021 are defined in [RFC7030].
注：コード0002および0006-0021の背後にあるセマンティクスは、[RFC7030]で定義されています。
0000 Reserved: Reserved for future use.
0000予約済み：将来の使用のために予約されています。
0001 Additional PAL value present: Indicates that this PAL entry refers to another PAL by referring to another /pal URI, which is defined in this section. This PAL package type limits the size of PALs to a more manageable size for clients. If this PAL package type appears, it MUST be the last entry in the PAL.
0001追加のPAL値が存在する：このPALエントリが、このセクションで定義されている別の/ pal URIを参照することによって別のPALを参照していることを示します。このPALパッケージタイプは、PALのサイズをクライアントが管理しやすいサイズに制限します。このPALパッケージタイプが表示される場合、それはPALの最後のエントリである必要があります。
Additionally, in order to avoid needlessly dereferencing URIs, this PAL package type MUST NOT be the only entry.
さらに、不必要にURIを逆参照しないようにするために、このPALパッケージタイプを唯一のエントリにすることはできません。
0002 X.509 CA certificate: Indicates that one or more CA certificates [RFC5280] are available for the client by pointing to a /cacerts URI, which is defined in [RFC7030].
0002 X.509 CA証明書：[RFC7030]で定義されている/ cacerts URIをポイントすることにより、クライアントが1つ以上のCA証明書[RFC5280]を使用できることを示します。
0003 X.509 EE certificate: Indicates that one or more EE certificates [RFC5280] are available for the client by pointing to an /eecerts URI, which is defined in Section 3.
0003 X.509 EE証明書：セクション3で定義されている/ eecerts URIをポイントすることにより、クライアントが1つ以上のEE証明書[RFC5280]を使用できることを示します
0004 X.509 ARL: Indicates that one or more ARLs (Authority Revocation Lists) [RFC5280] are available for the client by pointing to a /crls URI, which is defined in Section 4.
0004 X.509 ARL：セクション4で定義されている/ crls URIをポイントすることにより、クライアントが1つ以上のARL（権限取り消しリスト）[RFC5280]を使用できることを示します。
0005 X.509 CRL: Indicates that one or more CRLs (Certificate Revocation Lists) [RFC5280] are available for the client by pointing to a /crls URI, which is defined in Section 4.
0005 X.509 CRL：セクション4で定義されている/ crls URIをポイントすることにより、クライアントが1つ以上のCRL（証明書失効リスト）[RFC5280]を使用できることを示します。
Note: See Section 9 for additional information about PAL and certificate enrollment interaction. See Appendix B for additional informative information.
注：PALと証明書登録の相互作用の詳細については、セクション9を参照してください。補足情報については、付録Bを参照してください。
0006 Start DS certificate enrollment with CSR: Indicates that the client needs to begin enrolling its DS certificate (i.e., any certificate for which the key usage extension will have a digital signature set), using a template provided by the server with a CSR (Certificate Signing Request) attribute (see Appendix B). The PAL entry points to a /csrattrs URI, which is defined in [RFC7030].
0006 CSRを使用したDS証明書の登録の開始：クライアントがDS証明書（つまり、キー使用法拡張がデジタル署名を設定する証明書）の登録を開始する必要があることを示します。 Signing Request）属性（付録Bを参照）。 PALエントリは、[RFC7030]で定義されている/ csrattrs URIを指します。
0007 Start DS certificate enrollment: Indicates that the client needs to begin enrolling its DS certificate. The PAL entry points to a /simpleenroll URI, which is defined in [RFC7030].
0007 DS証明書の登録の開始：クライアントがDS証明書の登録を開始する必要があることを示します。 PALエントリは、[RFC7030]で定義されている/ simpleenroll URIを指します。
0008 DS certificate enrollment (success): Indicates that the client needs to retrieve a successful certification response. The PAL entry points to a /simpleenroll or a /fullcmc URI, both of which are defined in [RFC7030].
0008 DS証明書の登録（成功）：クライアントが正常な認証応答を取得する必要があることを示します。 PALエントリは/ simpleenrollまたは/ fullcmc URIを指します。どちらも[RFC7030]で定義されています。
0009 DS certificate enrollment (failure): Indicates that the client needs to retrieve a failed certification response for a DS certificate. This PAL entry points to a /simpleenroll or a /fullcmc URI.
0009 DS証明書の登録（失敗）：クライアントがDS証明書の失敗した認証応答を取得する必要があることを示します。このPALエントリは、/ simpleenrollまたは/ fullcmc URIを指します。
0010 Start DS certificate re-enrollment: Indicates that the client needs to rekey or renew a DS certificate. The PAL entry points to a /simplereenroll or a /fullcmc URI.
0010 DS証明書の再登録を開始します：クライアントがDS証明書を再生成または更新する必要があることを示します。 PALエントリは、/ simplereenrollまたは/ fullcmc URIを指します。
0011 DS certificate re-enrollment (success): See PAL package type 0008.
0011 DS証明書の再登録（成功）：PALパッケージタイプ0008を参照してください。
0012 DS certificate re-enrollment (failure): See PAL package type 0009.
0012 DS証明書の再登録（失敗）：PALパッケージタイプ0009を参照してください。
Note: The KE (Key Establishment) responses that follow use the same URIs as DS certificates, except that the certificates' key usage extension is set to only key agreement or key transport.
注：以下のKE（Key Establishment）応答は、DS証明書と同じURIを使用しますが、証明書の鍵使用法拡張は鍵合意または鍵転送のみに設定されます。
0013 Start KE certificate enrollment with CSR: See PAL package type 0006.
0013 CSRを使用してKE証明書の登録を開始します。PALパッケージタイプ0006を参照してください。
0014 Start KE certificate enrollment: See PAL package type 0007.
0014 KE証明書の登録を開始します。PALパッケージタイプ0007を参照してください。
0015 KE certificate enrollment (success): See PAL package type 0008.
0015 KE証明書の登録（成功）：PALパッケージタイプ0008を参照してください。
0016 KE certificate enrollment (failure): See PAL package type 0009.
0016 KE証明書の登録（失敗）：PALパッケージタイプ0009を参照してください。
0017 Start KE certificate re-enrollment: See PAL package type 0010.
0017 KE証明書の再登録を開始します。PALパッケージタイプ0010を参照してください。
0018 KE certificate re-enrollment (success): See PAL package type 0008.
0018 KE証明書の再登録（成功）：PALパッケージタイプ0008を参照してください。
0019 KE certificate re-enrollment (failure): See PAL package type 0009.
0019 KE証明書の再登録（失敗）：PALパッケージタイプ0009を参照してください。
Note: The variations in the asymmetric key packages are due to the number of CMS content types that can be used to protect the asymmetric key; the syntax for the asymmetric key is the same, but additional ASN.1 is needed to include it in a signed-data (i.e., the ASN.1 needs to be a CMS content type and not the private key info type). See Section 8 of this document for additional information.
注：非対称キーパッケージのバリエーションは、非対称キーを保護するために使用できるCMSコンテンツタイプの数によるものです。非対称キーの構文は同じですが、それを署名済みデータに含めるには追加のASN.1が必要です（つまり、ASN.1はCMSコンテンツタイプであり、秘密キー情報タイプではない必要があります）。詳細については、このドキュメントのセクション8を参照してください。
0020 Asymmetric Key Package (PKCS #8): Indicates that an asymmetric key generated by the server is available for the client; the package is an asymmetric key without additional encryption as specified in Section 4.4.2 of [RFC7030]. The PAL entry points to a /serverkeygen or a /fullcmc URI, which are defined in [RFC7030].
0020非対称キーパッケージ（PKCS＃8）：サーバーによって生成された非対称キーがクライアントで使用できることを示します。 [RFC7030]のセクション4.4.2で指定されているように、パッケージは追加の暗号化なしの非対称鍵です。 PALエントリは、[RFC7030]で定義されている/ serverkeygenまたは/ fullcmc URIを指します。
0021 Asymmetric Key Package (CMS): See PAL package type 0020 (the difference being that the package available is an asymmetric key package [RFC5958] that is signed and encapsulated in a signed-data content type, as specified in Section 4.4.2 of [RFC7030]). Also, see Section 8.1 of this document.
0021非対称キーパッケージ（CMS）：PALパッケージタイプ0020を参照してください（パッケージが非対称キーパッケージ[RFC5958]である点が異なります）。 [RFC7030]）。また、このドキュメントのセクション8.1を参照してください。
0022 Asymmetric Key Package (PKCS #12): See PAL package type 0020 (the difference being that the package available is the PKCS #12 [RFC7292] content type). See Section 8.3 of this document.
0022非対称キーパッケージ（PKCS＃12）：PALパッケージタイプ0020を参照してください（利用可能なパッケージはPKCS＃12 [RFC7292]コンテンツタイプです）。このドキュメントのセクション8.3を参照してください。
0023 Asymmetric Key Package Receipt or Error: Indicates that the server wants the client to return a key package receipt or error [RFC7191] to the /serverkeygen/return URI, which is defined in Section 8.
0023非対称キーパッケージの受信またはエラー：サーバーが、クライアントがキーパッケージの受信またはエラー[RFC7191]をセクション8で定義されている/ serverkeygen / return URIに返すことを望んでいることを示します。
0024 Symmetric Key Package: Indicates that a symmetric key package [RFC6031] is available for the client by pointing to a /symmetrickeys URI, which is defined in Section 5.
0024対称鍵パッケージ：セクション5で定義されている/ symmetrickeys URIを指すことにより、クライアントが対称鍵パッケージ[RFC6031]を使用できることを示します。
0025 Symmetric Key Package Receipt or Error: Indicates that the server wants the client to return a key package receipt or error [RFC7191] to the /symmetrickeys/return URI, which is defined in Section 5.
0025対称鍵パッケージの受信またはエラー：サーバーが、クライアントが鍵パッケージの受信またはエラー[RFC7191]をセクション5で定義されている/ symmetrickeys / return URIに返すことを望んでいることを示します。
0026 Firmware Package: Indicates that a firmware package [RFC4108] is available for the client, using the /firmware URI, which is defined in Section 6.
0026ファームウェアパッケージ：セクション6で定義されている/ firmware URIを使用して、ファームウェアパッケージ[RFC4108]がクライアントで使用できることを示します。
0027 Firmware Package Receipt or Error: Indicates that the server wants the client to return a firmware package load receipt or error [RFC4108] to the /firmware/return URI, which is defined in Section 6.
0027ファームウェアパッケージの受信またはエラー：サーバーが、クライアントがファームウェアパッケージのロードの受信またはエラー[RFC4108]をセクション6で定義されている/ firmware / return URIに返すことを望んでいることを示します。
Note: The /tamp and tamp/return URIs are defined in Section 7.
注：/ tampおよびtamp / return URIはセクション7で定義されています。
0028 TAMP Status Query: Indicates that a TAMP Status Query package [RFC5934] is available for the client, using the /tamp URI.
0028 TAMPステータスクエリ：/ tamp URIを使用して、クライアントがTAMPステータスクエリパッケージ[RFC5934]を使用できることを示します。
0029 TAMP Status Query Response or Error: Indicates that the server wants the client to return a TAMP Status Query Response or Error [RFC5934] to the /tamp/return URI.
0029 TAMPステータスクエリの応答またはエラー：サーバーがクライアントにTAMPステータスクエリの応答またはエラー[RFC5934]を/ tamp / return URIに返すことを要求していることを示します。
0030 Trust Anchor Update: Indicates that a Trust Anchor Update package [RFC5934] is available for the client, using the /tamp URI.
0030 Trust Anchor Update：/ tamp URIを使用して、Trust Anchor Updateパッケージ[RFC5934]がクライアントで使用できることを示します。
0031 Trust Anchor Update Confirm or Error: Indicates that the server wants the client to return a Trust Anchor Update Confirm or Error [RFC5934] to the /tamp/return URI.
0031トラストアンカーの更新の確認またはエラー：サーバーがクライアントにトラストアンカーの更新の確認またはエラー[RFC5934]を/ tamp / return URIに返すことを要求していることを示します。
0032 Apex Trust Anchor Update: Indicates that an Apex Trust Anchor Update package [RFC5934] is available for the client, using the /tamp URI.
0032 Apex Trust Anchor Update：/ tamp URIを使用して、クライアントがApex Trust Anchor Updateパッケージ[RFC5934]を使用できることを示します。
0033 Apex Trust Anchor Update Confirm or Error: Indicates that the server wants the client to return an Apex Trust Anchor Update Confirm or Error [RFC5934] to the /tamp/return URI.
0033 Apexトラストアンカーの更新の確認またはエラー：サーバーがクライアントにApexトラストアンカーの更新の確認またはエラー[RFC5934]を/ tamp / return URIに返すことを要求していることを示します。
0034 Community Update: Indicates that a Community Update package [RFC5934] is available for the client, using the /tamp URI.
0034コミュニティ更新：/ tamp URIを使用して、コミュニティ更新パッケージ[RFC5934]がクライアントで使用できることを示します。
0035 Community Update Confirm or Error: Indicates that the server wants the client to return a Community Update Confirm or Error [RFC5934] to the /tamp/return URI.
0035コミュニティ更新の確認またはエラー：サーバーがクライアントにコミュニティ更新の確認またはエラー[RFC5934]を/ tamp / return URIに返すことを要求していることを示します。
0036 Sequence Number Adjust: Indicates that a Sequence Number Adjust package [RFC5934] is available for the client, using the /tamp URI.
0036シーケンス番号調整：/ tamp URIを使用して、シーケンス番号調整パッケージ[RFC5934]がクライアントで使用できることを示します。
0037 Sequence Number Adjust Confirm or Error: Indicates that the server wants the client to return a Sequence Number Adjust Confirm or Error [RFC5934] to the /tamp/return URI.
0037シーケンス番号調整確認またはエラー：サーバーがクライアントにシーケンス番号調整確認またはエラー[RFC5934]を/ tamp / return URIに返すことを要求していることを示します。
The namespace is specified in Section 11.1. The fields in the schema were discussed earlier, in Sections 2.1 and 2.1.1.
名前空間はセクション11.1で指定されています。スキーマのフィールドについては、2.1と2.1.1で説明しました。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:pal="urn:ietf:params:xml:ns:pal"
targetNamespace="urn:ietf:params:xml:ns:pal"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<xsd:annotation>
<xsd:documentation>
This schema defines the types and elements needed
to retrieve client packages from the server or for the
client to post packages to the server.
</xsd:documentation>
</xsd:annotation>
<!-- ===== Element Declarations ===== -->
<xsd:element name="pal" type="pal:PAL" />
<!-- ===== Complex Data Element Type Definitions ===== -->
<xsd:complexType name="PAL">
<xsd:annotation>
<xsd:documentation>
This type defines the Package Availability List (PAL).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="message" type="pal:PALEntry"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
This item contains information about the package
and a link that the client uses to download or post
the package.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PALEntry">
<xsd:annotation>
<xsd:documentation>
This type defines a product in the PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="type" type="pal:PackageType" />
<xsd:element name="date" type="pal:GeneralizedTimeType"
minOccurs="0" />
<xsd:element name="size" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>
This item indicates the package's size.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="info" type="pal:PackageInfoType" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PackageInfoType">
<xsd:annotation>
<xsd:documentation>
This type allows a choice of X.500 Distinguished Name,
Subject Key Identifier, Issuer and Serial Number tuple,
or URI.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<xsd:element name="dn" type="pal:DistinguishedName" />
<xsd:element name="ski" type="pal:SubjectKeyIdentifier" />
<xsd:element name="iasn" type="pal:IssuerAndSerialNumber" />
<xsd:element name="uri" type="pal:ThisURI" />
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="IssuerAndSerialNumber">
<xsd:annotation>
<xsd:documentation>
This type holds the issuer Distinguished Name and
serial number of a referenced certificate.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="issuer" type="pal:DistinguishedName" />
<xsd:element name="serial" type="xsd:positiveInteger" />
</xsd:sequence>
</xsd:complexType>
<!-- ===== Simple Data Element Type Definitions ===== -->
<xsd:simpleType name="PackageType">
<xsd:annotation>
<xsd:documentation>
This type identifies each package that a client may retrieve
from the server with a 4-digit string.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="d{4}" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="GeneralizedTimeType">
<xsd:annotation>
<xsd:documentation>
This type indicates the date and time (YYYY-MM-DDTHH:MM:SSZ)
that the client last acknowledged successful receipt of the
package; it is absent if a) there is no indication that the
package has been downloaded or b) the PAL entry corresponds
to a pointer to the next PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".*:d{2}Z" />
<xsd:minInclusive value="2013-05-23T00:00:00Z" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DistinguishedName">
<xsd:annotation>
<xsd:documentation>
This type holds an X.500 Distinguished Name.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SubjectKeyIdentifier">
<xsd:annotation>
<xsd:documentation>
This type holds a hex string representing the value of a
certificate's SubjectKeyIdentifier.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:hexBinary">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ThisURI">
<xsd:annotation>
<xsd:documentation>
This type holds a URI but is length limited.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:anyURI">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
The following is an example PAL JSON object. The fields in the object were discussed earlier, in Sections 2.1 and 2.1.1.
以下は、PAL JSONオブジェクトの例です。オブジェクトのフィールドについては、2.1と2.1.1で説明しました。
[
{
"type": "0003",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"uri": "https://www.example.com/.well-known/est/eecerts/1234"
}
},
{
"type": "0006",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"iasn":
{
"issuer": "CN=Sean Turner,O=sn3rd,C=US",
"serial": 0
}
}
}
]
Clients request their PAL with an HTTP GET [RFC7231], using an operation path of "/pal". Clients indicate whether they would prefer XML or JSON by including the HTTP Accept header [RFC7231] with either "application/xml" or "application/json", respectively.
クライアントは、 "/ pal"の操作パスを使用して、HTTP GET [RFC7231]でPALを要求します。クライアントは、それぞれ「application / xml」または「application / json」でHTTP Acceptヘッダー[RFC7231]を含めることにより、XMLまたはJSONを好むかどうかを示します。
If the server has a PAL for the client, the server response MUST contain an HTTP 200 response code with a Content-Type of "application/xml" [RFC7303] or "application/json" [RFC8259].
サーバーにクライアントのPALがある場合、サーバー応答には、Content-Typeが「application / xml」[RFC7303]または「application / json」[RFC8259]のHTTP 200応答コードが含まれている必要があります。
When the server constructs a PAL, an order of precedence for PAL offerings is based on the following rationale:
サーバーがPALを構築するとき、PALオファリングの優先順位は次の根拠に基づいています。
o /cacerts and /crls packages are the most important because they support validation decisions on certificates used to sign and encrypt other listed PAL items.
o / cacertsおよび/ crlsパッケージは、リストされている他のPALアイテムの署名および暗号化に使用される証明書の検証決定をサポートするため、最も重要です。
o /csrattrs are the next in importance, since they provide information that the server would like the client to include in its certificate enrollment request.
o / csrattrsは、サーバーがクライアントの証明書登録要求に含めたい情報を提供するため、次に重要です。
o /simpleenroll, /simplereenroll, and /fullcmc packages are next in importance, since they can impact a certificate used by the client to sign CMS content or a certificate to establish keys for encrypting content exchanged with the client.
o / simpleenroll、/ simplereenroll、および/ fullcmcパッケージは、クライアントがCMSコンテンツに署名するために使用する証明書またはクライアントと交換されるコンテンツを暗号化するためのキーを確立するための証明書に影響を与える可能性があるため、次に重要です。
* A client engaged in certificate management SHOULD accept and process CA-provided transactions as soon as possible to avoid undue delays that might lead to protocol failure.
* 証明書管理に従事しているクライアントは、プロトコル障害につながる可能性のある過度の遅延を回避するために、CA提供のトランザクションをできるだけ早く受け入れて処理する必要があります（SHOULD）。
o /symmetrickeys, /firmware, /tamp, and /eecerts packages containing keys and other types of products are last. Precedence SHOULD be given to packages that the client has not previously downloaded. The items listed in a PAL may not identify all of the packages available for a device. This can be for any of the following reasons:
o キーおよびその他の種類の製品を含む/ symmetrickeys、/ firmware、/ tamp、および/ eecertsパッケージが最後です。クライアントが以前にダウンロードしていないパッケージに優先順位を与える必要があります。 PALにリストされているアイテムは、デバイスで利用可能なすべてのパッケージを識別するとは限りません。これは、次のいずれかの理由が考えられます。
* The server may temporarily withhold some outstanding PAL items to simplify client processing.
* サーバーは、クライアントの処理を簡略化するために、未処理のPALアイテムを一時的に保留する場合があります。
* If a CA has more than one certificate ready for the client, the server will provide a notice for one at a time. Pending notices will be serviced in order, according to the date when the certificate will be used (earliest date first).
* CAがクライアントに対して複数の証明書の準備ができている場合、サーバーは1つずつ通知を提供します。保留中の通知は、証明書が使用される日付（最も早い日付が最初）に従って順番に処理されます。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定します。
All other return codes are handled as specified in Section 4.2.3 of [RFC7030] (i.e., 202 handling and all other HTTP response codes).
他のすべての戻りコードは、[RFC7030]のセクション4.2.3で指定されたように処理されます（つまり、202の処理と他のすべてのHTTP応答コード）。
Numerous mechanisms exist for clients to query repositories for certificates. The service provided by the /eecerts PC is different in that it is not a general-purpose query for client certificates; instead, it allows the server to provide peer certificates to a client that the server knows through an out-of-band mechanism that the client will be communicating with. For example, a router being provisioned that connects to two peers can be provisioned with not only its certificate but also with the peers' certificates.
クライアントがリポジトリーに証明書を照会するためのメカニズムは数多くあります。 / eecerts PCによって提供されるサービスは、クライアント証明書の汎用クエリではないという点で異なります。代わりに、サーバーがクライアントにピア証明書を提供できるようにします。サーバーは、クライアントが通信する帯域外メカニズムを介してそれを認識しています。たとえば、2つのピアに接続するプロビジョニング中のルーターは、その証明書だけでなく、ピアの証明書でもプロビジョニングできます。
The server need not authenticate or authorize the client for distributing an EE certificate, because the package contents are already signed by a CA (i.e., the certificate(s) in a certs-only message has already been signed by a CA). The message flow is similar to Figure 1, except that the connection need not be HTTPS:
パッケージの内容はすでにCAによって署名されているため（つまり、certs-onlyメッセージ内の証明書はすでにCAによって署名されているため）、サーバーはEE証明書の配布についてクライアントを認証または承認する必要はありません。メッセージフローは図1と同様ですが、接続がHTTPSである必要はありません。
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Request EE Cert(s) |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver EE Cert(s) |
| (HTTP GET Response) |
| |
Figure 2: /eecerts Message Sequence
図2：/ eecertsメッセージシーケンス
Clients request EE certificates with an HTTP GET [RFC7231], using an operation path of "/eecerts".
クライアントは、「/ eecerts」の操作パスを使用して、HTTP GET [RFC7231]でEE証明書を要求します。
The response and processing of the returned error codes are identical to what is described in Section 4.1.3 of [RFC7030], except that the certificate provided is not the one issued to the client; instead, one or more client's peer certificates are returned in the certs-only message.
返されたエラーコードの応答と処理は、[RFC7030]のセクション4.1.3で説明されているものと同じですが、提供された証明書がクライアントに発行されたものではない点が異なります。代わりに、1つ以上のクライアントのピア証明書がcerts-onlyメッセージで返されます。
Clients MUST reject EE certificates that do not validate to an authorized TA.
クライアントは、許可されたTAに対して検証されないEE証明書を拒否する必要があります。
CRLs (and ARLs) are needed in many instances to perform certificate path validation [RFC5280]. They can be obtained from repositories if their location is provided in the certificate. However, the client needs to parse the certificate and perform an additional round trip to retrieve them. Providing CRLs during bootstrapping obviates the need for the client to parse the certificate and aids those clients who might be unable to retrieve the CRL. Clients are free to obtain CRLs on which they rely from sources other than the server (e.g., a local directory). The /crls PC allows servers to distribute CRLs at the same time that clients retrieve their certificate(s) and CA certificate(s) as well as peer certificates.
証明書パスの検証[RFC5280]を実行するには、多くの場合CRL（およびARL）が必要です。証明書で場所が指定されている場合は、リポジトリから取得できます。ただし、クライアントは証明書を解析し、それらを取得するために追加のラウンドトリップを実行する必要があります。ブートストラップ中にCRLを提供すると、クライアントが証明書を解析する必要がなくなり、CRLを取得できない可能性があるクライアントを支援します。クライアントは、サーバー以外のソース（ローカルディレクトリなど）から依存するCRLを自由に取得できます。 / crls PCを使用すると、クライアントが証明書とCA証明書、およびピア証明書を取得するのと同時に、サーバーはCRLを配布できます。
The server need not authenticate or authorize the client for distributing a CRL, because the package contents are already signed by a CA (i.e., the CRLs in a crls-only message have already been signed by a CA). The message flow is as depicted in Figure 2 but with "CRL(s)" instead of "EE Cert(s)".
パッケージの内容は既にCAによって署名されているため（つまり、crls-onlyメッセージのCRLはすでにCAによって署名されているため）、サーバーはクライアントを認証またはCRLの配布を承認する必要はありません。メッセージフローは図2に示すとおりですが、「EE Cert（s）」の代わりに「CRL（s）」が使用されています。
Clients request CRLs with an HTTP GET [RFC7231], using an operation path of "/crls".
クライアントは、 "/ crls"の操作パスを使用して、HTTP GET [RFC7231]でCRLを要求します。
The response, and the processing of that response, are identical to what is described in Section 4.1.3 of [RFC7030], except that instead of providing the issued certificate one of more CRLs are returned in the crls-only message.
応答とその応答の処理は、[RFC7030]のセクション4.1.3で説明されているものと同じですが、発行された証明書を提供する代わりに、1つ以上のCRLがcrls-onlyメッセージで返されます。
Clients MUST reject CRLs that do not validate to an authorized TA.
クライアントは、承認されたTAに対して検証されないCRLを拒否する必要があります。
In addition to public keys, clients often need one or more symmetric keys to communicate with their peers. The /symmetrickeys PC allows the server to distribute symmetric keys to clients.
公開鍵に加えて、クライアントは多くの場合、ピアと通信するために1つ以上の対称鍵を必要とします。 / symmetrickeys PCにより、サーバーは対称鍵をクライアントに配布できます。
Distribution of keys does not always work as planned, and clients need a way to inform the server that something has gone wrong; they also need a way to inform the server, if asked, that the distribution process has successfully completed. The /symmetrickeys/return PC allows clients to provide errors and receipts.
キーの配布は常に計画どおりに機能するわけではなく、クライアントは何かがうまくいかなかったことをサーバーに通知する方法が必要です。また、必要に応じて、配布プロセスが正常に完了したことをサーバーに通知する方法も必要です。 / symmetrickeys / return PCを使用すると、クライアントはエラーとレシートを提供できます。
Clients MUST authenticate the server, and clients MUST check the server's authorization.
クライアントはサーバーを認証する必要があり、クライアントはサーバーの承認を確認する必要があります。
The server MUST authenticate clients, and the server MUST check the client's authorization.
サーバーはクライアントを認証しなければならず（MUST）、サーバーはクライアントの承認をチェックしなければなりません（MUST）。
HTTP GET [RFC7231] is used when the server provides the key to the client (see Section 5.1), using the /symmetrickeys PC; HTTP POST [RFC7231] is used when the client provides a receipt (see Section 5.2) or an error (see Section 5.2) to the server with the /symmetrickeys/return PC.
HTTP GET [RFC7231]は、サーバーが/ symmetrickeys PCを使用してクライアント（セクション5.1を参照）にキーを提供するときに使用されます。 HTTP POST [RFC7231]は、クライアントが/ symmetrickeys / return PCを使用してサーバーに受信（セクション5.2を参照）またはエラー（セクション5.2を参照）を提供するときに使用されます。
Servers use /symmetrickeys to provide symmetric keys to clients; the symmetric key package is defined in [RFC6031].
サーバーは/ symmetrickeysを使用して、クライアントに対称鍵を提供します。対称鍵パッケージは[RFC6031]で定義されています。
As with the /serverkeygen PC defined in [RFC7030], the default method for distributing the symmetric key uses the encryption mode of the negotiated TLS cipher suite. Keys are not protected by preferred key-wrapping methods such as AES Key Wrap [RFC3394] or AES Key Wrap with Padding [RFC5649], because encryption of the symmetric key beyond that provided by TLS is OPTIONAL. Therefore, the cipher suite used to return the symmetric key MUST offer cryptographic strength that is commensurate with the symmetric key being delivered to the client. The cipher suite used MUST NOT have the NULL encryption algorithm, as this will disclose the unprotected symmetric key. It is strongly RECOMMENDED that servers always return encrypted symmetric keys.
[RFC7030]で定義されている/ serverkeygen PCと同様に、対称鍵を配布するデフォルトの方法は、ネゴシエートされたTLS暗号スイートの暗号化モードを使用します。 TLSが提供するものを超える対称鍵の暗号化はオプションであるため、鍵はAES鍵ラップ[RFC3394]やAES鍵パディング付きラップ[RFC5649]などの優先鍵ラッピング方式では保護されません。したがって、対称鍵を返すために使用される暗号スイートは、クライアントに配信される対称鍵に見合った暗号強度を提供する必要があります。使用される暗号スイートには、保護されていない対称鍵が開示されるため、NULL暗号化アルゴリズムを含めることはできません。サーバーは常に暗号化された対称キーを返すことが強く推奨されます。
The following depicts the protocol flow:
以下は、プロトコルフローを示しています。
| |
Client | Establish TLS | Server
| Session |
|<--------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|---------------------->|
|<----------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Req Symmetric Key |
| (HTTP GET Request) |
|---------------------->|
|<----------------------|
| Deliver Symmetric Key |
| (HTTP GET Response) |
| |
Figure 3: /symmetrickeys Message Sequence
図3：/ symmetrickeysメッセージシーケンス
Clients request the symmetric key from the server with an HTTP GET [RFC7231], using an operation path of "/symmetrickeys".
クライアントは、「/ symmetrickeys」の操作パスを使用して、HTTP GET [RFC7231]でサーバーに対称鍵を要求します。
If the request is successful, the server response MUST have an HTTP 200 response code with a Content-Type of "application/cms" [RFC7193]. The optional application/cms encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned symmetric key. The returned content varies:
リクエストが成功した場合、サーバーの応答には、Content-Typeが「application / cms」であるHTTP 200応答コードが含まれている必要があります[RFC7193]。オプションのapplication / cms encapsulatingContentおよびinnerContentパラメーターをContent-Typeに含めて、返される対称鍵に提供される保護を示す必要があります（SHOULD）。返されるコンテンツは異なります。
o If additional encryption is not being employed, the content associated with application/cms is a DER-encoded [X.690] symmetric key package.
o 追加の暗号化が採用されていない場合、application / cmsに関連付けられているコンテンツは、DERエンコード[X.690]対称鍵パッケージです。
o If additional encryption is employed, the content associated with application/cms is DER-encoded enveloped-data that encapsulates a signed-data that further encapsulates a symmetric key package.
o 追加の暗号化が採用されている場合、application / cmsに関連付けられているコンテンツは、対称鍵パッケージをさらにカプセル化する署名済みデータをカプセル化するDERエンコードされたエンベロープデータです。
o If additional encryption and origin authentication are employed, the content associated with application/cms is a DER-encoded signed-data that encapsulates an enveloped-data that encapsulates a signed-data that further encapsulates a symmetric key package.
o 追加の暗号化とオリジン認証が採用されている場合、application / cmsに関連付けられているコンテンツは、対称鍵パッケージをさらにカプセル化する署名データをカプセル化するエンベロープデータをカプセル化するDERエンコードの署名データです。
o If CCC (CMS Content Constraints) [RFC6010] is supported, the content associated with application/cms is a DER-encoded encrypted key package [RFC6032]. The encrypted key package provides three choices to encapsulate keys: EncryptedData, EnvelopedData, and AuthEnvelopedData. Prior to employing one of these three encryption choices, the key package can be encapsulated in a signed-data.
o CCC（CMSコンテンツ制約）[RFC6010]がサポートされている場合、application / cmsに関連付けられたコンテンツは、DERエンコードされた暗号化キーパッケージ[RFC6032]です。暗号化されたキーパッケージは、キーをカプセル化するための3つの選択肢、EncryptedData、EnvelopedData、AuthEnvelopedDataを提供します。これら3つの暗号化オプションのいずれかを使用する前に、キーパッケージを署名済みデータにカプセル化できます。
How the server knows whether the client supports the encrypted key package is beyond the scope of this document.
クライアントが暗号化されたキーパッケージをサポートしているかどうかをサーバーが認識する方法は、このドキュメントの範囲外です。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定します。
If a symmetric key package (which might be signed) or an encrypted key package (which might be signed before and after encryption) is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA.
対称鍵パッケージ（署名される可能性がある）または暗号化された鍵パッケージ（暗号化の前後に署名される可能性がある）がデジタル署名されている場合、デジタル署名が承認されたTAに検証されない場合、クライアントはそれを拒否する必要があります。
Note: Absent a policy on the client side requiring a signature, a malicious EST server can simply strip the signature, thus bypassing that check. In that case, this requirement is merely a sanity check, serving to detect mis-signed packages or misconfigured clients.
注：署名を必要とするクライアント側のポリシーがない場合、悪意のあるESTサーバーは単に署名を取り除き、そのチェックをバイパスできます。その場合、この要件は単なるサニティチェックであり、署名が間違っているパッケージや設定が間違っているクライアントを検出するのに役立ちます。
[RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6160], and [RFC6161] provide algorithm details for use when protecting the symmetric key package and encrypted key package.
[RFC3370]、[RFC5753]、[RFC5754]、[RFC6033]、[RFC6160]、および[RFC6161]は、対称鍵パッケージと暗号化鍵パッケージを保護するときに使用するアルゴリズムの詳細を提供します。
Clients use /symmetrickeys/return to provide symmetric key package receipts; the key package receipt content type is defined in [RFC7191]. Clients can be configured to automatically return receipts after processing a symmetric key package, return receipts based on processing of the key-package-identifier-and-receipt-request attribute [RFC7191], or return receipts when prompted by a PAL entry.
クライアントは/ symmetrickeys / returnを使用して、対称鍵パッケージの領収書を提供します。主要なパッケージ受領コンテンツタイプは[RFC7191]で定義されています。クライアントは、対称鍵パッケージの処理後に自動的に領収書を返すように構成したり、key-package-identifier-and-receipt-request属性[RFC7191]の処理に基づいて領収書を返したり、PALエントリによってプロンプトが表示されたときに領収書を返したりできます。
Servers can indicate that clients return a receipt by including the key-package-identifier-and-receipt-request attribute in a signed-data as a signed attribute. However, this attribute only appears when additional encryption is employed (see Section 5.1.2).
サーバーは、signed-dataにkey-package-identifier-and-receipt-request属性を署名済み属性として含めることにより、クライアントが領収書を返すことを示すことができます。ただし、この属性は、追加の暗号化が採用されている場合にのみ表示されます（セクション5.1.2を参照）。
Clients also use /symmetrickeys/return to return symmetric key package errors; the key package error content type is defined in [RFC7191]. Clients can be configured to automatically return errors after processing a symmetric key package or based on a PAL entry.
クライアントは/ symmetrickeys / returnを使用して対称鍵パッケージのエラーを返します。キーパッケージのエラーコンテンツタイプは[RFC7191]で定義されています。対称キーパッケージを処理した後、またはPALエントリに基づいてエラーを自動的に返すようにクライアントを構成できます。
The following depicts the protocol flow:
以下は、プロトコルフローを示しています。
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Return Receipt/Error |
| (HTTP POST Request) |
|--------------------->|
|<---------------------|
| (HTTP POST Response) |
| status code only |
| no content |
| |
Figure 4: /symmetrickeys/return Message Sequence
Clients return symmetric key receipts and errors to the server with an HTTP POST [RFC7231], using an operation path of "/symmetrickeys/return". The returned content varies:
クライアントは、「/ symmetrickeys / return」の操作パスを使用して、HTTP POST [RFC7231]で対称鍵の受信とエラーをサーバーに返します。返されるコンテンツは異なります。
o The key package receipt is digitally signed [RFC7191]; the Content-Type is "application/cms" [RFC7193]; and the associated content is signed-data, which encapsulates a key package receipt.
o キーパッケージの領収書はデジタル署名されています[RFC7191]。 Content-Typeは "application / cms" [RFC7193]です。関連するコンテンツは署名済みデータであり、主要なパッケージ受領書をカプセル化します。
o If the key package error is not digitally signed, the Content-Type is "application/cms" and the associated content is a key package error. If the key package error is digitally signed, the Content-Type is "application/cms" and the associated content is signed-data, which encapsulates a key package error.
o キーパッケージエラーがデジタル署名されていない場合、Content-Typeは "application / cms"であり、関連するコンテンツはキーパッケージエラーです。キーパッケージエラーがデジタル署名されている場合、Content-Typeは「application / cms」であり、関連するコンテンツはsigned-dataであり、キーパッケージエラーをカプセル化しています。
The optional application/cms encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the receipt or error.
オプションのapplication / cms encapsulatingContentおよびinnerContentパラメーターは、受信またはエラーに提供される保護を示すためにContent-Typeに含める必要があります（SHOULD）。
[RFC3370], [RFC5753], [RFC5754], and [RFC7192] provide algorithm details for use when protecting the key package receipt or key package error.
[RFC3370]、[RFC5753]、[RFC5754]、および[RFC7192]は、鍵パッケージの受信または鍵パッケージのエラーを保護するときに使用するアルゴリズムの詳細を提供します。
If the client successfully provides a receipt or error, the server response has an HTTP 204 response code (i.e., no content is returned).
クライアントが受信またはエラーを正常に提供した場合、サーバーの応答にはHTTP 204応答コードが含まれます（つまり、コンテンツは返されません）。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定します。
If a key package receipt or key package error is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
鍵パッケージの受領または鍵パッケージのエラーがデジタル署名されている場合、サーバーは、デジタル署名が承認されたTAに対して検証されない場合、それを拒否する必要があります。
Servers can distribute object code for cryptographic algorithms and software with the firmware package [RFC4108].
サーバーは、ファームウェアパッケージ[RFC4108]を使用して、暗号アルゴリズムとソフトウェアのオブジェクトコードを配布できます。
Clients MUST authenticate the server, and clients MUST check the server's authorization.
クライアントはサーバーを認証する必要があり、クライアントはサーバーの承認を確認する必要があります。
The server MUST authenticate the client, and the server MUST check the client's authorization.
サーバーはクライアントを認証しなければならず（MUST）、サーバーはクライアントの承認をチェックしなければなりません（MUST）。
The /firmware PC uses an HTTP GET [RFC7231], and the /firmware/return PC uses an HTTP POST [RFC7231]. GET is used when the client retrieves firmware from the server (see Section 6.1); POST is used when the client provides a receipt (see Section 6.2) or an error (see Section 6.2).
/ firmware PCはHTTP GET [RFC7231]を使用し、/ firmware / return PCはHTTP POST [RFC7231]を使用します。 GETは、クライアントがサーバーからファームウェアを取得するときに使用されます（セクション6.1を参照）。 POSTは、クライアントが領収書（セクション6.2を参照）またはエラー（セクション6.2を参照）を提供するときに使用されます。
The /firmware URI is used by servers to provide firmware packages to clients.
/ firmware URIは、サーバーにファームウェアパッケージをクライアントに提供するために使用されます。
The message flow is as depicted in Figure 3 modulo replacing "Symmetric Key" with "Firmware Package".
メッセージフローは、図3に示すとおりです。「対称キー」を「ファームウェアパッケージ」に置き換えたものです。
Clients request firmware from the server with an HTTP GET [RFC7231], using an operation path of "/firmware".
クライアントは、 "/ firmware"の操作パスを使用して、HTTP GET [RFC7231]でサーバーにファームウェアを要求します。
If the request is successful, the server response MUST have an HTTP 200 response code with a Content-Type of "application/cms" [RFC7193]. The optional encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned firmware. The returned content varies:
リクエストが成功した場合、サーバーの応答には、Content-Typeが「application / cms」であるHTTP 200応答コードが含まれている必要があります[RFC7193]。返されるファームウェアに提供される保護を示すために、オプションのencapsulatingContentおよびinnerContentパラメーターをContent-Typeに含める必要があります（SHOULD）。返されるコンテンツは異なります。
o If the firmware is unprotected, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] firmware package.
o ファームウェアが保護されていない場合、Content-Typeは「application / cms」で、コンテンツはDERエンコードされた[X.690]ファームウェアパッケージです。
o If the firmware is compressed, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] compressed data that encapsulates the firmware package.
o ファームウェアが圧縮されている場合、Content-Typeは「application / cms」で、コンテンツは、ファームウェアパッケージをカプセル化したDERエンコード[X.690]圧縮データです。
o If the firmware is encrypted, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] encrypted-data that encapsulates the firmware package (which might be compressed prior to encryption).
o ファームウェアが暗号化されている場合、Content-Typeは「application / cms」であり、コンテンツはファームウェアパッケージをカプセル化するDERエンコード[X.690]暗号化データです（暗号化前に圧縮されている場合があります）。
o If the firmware is signed, then the Content-Type is "application/cms" and the content is the DER-encoded [X.690] signed-data that encapsulates the firmware package (which might be compressed, encrypted, or compressed and then encrypted prior to signature).
o ファームウェアが署名されている場合、Content-Typeは "application / cms"であり、コンテンツはファームウェアパッケージをカプセル化するDERエンコード[X.690]署名済みデータです（圧縮、暗号化、または圧縮された後、署名前に暗号化されます）。
How the server knows whether the client supports the unprotected, signed, compressed, and/or encrypted firmware package is beyond the scope of this document.
クライアントが保護されていない、署名されている、圧縮されている、または暗号化されているファームウェアパッケージをサポートしているかどうかをサーバーが認識する方法は、このドキュメントの範囲外です。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定します。
If a firmware package is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA.
ファームウェアパッケージがデジタル署名されている場合、デジタル署名が承認されたTAに対して検証されない場合、クライアントはパッケージを拒否する必要があります。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the firmware package.
[RFC3370]、[RFC5753]、および[RFC5754]は、ファームウェアパッケージを保護するときに使用するアルゴリズムの詳細を提供します。
Clients use the /firmware/return PC to provide firmware package load receipts and errors [RFC4108]. Clients can be configured to automatically return receipts and errors after processing a firmware package or based on a PAL entry.
クライアントは/ firmware / return PCを使用して、ファームウェアパッケージのロードの受信とエラーを提供します[RFC4108]。クライアントは、ファームウェアパッケージの処理後、またはPALエントリに基づいて、レシートとエラーを自動的に返すように構成できます。
The message flow is as depicted in Figure 4 modulo the receipt or error is for a firmware package.
メッセージフローは、図4に示すように、受信またはエラーがファームウェアパッケージに対するものであることを法とします。
Clients return firmware receipts and errors to the server with an HTTP POST [RFC7231], using an operation path of "/firmware/return". The optional encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned firmware receipt or error. The returned content varies:
クライアントは、「/ firmware / return」の操作パスを使用して、HTTP POST [RFC7231]でファームウェアの受信とエラーをサーバーに返します。オプションのencapsulatingContentパラメータとinnerContentパラメータをContent-Typeに含めて、返されるファームウェアの受信またはエラーに提供される保護を示す必要があります（SHOULD）。返されるコンテンツは異なります。
o If the firmware receipt is not digitally signed, the Content-Type is "application/cms" [RFC7193] and the content is the DER-encoded firmware receipt.
o ファームウェアの領収書がデジタル署名されていない場合、Content-Typeは "application / cms" [RFC7193]であり、コンテンツはDERエンコードされたファームウェアの領収書です。
o If the firmware receipt is digitally signed, the Content-Type is "application/cms" and the content is the DER-encoded signed-data encapsulating the firmware receipt.
o ファームウェアの領収書がデジタル署名されている場合、Content-Typeは「application / cms」で、コンテンツはファームウェアの領収書をカプセル化したDERエンコードの署名済みデータです。
o If the firmware error is not digitally signed, the Content-Type is "application/cms" and the content is the DER-encoded firmware error.
o ファームウェアエラーがデジタル署名されていない場合、Content-Typeは「application / cms」で、コンテンツはDERエンコードされたファームウェアエラーです。
o If the firmware error is digitally signed, the Content-Type is "application/cms" and the content is the DER-encoded signed-data encapsulating the firmware error.
o ファームウェアエラーがデジタル署名されている場合、Content-Typeは「application / cms」であり、コンテンツは、ファームウェアエラーをカプセル化したDERエンコードの署名済みデータです。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the firmware receipt or firmware error.
[RFC3370]、[RFC5753]、および[RFC5754]は、ファームウェアの受信またはファームウェアのエラーを保護するときに使用するアルゴリズムの詳細を提供します。
If the request is successful, the server response MUST have an HTTP 204 response code (i.e., no content is returned).
リクエストが成功した場合、サーバー応答にはHTTP 204応答コードが必要です（つまり、コンテンツは返されません）。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定する必要があります。
If a firmware receipt or firmware error is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
ファームウェアの領収書またはファームウェアのエラーがデジタル署名されている場合、サーバーは、デジタル署名が承認されたTAに対して検証されない場合、それを拒否する必要があります。
Servers distribute TAMP packages to manage TAs in a client's trust anchor databases; TAMP packages are defined in [RFC5934]. TAMP will allow the flexibility for a device to load TAs while maintaining an operational state. Unlike other systems that require new software loads when new PKI Roots are authorized for use, TAMP allows for automated management of roots for provisioning or replacement as needed.
サーバーはTAMPパッケージを配布して、クライアントのトラストアンカーデータベース内のTAを管理します。 TAMPパッケージは[RFC5934]で定義されています。 TAMPは、デバイスが運用状態を維持しながらTAをロードできる柔軟性を提供します。新しいPKIルートの使用が許可されている場合に新しいソフトウェアのロードを必要とする他のシステムとは異なり、TAMPでは、必要に応じてプロビジョニングまたは置き換えのためにルートの自動管理が可能です。
Clients MUST authenticate the server, and clients MUST check the server's authorization.
クライアントはサーバーを認証する必要があり、クライアントはサーバーの承認を確認する必要があります。
The server MUST authenticate the client, and the server MUST check the client's authorization.
サーバーはクライアントを認証しなければならず（MUST）、サーバーはクライアントの承認をチェックしなければなりません（MUST）。
The /tamp PC uses an HTTP GET [RFC7231], and the tamp/return PC uses an HTTP POST [RFC7231]. GET is used when the server requests that the client retrieve a TAMP package (see Section 7.1); POST is used when the client provides a confirm (see Section 7.2), provides a response (see Section 7.2), or provides an error (see Section 7.2) for the TAMP package.
/ tamp PCはHTTP GET [RFC7231]を使用し、tamp / return PCはHTTP POST [RFC7231]を使用します。 GETは、サーバーがクライアントにTAMPパッケージの取得を要求するときに使用されます（セクション7.1を参照）。 POSTは、クライアントがTAMPパッケージの確認（セクション7.2を参照）、応答（セクション7.2を参照）、またはエラー（セクション7.2を参照）を提供するときに使用されます。
7.1. TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust
7.1. TAMPステータスクエリ、トラストアンカー更新、Apexトラストアンカー更新、コミュニティ更新、シーケンス番号調整
Clients use the /tamp PC to retrieve the TAMP packages: TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust. Clients can be configured to periodically poll the server for these packages or contact the server based on a PAL entry.
クライアントは/ tamp PCを使用してTAMPパッケージを取得します：TAMPステータスクエリ、信頼アンカー更新、Apex信頼アンカー更新、コミュニティ更新、シーケンス番号調整。これらのパッケージについてサーバーを定期的にポーリングするか、PALエントリに基づいてサーバーに接続するようにクライアントを構成できます。
The message flow is as depicted in Figure 3 modulo replacing "Symmetric Key" with the appropriate TAMP message.
メッセージフローは、図3に示すとおりです。「対称キー」を適切なTAMPメッセージに置き換えてモジュロ化します。
Clients request the TAMP packages from the server with an HTTP GET [RFC7231], using an operation path of "/tamp".
クライアントは、 "/ tamp"の操作パスを使用して、HTTP GET [RFC7231]でサーバーにTAMPパッケージを要求します。
If the request is successful, the server response MUST have an HTTP 200 response code and a Content-Type of:
リクエストが成功した場合、サーバーの応答にはHTTP 200応答コードとContent-Typeが含まれている必要があります。
o application/tamp-status-query for TAMP Status Query
o TAMPステータスクエリのapplication / tamp-status-query
o application/tamp-update for Trust Anchor Update
o Trust Anchor Updateのapplication / tamp-update
o application/tamp-apex-update for Apex Trust Anchor Update
o Apex Trust Anchor Updateのapplication / tamp-apex-update
o application/tamp-community-update for Community Update
o コミュニティアップデートのapplication / tamp-community-update
o application/tamp-sequence-adjust for Sequence Number Adjust
o シーケンス番号調整用のapplication / tamp-sequence-adjust
As specified in [RFC5934], these content types are digitally signed and clients must support validating the packages directly signed by TAs. For this specification, clients MUST support validation with a certificate and clients MUST reject it if the digital signature does not validate back to an authorized TA.
[RFC5934]で指定されているように、これらのコンテンツタイプはデジタル署名されており、クライアントはTAによって直接署名されたパッケージの検証をサポートする必要があります。この仕様では、クライアントは証明書による検証をサポートする必要があり、デジタル署名が承認されたTAに対して検証されない場合、クライアントは証明書を拒否する必要があります。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the TAMP packages.
[RFC3370]、[RFC5753]、および[RFC5754]は、TAMPパッケージを保護するときに使用するアルゴリズムの詳細を提供します。
Clients return the TAMP Status Query Response, Trust Anchor Update Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm, Sequence Number Adjust Confirm, and TAMP Error to servers, using the /tamp/return PC. Clients can be configured to automatically return responses, confirms, and errors after processing a TAMP package or based on a PAL entry.
クライアントは、/ tamp / return PCを使用して、TAMPステータスクエリ応答、トラストアンカー更新確認、Apexトラストアンカー更新確認、コミュニティ更新確認、シーケンス番号調整確認、およびTAMPエラーをサーバーに返します。 TAMPパッケージを処理した後、またはPALエントリに基づいて、応答、確認、エラーを自動的に返すようにクライアントを構成できます。
The message flow is as depicted in Figure 4 modulo replacing "Receipt/Error" with the appropriate TAMP response, confirm, or error.
メッセージフローは、図4に示すとおりです。「Receipt / Error」を適切なTAMP応答、確認、またはエラーに置き換えます。
Clients provide the TAMP responses, confirms, and errors to the server with an HTTP POST, using an operation path of "/tamp/return". The Content-Type is:
クライアントは、 "/ tamp / return"の操作パスを使用して、HTTP POSTでサーバーにTAMP応答、確認、およびエラーを提供します。 Content-Typeは次のとおりです。
o application/tamp-status-response for TAMP Status Query Response
o TAMPステータスクエリレスポンスのapplication / tamp-status-response
o application/tamp-update-confirm for Trust Anchor Update Confirm
o Trust Anchor Update Confirmのapplication / tamp-update-confirm
o application/tamp-apex-update-confirm for Apex Trust Anchor Update Confirm
o Apex Trust Anchor Update Confirmのapplication / tamp-apex-update-confirm
o application/tamp-community-update-confirm for Community Update Confirm
o コミュニティ更新確認のapplication / tamp-community-update-confirm
o application/tamp-sequence-adjust-confirm for Sequence Number Adjust Confirm
o シーケンス番号調整確認用のapplication / tamp-sequence-adjust-confirm
o application/tamp-error for TAMP Error
o TAMPエラーのapplication / tamp-error
As specified in [RFC5934], these content types should be signed. If signed, a signed-data encapsulates the TAMP content.
[RFC5934]で指定されているように、これらのコンテンツタイプは署名されている必要があります。署名されている場合、signed-dataはTAMPコンテンツをカプセル化します。
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use when protecting the TAMP packages.
[RFC3370]、[RFC5753]、および[RFC5754]は、TAMPパッケージを保護するときに使用するアルゴリズムの詳細を提供します。
If the request is successful, the server response MUST have an HTTP 204 response code (i.e., no content is returned).
リクエストが成功した場合、サーバー応答にはHTTP 204応答コードが必要です（つまり、コンテンツは返されません）。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定する必要があります。
If the package is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
パッケージがデジタル署名されている場合、サーバーは、デジタル署名が承認されたTAに対して検証されない場合、パッケージを拒否する必要があります。
[RFC7030] defines the /serverkeygen PC to support server-side generation of asymmetric keys. Keys are returned as either a) an unprotected PKCS #8 when additional security beyond TLS is not employed or b) a CMS asymmetric key package content type that is encapsulated in a signed-data content type that is further encapsulated in an enveloped-data content type when additional security beyond TLS is requested.
[RFC7030]は、サーバー側での非対称鍵の生成をサポートする/ serverkeygen PCを定義しています。キーは、a）TLSを超える追加のセキュリティが採用されていない場合の無保護PKCS＃8、またはb）エンベロープデータコンテンツにさらにカプセル化されている署名済みデータコンテンツタイプにカプセル化されているCMS非対称キーパッケージコンテンツタイプのいずれかとして返されます。 TLSを超える追加のセキュリティが要求される場合に入力します。
Some implementations prefer the use of other CMS content types to encapsulate the asymmetric key package. This document extends the content types that can be returned; see Section 8.1.
一部の実装では、非対称キーパッケージをカプセル化するために他のCMSコンテンツタイプの使用を優先します。このドキュメントは、返されるコンテンツタイプを拡張します。セクション8.1を参照してください。
[RFC7191] defines content types for key package receipts and errors. This document defines the /serverkeygen/return PC to add support for returning receipts and errors for asymmetric key packages; see Section 8.2.
[RFC7191]は、主要なパッケージの受領とエラーのコンテンツタイプを定義します。このドキュメントでは/ serverkeygen / return PCを定義して、非対称キーパッケージのレシートとエラーを返すサポートを追加しています。セクション8.2を参照してください。
PKCS #12 [RFC7292] (sometimes referred to as "PFX" (Personal Information Exchange) or "P12") is often used to distribute asymmetric private keys and associated certificates. This document extends the /serverkeygen PC to allow servers to distribute server-generated asymmetric private keys and the associated certificate to clients using PKCS #12; see Section 8.3.
PKCS＃12 [RFC7292]（ "PFX"（Personal Information Exchange）または "P12"と呼ばれることもあります）は、非対称の秘密キーと関連する証明書の配布によく使用されます。このドキュメントは/ serverkeygen PCを拡張して、サーバーがサーバー生成の非対称秘密鍵と関連証明書をPKCS＃12を使用してクライアントに配布できるようにします。セクション8.3を参照してください。
CMS supports a number of content types to encapsulate other CMS content types; [RFC7030] includes one such possibility. Note that when only relying on TLS the returned key is not a CMS content type. This document extends the CMS content types that can be returned.
CMSは、他のCMSコンテンツタイプをカプセル化する多くのコンテンツタイプをサポートしています。 [RFC7030]には、そのような可能性の1つが含まれています。 TLSのみに依存している場合、返されるキーはCMSコンテンツタイプではないことに注意してください。このドキュメントは、返されるCMSコンテンツタイプを拡張します。
If the client supports CCC [RFC6010], then the client can indicate that it supports encapsulated asymmetric keys in the encrypted key package [RFC5958] by including the encrypted key package's OID in a content type attribute [RFC2985] in the CSR (Certificate Signing Request) -- aka the certification request -- that it provides to the server. If the client knows a priori that the server supports the encrypted key package content type, then the client need not include the content type attribute in the CSR.
クライアントがCCC [RFC6010]をサポートしている場合、クライアントは、CSR（証明書署名要求）のコンテンツタイプ属性[RFC2985]に暗号化キーパッケージのOIDを含めることにより、暗号化キーパッケージ[RFC5958]でカプセル化された非対称キーをサポートすることを示すことができます。 ）-別名認証要求-サーバーに提供します。クライアントが、サーバーが暗号化されたキーパッケージのコンテンツタイプをサポートすることを事前に知っている場合、クライアントはCSRにコンテンツタイプ属性を含める必要はありません。
In all instances defined herein, the Content-Type is "application/cms" [RFC7193]. The optional encapsulatingContent and innerContent parameters SHOULD be included with the Content-Type to indicate the protection afforded to the returned asymmetric key package.
ここで定義されているすべてのインスタンスで、Content-Typeは「application / cms」[RFC7193]です。返される非対称鍵パッケージに提供される保護を示すために、オプションのencapsulatingContentおよびinnerContentパラメーターをContent-Typeに含める必要があります（SHOULD）。
If additional encryption and origin authentication are employed, the content associated with application/cms is a DER-encoded signed-data that encapsulates an enveloped-data that encapsulates a signed-data that further encapsulates an asymmetric key package.
追加の暗号化とオリジン認証が採用されている場合、application / cmsに関連付けられたコンテンツは、非対称鍵パッケージをさらにカプセル化する署名データをカプセル化するエンベロープデータをカプセル化するDERエンコードの署名データです。
If CCC is supported and additional encryption is employed, the content associated with application/cms is a DER-encoded encrypted key package [RFC6032] content type that encapsulates a signed-data that further encapsulates an asymmetric key package.
CCCがサポートされ、追加の暗号化が採用されている場合、application / cmsに関連付けられたコンテンツは、非対称暗号化パッケージをさらにカプセル化する署名データをカプセル化するDERエンコード暗号化鍵パッケージ[RFC6032]コンテンツタイプです。
If CCC is supported and if additional encryption and additional origin authentication are employed, the content associated with application/cms is a DER-encoded signed-data that encapsulates an encrypted key package content type that encapsulates a signed-data that further encapsulates an asymmetric key package.
CCCがサポートされており、追加の暗号化と追加のオリジン認証が採用されている場合、application / cmsに関連付けられたコンテンツは、非対称キーをさらにカプセル化する署名データをカプセル化する暗号化キーパッケージのコンテンツタイプをカプセル化するDERエンコードの署名データです。パッケージ。
The encrypted key package [RFC6032] provides three choices to encapsulate keys: EncryptedData, EnvelopedData, and AuthEnvelopedData, with EnvelopedData being the mandatory-to-implement choice.
暗号化されたキーパッケージ[RFC6032]は、キーをカプセル化するための3つの選択肢を提供します。EncryptedData、EnvelopedData、AuthEnvelopedDataで、EnvelopedDataが実装に必須の選択肢です。
When rejecting a request, the server specifies either an HTTP 4xx error or an HTTP 5xx error.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定します。
If an asymmetric key package or an encrypted key package is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA.
非対称キーパッケージまたは暗号化キーパッケージがデジタル署名されている場合、デジタル署名が承認されたTAに対して検証されない場合、クライアントはそれを拒否する必要があります。
Note: Absent a policy on the client side requiring a signature, a malicious EST server can simply strip the signature, thus bypassing that check. In that case, this requirement is merely a sanity check, serving to detect mis-signed packages or misconfigured clients.
注：署名を必要とするクライアント側のポリシーがない場合、悪意のあるESTサーバーは単に署名を取り除き、そのチェックをバイパスできます。その場合、この要件は単なるサニティチェックであり、署名が間違っているパッケージや設定が間違っているクライアントを検出するのに役立ちます。
[RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6161], and [RFC6162] provide algorithm details for use when protecting the asymmetric key package and encrypted key package.
[RFC3370]、[RFC5753]、[RFC5754]、[RFC6033]、[RFC6161]、および[RFC6162]は、非対称キーパッケージと暗号化キーパッケージを保護するときに使用するアルゴリズムの詳細を提供します。
Clients can be configured to automatically return receipts after processing an asymmetric key package, return receipts based on processing of the key-package-identifier-and-receipt-request attribute [RFC7191], or return receipts when prompted by a PAL entry. Servers can indicate that clients return a receipt by including the key-package-identifier-and-receipt-request attribute [RFC7191] in a signed-data as a signed attribute.
クライアントは、非対称キーパッケージの処理後に自動的にレシートを返す、key-package-identifier-and-receipt-request属性[RFC7191]の処理に基づいてレシートを返す、またはPALエントリによってプロンプトが表示されたときにレシートを返すように構成できます。サーバーは、signed-dataにkey-package-identifier-and-receipt-request属性[RFC7191]を署名済み属性として含めることにより、クライアントが受領書を返すことを示すことができます。
The protocol flow is identical to that depicted in Figure 4 modulo the receipt or error is for asymmetric keys.
プロトコルフローは、図4に示したものと同じですが、受信またはエラーは非対称キー用です。
The server and client processing is as described in Sections 5.2.1 and 5.2.2 modulo the PC, which, for Asymmetric Key Packages, is "/serverkeygen/return".
サーバーとクライアントの処理は、セクション5.2.1と5.2.2で説明されているように、非対称鍵パッケージの場合、「/ serverkeygen / return」であるPCを法とします。
PFX is widely deployed and supports protecting keys in the same fashion as CMS, but it does so differently.
PFXは広く展開されており、CMSと同じ方法でキーの保護をサポートしていますが、その方法は異なります。
Similar to the other server-generated asymmetric keys provided through the /serverkeygen PC:
/ serverkeygen PCを通じて提供される他のサーバー生成非対称鍵と同様：
o The certificate request is HTTPS POSTed and is the same format as for the "/simpleenroll" and "/simplereenroll" path extensions with the same content type.
o 証明書要求はHTTPS POSTされ、同じコンテンツタイプの「/ simpleenroll」および「/ simplereenroll」パス拡張と同じ形式です。
o In all respects, the server SHOULD treat the CSR as it would any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow the reuse of existing codebases for generating and parsing such requests.
o すべての点で、サーバーはCSRを登録または再登録する場合と同じようにCSRを処理する必要があります。ここでの唯一の違いは、サーバーがCSRの公開鍵の値と署名を無視する必要があることです。これらは、既存のコードベースを再利用してこのようなリクエストを生成および解析できるようにするためにのみリクエストに含まれています。
PBE (password-based encryption) shrouding of PKCS #12 is supported, and this specification makes no attempt to alter this de facto standard. As such, there is no support of the DecryptKeyIdentifier specified in [RFC7030] for use with PKCS #12 (i.e., "enveloping" is not supported). Note: The use of PBE requires that the password be distributed to the client; methods to distribute this password are beyond the scope of this document.
PKCS＃12のPBE（パスワードベースの暗号化）シュラウドがサポートされており、この仕様では、この事実上の標準を変更することはありません。そのため、PKCS＃12で使用するための[RFC7030]で指定されたDecryptKeyIdentifierのサポートはありません（つまり、「エンベロープ」はサポートされていません）。注：PBEを使用するには、パスワードをクライアントに配布する必要があります。このパスワードを配布する方法は、このドキュメントの範囲外です。
If the request is successful, the server response MUST have an HTTP 200 response code with a Content-Type of "application/pkcs12" [PKCS12] that consists of a base64-encoded DER-encoded [X.690] PFX [RFC7292].
リクエストが成功した場合、サーバーの応答には、base64でエンコードされたDERでエンコードされた[X.690] PFX [RFC7292]で構成される "application / pkcs12" [PKCS12]のContent-Typeを持つHTTP 200レスポンスコードが含まれている必要があります。
Note that this response is different than the response returned as described in Section 4.4.2 of [RFC7030], because here the private key and the certificate are included in the same PFX.
この応答は、[RFC7030]のセクション4.4.2で説明されているように返される応答とは異なります。ここでは、秘密鍵と証明書が同じPFXに含まれているためです。
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error. The response data's Content-Type MAY be "text/plain" [RFC2046] to convey human-readable error messages.
リクエストを拒否する場合、サーバーはHTTP 4xxエラーまたはHTTP 5xxエラーを指定する必要があります。人間が読めるエラーメッセージを伝えるために、応答データのContent-Typeは「text / plain」[RFC2046]である場合があります。
The /fullcmc PC is defined in [RFC7030]; the CMC (Certificate Management over Cryptographic Message Syntax) requirements and packages are defined in [RFC5272], [RFC5273], [RFC5274], and [RFC6402]. This section describes PAL interactions.
/ fullcmc PCは[RFC7030]で定義されています。 CMC（Cryptographic Management over Cryptographic Message Syntax）の要件とパッケージは、[RFC5272]、[RFC5273]、[RFC5274]、および[RFC6402]で定義されています。このセクションでは、PALの相互作用について説明します。
Under normal circumstances, the client-server interactions for PKI enrollment are as follows:
通常の状況では、PKI登録のクライアント/サーバーの相互作用は次のとおりです。
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
If the response is rejected during the same session:
同じセッション中に応答が拒否された場合：
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: empty
HTTPS Status Code
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
If the request is to be filled later:
リクエストが後で満たされる場合：
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: empty
HTTPS Status Code
+ Retry-After
or
POST res: PKIResponse (pending)
Content-Type: application/pkcs7-mime
smime-type=CMC-response
--------------------->
POST req: PKIRequest (same request)
Content-Type: application/pkcs10
or
POST req: PKIRequest (CMC Status Info only)
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
With the PAL, the client begins after pulling the PAL and a Start Issuance PAL package type, essentially adding the following before the request:
PALを使用すると、クライアントはPALおよびStart Issuance PALパッケージタイプをプルした後に開始し、基本的にリクエストの前に以下を追加します。
Client Server
--------------------->
GET req: PAL
<--------------------
GET res: PAL
Content-Type: application/xml
The client then proceeds as above with a simple PKI enrollment or a full CMC enrollment, or it begins enrollment assisted by a CSR:
次に、クライアントは上記のように単純なPKI登録または完全なCMC登録を使用して続行するか、CSRの支援を受けて登録を開始します。
Client Server
--------------------->
GET req: DS certificate with CSR
<--------------------
GET res: PAL
Content-Type: application/csrattrs
For immediately rejected requests, CMC works well. If the server prematurely closes the connection, then the procedures in Section 6.3.1 of [RFC7230] apply. But this might leave the client and server in a different state. The client could merely resubmit the request, but another option, documented herein, is for the client to instead download the PAL to see if the server has processed the request. Clients might also use this process when they are unable to remain connected to the server for the entire enrollment process; if the server does not or is not able to return a PKIData indicating a status of pending, then the client will not know whether the request was received. If a client uses the PAL and reconnects to determine if the certification or rekey or renew request was processed:
すぐに拒否された要求の場合、CMCは適切に機能します。サーバーが途中で接続を閉じると、[RFC7230]のセクション6.3.1の手順が適用されます。ただし、これにより、クライアントとサーバーが異なる状態になる可能性があります。クライアントは単に要求を再送信することができますが、ここに記載されている別のオプションは、クライアントが代わりにPALをダウンロードして、サーバーが要求を処理したかどうかを確認することです。クライアントは、登録プロセス全体を通じてサーバーに接続したままにできない場合にも、このプロセスを使用できます。サーバーが保留中の状態を示すPKIDataを返さない、または返すことができない場合、クライアントは要求が受信されたかどうかを認識しません。クライアントがPALを使用して再接続し、認証、キー更新、または更新要求が処理されたかどうかを判断する場合：
o Clients MUST authenticate the server, and clients MUST check the server's authorization.
o クライアントはサーバーを認証する必要があり、クライアントはサーバーの承認を確認する必要があります。
o The server MUST authenticate the client, and the server MUST check the client's authorization.
o サーバーはクライアントを認証しなければならず（MUST）、サーバーはクライアントの承認をチェックしなければなりません（MUST）。
o Clients retrieve the PAL, using the /pal URI.
o クライアントは、/ pal URIを使用してPALを取得します。
o Clients and servers use the operation path of "/simpleenroll", "simplereenroll", or "/fullcmc", based on the PAL entry, with an HTTP GET [RFC7231] to get the success or failure response.
o クライアントとサーバーは、PALエントリに基づいて、 "/ simpleenroll"、 "simplereenroll"、または "/ fullcmc"の操作パスを使用して、HTTP GET [RFC7231]で成功または失敗の応答を取得します。
Responses are as specified in [RFC7030].
応答は[RFC7030]で指定されているとおりです。
This document relies on many other specifications; however, all of the security considerations in [RFC7030] apply. Refer also to the following:
このドキュメントは他の多くの仕様に依存しています。ただし、[RFC7030]のセキュリティに関する考慮事項はすべて適用されます。以下も参照してください。
o For HTTP, HTTPS, and TLS security considerations, see [RFC7231], [RFC2818], and [RFC5246].
o HTTP、HTTPS、およびTLSのセキュリティの考慮事項については、[RFC7231]、[RFC2818]、および[RFC5246]を参照してください。
o For URI security considerations, see [RFC3986].
o URIセキュリティの考慮事項については、[RFC3986]を参照してください。
o For content type security considerations, see [RFC4073], [RFC4108], [RFC5272], [RFC5652], [RFC5751], [RFC5934], [RFC5958], [RFC6031], [RFC6032], [RFC6268], [RFC6402], [RFC7191], and [RFC7292].
o コンテンツタイプのセキュリティに関する考慮事項については、[RFC4073]、[RFC4108]、[RFC5272]、[RFC5652]、[RFC5751]、[RFC5934]、[RFC5958]、[RFC6031]、[RFC6032]、[RFC6268]、[RFC6402]を参照してください、[RFC7191]、および[RFC7292]。
o For algorithms used to protect packages, see [RFC3370], [RFC5649], [RFC5753], [RFC5754], [RFC5959], [RFC6033], [RFC6160], [RFC6161], [RFC6162], and [RFC7192].
o パッケージの保護に使用されるアルゴリズムについては、[RFC3370]、[RFC5649]、[RFC5753]、[RFC5754]、[RFC5959]、[RFC6033]、[RFC6160]、[RFC6161]、[RFC6162]、および[RFC7192]を参照してください。
o For random numbers, see [RFC4086].
o 乱数については、[RFC4086]を参照してください。
o For server-generated asymmetric key pairs, see [RFC7030].
o サーバー生成の非対称鍵ペアについては、[RFC7030]を参照してください。
IANA has created the "PAL Package Types" registry and performed three registrations: PAL Name Space, PAL XML Schema, and PAL Package Types.
IANAは「PALパッケージタイプ」レジストリを作成し、PAL名前空間、PAL XMLスキーマ、およびPALパッケージタイプの3つの登録を実行しました。
This section registers a new XML namespace [XMLNS], "urn:ietf:params:xml:ns:pal", per the guidelines in [RFC3688]:
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間[XMLNS]、「urn：ietf：params：xml：ns：pal」を登録します。
URI: urn:ietf:params:xml:ns:pal
Registrant Contact: Sean Turner (sean@sn3rd.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Package Availability List</title>
</head>
<body>
<h1>Namespace for Package Availability List</h1>
<h2>urn:ietf:params:xml:ns:pal</h2>
<p>See RFC 8295</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:pal Registrant Contact: Sean Turner (sean@sn3rd.com) XML: See Section 2.1.2.
URI：urn：ietf：params：xml：schema：pal登録者の連絡先：Sean Turner（sean@sn3rd.com）XML：セクション2.1.2を参照してください。
IANA has created a new registry named "PAL Package Types". This registry is for PAL package types whose initial values are found in Section 2.1.1. Future registrations of PAL package types are subject to Expert Review, as defined in RFC 8126 [RFC8126]. Package types MUST be paired with a media type; package types specify the path components to be used that in turn specify the media type used.
IANAは、「PALパッケージタイプ」という名前の新しいレジストリを作成しました。このレジストリは、初期値がセクション2.1.1にあるPALパッケージタイプ用です。 PALパッケージタイプの将来の登録は、RFC 8126 [RFC8126]で定義されているように、エキスパートレビューの対象となります。パッケージタイプはメディアタイプとペアにする必要があります。パッケージタイプは、使用するパスコンポーネントを指定し、次に使用するメディアタイプを指定します。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https://www.rfc-editor.org / info / rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585] Housley、R。およびP. Hoffman、「Internet X.509 Public Key Infrastructure Operational Protocols：FTP and HTTP」、RFC 2585、DOI 10.17487 / RFC2585、1999年5月、<https：//www.rfc-editor。 org / info / rfc2585>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>.
[RFC2985] Nystrom、M。およびB. Kaliski、「PKCS＃9：Selected Object Classes and Attribute Types Version 2.0」、RFC 2985、DOI 10.17487 / RFC2985、2000年11月、<https://www.rfc-editor.org / info / rfc2985>。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, <https://www.rfc-editor.org/info/rfc3370>.
[RFC3370] Housley、R。、「Cryptographic Message Syntax（CMS）Algorithms」、RFC 3370、DOI 10.17487 / RFC3370、2002年8月、<https://www.rfc-editor.org/info/rfc3370>。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC3394] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、DOI 10.17487 / RFC3394、2002年9月、<https://www.rfc-editor.org/info/ rfc3394>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, DOI 10.17487/RFC4073, May 2005, <https://www.rfc-editor.org/info/rfc4073>.
[RFC4073] Housley、R。、「暗号化メッセージ構文（CMS）による複数のコンテンツの保護」、RFC 4073、DOI 10.17487 / RFC4073、2005年5月、<https://www.rfc-editor.org/info/rfc4073> 。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/info/rfc4108>.
[RFC4108] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、DOI 10.17487 / RFC4108、2005年8月、<https://www.rfc-editor.org/info/rfc4108> 。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, <https://www.rfc-editor.org/info/rfc4514>.
[RFC4514] Zeilenga、K。、編、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現」、RFC 4514、DOI 10.17487 / RFC4514、2006年6月、<https://www.rfc-editor.org / info / rfc4514>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/info/rfc5272>.
[RFC5272] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理」、RFC 5272、DOI 10.17487 / RFC5272、2008年6月、<https://www.rfc-editor.org/info/rfc5272> 。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, <https://www.rfc-editor.org/info/rfc5273>.
[RFC5273] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理：トランスポートプロトコル」、RFC 5273、DOI 10.17487 / RFC5273、2008年6月、<https://www.rfc-editor.org/info / rfc5273>。
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008, <https://www.rfc-editor.org/info/rfc5274>.
[RFC5274] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理メッセージ：コンプライアンス要件」、RFC 5274、DOI 10.17487 / RFC5274、2008年6月、<https://www.rfc-editor.org/ info / rfc5274>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-editor.org/info/rfc5649>.
[RFC5649] Housley、R.、M。Dworkin、「Advanced Encryption Standard（AES）Key Wrap with Padding Algorithm」、RFC 5649、DOI 10.17487 / RFC5649、2009年9月、<https://www.rfc-editor.org/ info / rfc5649>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<https：//www.rfc- editor.org/info/rfc5751>。
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5753]ターナーS.およびD.ブラウン、「Cryptographic Message Syntax（CMS）での楕円曲線暗号（ECC）アルゴリズムの使用」、RFC 5753、DOI 10.17487 / RFC5753、2010年1月、<https：//www.rfc -editor.org/info/rfc5753>。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、DOI 10.17487 / RFC5754、2010年1月、<https://www.rfc-editor.org/info/rfc5754>。
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, DOI 10.17487/RFC5934, August 2010, <https://www.rfc-editor.org/info/rfc5934>.
[RFC5934] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Management Protocol（TAMP）」、RFC 5934、DOI 10.17487 / RFC5934、2010年8月、<https：//www.rfc-editor。 org / info / rfc5934>。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、DOI 10.17487 / RFC5958、2010年8月、<https://www.rfc-editor.org/info/rfc5958>。
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, DOI 10.17487/RFC5959, August 2010, <https://www.rfc-editor.org/info/rfc5959>.
[RFC5959] Turner、S。、「Algorithms for Asymmetric Key Package Content Type」、RFC 5959、DOI 10.17487 / RFC5959、2010年8月、<https://www.rfc-editor.org/info/rfc5959>。
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010, <https://www.rfc-editor.org/info/rfc5967>.
[RFC5967] Turner、S。、「The application / pkcs10 Media Type」、RFC 5967、DOI 10.17487 / RFC5967、2010年8月、<https://www.rfc-editor.org/info/rfc5967>。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, DOI 10.17487/RFC6010, September 2010, <https://www.rfc-editor.org/info/rfc6010>.
[RFC6010] Housley、R.、Ashmore、S。、およびC. Wallace、「暗号化メッセージ構文（CMS）コンテンツ制約拡張」、RFC 6010、DOI 10.17487 / RFC6010、2010年9月、<https：//www.rfc- editor.org/info/rfc6010>。
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, DOI 10.17487/RFC6031, December 2010, <https://www.rfc-editor.org/info/rfc6031>.
[RFC6031]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Symmetric Key Package Content Type」、RFC 6031、DOI 10.17487 / RFC6031、2010年12月、<https://www.rfc-editor.org/ info / rfc6031>。
[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6032, DOI 10.17487/RFC6032, December 2010, <https://www.rfc-editor.org/info/rfc6032>.
[RFC6032]ターナー、S。およびR.ハウズリー、「Cryptographic Message Syntax（CMS）Encrypted Key Package Content Type」、RFC 6032、DOI 10.17487 / RFC6032、2010年12月、<https://www.rfc-editor.org/ info / rfc6032>。
[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6033, DOI 10.17487/RFC6033, December 2010, <https://www.rfc-editor.org/info/rfc6033>.
[RFC6033] Turner、S。、「Cryptographic Message Syntax（CMS）Encrypted Key Package Content Type」のアルゴリズム、RFC 6033、DOI 10.17487 / RFC6033、2010年12月、<https://www.rfc-editor.org/info/ rfc6033>。
[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types", RFC 6160, DOI 10.17487/RFC6160, April 2011, <https://www.rfc-editor.org/info/rfc6160>.
[RFC6160]ターナー、S。、「対称キーパッケージコンテンツタイプの暗号化メッセージ構文（CMS）保護のアルゴリズム」、RFC 6160、DOI 10.17487 / RFC6160、2011年4月、<https://www.rfc-editor.org/ info / rfc6160>。
[RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type", RFC 6161, DOI 10.17487/RFC6161, April 2011, <https://www.rfc-editor.org/info/rfc6161>.
[RFC6161]ターナー、S。、「暗号化メッセージ構文（CMS）暗号化キーパッケージコンテンツタイプの楕円曲線アルゴリズム」、RFC 6161、DOI 10.17487 / RFC6161、2011年4月、<https://www.rfc-editor.org/ info / rfc6161>。
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type", RFC 6162, DOI 10.17487/RFC6162, April 2011, <https://www.rfc-editor.org/info/rfc6162>.
[RFC6162]ターナー、S。、「暗号メッセージ構文（CMS）非対称鍵パッケージコンテンツタイプの楕円曲線アルゴリズム」、RFC 6162、DOI 10.17487 / RFC6162、2011年4月、<https://www.rfc-editor.org/ info / rfc6162>。
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268] Schaad、J。およびS. Turner、「暗号化メッセージ構文（CMS）およびX.509（PKIX）を使用する公開鍵インフラストラクチャのための追加の新しいASN.1モジュール」、RFC 6268、DOI 10.17487 / RFC6268、7月2011、<https://www.rfc-editor.org/info/rfc6268>。
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, <https://www.rfc-editor.org/info/rfc6402>.
[RFC6402] Schaad、J。、「CMS（CMC）更新による証明書管理」、RFC 6402、DOI 10.17487 / RFC6402、2011年11月、<https://www.rfc-editor.org/info/rfc6402>。
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030] Pritikin、M。、編、Yee、P。、編、およびD. Harkins、編、「Enrollment over Secure Transport」、RFC 7030、DOI 10.17487 / RFC7030、2013年10月、<https：// www.rfc-editor.org/info/rfc7030>。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.
[RFC7303] Thompson、H。およびC. Lilley、「XML Media Types」、RFC 7303、DOI 10.17487 / RFC7303、2014年7月、<https://www.rfc-editor.org/info/rfc7303>。
[RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7191, DOI 10.17487/RFC7191, April 2014, <https://www.rfc-editor.org/info/rfc7191>.
[RFC7191] Housley、R。、「Cryptographic Message Syntax（CMS）Key Package Receipt and Error Content Types」、RFC 7191、DOI 10.17487 / RFC7191、2014年4月、<https://www.rfc-editor.org/info/ rfc7191>。
[RFC7192] Turner, S., "Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types", RFC 7192, DOI 10.17487/RFC7192, April 2014, <https://www.rfc-editor.org/info/rfc7192>.
[RFC7192]ターナー、S。、「暗号化メッセージ構文（CMS）鍵パッケージの受信とエラーコンテンツタイプのアルゴリズム」、RFC 7192、DOI 10.17487 / RFC7192、2014年4月、<https://www.rfc-editor.org/ info / rfc7192>。
[RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/cms Media Type", RFC 7193, DOI 10.17487/RFC7193, April 2014, <https://www.rfc-editor.org/info/rfc7193>.
[RFC7193]ターナー、S.、Housley、R。、およびJ. Schaad、「The application / cms Media Type」、RFC 7193、DOI 10.17487 / RFC7193、2014年4月、<https://www.rfc-editor.org / info / rfc7193>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<https：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content"、RFC 7231、DOI 10.17487 / RFC7231、June 2014、<https：// www.rfc-editor.org/info/rfc7231>。
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.
[RFC7292] Moriarty、K。、編、Nystrom、M.、Parkinson、S.、Rusch、A。、およびM. Scott、「PKCS＃12：Personal Information Exchange Syntax v1.1」、RFC 7292、DOI 10.17487 / RFC7292、2014年7月、<https://www.rfc-editor.org/info/rfc7292>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、World Wide Web Consortium Recommendation REC -xml-20081126、2008年11月、<https://www.w3.org/TR/2008/REC-xml-20081126/>。
[XMLSCHEMA] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XMLSCHEMA] Malhotra、A。およびP. Biron、「XML Schema Part 2：Datatypes Second Edition」、World Wide Web Consortium Recommendation REC-xmlschema-2-20041028、2004年10月、<https://www.w3.org/ TR / 2004 / REC-xmlschema-2-20041028>。
[X.690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.
[X.690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690 、ISO / IEC 8825-1、2015年8月、<https://www.itu.int/rec/T-REC-X.690/en>。
[PKCS12] IANA, "PKCS #12", <https://www.iana.org/assignments/ media-types/application/pkcs12>.
[PKCS12] IANA、「PKCS＃12」、<https://www.iana.org/assignments/ media-types / application / pkcs12>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<https://www.rfc-editor.org/info/rfc4949>。
[XMLNS] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208/, December 2009, <https://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[XMLNS] Bray、T.、Hollander、D.、Layman、A.、Tobin、R。、およびH. Thompson、「Namespaces in XML 1.0（Third Edition）」、World Wide Web Consortium Recommendation REC-xml-names- 20091208 /、2009年12月、<https://www.w3.org/TR/2009/REC-xml-names-20091208/>。
This is an informative appendix. It includes examples of protocol flows.
これは有益な付録です。プロトコルフローの例が含まれています。
Steps for using a PAL include the following:
PALを使用する手順は次のとおりです。
1. Access PAL
1. PALにアクセスする
2. Process PAL entries 2.1. Get CA certificates 2.2. Get CRLs 2.3. Get CSR attributes 2.4. Enroll: simple enrollment, re-enrollment, or full CMC 2.5. Get Firmware, TAMP, Symmetric Keys, or EE certificates
2. PALエントリの処理2.1。 CA証明書2.2を取得します。 CRL 2.3を取得します。 CSR属性を取得する2.4。登録：単純な登録、再登録、または完全なCMC 2.5。ファームウェア、TAMP、対称鍵、またはEE証明書を取得する
Client Server
---------------------> -+
GET req: | /pal
<--------------------- |
GET res: PAL |
Content-Type: application/xml |
|
---------------------> -+
GET req: | /cacerts
<--------------------- |
GET res: CA Certificates |
Content-Type: application/pkcs7-smime |
smime-type=certs-only |
|
---------------------> -+
GET req: | /crls
<--------------------- |
GET res: CRLs |
Content-Type: application/pkcs7-smime |
smime-type=crls-only |
|
---------------------> -+
GET req: | /csrattrs
<--------------------- |
GET res: attributes |
---------------------> -+
POST req: PKIRequest | /simpleenroll and
Content-Type: application/pkcs10 | /simplereenroll
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-request |
|
<-------------------- |
(success or failure) |
POST res: PKIResponse | /simpleenroll
Content-Type: application/pkcs7-mime | /simplereenroll
smime-type=certs-only | /fullcmc
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-response |
|
--------------------> -+
GET req: | /firmware
<-------------------- | /tamp
GET res: Firmware, TAMP Query | /symmetrickeys
+ Updates, Symmetric Keys |
Content-Type: application/cms |
|
---------------------> -+
POST res: Firmware Receipts or Errors, | /firmware/return
TAMP Response or Confirms or Errors, | /tamp/return
Symmetric Key Receipts or Errors | /symmetrickeys/
| return
|
Content-Type: application/cms |
<-------------------- |
POST res: empty |
(success or failure) |
--------------------> -+
GET req: | /eecerts
<-------------------- |
GET res: Other EE certificates |
Content-Type: application/pkcs7-mime |
smime-type=certs-only |
The figure above shows /eecerts after /*/return, but this is for illustrative purposes only.
上の図は、/ * / returnの後に/ eecertsを示していますが、これは説明のみを目的としています。
This is an informative appendix.
これは有益な付録です。
In some cases, the client is severely limited in its ability to encode and decode ASN.1 objects. If the client knows that a "csr" template is being provided during enrollment, then it can peel the returned CSR attribute, generate its keys, place the public key in the certification request, and then sign the request. To accomplish this, the server returns a pKCS7PDU attribute [RFC2985] in the /csrattrs (the following is "pseudo ASN.1" and is only meant to show the fields needed to accomplish returning a template certification request):
場合によっては、クライアントはASN.1オブジェクトをエンコードおよびデコードする機能が大幅に制限されます。登録時に「csr」テンプレートが提供されていることをクライアントが知っている場合、クライアントは返されたCSR属性をはがし、そのキーを生成し、公開キーを認証リクエストに配置して、リクエストに署名できます。これを達成するために、サーバーは/ csrattrsでpKCS7PDU属性[RFC2985]を返します（以下は「疑似ASN.1」であり、テンプレート認証要求を返すために必要なフィールドを示すことのみを目的としています）。
pKCS7PDU ATTRIBUTE ::= {
WITH SYNTAX ContentInfo
ID pkcs-9-at-pkcs7PDU
}
pkcs-9-at-pkcs7PDU OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
pkcs-9-at(25) 5
}
The ContentInfo is a PKIData:
ContentInfoはPKIDataです。
PKIData ::= SEQUENCE {
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest
}
Where TaggedRequest is a choice between the PKCS #10 or Certificate Request Message Format (CRMF) requests.
ここで、TaggedRequestは、PKCS＃10または証明書要求メッセージ形式（CRMF）要求の間の選択です。
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
}
Or, the ContentInfo can be a signed-data content type that further encapsulates a PKIData.
または、ContentInfoは、PKIDataをさらにカプセル化する署名付きデータコンテンツタイプにすることもできます。
Acknowledgements
謝辞
Thanks in no particular order go to Alexey Melnikov, Paul Hoffman, Brad McInnis, Max Pritikin, Francois Rousseau, Chris Bonatti, and Russ Housley for taking time to provide comments.
コメントを提供するために時間を割いてくださったAlexey Melnikov、Paul Hoffman、Brad McInnis、Max Pritikin、Francois Rousseau、Chris Bonatti、およびRuss Housleyに特に順不同で感謝します。
Author's Address
著者のアドレス
Sean Turner sn3rd
ショーンターナーsn3rd
Email: sean@sn3rd.com