Internet Engineering Task Force (IETF) O. Steele
Request for Comments: 9995
Category: Standards Track S. Lasker
ISSN: 2070-1721
H. Birkholz
Fraunhofer SIT
July 2026
This document defines new CBOR Object Signing and Encryption (COSE) header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find the original payload content.
この文書では、ハッシュ関数の出力としてペイロードを通知するための新しい CBOR Object Signing and Encryption (COSE) ヘッダー パラメーターを定義します。このメカニズムにより、署名の検証に元のペイロードへのアクセスが必要ないため、より高速な検証が可能になります。さらに、ハッシュされたペイロードのコンテンツ形式と可用性のヒントが定義され、元のペイロード コンテンツの検索に役立つオプションの検出メカニズムへの参照が提供されます。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9995.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9995 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Header Parameters
4. Hash Envelope CDDL
4.1. Envelope Extended Diagnostic Notation
5. Security Considerations
5.1. Choice of Hash Function
5.2. COSE_Encrypt
5.3. Payload Verification
6. IANA Considerations
6.1. COSE Header Parameters
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
Section 2 of [RFC9052] defines detached payloads for COSE, using nil as the payload. In order to verify a COSE_Sign or a COSE_Mac, the recipient requires access to the payload content. Hashes are already used on a regular basis as identifiers for payload data, such as documents or software components. As hashes typically are smaller than the payload data they represent, they are simpler to transport. Additional hints in the protected header ensure cryptographic agility for the hashing and signing algorithms. Hashes and other identifiers are commonly used as hints to discover and distinguish resources. Using a hash as an identifier for a resource has the advantage of enabling integrity checking.
[RFC9052] のセクション 2 では、ペイロードとして nil を使用する、COSE の切り離されたペイロードを定義しています。COSE_Sign または COSE_Mac を検証するには、受信者がペイロード コンテンツにアクセスする必要があります。ハッシュは、ドキュメントやソフトウェア コンポーネントなどのペイロード データの識別子としてすでに定期的に使用されています。通常、ハッシュはそれが表すペイロード データよりも小さいため、転送が簡単になります。保護されたヘッダー内の追加のヒントにより、ハッシュおよび署名アルゴリズムの暗号化の俊敏性が保証されます。ハッシュやその他の識別子は、リソースを発見して区別するためのヒントとして一般的に使用されます。リソースの識別子としてハッシュを使用すると、整合性チェックが可能になるという利点があります。
In some applications, such as remote signing procedures, conveyance of hashes instead of original payload content reduces transmission time and costs.
リモート署名手順などの一部のアプリケーションでは、元のペイロード コンテンツの代わりにハッシュを送信することで、送信時間とコストが削減されます。
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 terms "COSE" and "CDDL" are defined in [RFC9052] and [RFC8610], respectively. The term "payload" is defined in Section 4.1 of [RFC9052] for COSE_Sign and in Section 6.1 of [RFC9052] for COSE_Mac. The term "preimage" refers to the set of input values to a function that produce a given output, called the "image". A hash function applied to a message (preimage) produces a digest value (image).
「COSE」と「CDDL」という用語は、それぞれ [RFC9052] と [RFC8610] で定義されています。「ペイロード」という用語は、COSE_Sign については [RFC9052] のセクション 4.1 で定義され、COSE_Mac については [RFC9052] のセクション 6.1 で定義されています。「プリイメージ」という用語は、「イメージ」と呼ばれる特定の出力を生成する関数への入力値のセットを指します。メッセージ (プリイメージ) に適用されるハッシュ関数は、ダイジェスト値 (イメージ) を生成します。
This document specifies the following new header parameters commonly used alongside hashes to identify resources:
このドキュメントでは、リソースを識別するためにハッシュと一緒に一般的に使用される次の新しいヘッダー パラメーターを指定します。
258:
258:
The hash algorithm used to produce the payload.
ペイロードの生成に使用されるハッシュ アルゴリズム。
259:
259:
The content type of the bytes that were hashed (preimage) to produce the payload, given as a content-format number (Section 12.3 of [RFC7252]) or as a media-type name optionally with parameters (Section 8.3 of [RFC9110]).
ペイロードを生成するためにハッシュされたバイト (プリイメージ) のコンテンツ タイプ。コンテンツ フォーマット番号 ([RFC7252] のセクション 12.3)、またはオプションでパラメータを含むメディア タイプ名 ([RFC9110] のセクション 8.3) として指定されます。
260:
260:
An identifier enabling retrieval of the original resource (preimage) identified by the payload.
ペイロードによって識別される元のリソース (プリイメージ) の取得を可能にする識別子。
Hash_Envelope = #6.18(Hash_Envelope_as_COSE_Sign1)
Hash_Envelope_as_COSE_Sign1 = [
protected: bstr .cbor Hash_Envelope_Protected_Header,
unprotected: Hash_Envelope_Unprotected_Header,
payload: bstr / nil,
signature: bstr
]
Hash_Envelope_Protected_Header = {
? &(alg: 1) => int,
&(payload_hash_alg: 258) => int,
? &(payload_preimage_content_type: 259) => uint / tstr,
? &(payload_location: 260) => tstr,
* (int / tstr) => any
}
Hash_Envelope_Unprotected_Header = {
* (int / tstr) => any
}
* Label 1 (alg) is the cryptographic algorithm to use.
* ラベル 1 (alg) は、使用する暗号アルゴリズムです。
* Label 258 (payload_hash_alg) MUST be present in the protected header and MUST NOT be present in the unprotected header.
* ラベル 258 (payload_hash_alg) は、保護されたヘッダーに存在しなければならず、保護されていないヘッダーには存在してはなりません。
* Label 259 (payload_preimage_content_type) MAY be present in the protected header and MUST NOT be present in the unprotected header.
* ラベル 259 (payload_preimage_content_type) は、保護されたヘッダーに存在してもよく、保護されていないヘッダーには存在してはなりません (MUST NOT)。
* Label 260 (payload_location) MAY be present in the protected header and MUST NOT be present in the unprotected header.
* ラベル 260 (payload_location) は、保護されたヘッダーに存在してもよく、保護されていないヘッダーには存在してはなりません (MUST NOT)。
* Label 3 (content_type) MUST NOT be present in the protected or unprotected headers.
* ラベル 3 (content_type) は、保護されたヘッダーまたは保護されていないヘッダーに存在してはなりません。
Label 3 (content_type) is easily confused with Label 259 (payload_preimage_content_type). The difference between content_type (3) and payload_preimage_content_type (259) is that content_type is used to identify the content format associated with payload, whereas payload_preimage_content_type is used to identify the content format of the bytes that are hashed to produce the payload.
ラベル 3 (content_type) は、ラベル 259 (payload_preimage_content_type) と混同されやすいです。content_type (3) と payload_preimage_content_type (259) の違いは、content_type はペイロードに関連付けられたコンテンツ形式を識別するために使用されるのに対し、payload_preimage_content_type はペイロードを生成するためにハッシュされるバイトのコンテンツ形式を識別するために使用されることです。
Output from hash algorithms is generally small; thus, the payload is typically expected to be inline. But it can also be detached, as in any other COSE message [RFC9052].
ハッシュ アルゴリズムからの出力は一般に小さいです。したがって、通常、ペイロードはインラインであることが予想されます。しかし、他の COSE メッセージ [RFC9052] と同様に、切り離すこともできます。
For example, when the actual content is a byte string (bstr), a verifier appraising the payload has to decide whether that bstr represents the digest bytes or the preimage bytes. Setting payload_preimage_content_type to bstr makes clear that the preimage bytes themselves were a bstr.
たとえば、実際のコンテンツがバイト文字列 (bstr) である場合、ペイロードを評価する検証者は、その bstr がダイジェスト バイトを表すかプレイメージ バイトを表すかを判断する必要があります。payload_preimage_content_type を bstr に設定すると、プリイメージのバイト自体が bstr であることが明確になります。
The following informative example uses Extended Diagnostic Notation as defined in Appendix G of [RFC8610] and demonstrates how to construct a hash envelope for a resource already commonly referenced by its hash.
次の有益な例では、[RFC8610] の付録 G で定義されている拡張診断表記法を使用し、ハッシュによってすでに共通に参照されているリソースのハッシュ エンベロープを構築する方法を示します。
18([ # COSE_Sign1
<<{
/ signature alg / 1: -35, # ES384
/ key identifier / 4: h'75726e3a...32636573',
/ COSE_Sign1 type / 16: "application/example+cose",
/ hash algorithm / 258: -16, # sha256
/ media type / 259: "application/spdx+json",
/ location /
260: "https://sbom.example/.../manifest.spdx.json"
}>>
/ unprotected / {},
/ payload / h'935b5a91...e18a588a',
# SHA-256 digest of manifest.spdx.json"
/ signature / h'15280897...93ef39e5'
# ECDSA Signature with SHA-384 and P-384
])
In this example, a System Package Data Exchange [SPDX] Software Bill of Materials (SBOM) in JSON format is already commonly identified by its SHA-256 hash. The content type for "manifest.spdx.json" is already well known as "application/spdx+json" and is registered with IANA (https://www.iana.org/assignments/media-types/application/ spdx+json).
この例では、JSON 形式の System Package Data Exchange [SPDX] ソフトウェア部品表 (SBOM) が、SHA-256 ハッシュによってすでに一般的に識別されています。「manifest.spdx.json」のコンテンツ タイプは「application/spdx+json」としてすでによく知られており、IANA (https://www.iana.org/assignments/media-types/application/spdx+json) に登録されています。
The full JSON SBOM is available at a URL, such as "https://sbom.example/.../manifest.spdx.json".
完全な JSON SBOM は、「https://sbom.example/.../manifest.spdx.json」などの URL で入手できます。
The payload of this COSE_Sign1 is the SHA-256 hash of "manifest.spdx.json".
この COSE_Sign1 のペイロードは、「manifest.spdx.json」の SHA-256 ハッシュです。
The type of this COSE_Sign1 is "application/example+cose", but other types may be used to establish more-specific media types for signatures of hashes.
この COSE_Sign1 のタイプは「application/example+cose」ですが、ハッシュの署名のより具体的なメディア タイプを確立するために他のタイプを使用することもできます。
The signature is produced using ES384, as defined in Section 3.4 of [RFC7518], which means using the Elliptic Curve Digital Signature Algorithm (ECDSA) with the SHA-384 hash function and P-384 elliptic curve.
署名は、[RFC7518] のセクション 3.4 で定義されている ES384 を使用して生成されます。これは、SHA-384 ハッシュ関数と P-384 楕円曲線を備えた楕円曲線デジタル署名アルゴリズム (ECDSA) を使用することを意味します。
This example is chosen to highlight that an existing system may use a hash algorithm such as SHA-256. This hash becomes the payload of a COSE_Sign1. When signed with a signature algorithm that is parameterized via a hash function, such as ECDSA with SHA-384, the to-be-signed structure is as described in Section 4.4 of [RFC9052].
この例は、既存のシステムが SHA-256 などのハッシュ アルゴリズムを使用する可能性があることを強調するために選択されています。このハッシュは COSE_Sign1 のペイロードになります。SHA-384 を使用した ECDSA など、ハッシュ関数を介してパラメータ化された署名アルゴリズムで署名される場合、署名される構造は [RFC9052] のセクション 4.4 に記載されているとおりです。
The resulting signature is computed over the protected header and payload, providing integrity and authenticity for the hash algorithm, content type, and location of the associated resource, in this case a software bill of materials.
結果として得られる署名は、保護されたヘッダーとペイロードに対して計算され、ハッシュ アルゴリズム、コンテンツ タイプ、関連リソース (この場合はソフトウェア部品表) の場所の整合性と信頼性が提供されます。
The hash/signature algorithm combination is RECOMMENDED to be at least as strong as the payload hash algorithm. For example, if the payload was produced with SHA-256, and is signed with ECDSA, use at least P-256 and SHA-256. Note that, when using a pre-hash algorithm, the algorithm MUST be registered in the IANA "COSE Algorithms" registry [COSE-Algorithms] and MUST be distinguishable from non-pre-hash variants that may also be present.
ハッシュ/署名アルゴリズムの組み合わせは、少なくともペイロード ハッシュ アルゴリズムと同じくらい強力であることが推奨されます。たとえば、ペイロードが SHA-256 で生成され、ECDSA で署名されている場合は、少なくとも P-256 と SHA-256 を使用します。プレハッシュ アルゴリズムを使用する場合、そのアルゴリズムは IANA "COSE Algorithms" レジストリ [COSE-Algorithms] に登録されなければならず、また存在する可能性のある非プレハッシュ バリアントと区別できなければならないことに注意してください。
Only COSE_Sign/COSE_Sign1 and COSE_Mac/COSE_Mac0 are in scope for this document. COSE_Encrypt/COSE_Encrypt0 is out of scope for this document. At the time of publication, there is no known use case for COSE_Encrypt/COSE_Encrypt0. It may be covered by a future extension, which would address whether the hash function is applied before or after encryption and clarify privacy considerations.
このドキュメントの対象となるのは、COSE_Sign/COSE_Sign1 および COSE_Mac/COSE_Mac0 のみです。COSE_Encrypt/COSE_Encrypt0 はこのドキュメントの範囲外です。公開時点では、COSE_Encrypt/COSE_Encrypt0 の既知の使用例はありません。これは将来の拡張機能でカバーされる可能性があり、ハッシュ関数が暗号化の前後に適用されるかどうかに対処し、プライバシーの考慮事項が明確になります。
If a payload-location is specified, a verifier can choose to fetch the content and confirm that the digest of it, produced with the function defined by payload-hash-alg, matches the payload bytes. Verifiers that do not have access to the internet and obtain the preimage via other means will not be able to perform that check nor to derive utility from it.
payload-location が指定されている場合、検証者はコンテンツをフェッチし、payload-hash-alg で定義された関数で生成されたそのダイジェストがペイロード バイトと一致することを確認することを選択できます。インターネットにアクセスできず、他の手段でプリイメージを取得できない検証者は、そのチェックを実行することも、そこからユーティリティを引き出すこともできません。
IANA has registered the COSE header parameters defined in Section 3 (as listed in Table 1) in the "COSE Header Parameters" registry [COSE-HDR-PARAMS]. They have been registered in the 'Integer values from 256 to 65535' range per the 'Specification Required' registration policy [RFC8126].
IANA は、セクション 3 で定義されている COSE ヘッダー パラメーター (表 1 にリストされている) を「COSE ヘッダー パラメーター」レジストリ [COSE-HDR-PARAMS] に登録しました。これらは、「仕様が必要」登録ポリシー [RFC8126] に従って、「256 ～ 65535 の整数値」の範囲で登録されています。
+=========+=====+======+======================+===========+=========+
|Name |Label|Value |Value Registry |Description|Reference|
| | |Type | | | |
+=========+=====+======+======================+===========+=========+
|payload- |258 |int |[COSE-Algorithms] |The hash |RFC 9995,|
|hash-alg | | | |algorithm |Section 3|
| | | | |used to | |
| | | | |produce the| |
| | | | |payload of | |
| | | | |a | |
| | | | |COSE_Sign1 | |
+---------+-----+------+----------------------+-----------+---------+
|preimage-|259 |uint /|[CoAP-Content-Formats]|The |RFC 9995,|
|content- | |tstr | |content- |Section 3|
|type | | | |format | |
| | | | |number or | |
| | | | |content- | |
| | | | |type | |
| | | | |(media-type| |
| | | | |name) of | |
| | | | |data that | |
| | | | |has been | |
| | | | |hashed to | |
| | | | |produce the| |
| | | | |payload of | |
| | | | |the | |
| | | | |COSE_Sign1 | |
+---------+-----+------+----------------------+-----------+---------+
|payload- |260 |tstr |(none) |The string |RFC 9995,|
|location | | | |or URI hint|Section 3|
| | | | |for the | |
| | | | |location of| |
| | | | |the data | |
| | | | |hashed to | |
| | | | |produce the| |
| | | | |payload of | |
| | | | |a | |
| | | | |COSE_Sign1 | |
+---------+-----+------+----------------------+-----------+---------+
Table 1: Newly Registered COSE Header Parameters
表 1: 新しく登録された COSE ヘッダー パラメーター
[COSE-HDR-PARAMS]
IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[CoAP-Content-Formats]
IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/cose>.
[COSE-Algorithms]
IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[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>.
[SPDX] "SPDX Specification",
<https://spdx.dev/use/specifications/>.
The following individuals provided input into the final form of the document: Carsten Bormann, Antoine Delignat-Lavaud, and Cedric Fournet.
Carsten Bormann、Antoine Delignat-Lavaud、Cedric Fournet の各氏が文書の最終形式に意見を提供しました。
Orie Steele
Email: orie@or13.io
Steve Lasker
Email: stevenlasker@hotmail.com
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact