Internet Engineering Task Force (IETF) H. Brockhaus
Request for Comments: 9811 D. von Oheimb
Obsoletes: 6712, 9480 Siemens
Category: Standards Track M. Ounsworth
ISSN: 2070-1721 J. Gray
Entrust
July 2025
This document describes how to layer the Certificate Management Protocol (CMP) over HTTP.
このドキュメントでは、HTTPを介して証明書管理プロトコル（CMP）を階層化する方法について説明します。
It includes the updates to RFC 6712 specified in Section 3 of RFC 9480; these updates introduce CMP URIs using a well-known prefix. It obsoletes RFC 6712; and, together with RFC 9810, it also obsoletes RFC 9480.
これには、RFC 9480のセクション3で指定されたRFC 6712の更新が含まれています。これらの更新は、よく知られているプレフィックスを使用してCMP URIを導入します。RFC 6712が廃止されました。また、RFC 9810とともに、RFC 9480も廃止されます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9811.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9811で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Changes Made by RFC 9480
1.2. Changes Made by This Document
2. Conventions Used in This Document
3. HTTP-Based Protocol
3.1. General Form
3.2. Media Type
3.3. Communication Workflow
3.4. HTTP Request-URI
3.5. Pushing of Announcements
4. Implementation Considerations
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
The Certificate Management Protocol (CMP) [RFC9810] requires a well-defined transfer mechanism to enable End Entities (EEs), Registration Authorities (RAs), and Certification Authorities (CAs) to pass PKIMessage structures between them.
証明書管理プロトコル（CMP）[RFC9810]では、最終エンティティ（EE）、登録当局（RA）、および認定機関（CAS）を可能にするために明確に定義された転送メカニズムが必要です。
The first version of the CMP specification [RFC2510] included a brief description of a simple transfer protocol layer on top of TCP. Its features were simple transfer-level error handling and a mechanism to poll for outstanding PKI messages. Additionally, it was mentioned that PKI messages could also be conveyed using file-, email-, and HTTP-based transfer, but those were not specified in detail.
CMP仕様[RFC2510]の最初のバージョンには、TCPの上に単純な転送プロトコル層の簡単な説明が含まれていました。その機能は、単純な転送レベルのエラー処理と、優れたPKIメッセージの投票メカニズムでした。さらに、PKIメッセージは、ファイル、電子メール、およびHTTPベースの転送を使用して伝達できることも言及されていますが、それらは詳細に指定されていません。
Since the second version of the CMP specification [RFC4210] incorporated its own polling mechanism, the need for a transfer protocol providing this functionality vanished. The remaining features CMP requires from its transfer protocols are connection and error handling.
CMP仕様[RFC4210]の2番目のバージョンは独自のポーリングメカニズムを組み込んだため、この機能を提供する転送プロトコルの必要性は消滅しました。CMPがその転送プロトコルから必要とする残りの機能は、接続とエラー処理です。
CMP can benefit from utilizing reliable transport, as it requires connection and error handling from the transfer protocol. All these features are covered by HTTP. Additionally, delayed delivery of CMP response messages may be handled at transfer level, regardless of the message contents. Since [RFC9480] extends the polling mechanism specified in the second version of CMP [RFC4210] to cover all types of PKI management transactions, delays detected at application level may also be handled within CMP, using pollReq and pollRep messages.
CMPは、転送プロトコルからの接続とエラー処理が必要であるため、信頼できる輸送を利用することで利益を得ることができます。これらすべての機能は、HTTPでカバーされています。さらに、メッセージの内容に関係なく、CMP応答メッセージの配信の遅延は、転送レベルで処理される場合があります。[RFC9480]は、CMP [RFC4210]の2番目のバージョンで指定されたポーリングメカニズムを拡張して、あらゆる種類のPKI管理トランザクションをカバーするため、アプリケーションレベルで検出された遅延は、PollreqおよびPollrepメッセージを使用してCMP内で処理することもできます。
The usage of HTTP (e.g., HTTP/1.1 as specified in [RFC9110] and [RFC9112]) for transferring CMP messages exclusively uses the POST method for requests, effectively tunneling CMP over HTTP. While this is generally considered bad practice (see RFC 9205 [BCP56] for best current practice on building protocols with HTTP) and should not be emulated, there are good reasons to do so for transferring CMP. HTTP is used as it is generally easy to implement and it is able to traverse network borders utilizing ubiquitous proxies. Most importantly, HTTP is already commonly used in existing CMP implementations. Other HTTP request methods, such as GET, are not used because PKI management operations can only be triggered using CMP's PKI messages, which need to be transferred using a POST request.
CMPメッセージを転送するためのHTTP（例：[RFC9110]および[RFC9112]で指定されているHTTP/1.1）の使用は、リクエストにPOSTメソッドのみを使用し、HTTPを効果的にCMPにトンネル化します。これは一般に悪い慣行と見なされますが（HTTPを使用してプロトコルを構築するための最良の現在のプラクティスについては、RFC 9205 [BCP56]を参照）、エミュレートすべきではありませんが、CMPを転送するための正当な理由があります。HTTPは一般的に実装が簡単で、ユビキタスプロキシを使用してネットワーク境界線を通過できるため使用されます。最も重要なことは、HTTPは既存のCMP実装ですでに一般的に使用されていることです。PKI管理操作は、POSTリクエストを使用して転送する必要があるCMPのPKIメッセージを使用してのみトリガーできるため、GETなどの他のHTTPリクエストメソッドは使用されません。
With its status codes, HTTP provides needed error reporting capabilities. General problems on the server side, as well as those directly caused by the respective request, can be reported to the client.
ステータスコードを使用して、HTTPは必要なエラーレポート機能を提供します。サーバー側の一般的な問題と、それぞれの要求によって直接引き起こされる問題は、クライアントに報告できます。
As CMP implements a transaction identification (transactionID), identifying transactions spanning over more than just a single request/response pair, the statelessness of HTTP is not blocking its usage as the transfer protocol for CMP messages.
CMPがトランザクション識別（TransactionID）を実装し、単一のリクエスト/応答ペア以上に及ぶトランザクションを識別するため、HTTPのステートレス性は、CMPメッセージの転送プロトコルとしての使用法をブロックしていません。
CMP Updates [RFC9480] updated Section 3.6 of [RFC6712], supporting the PKI management operations specified in the Lightweight CMP Profile [RFC9483], in the following areas:
CMPは[RFC9480]の更新[RFC9480] [RFC6712]のセクション3.6を更新し、次の領域で軽量CMPプロファイル[RFC9483]で指定されたPKI管理操作をサポートします。
* Introduced the HTTP URI path prefix '/.well-known/cmp'.
* HTTP URIパスプレフィックス '/.Well-Nownd/CMP'を導入しました。
* Added options for extending the URI structure with further segments and defined a new protocol registry group to that aim.
* URI構造をさらにセグメントで拡張するためのオプションを追加し、新しいプロトコルレジストリグループをその目的に定義しました。
This document obsoletes [RFC6712]. It includes the changes specified in Section 3 of [RFC9480], as described in Section 1.1 of this document. Additionally, it adds the following changes:
この文書は廃止[RFC6712]。このドキュメントのセクション1.1で説明されているように、[RFC9480]のセクション3で指定された変更が含まれます。さらに、次の変更を追加します。
* Removed the requirement to support HTTP/1.0 [RFC1945] in accordance with Section 4.1 of RFC 9205 [BCP56].
* RFC 9205 [BCP56]のセクション4.1に従って、HTTP/1.0 [RFC1945]をサポートするための要件を削除しました。
* Implementations MUST forward CMP messages when an HTTP error status code occurs; see Section 3.1.
* HTTPエラーステータスコードが発生した場合、実装はCMPメッセージを転送する必要があります。セクション3.1を参照してください。
* Removed Section 3.8 of [RFC6712] as it contains information redundant with current HTTP specification.
* 現在のHTTP仕様に冗長な情報が含まれているため、[RFC6712]のセクション3.8を削除しました。
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] で説明されているように解釈されます。
For direct interaction between two entities, where a reliable transport protocol like TCP [RFC9293] is available, HTTP [RFC9110] SHOULD be utilized for conveying CMP messages. This specification requires using the POST method (Section 3.1) and the "Content-Type" header field (Section 3.2), which are available since HTTP/1.0 [RFC1945].
TCP [RFC9293]のような信頼できる輸送プロトコルが利用可能な2つのエンティティ間の直接的な相互作用のために、HTTP [RFC9110]を使用してCMPメッセージを伝えるために利用する必要があります。この仕様では、HTTP/1.0 [RFC1945]以降利用可能なPOSTメソッド（セクション3.1）と「コンテンツタイプ」ヘッダーフィールド（セクション3.2）を使用する必要があります。
Note: In some situations, CMP requires multiple request/response pairs to perform a PKI management operation. Their affiliation with a PKI management operation is indicated by a transaction identifier in the CMP message header (see transactionID described in Section 5.1.1 of [RFC9810]). For details on how to transfer multiple requests, see Section 4.11 of RFC 9205 [BCP56].
注：状況によっては、CMPはPKI管理操作を実行するために複数のリクエスト/応答ペアが必要です。PKI管理操作との提携は、CMPメッセージヘッダーのトランザクション識別子によって示されます（[RFC9810]のセクション5.1.1で説明されているTransactionIDを参照）。複数のリクエストを転送する方法の詳細については、RFC 9205のセクション4.11 [BCP56]を参照してください。
A DER-encoded [ITU.X690.2021] PKIMessage (Section 5.1 of [RFC9810]) MUST be sent as the content of an HTTP POST request. If this HTTP request is successful, the server returns the CMP response in the content of the HTTP response. The HTTP response status code in this case MUST be 200 (OK); other Successful 2xx status codes MUST NOT be used for this purpose. HTTP responses to pushed CMP announcement messages described in Section 3.5 utilize the status codes 201 and 202 to identify whether the received information was processed.
http postリクエストの内容として、der-encoded [itu.x690.2021] pkimessage（[rfc9810]のセクション5.1）を送信する必要があります。このHTTP要求が成功した場合、サーバーはHTTP応答のコンテンツでCMP応答を返します。この場合のHTTP応答ステータスコードは200（OK）でなければなりません。他の成功した2XXステータスコードは、この目的に使用してはなりません。セクション3.5で説明されているプッシュされたCMPアナウンスメッセージへのHTTP応答は、ステータスコード201と202を利用して、受信した情報が処理されたかどうかを特定します。
While Redirection 3xx status codes MAY be supported by implementations, clients should only be enabled to automatically follow them after careful consideration of possible security implications. As described in Section 5, the 301 (Moved Permanently) status code could be misused for permanent denial of service.
リダイレクト3XXステータスコードは実装によってサポートされる場合がありますが、セキュリティの影響を慎重に検討した後、クライアントは自動的に追跡できるようにする必要があります。セクション5で説明されているように、301（永続的に移動）ステータスコードは、恒久的なサービス拒否のために誤用される可能性があります。
All applicable Client Error 4xx or Server Error 5xx status codes MAY be used to inform the client about errors. Whenever a client receives an HTTP response with a status code in the 2xx, 4xx, or 5xx ranges, it MUST support handling response message content containing a CMP response PKIMessage.
すべての該当するクライアントエラー4xxまたはサーバーエラー5xxステータスコードを使用して、クライアントにエラーについて通知できます。クライアントが2xx、4xx、または5xx範囲のステータスコードを使用してHTTP応答を受信するときはいつでも、CMP応答pkimessageを含む対応メッセージコンテンツの処理をサポートする必要があります。
The Internet media type "application/pkixcmp" MUST be set in the HTTP "Content-Type" header field when conveying a PKIMessage.
インターネットメディアタイプ「アプリケーション/PKIXCMP」は、pkimessageを伝えるときにHTTP「コンテンツタイプ」ヘッダーフィールドに設定する必要があります。
In CMP, most communication is initiated by the EEs where every CMP request triggers a CMP response message from the CA or RA.
CMPでは、ほとんどの通信がEESによって開始され、すべてのCMP要求がCAまたはRAからのCMP応答メッセージをトリガーします。
The CMP announcement messages described in Section 3.5 are an exception. Their creation may be triggered by certain events or done on a regular basis by a CA. The recipient of the announcement only replies with an HTTP status code acknowledging the receipt or indicating an error, but not with a CMP response.
セクション3.5で説明されているCMPアナウンスメッセージは例外です。それらの作成は、特定のイベントによってトリガーされるか、CAによって定期的に行われる場合があります。アナウンスの受信者は、領収書を認めたり、エラーを示したりするが、CMP応答ではないHTTPステータスコードでのみ返信します。
If the receipt of an HTTP request is not confirmed by receiving an HTTP response, it MUST be assumed that the transferred CMP message was not successfully delivered to its destination.
HTTPリクエストの受信がHTTP応答を受信して確認されない場合、転送されたCMPメッセージが宛先に正常に配信されなかったと仮定する必要があります。
Each CMP server on a PKI management entity supporting HTTP or HTTPS transfer MUST support the use of the path prefix '/.well-known/' as defined in [RFC8615] and the registered name 'cmp' to ease interworking in a multi-vendor environment.
HTTPまたはHTTPS転送をサポートするPKI管理エンティティ上の各CMPサーバーは、[RFC8615]で定義されているパスプレフィックス「/.Well-Nownd/」の使用をサポートする必要があります。
CMP clients have to be configured with sufficient information to form the CMP server URI. This is at least the authority portion of the URI, e.g., 'www.example.com:80', or the full operation path segment of the PKI management entity. Additionally, path segments MAY be added after the registered application name as part of the full operation path to provide further distinction. The path segment 'p' followed by an arbitraryLabel <name> could, for example, support the differentiation of specific CAs or certificate profiles. Further path segments, e.g., as specified in the Lightweight CMP Profile [RFC9483], could indicate PKI management operations using an operationLabel <operation>. The following list shows examples of valid full CMP URIs:
CMPクライアントは、CMPサーバーURIを形成するのに十分な情報で構成する必要があります。これは、少なくともURIの権限部分、たとえば「www.example.com:80」、またはPKI管理エンティティの完全な操作パスセグメントです。さらに、さらに操作パスの一部として、登録されたアプリケーション名の後にパスセグメントを追加して、さらに区別することができます。パスセグメント「P」とそれに続くArbitraryLabel <Name>たとえば、たとえば、特定のCASまたは証明書プロファイルの区別をサポートできます。たとえば、軽量CMPプロファイル[RFC9483]で指定されているさらなるパスセグメントは、OperationLabel <Operation>を使用してPKI管理操作を示すことができます。次のリストは、有効な完全なCMP URIの例を示しています。
* http://www.example.com/.well-known/cmp
* http://www.example.com/.well-known/cmp
* http://www.example.com/.well-known/cmp/<operation>
* http://www.example.com/.well-known/cmp/<operation>
* http://www.example.com/.well-known/cmp/p/<name>
* http://www.example.com/.well-known/cmp/p/<name>
* http://www.example.com/.well-known/cmp/p/<name>/<operation>
* http://www.example.com/.well-known/cmp/p/<name>/<operation>
Note that https can also be used instead of http; see item 5 in the Security Considerations (Section 5).
HTTPの代わりにHTTPも使用できることに注意してください。セキュリティ上の考慮事項の項目5を参照してください（セクション5）。
A CMP server may create event-triggered announcements or generate them on a regular basis. It MAY utilize HTTP transfer to convey them to a suitable recipient. In this use case, the CMP server acts as an HTTP client, and the recipient needs to utilize an HTTP server. As no request messages are specified for those announcements, they can only be pushed to the recipient.
CMPサーバーは、イベントトリガーされたアナウンスメントを作成したり、定期的に生成したりする場合があります。HTTP転送を利用して、適切な受信者に伝えることができます。このユースケースでは、CMPサーバーはHTTPクライアントとして機能し、受信者はHTTPサーバーを利用する必要があります。これらの発表にはリクエストメッセージが指定されていないため、受信者にのみプッシュすることができます。
If an EE wants to poll for a potential CA Key Update Announcement or the current Certificate Revocation List (CRL), a PKI Information Request using a general message as described in Appendix D.5 of [RFC9810] can be used.
EEが潜在的なCAキーアップデートアナウンスまたは現在の証明書取消リスト（CRL）の投票を望む場合、[RFC9810]の付録D.5で説明されている一般的なメッセージを使用したPKI情報リクエストを使用できます。
When pushing announcement messages, PKIMessage structures MUST be sent as the content of an HTTP POST request.
アナウンスメッセージをプッシュするときは、pkimessage構造をHTTP POSTリクエストのコンテンツとして送信する必要があります。
Suitable recipients for CMP announcements might, for example, be repositories storing the announced information, such as directory services. Those services listen for incoming messages, utilizing the same HTTP Request-URI scheme as defined in Section 3.4.
たとえば、CMPアナウンスに適した受信者は、ディレクトリサービスなどの発表された情報を保存するリポジトリである場合があります。これらのサービスは、セクション3.4で定義されているのと同じHTTP Request-URIスキームを使用して、着信メッセージを聞きます。
The following types of PKIMessage are announcements that may be pushed by a CA. The prefixed numbers reflect ASN.1 tags of the PKIBody structure (Section 5.1.2 of [RFC9810]).
次の種類のpkimessageは、caによってプッシュされる可能性のある発表です。接頭辞番号は、pkibody構造のasn.1タグを反映しています（[RFC9810]のセクション5.1.2）。
[15] CA Key Update Announcement
[16] Certificate Announcement
[17] Revocation Announcement
[18] CRL Announcement
CMP announcement messages do not require any CMP response. However, the recipient MUST acknowledge receipt with an HTTP response having an appropriate status code and empty content. When not receiving such a response, it MUST be assumed that the delivery was not successful. If applicable, the sending side MAY try sending the announcement again after waiting for an appropriate time span.
CMPアナウンスメッセージには、CMP応答は必要ありません。ただし、受信者は、適切なステータスコードと空のコンテンツを持つHTTP応答で領収書を確認する必要があります。そのような応答を受け取らない場合、配達が成功しなかったと想定する必要があります。該当する場合、送信側は、適切な期間を待ってから再び発表を送信してみることがあります。
If the announced issue was successfully stored in a database or was already present, the answer MUST be an HTTP response with a 201 (Created) status code and empty content.
発表された問題がデータベースに正常に保存されているか、すでに存在していた場合、答えは201（作成）ステータスコードと空のコンテンツを使用したHTTP応答でなければなりません。
In case the announced information was only accepted for further processing, the status code of the returned HTTP response MAY also be 202 (Accepted). After an appropriate delay, the sender may then try to send the announcement again and may repeat this until it receives a confirmation that it has been successfully processed. The appropriate duration of the delay and the option to increase it between consecutive attempts should be carefully considered.
発表された情報がさらなる処理のためにのみ受け入れられた場合、返されたHTTP応答のステータスコードも202である可能性があります（受け入れられます）。適切な遅延の後、送信者は再び発表を送信しようとすることがあり、それが正常に処理されたことの確認を受けるまでこれを繰り返すことができます。遅延の適切な期間と連続した試行間でそれを増やすオプションは、慎重に検討する必要があります。
A receiver MUST answer with a suitable 4xx or 5xx error code when a problem occurs.
レシーバーは、問題が発生したときに適切な4xxまたは5xxエラーコードで回答する必要があります。
Implementers should be aware that other implementations might exist that use a different approach for transferring CMP over HTTP. Further, implementations based on earlier documents that led to [RFC6712] might use an unregistered "application/pkixcmp-poll" media type. Conforming implementations MAY handle this type like "application/pkixcmp".
実装者は、HTTPを介してCMPを転送するために異なるアプローチを使用する他の実装が存在する可能性があることに注意する必要があります。さらに、[RFC6712]につながった以前のドキュメントに基づく実装は、未登録の「アプリケーション/PKIXCMPポール」メディアタイプを使用する可能性があります。適合実装は、「アプリケーション/PKIXCMP」などのこのタイプを処理する場合があります。
All security considerations in HTTP [RFC9110] apply. The following items need to be considered by implementers and users:
HTTP [RFC9110]のすべてのセキュリティ上の考慮事項が適用されます。次の項目は、実装者とユーザーが考慮する必要があります。
1. There is the risk for denial-of-service attacks through resource consumption by opening many connections to an HTTP server. Therefore, idle connections should be terminated after an appropriate timeout; this may also depend on the available free resources.
1. HTTPサーバーへの多くの接続を開くことにより、リソース消費によるサービス拒否攻撃のリスクがあります。したがって、適切なタイムアウト後にアイドル接続を終了する必要があります。これは、利用可能な無料リソースにも依存する場合があります。
2. Without being encapsulated in effective security protocols, such as Transport Layer Security (TLS) [RFC5246] [RFC8446], or without using HTTP digest [RFC9530], there is no integrity protection at the HTTP level. Therefore, information from the HTTP should not be used to change state of the transaction, regardless of whether any mechanism was used to ensure the authenticity or integrity of HTTP messages (e.g., TLS or HTTP digests).
2. 輸送層セキュリティ（TLS）[RFC5246] [RFC8446]などの効果的なセキュリティプロトコルにカプセル化されていない場合、またはHTTPダイジェスト[RFC9530]を使用することなく、HTTPレベルでは完全性保護はありません。したがって、HTTPメッセージの信頼性または整合性（TLSまたはHTTPダイジェストなど）を確保するためにメカニズムが使用されたかどうかにかかわらず、HTTPからの情報は、トランザクションの状態を変更するために使用すべきではありません。
3. Client users should be aware that storing the target location of an HTTP response with the 301 (Moved Permanently) status code could be exploited by a meddler-in-the-middle attacker trying to block them permanently from contacting the correct server.
3. クライアントユーザーは、301（永久に移動）ステータスコードを使用してHTTP応答のターゲット位置を保存することは、正しいサーバーへの連絡を永久にブロックしようとする中間攻撃者によって悪用される可能性があることに注意する必要があります。
4. If no measures to authenticate and protect the HTTP responses to pushed announcement messages are in place, their information regarding the announcement's processing state may not be trusted. In that case, the overall design of the PKI system must not depend on the announcements being reliably received and processed by their destination.
4. プッシュされたアナウンスメッセージに対するHTTP応答を認証および保護するための措置がない場合、発表の処理状態に関する情報は信頼されない可能性があります。その場合、PKIシステムの全体的な設計は、目的地によって確実に受け取られ処理されているアナウンスに依存してはなりません。
5. CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential personal, technical, or business-critical information. The protection of the confidentiality of CMP messages together with an initial authentication of the RA/CA before the first CMP message is transmitted ensures the privacy of the EE requesting certificates. Therefore, users of the HTTP transfer for CMP messages should consider using HTTP over TLS according to [RFC9110] or using virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC7296].
5. CMPは、組み込みの整合性の保護と認証を提供します。CMPメッセージで暗号化されていない情報には、傍受されたときにPKIのセキュリティを危険にさらす機密情報が含まれていません。ただし、盗聴者が利用可能な情報を利用して、個人的な個人、技術、またはビジネス上の機密情報を収集することが可能かもしれません。CMPメッセージの機密性の保護と、最初のCMPメッセージが送信される前にRA/CAの初期認証とともに、EEのプライバシーが証明書を要求します。したがって、CMPメッセージのHTTP転送のユーザーは、[RFC9110]に従ってTLSを介してHTTPを使用するか、たとえば[RFC7296]に従ってインターネットプロトコルセキュリティを利用して作成された仮想プライベートネットワークを使用することを検討する必要があります。
IANA has made the following updates:
IANAは次の更新を行いました。
* the reference for "application/pkixcmp" in the "Media Types" registry <https://www.iana.org/assignments/media-types> refers to this document, instead of [RFC2510].
* 「メディアタイプ」レジストリの「アプリケーション/PKIXCMP」の参照<https://www.iana.org/assignments/media-types>は、[rfc2510]ではなくこのドキュメントを指します。
* the reference for "application/pkixcmp" in the "CoAP Content-Formats" registry <https://www.iana.org/assignments/core-parameters> refers to this document, instead of [RFC4210].
* 「COAPコンテンツフォーマット」レジストリ<https://www.iana.org/assignments/core-parameters>の「アプリケーション/pkixcmp」の参照は、[rfc4210]の代わりにこのドキュメントを指します。
* the reference for "cmp" in the "Well-Known URIs" registry <https://www.iana.org/assignments/well-known-uris/> refers to this document instead of [RFC4210].
* 「よく知られているURIS」レジストリ<https://www.iana.org/assignments/well-known-uris/>の「cmp」の参照は、[rfc4210]の代わりにこのドキュメントを参照しています。
* the reference for "p" in the "CMP Well-Known URI Path Segments" registry <https://www.iana.org/assignments/cmp> refers to this document instead of [RFC9480].
* 「P」の「P」の参照は、よく知られているURIパスセグメント "レジストリ<https://www.iana.org/assignments/cmp>は[rfc9480]ではなくこのドキュメントを指します。
No further action by IANA is necessary for this document or any anticipated updates.
このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
[ITU.X690.2021]
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, 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>.
[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>.
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9810] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", RFC 9810,
DOI 10.17487/RFC9810, July 2025,
<https://www.rfc-editor.org/info/rfc9810>.
[BCP56] Best Current Practice 56,
<https://www.rfc-editor.org/info/bcp56>.
At the time of writing, this BCP comprises the following:
Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/info/rfc9205>.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols",
RFC 2510, DOI 10.17487/RFC2510, March 1999,
<https://www.rfc-editor.org/info/rfc2510>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[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>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, November 2023,
<https://www.rfc-editor.org/info/rfc9480>.
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, November 2023,
<https://www.rfc-editor.org/info/rfc9483>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>.
The authors wish to thank Tomi Kause and Martin Peylo, the original authors of [RFC6712], for their work.
著者は、[RFC6712]の元の著者であるTomi KauseとMartin Peyloの研究に感謝したいと考えています。
We also thank all reviewers for their valuable feedback.
また、すべてのレビュアーの貴重なフィードバックに感謝します。
Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
David von Oheimb
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: david.von.oheimb@siemens.com
URI: https://www.siemens.com
Mike Ounsworth
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: mike.ounsworth@entrust.com
URI: https://www.entrust.com
John Gray
Entrust
1187 Park Place
Minneapolis, MN 55379
United States of America
Email: john.gray@entrust.com
URI: https://www.entrust.com