[要約] RFC 9360 は、COSEメッセージ構造でX.509証明書を参照および運搬するための属性を提供することで、キーの識別と輸送方法を拡張します。
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 9360 August Cellars
Category: Standards Track February 2023
ISSN: 2070-1721
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.
CBORオブジェクトの署名と暗号化（COSE）メッセージ構造は、一般的なキーへの参照を使用します。一部のアルゴリズムでは、必要に応じてキーに関連するパラメーターを伝達する追加のプロパティが定義されています。COSEキー構造は、COSEメッセージ以外のキーを輸送するために使用されます。このドキュメントは、X.509証明書を参照または含める属性を提供することにより、キーを識別および輸送できる方法を拡張します。
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/rfc9360.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9360で取得できます。
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 Terminology
2. X.509 COSE Header Parameters
3. X.509 Certificates and Static-Static ECDH
4. IANA Considerations
4.1. COSE Header Parameters Registry
4.2. COSE Header Algorithm Parameters Registry
4.3. Media Type application/cose-x509
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Author's Address
In the process of writing [RFC8152] and [RFC9052], the CBOR Object Signing and Encryption (COSE) Working Group discussed X.509 certificates [RFC5280] and decided that no use cases were presented that showed a need to support certificates. Since that time, a number of cases have been defined in which X.509 certificate support is necessary, and by implication, applications will need a documented and consistent way to handle such certificates. This document defines a set of attributes that will allow applications to transport and refer to X.509 certificates in a consistent manner.
[RFC8152]および[RFC9052]を作成する過程で、CBORオブジェクトの署名と暗号化（COSE）ワーキンググループは、X.509証明書[RFC5280]について議論し、証明書をサポートする必要性を示すユースケースが提示されていないことを決定しました。それ以来、X.509証明書サポートが必要な多くのケースが定義されており、暗示により、アプリケーションはそのような証明書を処理するための文書化された一貫した方法が必要です。このドキュメントでは、アプリケーションが一貫した方法でX.509証明書を輸送し、参照できる属性のセットを定義します。
In some of these cases, a constrained device is being deployed in the context of an existing X.509 PKI: for example, [Constrained-BRSKI] describes a device enrollment solution that relies on the presence of a factory-installed certificate on the device. [EDHOC] was also written with the idea that long-term certificates could be used to provide for authentication of devices and establish session keys. Another possible scenario is the use of COSE as the basis for a secure messaging application. This scenario assumes the presence of long-term keys and a central authentication authority. Basing such an application on public key certificates allows it to make use of well-established key management disciplines.
これらのケースの一部では、既存のX.509 PKIのコンテキストで制約されたデバイスが展開されています：たとえば、[Constreaded-Brski]は、デバイスに工場で設置された証明書の存在に依存するデバイス登録ソリューションを説明しています。。[EDHOC]は、デバイスの認証を提供し、セッションキーを確立するために長期的な証明書を使用できるという考えで書かれました。別の可能なシナリオは、安全なメッセージングアプリケーションの基礎としてCOSEを使用することです。このシナリオでは、長期キーと中央認証機関の存在を想定しています。このようなアプリケーションを公開キーの証明書に基づいて、確立された主要な管理分野を利用することができます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The use of X.509 certificates allows for an existing trust infrastructure to be used with COSE. This includes the full suite of enrollment protocols, trust anchors, trust chaining, and revocation checking that have been defined over time by the IETF and other organizations. The Concise Binary Object Representation (CBOR) key structures [RFC8949] that have been defined in COSE currently do not support all of these properties, although some may be found in CBOR Web Tokens (CWTs) [RFC8392].
X.509証明書を使用すると、既存の信頼インフラストラクチャをCOSEで使用できます。これには、IETFおよび他の組織によって時間の経過とともに定義されてきた登録プロトコルの完全なスイート、信頼のアンカー、信頼チェーン、および取り消しチェックが含まれます。COSEで定義されている簡潔なバイナリオブジェクト表現（CBOR）キー構造[RFC8949]は現在これらのプロパティのすべてをサポートしていませんが、CBOR Webトークン（CWTS）[RFC8392]にあるものもあります。
It is not necessarily expected that constrained devices themselves will evaluate and process X.509 certificates: it is perfectly reasonable for a constrained device to be provisioned with a certificate that it subsequently provides to a relying party -- along with a signature or encrypted message -- on the assumption that the relying party is not a constrained device and is capable of performing the required certificate evaluation and processing. It is also reasonable that a constrained device would have the hash of a certificate associated with a public key and be configured to use a public key for that thumbprint, but without performing the certificate evaluation or even having the entire certificate. In any case, there still needs to be an entity that is responsible for handling the possible certificate revocation.
制約付きデバイス自体がX.509証明書を評価および処理することは必ずしも予想されていません。制約されたデバイスが、署名または暗号化されたメッセージとともに、その後依存している当事者に提供する証明書を制約されたデバイスにプロビジョニングすることは完全に合理的です - - 依存者が制約されたデバイスではなく、必要な証明書の評価と処理を実行できると仮定します。また、制約されたデバイスが公開キーに関連付けられた証明書のハッシュを持ち、そのサムプリントに公開キーを使用するように構成されているが、証明書の評価を実行したり、証明書全体を持っていることも合理的です。いずれにせよ、可能な証明書の取り消しを処理する責任のあるエンティティがまだ必要です。
Parties that intend to rely on the assertions made by a certificate obtained from any of these methods still need to validate it. This validation can be done according to the PKIX rules specified in [RFC5280] or by using a different trust structure, such as a trusted certificate distributor for self-signed certificates. The PKIX validation includes matching against the trust anchors configured for the application. These rules apply when the validation succeeds in a single step as well as when certificate chains need to be built. If the application cannot establish trust in the certificate, the public key contained in the certificate cannot be used for cryptographic operations.
これらの方法のいずれかから取得した証明書によって行われたアサーションに依存することを意図する当事者は、まだ検証する必要があります。この検証は、[RFC5280]で指定されたPKIXルールに従って、または自己署名証明書の信頼できる証明書ディストリビューターなどの異なる信頼構造を使用して実行できます。PKIX検証には、アプリケーション用に構成された信頼アンカーとの一致が含まれます。これらのルールは、検証が単一のステップで成功したときと証明書チェーンを構築する必要があるときに適用されます。申請が証明書に信頼を確立できない場合、証明書に含まれる公開鍵は暗号化操作に使用できません。
The header parameters defined in this document are as follows:
このドキュメントで定義されているヘッダーパラメーターは次のとおりです。
x5bag:
x5bag：
This header parameter contains a bag of X.509 certificates. The set of certificates in this header parameter is unordered and may contain self-signed certificates. Note that there could be duplicate certificates. The certificate bag can contain certificates that are completely extraneous to the message. (An example of this would be where a signed message is being used to transport a certificate containing a key agreement key.) As the certificates are unordered, the party evaluating the signature will need to be capable of building the certificate path as necessary. That party will also have to take into account that the bag may not contain the full set of certificates needed to build any particular chain.
このヘッダーパラメーターには、X.509証明書のバッグが含まれています。このヘッダーパラメーターの証明書のセットは順序付けられておらず、自己署名証明書が含まれている場合があります。重複証明書がある可能性があることに注意してください。証明書バッグには、メッセージが完全に無関係な証明書を含めることができます。（この例は、署名されたメッセージがキー契約キーを含む証明書を輸送するために使用されている場所です。）証明書は順序付けられていないため、署名を評価する当事者は、必要に応じて証明書パスを構築できる必要があります。その当事者はまた、バッグに特定のチェーンを構築するために必要な証明書の完全なセットが含まれていない可能性があることを考慮する必要があります。
The trust mechanism MUST process any certificates in this parameter as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation. As the contents of this header parameter are untrusted input, the header parameter can be in either the protected or unprotected header bucket. Sending the header parameter in the unprotected header bucket allows an intermediary to remove or add certificates.
信頼メカニズムは、このパラメーターの任意の証明書を信頼されていない入力として処理する必要があります。パラメーター内に自己署名証明書が存在することは、帯域外の確認なしに、信頼のアンカーのセットの更新を引き起こしてはなりません。このヘッダーパラメーターの内容は信頼されていない入力であるため、ヘッダーパラメーターは保護されていないまたは保護されていないヘッダーバケットのいずれかになります。保護されていないヘッダーバケットにヘッダーパラメーターを送信すると、仲介者が証明書を削除または追加することができます。
The end-entity certificate MUST be integrity protected by COSE. This can, for example, be done by sending the header parameter in the protected header, sending an 'x5bag' in the unprotected header combined with an 'x5t' in the protected header, or including the end-entity certificate in the external_aad.
エンドエンティティ証明書は、COSEによって保護されている整合性でなければなりません。これは、たとえば、保護されたヘッダーにヘッダーパラメーターを送信したり、保護されていないヘッダーに「x5bag」を送信して、保護されたヘッダーの 'x5t'と組み合わせたり、external_aadにエンドエンティティ証明書を含めたりすることで実行できます。
This header parameter allows for a single X.509 certificate or a bag of X.509 certificates to be carried in the message.
このヘッダーパラメーターを使用すると、単一のx.509証明書またはx.509証明書の袋をメッセージに掲載できます。
* If a single certificate is conveyed, it is placed in a CBOR byte string.
* 単一の証明書が伝達されると、CBORバイト文字列に配置されます。
* If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate being in its own byte string.
* 複数の証明書が伝達される場合、各証明書は独自のバイト文字列にあるバイト文字列のCBOR配列が使用されます。
x5chain:
x5chain：
This header parameter contains an ordered array of X.509 certificates. The certificates are to be ordered starting with the certificate containing the end-entity key followed by the certificate that signed it, and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party already has, or can locate, the missing certificates. This means that the relying party is still required to do path building but that a candidate path is proposed in this header parameter.
このヘッダーパラメーターには、X.509証明書の順序付けられた配列が含まれています。証明書は、エンドエンティティキーを含む証明書から開始して、それに署名した証明書などが注文されます。頼っている当事者が不足している証明書を既に持っている、または見つけることができると信じる理由がある場合、チェーン全体が要素に存在する必要はありません。これは、頼りになる当事者がパスビルディングを行うためにまだ必要であることを意味しますが、このヘッダーパラメーターで候補パスが提案されていることを意味します。
The trust mechanism MUST process any certificates in this parameter as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation. As the contents of this header parameter are untrusted input, the header parameter can be in either the protected or unprotected header bucket. Sending the header parameter in the unprotected header bucket allows an intermediary to remove or add certificates.
信頼メカニズムは、このパラメーターの任意の証明書を信頼されていない入力として処理する必要があります。パラメーター内に自己署名証明書が存在することは、帯域外の確認なしに、信頼のアンカーのセットの更新を引き起こしてはなりません。このヘッダーパラメーターの内容は信頼されていない入力であるため、ヘッダーパラメーターは保護されていないまたは保護されていないヘッダーバケットのいずれかになります。保護されていないヘッダーバケットにヘッダーパラメーターを送信すると、仲介者が証明書を削除または追加することができます。
The end-entity certificate MUST be integrity protected by COSE. This can, for example, be done by sending the header parameter in the protected header, sending an 'x5chain' in the unprotected header combined with an 'x5t' in the protected header, or including the end-entity certificate in the external_aad.
エンドエンティティ証明書は、COSEによって保護されている整合性でなければなりません。これは、たとえば、保護されたヘッダーにヘッダーパラメーターを送信したり、保護されていないヘッダーに「x5chain」を送信して、保護されたヘッダーの「x5t」を組み合わせたり、external_aadにエンドエンティティ証明書を含めたりすることで実行できます。
This header parameter allows for a single X.509 certificate or a chain of X.509 certificates to be carried in the message.
このヘッダーパラメーターにより、単一のx.509証明書またはx.509証明書のチェーンがメッセージに掲載されます。
* If a single certificate is conveyed, it is placed in a CBOR byte string.
* 単一の証明書が伝達されると、CBORバイト文字列に配置されます。
* If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate being in its own byte string.
* 複数の証明書が伝達される場合、各証明書は独自のバイト文字列にあるバイト文字列のCBOR配列が使用されます。
x5t:
x5t：
This header parameter identifies the end-entity X.509 certificate by a hash value (a thumbprint). The 'x5t' header parameter is represented as an array of two elements. The first element is an algorithm identifier that is an integer or a string containing the hash algorithm identifier corresponding to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry (see <https://www.iana.org/assignments/cose/>). The second element is a binary string containing the hash value computed over the DER-encoded certificate.
このヘッダーパラメーターは、ハッシュ値（サムプリント）でエンドエンティティX.509証明書を識別します。「x5t」ヘッダーパラメーターは、2つの要素の配列として表されます。最初の要素は、「Coseアルゴリズム」レジストリに登録されているアルゴリズムの値列（整数またはテキスト文字列）に対応するハッシュアルゴリズム識別子を含む整数または文字列であるアルゴリズム識別子です（<https：// wwwを参照してください。iana.org/assignments/cose/>）。2番目の要素は、derエンコードされた証明書で計算されたハッシュ値を含むバイナリ文字列です。
As this header parameter does not provide any trust, the header parameter can be in either a protected or unprotected header bucket.
このヘッダーパラメーターは信頼を提供しないため、ヘッダーパラメーターは保護されたまたは保護されていないヘッダーバケットのいずれかになります。
The identification of the end-entity certificate MUST be integrity protected by COSE. This can be done by sending the header parameter in the protected header or including the end-entity certificate in the external_aad.
エンドエンティティ証明書の識別は、COSEによって整合性保護されている必要があります。これは、保護されたヘッダーにヘッダーパラメーターを送信するか、外部_AADにエンドエンティティ証明書を含めることで実行できます。
The 'x5t' header parameter can be used alone or together with the 'x5bag', 'x5chain', or 'x5u' header parameters to provide integrity protection of the end-entity certificate.
「x5t」ヘッダーパラメーターは、単独で、または「x5bag」、「x5chain」、または「x5u」ヘッダーパラメーターと一緒に使用でき、エンドエンティティ証明書の整合性保護を提供できます。
For interoperability, applications that use this header parameter MUST support the hash algorithm 'SHA-256' but can use other hash algorithms. This requirement allows for different implementations to be configured to use an interoperable algorithm, but does not preclude the use (by prior agreement) of other algorithms.
相互運用性のために、このヘッダーパラメーターを使用するアプリケーションは、ハッシュアルゴリズム「SHA-256」をサポートする必要がありますが、他のハッシュアルゴリズムを使用できます。この要件により、異なる実装を相互運用可能なアルゴリズムを使用するように構成できますが、他のアルゴリズムの（事前の合意による）使用を排除することはできません。
x5u:
x5u：
This header parameter provides the ability to identify an X.509 certificate by a URI [RFC3986]. It contains a CBOR text string. The referenced resource can be any of the following media types:
このヘッダーパラメーターは、URI [RFC3986]によってX.509証明書を識別する機能を提供します。CBORテキスト文字列が含まれています。参照されたリソースは、次のメディアタイプのいずれかにすることができます。
* application/pkix-cert [RFC2585]
* アプリケーション/pkix-cert [rfc2585]
* application/pkcs7-mime; smime-type="certs-only" [RFC8551]
* アプリケーション/PKCS7-MIME;SMIME-TYPE = "CERTS-ONLY" [RFC8551]
* application/cose-x509 (Section 4.3)
* アプリケーション/COSE-X509（セクション4.3）
* application/cose-x509; usage=chain (Section 4.3)
* アプリケーション/COSE-X509;使用法=チェーン（セクション4.3）
When the application/cose-x509 media type is used, the data is a CBOR sequence of single-entry COSE_X509 structures (encoding "bstr"). If the parameter "usage" is set to "chain", this sequence indicates a certificate chain.
アプリケーション/COSE-X509メディアタイプを使用すると、データは単一エントリCOSE_X509構造のCBORシーケンス（「BSTR」をエンコード）です。パラメーター「使用」が「チェーン」に設定されている場合、このシーケンスは証明書チェーンを示します。
The end-entity certificate MUST be integrity protected by COSE. This can, for example, be done by sending the 'x5u' in the unprotected or protected header combined with an 'x5t' in the protected header, or including the end-entity certificate in the external_aad. As the end-entity certificate is integrity protected by COSE, the URI does not need to provide any protection.
エンドエンティティ証明書は、COSEによって保護されている整合性でなければなりません。これは、たとえば、保護されていないヘッダーまたは保護されたヘッダーに「x5u」を保護されたヘッダーの「x5t」と組み合わせて送信するか、external_aadにエンドエンティティ証明書を含めることで実行できます。エンドエンティティ証明書はCOSEによって保護されているため、URIは保護を提供する必要はありません。
If a retrieved certificate does not chain to an existing trust anchor, that certificate MUST NOT be trusted unless the URI provides integrity protection and server authentication and the server is configured as trusted to provide new trust anchors or if an out-of-band confirmation can be received for trusting the retrieved certificate. If an HTTP or Constrained Application Protocol (CoAP) GET request is used to retrieve a certificate, TLS [RFC8446], DTLS [RFC9147], or Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] SHOULD be used.
検索された証明書が既存の信頼アンカーにチェーンしない場合、URIが整合性保護とサーバー認証を提供しない限り、その証明書を信頼してはなりません。取得された証明書を信頼するために受け取られます。HTTPまたは制約付きアプリケーションプロトコル（COAP）GETリクエストを使用して証明書、TLS [RFC8446]、DTLS [RFC9147]、または制約された安らかな環境（OSCORE）[RFC8613]のオブジェクトセキュリティを使用する必要があります。
The header parameters are used in the following locations:
ヘッダーパラメーターは、次の場所で使用されます。
COSE_Signature and COSE_Sign1 objects:
cose_signature and cose_sign1オブジェクト：
In these objects, the parameters identify the certificate to be used for validating the signature.
これらのオブジェクトでは、パラメーターは、署名を検証するために使用される証明書を識別します。
COSE_recipient objects:
cose_recipientオブジェクト：
In this location, the parameters identify the certificate for the recipient of the message.
この場所では、パラメーターがメッセージの受信者の証明書を識別します。
The labels assigned to each header parameter can be found in Table 1.
各ヘッダーパラメーターに割り当てられたラベルは、表1にあります。
+=========+=======+===============+=====================+
| Name | Label | Value Type | Description |
+=========+=======+===============+=====================+
| x5bag | 32 | COSE_X509 | An unordered bag of |
| | | | X.509 certificates |
+---------+-------+---------------+---------------------+
| x5chain | 33 | COSE_X509 | An ordered chain of |
| | | | X.509 certificates |
+---------+-------+---------------+---------------------+
| x5t | 34 | COSE_CertHash | Hash of an X.509 |
| | | | certificate |
+---------+-------+---------------+---------------------+
| x5u | 35 | uri | URI pointing to an |
| | | | X.509 certificate |
+---------+-------+---------------+---------------------+
Table 1: X.509 COSE Header Parameters
表1：X.509 COSEヘッダーパラメーター
Below is an equivalent Concise Data Definition Language (CDDL) description (see [RFC8610]) of the text above.
以下は、上記のテキストの同等の簡潔なデータ定義言語（CDDL）の説明（[RFC8610]を参照）の説明です。
COSE_X509 = bstr / [ 2*certs: bstr ]
COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
The contents of "bstr" are the bytes of a DER-encoded certificate.
「BSTR」の内容は、derエンコードされた証明書のバイトです。
The header parameters defined in the previous section are used to identify the recipient certificates for the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithms. In this section, we define the algorithm-specific parameters that are used for identifying or transporting the sender's key for static-static key agreement algorithms.
前のセクションで定義されたヘッダーパラメーターは、楕円曲線diffie-hellman（ECDH）キー契約アルゴリズムの受信証明書を識別するために使用されます。このセクションでは、静的静的キー契約アルゴリズムの送信者のキーを識別または輸送するために使用されるアルゴリズム固有のパラメーターを定義します。
These attributes are defined analogously to those in the previous section. There is no definition for the certificate bag, as the same attribute would be used for both the sender and recipient certificates.
これらの属性は、前のセクションの属性と同様に定義されています。送信者と受信者の両方の証明書に同じ属性が使用されるため、証明書バッグには定義はありません。
x5chain-sender:
x5chain-sender：
This header parameter contains the chain of certificates starting with the sender's key exchange certificate. The structure is the same as 'x5chain'.
このヘッダーパラメーターには、送信者のキー交換証明書から始まる証明書のチェーンが含まれています。構造は「x5chain」と同じです。
x5t-sender:
x5t-sender：
This header parameter contains the hash value for the sender's key exchange certificate. The structure is the same as 'x5t'.
このヘッダーパラメーターには、送信者のキー交換証明書のハッシュ値が含まれています。構造は「x5t」と同じです。
x5u-sender:
x5u-sender：
This header parameter contains a URI for the sender's key exchange certificate. The structure and processing are the same as 'x5u'.
このヘッダーパラメーターには、送信者のキー交換証明書のURIが含まれています。構造と処理は「x5u」と同じです。
+==============+=====+=============+===================+===========+
|Name |Label|Type | Algorithm |Description|
+==============+=====+=============+===================+===========+
|x5t-sender |-27 |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint |
| | | | ECDH-SS+HKDF-512, |for the |
| | | | ECDH-SS+A128KW, |sender's |
| | | | ECDH-SS+A192KW, |X.509 |
| | | | ECDH-SS+A256KW |certificate|
+--------------+-----+-------------+-------------------+-----------+
|x5u-sender |-28 |uri | ECDH-SS+HKDF-256, |URI for the|
| | | | ECDH-SS+HKDF-512, |sender's |
| | | | ECDH-SS+A128KW, |X.509 |
| | | | ECDH-SS+A192KW, |certificate|
| | | | ECDH-SS+A256KW | |
+--------------+-----+-------------+-------------------+-----------+
|x5chain-sender|-29 |COSE_X509 | ECDH-SS+HKDF-256, |static key |
| | | | ECDH-SS+HKDF-512, |X.509 |
| | | | ECDH-SS+A128KW, |certificate|
| | | | ECDH-SS+A192KW, |chain |
| | | | ECDH-SS+A256KW | |
+--------------+-----+-------------+-------------------+-----------+
Table 2: Static ECDH Algorithm Values
表2：静的ECDHアルゴリズム値
IANA has registered the new COSE Header parameters in Table 1 in the "COSE Header Parameters" registry. The "Value Registry" field is empty for all of the items. For each item, the "Reference" field points to this document.
IANAは、「COSEヘッダーパラメーター」レジストリに新しいCOSEヘッダーパラメーターを登録しています。「値レジストリ」フィールドは、すべてのアイテムに対して空です。各アイテムについて、「参照」フィールドはこのドキュメントを指します。
IANA has registered the new COSE Header Algorithm parameters in Table 2 in the "COSE Header Algorithm Parameters" registry. For each item, the "Reference" field points to this document.
IANAは、「COSEヘッダーアルゴリズムパラメーター」レジストリに表2に、新しいCOSEヘッダーアルゴリズムパラメーターを登録しています。各アイテムについて、「参照」フィールドはこのドキュメントを指します。
When the application/cose-x509 media type is used, the data is a CBOR sequence of single-entry COSE_X509 structures (encoding "bstr"). If the parameter "usage" is set to "chain", this sequence indicates a certificate chain.
アプリケーション/COSE-X509メディアタイプを使用すると、データは単一エントリCOSE_X509構造のCBORシーケンス（「BSTR」をエンコード）です。パラメーター「使用」が「チェーン」に設定されている場合、このシーケンスは証明書チェーンを示します。
IANA has registered the following media type [RFC6838]:
IANAは、次のメディアタイプ[RFC6838]を登録しました。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
cose-x509
COSE-X509
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
usage
使用法使い慣用例古格振り合い振合い俗習
* Can be absent to provide no further information about the intended meaning of the order in the CBOR sequence of certificates.
* 証明書のCBORシーケンスで順序の意図された意味に関するさらなる情報を提供しないことはありません。
* Can be set to "chain" to indicate that the sequence of data items is to be interpreted as a certificate chain.
* 「チェーン」に設定して、データ項目のシーケンスが証明書チェーンとして解釈されることを示すことができます。
Encoding considerations:
考慮事項のエンコード：
binary
バイナリバイナリー二進
Security considerations:
セキュリティ上の考慮事項：
See the Security Considerations section of RFC 9360.
RFC 9360のセキュリティに関する考慮事項セクションを参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9360
RFC 9360
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Applications that employ COSE and use X.509 as a certificate type.
COSEを採用し、X.509を証明書タイプとして使用するアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
iesg@ietf.org
iesg@ietf.org
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
COSE WG
COSE WG
Change controller:
Change Controller：
IESG
iesg
Establishing trust in a certificate is a vital part of processing. A major component of establishing trust is determining what the set of trust anchors are for the process. A new self-signed certificate appearing on the client cannot be a trigger to modify the set of trust anchors, because a well-defined trust-establishment process is required. One common way for a new trust anchor to be added to (or removed from) a device is by doing a new firmware upgrade.
証明書に信頼を確立することは、処理の重要な部分です。信頼を確立することの主要な要素は、プロセスのための信頼アンカーのセットが何であるかを決定することです。明確に定義された信頼確立プロセスが必要であるため、クライアントに表示される新しい自己署名証明書は、信頼アンカーのセットを変更するトリガーになることはできません。新しいトラストアンカーをデバイスに追加（または削除する）ための1つの一般的な方法は、新しいファームウェアのアップグレードを実行することです。
In constrained systems, there is a trade-off between the order of checking the signature and checking the certificate for validity. Validating certificates can require that network resources be accessed in order to get revocation information or retrieve certificates during path building. The resulting network access can consume power and network bandwidth. On the other hand, if the certificates are validated after the signature is validated, an oracle can potentially be built based on detecting the network resources, which is only done if the signature validation passes. In any event, both the signature validation and the certificate validation MUST be completed successfully before acting on any requests.
制約されたシステムでは、署名をチェックする順序と証明書の有効性の確認との間にトレードオフがあります。証明書の検証では、パスビルディング中に取り消し情報を取得したり、証明書を取得したりするために、ネットワークリソースにアクセスする必要があります。結果のネットワークアクセスは、電力とネットワークの帯域幅を消費できます。一方、署名が検証された後に証明書が検証された場合、ネットワークリソースの検出に基づいてOracleを構築できます。これは、署名検証が通過した場合にのみ行われます。いずれにせよ、リクエストに基づいて行動する前に、署名検証と証明書の検証の両方を正常に完了する必要があります。
Unless it is known that the Certificate Authority (CA) required proof of possession of the subject's private key to issue an end-entity certificate, the end-entity certificate MUST be integrity protected by COSE. Without proof of possession, an attacker can trick the CA into issuing an identity-misbinding certificate with someone else's "borrowed" public key but with a different subject. An on-path attacker can then perform an identity-misbinding attack by replacing the real end-entity certificate in COSE with such an identity-misbinding certificate.
証明書当局（CA）が、エンドエンティティ証明書を発行するために被験者の秘密鍵を所有することの証明を必要としていないことが知られていない限り、End-Entity証明書はCOSEによって保護されている必要があります。所持の証明がなければ、攻撃者はCAをだまして、他の誰かの「借りた」公開鍵とは異なる主題を使用して、アイデンティティ測定証明書を発行することができます。その後、Pathオンパス攻撃者は、COSEの実際のエンドエンティティ証明書をそのようなアイデンティティ測定証明書に置き換えることにより、ID測定攻撃を実行できます。
End-entity X.509 certificates contain identities that a passive on-path attacker eavesdropping on the conversation can use to identify and track the subject. COSE does not provide identity protection by itself, and the 'x5t' and 'x5u' header parameters are just alternative permanent identifiers and can also be used to track the subject. To provide identity protection, COSE can be sent inside another security protocol providing confidentiality.
エンドエンティティX.509証明書には、会話を装備するパッシブオンパス攻撃者が主題を特定して追跡するために使用できるアイデンティティが含まれています。COSEはそれ自体でアイデンティティ保護を提供せず、「X5T」および「X5U」ヘッダーパラメーターは単なる代替永久識別子であり、被験者の追跡にも使用できます。身元保護を提供するために、COSEを別のセキュリティプロトコル内に送信して機密性を提供できます。
Before using the key in a certificate, the key MUST be checked against the algorithm to be used, and any algorithm-specific checks need to be made. These checks can include validating that points are on curves for elliptical curve algorithms and that the sizes of RSA keys are within an acceptable range. The use of unvalidated keys can lead to either loss of security or excessive consumption of resources (for example, using a 200K RSA key).
証明書にキーを使用する前に、使用するアルゴリズムに対してキーをチェックする必要があり、アルゴリズム固有のチェックを作成する必要があります。これらのチェックには、ポイントが楕円曲線アルゴリズムの曲線上にあること、およびRSAキーのサイズが許容範囲内にあることを検証することが含まれます。バリデートされていないキーを使用すると、セキュリティの喪失またはリソースの過度の消費のいずれかにつながる可能性があります（たとえば、200k RSAキーを使用）。
When processing the 'x5u' header parameter, the security considerations of [RFC3986], and specifically those defined in Section 7.1 of [RFC3986], also apply.
「X5U」ヘッダーパラメーターを処理する場合、[RFC3986]のセキュリティ上の考慮事項、特に[RFC3986]のセクション7.1で定義されているセキュリティに関する考慮事項も適用されます。
Regardless of the source, certification path validation is an important part of establishing trust in a certificate. Section 6 of [RFC5280] provides guidance for the path validation. The security considerations of [RFC5280] are also important for the correct usage of this document.
ソースに関係なく、認証パス検証は、証明書に信頼を確立する上で重要な部分です。[RFC5280]のセクション6では、パス検証のガイダンスを提供します。[RFC5280]のセキュリティ上の考慮事項は、このドキュメントの正しい使用法にとっても重要です。
Protecting the integrity of the 'x5bag', 'x5chain', and 'x5t' contents by placing them in the protected header bucket can help mitigate some risks of a misbehaving CA (cf. Section 5.1 of [RFC2634]).
保護されたヘッダーバケットにそれらを配置することにより、「x5bag」、「x5chain」、および「x5t」の内容の完全性を保護することは、誤動作のリスクを軽減するのに役立ちます（[rfc2634]のセクション5.1を参照）。
The security of the algorithm used for 'x5t' does not affect the security of the system, as this header parameter selects which certificate that is already present on the system should be used, but it does not provide any trust.
「x5t」に使用されるアルゴリズムのセキュリティは、システムに既に存在する証明書を使用する必要があるが、信頼を提供しないため、システムのセキュリティに影響を与えません。
[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>.
[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>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[Constrained-BRSKI]
Richardson, M., van der Stok, P., Kampanakis, P., and E.
Dijk, "Constrained Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
draft-ietf-anima-constrained-voucher-19, 2 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
constrained-voucher-19>.
[EDHOC] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
Progress, Internet-Draft, draft-ietf-lake-edhoc-19, 3
February 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lake-edhoc-19>.
[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>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/info/rfc2634>.
[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>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[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>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[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>.
Jim Schaad passed on 3 October 2020. This document is primarily his work. Ivaylo Petrov served as the document editor after Jim's untimely death, mostly helping with the approval and publication processes. Jim deserves all credit for the technical content.
ジム・シャードは2020年10月3日に可決されました。この文書は主に彼の仕事です。Ivaylo Petrovは、ジムの早すぎる死後、文書編集者を務めました。ジムは、技術コンテンツのすべてのクレジットに値します。
Jim Schaad
August Cellars