[要約] RFC 9482 aims to utilize CoAP for transferring certificates in the Certificate Management Protocol, facilitating secure communication among PKI entities. Its purpose is to enable efficient certificate creation and management for constrained devices in the IoT domain.
Internet Engineering Task Force (IETF) M. Sahni, Ed.
Request for Comments: 9482 S. Tripathi, Ed.
Category: Standards Track Palo Alto Networks
ISSN: 2070-1721 November 2023
This document specifies the use of the Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space.
このドキュメントは、証明書管理プロトコル（CMP）の転送メカニズムとして、制約付きアプリケーションプロトコル（COAP）の使用を指定します。CMPは、証明書の作成と管理を目的として、さまざまなPKIエンティティ間の相互作用を定義します。COAPは、インターネットの分野でさまざまな制約されたデバイスが使用するHTTPのようなクライアントサーバープロトコルです。
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/rfc9482.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9482で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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. Requirements Language
2. CoAP Transfer Mechanism for CMP
2.1. CoAP URI Format
2.2. Discovery of CMP RA/CA
2.3. CoAP Request Format
2.4. CoAP Block-Wise Transfer Mode
2.5. Multicast CoAP
2.6. Announcement PKIMessage
3. Proxy Support
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
The Certificate Management Protocol (CMP) [RFC4210] is used by the PKI entities for the generation and management of certificates. One of the requirements of CMP is to be independent of the transport protocol in use. CMP has mechanisms to take care of required transactions, error reporting, and protection of messages.
証明書管理プロトコル（CMP）[RFC4210]は、証明書の生成と管理のためにPKIエンティティによって使用されます。CMPの要件の1つは、使用中の輸送プロトコルとは独立していることです。CMPには、必要なトランザクション、エラーレポート、およびメッセージの保護に対処するメカニズムがあります。
The Constrained Application Protocol (CoAP) defined in [RFC7252], [RFC7959], and [RFC8323] is a client-server protocol like HTTP. It is designed to be used by constrained devices over constrained networks. The recommended transport for CoAP is UDP; however, [RFC8323] specifies the support of CoAP over TCP, TLS, and WebSockets.
[RFC7252]、[RFC7959]、および[RFC8323]で定義されている制約付きアプリケーションプロトコル（COAP）は、HTTPのようなクライアントサーバープロトコルです。制約付きネットワークを介して制約付きデバイスで使用されるように設計されています。COAPの推奨輸送はUDPです。ただし、[RFC8323]は、TCP、TLS、およびWebSocketを介したCOAPのサポートを指定します。
This document specifies the use of CoAP over UDP as a transport medium for CMP version 2 [RFC4210], CMP version 3 [RFC9480] (designated as CMP in this document), and the Lightweight CMP Profile [RFC9483]. In general, this document follows the HTTP transfer for CMP specifications defined in [RFC6712] and specifies the requirements for using CoAP as a transfer mechanism for CMP.
このドキュメントは、CMPバージョン2 [RFC4210]の輸送媒体としてのUDP経由のCOAPを使用して、CMPバージョン3 [RFC9480]（このドキュメントでCMPとして指定）、および軽量CMPプロファイル[RFC9483]を指定しています。一般に、このドキュメントは[RFC6712]で定義されたCMP仕様のHTTP転送に従い、COAPをCMPの転送メカニズムとして使用するための要件を指定します。
This document also provides guidance on how to use a "CoAP-to-HTTP" proxy to ease adoption of a CoAP transfer mechanism by enabling the interconnection with existing PKI entities already providing CMP over HTTP.
このドキュメントは、HTTPを介してすでにCMPを提供している既存のPKIエンティティとの相互接続を有効にすることにより、COAP転送メカニズムの採用を容易にするために、「Coap-to-HTTP」プロキシを使用する方法に関するガイダンスも提供します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A CMP transaction consists of exchanging PKIMessages [RFC4210] between PKI end entities (EEs), registration authorities (RAs), and certification authorities (CAs). If the EEs are constrained devices, then they may prefer, as a CMP client, the use of CoAP instead of HTTP as the transfer mechanism. In general, the RAs and CAs are not constrained and can support both CoAP and HTTP client and server implementations. This section specifies how to use CoAP as the transfer mechanism for CMP.
CMPトランザクションは、PKIエンドエンティティ（EES）、登録当局（RAS）、および認証当局（CAS）の間でpkimessage [RFC4210]を交換することで構成されています。EESが制約されたデバイスである場合、CMPクライアントとして、転送メカニズムとしてHTTPの代わりにCOAPの使用を好む場合があります。一般に、RASとCASは制約されておらず、COAPとHTTPの両方のクライアントとサーバーの実装をサポートできます。このセクションでは、COAPをCMPの転送メカニズムとして使用する方法を指定します。
The CoAP URI format is described in Section 6 of [RFC7252]. The CoAP endpoints MUST support use of the path prefix "/.well-known/" as defined in [RFC8615] and the registered name "cmp" to help with endpoint discovery and interoperability. Optional path segments MAY be added after the registered application name (i.e., after "/.well-known/cmp") to provide 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, for example, as specified in Lightweight CMP Profile [RFC9483], could indicate PKI management operations using an operationLabel <operation>. A valid full CMP URI can look like this:
COAP URI形式は、[RFC7252]のセクション6で説明されています。COAPエンドポイントは、エンドポイントの発見と相互運用性を支援するために、[RFC8615]と登録名「CMP」で定義されているパスプレフィックス「/.Well-Nownd/」の使用をサポートする必要があります。オプションのパスセグメントは、登録されたアプリケーション名の後（つまり、「/.Well-Nowned/CMP」の後）、区別を提供することができます。パスセグメント「P」とそれに続くArbitraryLabel <Name>たとえば、たとえば、特定のCASまたは証明書プロファイルの区別をサポートできます。たとえば、軽量CMPプロファイル[RFC9483]で指定されているように、さらなるパスセグメントは、OperationLabel <Operation>を使用してPKI管理操作を示すことができます。有効な完全なCMP URIは次のようになります：
coap://www.example.com/.well-known/cmp
coap://www.example.com/.well-known/cmp/<operation>
coap://www.example.com/.well-known/cmp/p/<profileLabel>
coap://www.example.com/.well-known/cmp/p/<profileLabel>/<operation>
The EEs can be configured with enough information to form the CMP server URI. The minimum information that can be configured is the scheme, i.e., "coap:" or "coaps:", and the authority portion of the URI, e.g., "example.com:5683". If the port number is not specified in the authority, then the default port numbers MUST be assumed for the "coap:" and "coaps:" scheme URIs. The default port for "coap:" scheme URIs is 5683 and the default port for "coaps:" scheme URIs is 5684 [RFC7252].
EEは、CMPサーバーURIを形成するのに十分な情報で構成できます。構成できる最小情報は、スキーム、つまり「coap：」または「coaps：」、およびuriの権限部分、例えば「example.com：5683」です。ポート番号が当局で指定されていない場合、「coap：」および「coaps：」スキームurisでデフォルトのポート番号を想定する必要があります。「coap：」のデフォルトポートは、urisが5683で、「coap：」のデフォルトポートは5684 [RFC7252]です。
Optionally, in the environments where a Local RA or CA is deployed, EEs can also use the CoAP service discovery mechanism [RFC7252] to discover the URI of the Local RA or CA. The CoAP CMP endpoints supporting service discovery MUST also support resource discovery in the Constrained RESTful Environments (CoRE) Link Format, as described in [RFC6690]. The link MUST include the 'ct' attribute defined in Section 7.2.1 of [RFC7252] with the value of "application/pkixcmp", as defined in the "CoAP Content-Formats" IANA registry.
オプションでは、ローカルRAまたはCAが展開されている環境では、EESはCOAPサービス発見メカニズム[RFC7252]を使用して、ローカルRAまたはCAのURIを発見することもできます。サービスの発見をサポートするCOAP CMPエンドポイントは、[RFC6690]で説明されているように、制約されたRESTFUL環境（CORE）リンク形式でのリソース発見もサポートする必要があります。リンクには、[RFC7252]のセクション7.2.1で定義されている「CT」属性を、「COAPコンテンツフォーマット」IANAレジストリで定義されている「アプリケーション/PKIXCMP」の値を含める必要があります。
The CMP PKIMessages MUST be DER encoded and sent as the body of the CoAP POST request. A CMP client MUST send each CoAP request marked as a Confirmable message [RFC7252]. If the CoAP request is successful, then the CMP RA or CA MUST return a Success 2.xx response code; otherwise, the CMP RA or CA MUST return an appropriate Client Error 4.xx or Server Error 5.xx response code. A CMP RA or CA may choose to send a piggybacked response [RFC7252] to the client, or it MAY send a separate response [RFC7252] in case it takes some time for the RA or CA to process the CMP transaction.
CMP pkimessagesは、coap postリクエストの本文としてder exemededおよび送信する必要があります。CMPクライアントは、確認可能なメッセージ[RFC7252]としてマークされた各COAPリクエストを送信する必要があります。COAP要求が成功した場合、CMP RAまたはCAは成功2.xx応答コードを返す必要があります。それ以外の場合、CMP RAまたはCAは、適切なクライアントエラー4.xxまたはサーバーエラー5.xx応答コードを返す必要があります。CMP RAまたはCAは、PiggyBacked Response [RFC7252]をクライアントに送信することを選択できます。または、RAまたはCAがCMPトランザクションを処理するのに時間がかかる場合に備えて、個別の応答[RFC7252]を送信する場合があります。
When transferring CMP PKIMessage over CoAP, the content-format "application/pkixcmp" MUST be used.
COAPを介してCMP pkimessageを転送する場合、コンテンツフォーマット「アプリケーション/PKIXCMP」を使用する必要があります。
A CMP PKIMessage consists of a header, body, protection, and extraCerts structure, which may contain many optional and potentially large fields. Thus, a CMP message can be much larger than the Maximum Transmission Unit (MTU) of the outgoing interface of the device. The EEs and RAs or CAs MUST use the block-wise transfer mode [RFC7959] to transfer such large messages instead of relying on IP fragmentation.
CMP pkimessageは、ヘッダー、ボディ、保護、およびエクストラメッツ構造で構成され、多くのオプションで潜在的に大きなフィールドを含む場合があります。したがって、CMPメッセージは、デバイスの発信インターフェイスの最大伝送ユニット（MTU）よりもはるかに大きくなります。EEとRASまたはCASは、ブロックごとの転送モード[RFC7959]を使用して、IPフラグメンテーションに依存する代わりにこのような大きなメッセージを転送する必要があります。
If a CoAP-to-HTTP proxy is in the path between EEs and an RA or EEs and a CA and if the server supports, then it MUST use the chunked transfer encoding [RFC9112] to send data over the HTTP transport. The proxy MUST try to reduce the number of packets sent by using an optimal chunk length for the HTTP transport.
COAP-to-HTTPプロキシがEESとRAまたはEESおよびCAの間のパスにあり、サーバーがサポートする場合は、[RFC9112]を使用してHTTPトランスポートを介してデータを送信する必要があります。プロキシは、HTTPトランスポートに最適なチャンク長を使用して送信されるパケットの数を減らす必要があります。
CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination address.
COAPを介して送信されるCMP PKIMESSAGESは、マルチキャストの宛先アドレスを使用してはなりません。
A CMP server may publish announcements that can be triggered by an event or periodically for the other PKI entities. Here is the list of CMP announcement messages prefixed by their respective ASN.1 identifier (see Section 5.1.2 of [RFC4210]):
CMPサーバーは、他のPKIエンティティのイベントまたは定期的にトリガーできるアナウンスを公開する場合があります。以下は、それぞれのasn.1識別子が付けたCMPアナウンスメッセージのリストです（[RFC4210]のセクション5.1.2を参照）：
[15] CA Key Update Announcement
[16] Certificate Announcement
[17] Revocation Announcement
[18] CRL Announcement
An EE MAY use the CoAP Observe Option [RFC7641] to register itself to get any announcement messages from the RA or CA. The EE can send a GET request to the server's URI suffixed by "/ann". For example, a path to register for announcement messages may look like this:
EEは、COAP Observe Option [RFC7641]を使用して、RAまたはCAから発表メッセージを取得するために登録する場合があります。EEは、「/ann」で接尾辞を付けたサーバーのURIにGETリクエストを送信できます。たとえば、アナウンスメッセージに登録するパスは次のようになります。
coap://www.example.com/.well-known/cmp/ann
coap://www.example.com/.well-known/cmp/p/<profileLabel>/ann
If the server supports CMP announcement messages, then it MUST send an appropriate Success 2.xx response code; otherwise, it MUST send an appropriate Client Error 4.xx or Server Error 5.xx response code. If for some reason the server cannot add the client to its list of observers for the announcements, it can omit the Observe Option [RFC7641] in the response to the client. Upon receiving a Success 2.xx response without the Observe Option [RFC7641], after some time, a client MAY try to register again for announcements from the CMP server. Since a server can remove the EE from the list of observers for announcement messages, an EE SHOULD periodically reregister itself for announcement messages.
サーバーがCMPアナウンスメッセージをサポートする場合、適切な成功2.xx応答コードを送信する必要があります。それ以外の場合、適切なクライアントエラー4.xxまたはサーバーエラー5.xx応答コードを送信する必要があります。何らかの理由で、サーバーがクライアントをアナウンスのオブザーバーのリストに追加できない場合は、クライアントへの応答でオプション[RFC7641]を省略できます。オプション[RFC7641]を使用せずに2.xx応答を成功させると、しばらくしてから、クライアントはCMPサーバーからの発表について再度登録しようとすることがあります。サーバーは、発表メッセージのためにオブザーバーのリストからEEを削除できるため、EEは発表メッセージのために定期的に再登録する必要があります。
Alternatively, an EE MAY periodically poll for the current status of the CA via the "PKI Information Request" message; see Section 6.5 of [RFC4210]. If supported, EEs MAY also use "support messages" defined in Section 4.3 of Lightweight CMP Profile [RFC9483] to get information about the CA status. These mechanisms will help constrained devices that are acting as EEs to conserve resources by eliminating the need to create an endpoint for receiving notifications from the RA or CA. It will also simplify the implementation of a CoAP-to-HTTP proxy.
あるいは、EEは、「PKI情報リクエスト」メッセージを介してCAの現在のステータスを定期的に投票することができます。[RFC4210]のセクション6.5を参照してください。サポートされている場合、EESは、軽量CMPプロファイル[RFC9483]のセクション4.3で定義された「サポートメッセージ」を使用して、CAステータスに関する情報を取得することもできます。これらのメカニズムは、RAまたはCAから通知を受信するためのエンドポイントを作成する必要性を排除することにより、リソースを節約するためにEESとして機能している制約付きデバイスに役立ちます。また、Coap-to-HTTPプロキシの実装を簡素化します。
This section provides guidance on using a CoAP-to-HTTP proxy between EEs and RAs or CAs in order to avoid changes to the existing PKI implementation.
このセクションでは、既存のPKI実装の変更を回避するために、EESとRASまたはCASの間でCOAPからHTTPプロキシを使用することに関するガイダンスを提供します。
Since the CMP payload is the same over CoAP and HTTP transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be implemented based on Section 10 of [RFC7252]. The CoAP-to-HTTP proxy can either be located closer to the EEs or closer to the RA or CA. The proxy MAY support service discovery and resource discovery, as described in Section 2.2. The CoAP-to-HTTP proxy MUST function as a reverse proxy, only permitting connections to a limited set of preconfigured servers. It is out of scope of this document to specify how a reverse proxy can route CoAP client requests to one of the configured servers. Some recommended mechanisms are as follows:
CMPペイロードはCOAPおよびHTTP転送メカニズムで同じであるため、[RFC7252]のセクション10に基づいて、COAPからHTTPクロスプロトコルプロキシを実装できます。Coap-to-HTTPプロキシは、EESに近いか、RAまたはCAに近いかのいずれかを配置できます。プロキシは、セクション2.2で説明されているように、サービスの発見とリソースの発見をサポートする場合があります。Coap-to-HTTPプロキシは、逆プロキシとして機能する必要があり、限られた事前設定されたサーバーのセットへの接続のみを許可する必要があります。このドキュメントの範囲外では、逆プロキシがCOAPクライアント要求を構成されたサーバーのいずれかにルーティングする方法を指定します。いくつかの推奨メカニズムは次のとおりです。
* Use the Uri-Path option to identify a server.
* URI-PATHオプションを使用して、サーバーを識別します。
* Use separate hostnames for each of the configured servers and then use the Uri-Host option for routing the CoAP requests.
* 構成された各サーバーに個別のホスト名を使用し、COAPリクエストをルーティングするためにURI-HOSTオプションを使用します。
* Use separate hostnames for each of the configured servers and then use Server Name Indication [RFC8446] in case of the "coaps://" scheme for routing CoAP requests.
* 構成された各サーバーに個別のホスト名を使用し、COAPリクエストをルーティングするための「CoAps：//」スキームの場合、サーバー名表示[RFC8446]を使用します。
* If PKIProtection is used, the PKIHeader and PKIBody of the CMP are cryptographically protected against malicious modifications. As such, UDP can be used without compromising the security of the CMP. Security considerations for CoAP are defined in [RFC7252].
* PKIPROTECTIONを使用すると、CMPのPKIHEADERとPKIBODYは悪意のある修正から暗号化されています。そのため、UDPは、CMPのセキュリティを損なうことなく使用できます。COAPのセキュリティ上の考慮事項は、[RFC7252]で定義されています。
* The CMP does not provide confidentiality of the CMP payloads. If confidentiality is desired, CoAP over DTLS [RFC9147] SHOULD be used to provide confidentiality for the CMP payloads; although, it cannot conceal that the CMP is used within the DTLS layer.
* CMPは、CMPペイロードの機密性を提供しません。機密性が必要な場合は、CMPペイロードの機密性を提供するために、DTLS [RFC9147]を使用する必要があります。ただし、CMPがDTLSレイヤー内で使用されていることを隠すことはできません。
* Section 9.1 of [RFC7252] defines how to use DTLS [RFC9147] for securing CoAP. DTLS [RFC9147] associations SHOULD be kept alive and reused where possible to amortize on the additional overhead of DTLS on constrained devices.
* [RFC7252]のセクション9.1は、COAPを保護するためにDTLS [RFC9147]を使用する方法を定義しています。DTLS [RFC9147]関連付けは、制約されたデバイス上のDTLの追加のオーバーヘッドを償却するために、可能であれば再利用する必要があります。
* An EE might not witness all of the announcement messages when using the CoAP Observe Option [RFC7641], since the Observe Option is a "best-effort" approach and the server might lose its state for subscribers to its announcement messages. The EEs may use an alternate method described in Section 2.6 to obtain time critical changes, such as Certificate Revocation List (CRL) [RFC5280] updates.
* 観察オプションは「ベストエフォート」アプローチであり、サーバーはサブスクライバーが発表メッセージのサブスクライバーの状態を失う可能性があるため、COAP Observeオプション[RFC7641]を使用する場合、EEはすべての発表メッセージを目撃しない場合があります。EESは、セクション2.6で説明されている代替方法を使用して、証明書の取り消しリスト（CRL）[RFC5280]更新など、時間の重大な変更を取得できます。
* Implementations SHOULD use the available datagram size and avoid sending small datagrams containing partial CMP PKIMessage data in order to reduce memory usage for packet buffering.
* 実装では、使用可能なデータグラムのサイズを使用し、パケットバッファリングのメモリ使用量を削減するために、部分的なCMP PKIMESSAGEデータを含む小さなデータグラムの送信を避ける必要があります。
* A CoAP-to-HTTP proxy can also protect the PKI entities by handling UDP and CoAP messages. The proxy can mitigate attacks, like denial-of-service attacks, replay attacks, and resource-exhaustion attacks, by enforcing basic checks, like validating that the ASN.1 syntax is compliant to CMP messages and validating the PKIMessage protection before sending them to PKI entities.
* COAP-to-HTTPプロキシは、UDPメッセージとCOAPメッセージを処理することにより、PKIエンティティを保護することもできます。プロキシは、ASN.1構文がCMPメッセージに準拠していることを検証するなど、基本的なチェックを実施することにより、サービス拒否攻撃、リプレイ攻撃、リソース排除攻撃など、攻撃を軽減できます。PKIエンティティ。
* Since the proxy may have access to the CMP-level metadata and control over the flow of CMP messages, proper role-based access control should be in place. The proxy can be deployed at the edge of the "end entities" network or in front of an RA and CA to protect them. However, the proxy may itself be vulnerable to resource-exhaustion attacks as it's required to buffer the CMP messages received over CoAP transport before sending it to the HTTP endpoint. This can be mitigated by using short timers for discarding the buffered messages and rate limiting clients based on the resource usage.
* プロキシはCMPレベルのメタデータにアクセスし、CMPメッセージのフローを制御する可能性があるため、適切なロールベースのアクセス制御が整っている必要があります。プロキシは、「End Entities」ネットワークの端に、またはそれらを保護するためにRAとCAの前に展開できます。ただし、プロキシ自体は、HTTPエンドポイントに送信する前に、COAP輸送を介して受信したCMPメッセージをバッファリングする必要があるため、リソース排除攻撃に対して脆弱である可能性があります。これは、バッファリングされたメッセージを破棄し、リソースの使用に基づいてクライアントを制限するために短いタイマーを使用することで軽減できます。
IANA has registered "application/pkixcmp" (ID 259) in the "CoAP Content-Formats" registry <https://www.iana.org/assignments/core-parameters> to transfer CMP transactions over CoAP.
IANAは、「COAPコンテンツフォーマット」レジストリに「アプリケーション/PKIXCMP」（ID 259）を登録しています<https://www.iana.org/assignments/core-parameters> CMPトランザクションをCOAPで転送します。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
pkixcmp
pkixcmp
Reference:
参照：
RFC 9482 [RFC4210]
RFC 9482 [RFC4210]
IANA has also registered a new path segment "ann" in the "CMP Well-Known URI Path Segments" registry <https://www.iana.org/assignments/ cmp> for the EEs to register themselves for the announcement messages.
IANAはまた、EESが発表メッセージに登録するために、「有名なURIパスセグメント」レジストリ<https://www.iana.org/assignments/ cmp>に新しいパスセグメント「アン」を登録しました。
Path Segment:
パスセグメント：
ann
アン
Description:
説明：
The path to send a GET request with the CoAP Observe Option to register for CMP announcement messages.
CMPアナウンスメッセージに登録するCOAP Observe Optionオプションを使用してGETリクエストを送信するパス。
Reference:
参照：
RFC 9482
RFC 9482
IANA has added this document as a reference for the "cmp" entry in the "Well-Known URIs" registry <https://www.iana.org/assignments/ well-known-uris>.
IANAは、このドキュメントを「有名なURIS」レジストリ<https://www.iana.org/assignments/ wearknown-uris>の「cmp」エントリの参照として追加しました。
IANA has also added this document as a reference for the "p" entry in the "CMP Well-Known URI Path Segments" registry <https://www.iana.org/assignments/cmp/>.
IANAはまた、このドキュメントを「著名なURIパスセグメント」レジストリの「P」エントリの参照として追加しました<https://www.iana.org/assignments/cmp/>。
[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>.
[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>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[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>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[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>.
[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>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[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>.
[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>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
[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>.
The authors would like to thank Hendrik Brockhaus, David von Oheimb, and Andreas Kretschmer for their guidance in writing the content of this document and providing valuable feedback.
著者は、Hendrik Brockhaus、David von Oheimb、およびAndreas Kretschmerに、このドキュメントの内容を書いて貴重なフィードバックを提供してくれたガイダンスに感謝します。
Mohit Sahni (editor)
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
United States of America
Email: msahni@paloaltonetworks.com
Saurabh Tripathi (editor)
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
United States of America
Email: stripathi@paloaltonetworks.com