Internet Engineering Task Force (IETF) O. Steele
Request for Comments: 9942 Tradeverifyd
Category: Standards Track H. Birkholz
ISSN: 2070-1721 Fraunhofer SIT
A. Delignat-Lavaud
C. Fournet
Microsoft
June 2026
CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs.
CBOR オブジェクト署名および暗号化 (COSE) の受領書は、検証可能なデータ構造 (VDS) のプロパティを検証者に証明します。VDS および関連するプルーフ タイプにより、最小限の開示、透明性、曖昧さの防止などのセキュリティ プロパティが有効になります。透明性は長期にわたって信頼を維持するのに役立ち、証明書、エンドツーエンドの暗号化メッセージング システム、サプライ チェーンのセキュリティに適用されています。この仕様は、CBOR (Concise Binary Object Representation) と COSE に基づいて構築することにより、簡潔な透過性指向のシステムを可能にします。このアプローチの拡張性は、マークル包含および一貫性証明のための CBOR エンコーディングを提供することによって実証されます。
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/rfc9942.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9942 で入手できます。
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
1.1. Requirements Notation
2. New COSE Header Parameters
3. Terminology
4. VDSs in CBOR
4.1. Structures
4.2. Proofs
4.3. Usage
4.4. Profiles
4.4.1. Registration Requirements
5. RFC9162_SHA256
5.1. Verifiable Data Structure
5.2. Inclusion Proof
5.2.1. Receipt of Inclusion
5.3. Consistency Proof
5.3.1. Receipt of Consistency
6. Privacy Considerations
6.1. Log Length
6.2. Header Parameters
7. Security Considerations
7.1. Choice of Signature Algorithms
7.2. Validity Period
7.3. Status Updates
8. IANA Considerations
8.1. COSE Header Parameter
8.2. VDS Registries
8.2.1. Expert Review
8.2.2. Templates and Initial Contents
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
COSE Receipts are signed proofs that include metadata about certain states of a Verifiable Data Structure (VDS) that are true when the COSE Receipt was issued. COSE Receipts can include proofs that a document is in a database (proof of inclusion), that a database is append-only (proof of consistency), that a smaller set of statements are contained in a large set of statements (proof of disclosure, a special case of proof of inclusion), or that certain data is not yet present in a database (proof of non-inclusion). Different VDSs can produce different Verifiable Data Structure Proofs (VDPs). The combination of representations of various VDSs and VDP can significantly increase the burden for implementers and create interoperability challenges for transparency services. This document describes how to convey VDS and associated VDP types in unified Enveloped COSE Structures.
COSE 領収書は、COSE 領収書が発行されたときに真であった検証可能なデータ構造 (VDS) の特定の状態に関するメタデータを含む署名付き証明です。COSE 受領書には、文書がデータベース内にあること (包含の証明)、データベースが追加専用であること (一貫性の証明)、大規模なステートメントのセットに小規模なステートメントのセットが含まれていること (開示の証明、包含の証明の特殊なケース)、または特定のデータがデータベースにまだ存在していないこと (非包含の証明) を含めることができます。異なる VDS は、異なる Verifiable Data Structure Proofs (VDP) を生成できます。さまざまな VDS と VDP の表現を組み合わせると、実装者の負担が大幅に増加し、透明性サービスの相互運用性の課題が生じる可能性があります。このドキュメントでは、統合されたエンベロープ COSE 構造で VDS および関連する VDP タイプを伝達する方法について説明します。
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] で説明されているように解釈されます。
This document defines three new COSE header parameters, which are introduced up front in this section and elaborated on later in this document.
このドキュメントでは、3 つの新しい COSE ヘッダー パラメーターを定義します。これらはこのセクションで最初に紹介され、このドキュメントの後半で詳しく説明されます。
394:
394:
A COSE header parameter named "receipts" with a value type of array where the array contains one or more COSE Receipts as specified in this document.
配列の値型を持つ「receipts」という名前の COSE ヘッダー パラメーター。このドキュメントで指定されているように、配列には 1 つ以上の COSE Receipts が含まれます。
395:
395:
A COSE header parameter named "vds" (for Verifiable Data Structure), which conveys the algorithm identifier for a VDS. Correspondingly, see Section 8.2.2.1 for a registry defining the integers used to identify VDSs.
「vds」(Verifiable Data Structure の略) という名前の COSE ヘッダー パラメーター。VDS のアルゴリズム識別子を伝えます。同様に、VDS の識別に使用される整数を定義するレジストリについては、セクション 8.2.2.1 を参照してください。
396:
396:
A COSE header parameter named "vdp" (for VDPs), which conveys a map containing VDPs organized by Proof Type. Correspondingly, see Section 8.2.2.2 for a registry defining the integers used to identify VDS Proof Types.
「vdp」(VDP の場合) という名前の COSE ヘッダー パラメーター。プルーフ タイプごとに編成された VDP を含むマップを伝えます。同様に、VDS プルーフ タイプの識別に使用される整数を定義するレジストリについては、セクション 8.2.2.2 を参照してください。
The terms "header" and "payload" are defined in [STD96]. The term "claim" is defined in [RFC8392].
「ヘッダ」と「ペイロード」という用語は[STD96]で定義されています。「クレーム」という用語は[RFC8392]で定義されています。
Additionally, this document uses the following terminology:
さらに、このドキュメントでは次の用語を使用します。
CDDL:
CDDL:
Concise Data Definition Language (CDDL) is defined in [RFC8610].
簡潔なデータ定義言語 (CDDL) は [RFC8610] で定義されています。
EDN:
EDN:
CBOR Extended Diagnostic Notation (EDN) is defined in [RFC8949], where it is referred to as "diagnostic notation", and is revised in [CBOR-EDN].
CBOR 拡張診断表記法 (EDN) は [RFC8949] で定義されており、そこでは「診断表記法」と呼ばれ、[CBOR-EDN] で改訂されています。
Entry:
エントリ：
An entry in a VDS for which proofs can be derived.
プルーフを導出できる VDS 内のエントリ。
Proof Type:
証明の種類:
A property that can be obtained by verifying a given proof over one or more entries in a VDS. For example, a VDS, such as a binary Merkle Tree, can support inclusion proofs where each proof confirms that a given entry is included in a Merkle Tree root.
VDS 内の 1 つ以上のエントリに対して特定の証明を検証することによって取得できるプロパティ。たとえば、バイナリ マークル ツリーなどの VDS は、指定されたエントリがマークル ツリー ルートに含まれていることを各証明で確認する包含証明をサポートできます。
Proof Value:
証明値:
An encoding of a Proof Type in CBOR [RFC8949].
CBOR [RFC8949] における Proof Type のエンコーディング。
Receipt:
レシート：
A COSE Single Signer Data Object, as defined in RFC 9052 of [STD96], containing the header parameters necessary to convey one or more VDP for an associated VDS.
[STD96] の RFC 9052 で定義されている COSE 単一署名者データ オブジェクト。関連付けられた VDS の 1 つ以上の VDP を伝達するために必要なヘッダー パラメーターが含まれます。
Verifiable Data Structure (VDS):
検証可能なデータ構造 (VDS):
A data structure that supports one or more VDS Proof Types. This property describes an algorithm used to maintain a VDS, for example, a binary Merkle Tree algorithm.
1 つ以上の VDS プルーフ タイプをサポートするデータ構造。このプロパティは、VDS を維持するために使用されるアルゴリズム (バイナリ マークル ツリー アルゴリズムなど) を記述します。
Verifiable Data Structure Proof (VDP):
検証可能なデータ構造証明 (VDP):
A data structure used to convey Proof Types for proving different properties, such as authentication, inclusion, consistency, and freshness. Parameters can include multiple proofs of a given type or multiple types of proof (inclusion and consistency).
認証、包含、一貫性、鮮度などのさまざまなプロパティを証明するための証明タイプを伝達するために使用されるデータ構造。パラメーターには、特定のタイプの複数のプルーフ、または複数のタイプのプルーフ (包含および一貫性) を含めることができます。
This section describes representations of VDPs in [RFC8949]. For example, construction of a Merkle Tree leaf or an inclusion proof from a leaf to a Merkle Tree root might have several different representations, depending on the VDS used. Differences in representations are necessary to support efficient verification, unique security or privacy properties, and for compatibility with specific implementations. This document defines two extension points for enabling VDSs with COSE and provides concrete examples for the structures and proofs defined in Section 2.1.3 of [RFC9162] and Section 2.1.4 of [RFC9162]. The design of these structures is influenced by the conventions established for COSE Keys.
このセクションでは、[RFC8949] における VDP の表現について説明します。たとえば、マークル ツリー リーフの構築、またはリーフからマークル ツリー ルートまでの包含証明は、使用される VDS に応じて、いくつかの異なる表現を持つ可能性があります。表現の違いは、効率的な検証、独自のセキュリティまたはプライバシーのプロパティをサポートし、特定の実装との互換性を確保するために必要です。この文書は、COSE で VDS を有効にするための 2 つの拡張ポイントを定義し、[RFC9162] のセクション 2.1.3 および [RFC9162] のセクション 2.1.4 で定義されている構造と証明の具体的な例を提供します。これらの構造の設計は、COSE キーに対して確立された規則の影響を受けます。
Similar to COSE Key Types [IANA.cose_header-parameters], different VDSs support different algorithms.
COSE キー タイプ [IANA.cose_header-parameters] と同様に、異なる VDS は異なるアルゴリズムをサポートします。
This document establishes a registry of VDS algorithms; see Section 8.2.2.1 for details.
この文書は、VDS アルゴリズムのレジストリを確立します。詳細については、セクション 8.2.2.1 を参照してください。
As is the case for COSE Key Type Parameters [IANA.cose_header-parameters], EC2 keys (1: 2) require and give meaning to specific parameters, such as -1 (crv), -2 (x), -3 (y), and -4 (d). RFC9162_SHA256 (395: 1) supports both (-1) inclusion and (-2) consistency proofs.
COSE キー タイプ パラメータ [IANA.cose_header-parameters] の場合と同様、EC2 キー (1:2) は、-1 (crv)、-2 (x)、-3 (y)、-4 (d) などの特定のパラメータを必要とし、そのパラメータに意味を与えます。RFC9162_SHA256 (395: 1) は、(-1) 包含証明と (-2) 整合性証明の両方をサポートします。
This document establishes a registry of VDS algorithm proofs; see Section 8.2.2.2 for details.
この文書は、VDS アルゴリズム証明のレジストリを確立します。詳細については、セクション 8.2.2.2 を参照してください。
Proof Types are specific to their associated "Verifiable Data Structure"; for example, different Merkle Trees might support different representations of inclusion proof or consistency proof. Implementers should not expect interoperability across "Verifiable Data Structures". Security analysis MUST be conducted prior to migrating to new structures to ensure the new security and privacy assumptions are acceptable for the use case.
証明タイプは、関連付けられた「検証可能なデータ構造」に固有です。たとえば、異なるマークル ツリーは、包含証明や一貫性証明の異なる表現をサポートする場合があります。実装者は、「検証可能なデータ構造」間の相互運用性を期待すべきではありません。新しいセキュリティとプライバシーの前提がユースケースに受け入れられることを確認するために、新しい構造に移行する前にセキュリティ分析を実行する必要があります。
This document registers a new COSE header parameter "receipts" (394) to enable Receipts to be conveyed in the protected and unprotected headers of Enveloped COSE Structures.
この文書は、新しい COSE ヘッダー パラメーター「receipts」(394) を登録して、Enveloped COSE 構造の保護されたヘッダーと保護されていないヘッダーで受領書を伝達できるようにします。
When the "receipts" header parameter is present, the verifier MUST confirm that the associated VDS and VDPs match entries present in the registries established in this specification, including values added in subsequent registrations.
「receipts」ヘッダーパラメータが存在する場合、検証者は、関連する VDS および VDP が、後続の登録で追加される値を含め、この仕様で確立されたレジストリに存在するエントリと一致することを確認しなければなりません (MUST)。
Receipts MUST be tagged as COSE_Sign1.
領収書には COSE_Sign1 というタグを付ける必要があります。
Figure 1 defines how Receipts are included in a COSE_Sign1 data item:
図 1 は、COSE_Sign1 データ項目に領収書がどのように含まれるかを定義しています。
Signature_With_Receipt = #6.18(COSE_Sign1)
cose-label = int / text
cose-values = any
Protected_Header = {
* cose-label => cose-values
}
Unprotected_Header = {
&(receipts: 394) => [+ bstr .cbor Receipt]
* cose-label => cose-values
}
COSE_Sign1 = [
protected : bstr .cbor Protected_Header
unprotected : Unprotected_Header
payload : bstr / nil
signature : bstr
]
Receipt = Receipt_For_Inclusion / Receipt_For_Consistency
; Note the proof formats shown here are for RFC9162_SHA256.
; Other VDSs may have different proof formats.
Receipt_For_Inclusion = #6.18(Signed_Inclusion_Proof)
Signed_Inclusion_Proof = [
protected :
bstr .cbor RFC9162_SHA256_Inclusion_Protected_Header,
unprotected : RFC9162_SHA256_Inclusion_Unprotected_Header,
payload : bstr / nil,
signature : bstr
]
RFC9162_SHA256_Inclusion_Protected_Header = {
&(alg: 1) => int
&(vds: 395) => int
* cose-label => cose-values
}
RFC9162_SHA256_Inclusion_Unprotected_Header = {
&(vdp: 396) => RFC9162_SHA256_Verifiable_Inclusion_Proofs
* cose-label => cose-values
}
RFC9162_SHA256_Verifiable_Inclusion_Proofs = {
&(inclusion-proof: -1) => RFC9162_SHA256_Inclusion_Proofs
}
RFC9162_SHA256_Inclusion_Proofs = [
+ RFC9162_SHA256_Inclusion_Proof
]
RFC9162_SHA256_Inclusion_Proof =
bstr .cbor RFC9162_SHA256_Inclusion_Proof_Content
RFC9162_SHA256_Inclusion_Proof_Content = [
tree_size: uint,
leaf_index: uint,
inclusion_path:[ + bstr ]
]
Receipt_For_Consistency = #6.18(Signed_Consistency_Proof)
Signed_Consistency_Proof = [
protected :
bstr .cbor RFC9162_SHA256_Consistency_Protected_Header,
unprotected : RFC9162_SHA256_Consistency_Unprotected_Header,
payload : bstr / nil, ; Newer Merkle Tree root
signature : bstr
]
RFC9162_SHA256_Consistency_Protected_Header = {
&(alg: 1) => int,
&(vds: 395) => int,
* cose-label => cose-values
}
RFC9162_SHA256_Consistency_Unprotected_Header = {
&(vdp: 396) => RFC9162_SHA256_Verifiable_Consistency_Proofs
* cose-label => cose-values
}
RFC9162_SHA256_Verifiable_Consistency_Proofs = {
&(consistency-proof: -2) => RFC9162_SHA256_Consistency_Proofs
}
RFC9162_SHA256_Consistency_Proofs = [
+ RFC9162_SHA256_Consistency_Proof
]
RFC9162_SHA256_Consistency_Proof =
bstr .cbor RFC9162_SHA256_Consistency_Proof_Content
RFC9162_SHA256_Consistency_Proof_Content = [
tree_size_1: uint,
tree_size_2: uint,
consistency_path: [ + bstr ]
]
Figure 1: CDDL for a COSE_Sign1 with Attached Receipts
図 1: 領収書が添付された COSE_Sign1 の CDDL
The following informative EDN is provided:
次の有益な EDN が提供されます。
/ cose-sign1 / 18([
/ protected / <<{
/ kid / 4 : h'bc297b51...e4edf0de',
/ algorithm / 1 : -7, # ES256
}>>,
/ unprotected / {
/ receipts / 394 : [
<</ cose-sign1 / 18([
/ protected / <<{
/ kid / 4 : h'abcdef12...34567890',
/ algorithm / 1 : -7, # ES256
/ vds / 395 : 1, # RFC9162_SHA256
}>>,
/ unprotected / {
/ proofs / 396 : {
/ inclusion / -1 : [
<<[
/ size / 9, / leaf / 8,
/ inclusion path /
[ h'7558a95f...e02e35d6' ]
]>>
],
},
},
/ payload / null,
/ signature / h'02d227ed...ccd3774f'
])>>,
<</ cose-sign1 / 18([
/ protected / <<{
/ kid / 4 : h'abcdef12...34567890',
/ algorithm / 1 : -7, # ES256
/ vds / 395 : 1, # RFC9162_SHA256
}>>,
/ unprotected / {
/ proofs / 396 : {
/ inclusion / -1 : [
<<[
/ size / 6, / leaf / 5,
/ inclusion path /
[ h'9352f974...4ffa7ce0',
h'54806f32...f007ea06' ]
]>>
],
},
},
/ payload / null,
/ signature / h'36581f38...a5581960'
])>>
],
},
/ payload / h'0167c57c...deeed6d4',
/ signature / h'2544f2ed...5840893b'
])
Figure 2: An Example COSE Signature with Multiple Receipts
図 2: 複数の受領書を含む COSE 署名の例
The specific structure of COSE Receipts is dependent on the structure of the COSE_Sign1 payload and the VDPs contained in the COSE_Sign1 unprotected header. The CDDL definition for VDPs is specific to each VDS. This document describes proofs for RFC9162_SHA256 in the following sections.
COSE 受領書の特定の構造は、COSE_Sign1 ペイロードの構造と、COSE_Sign1 保護されていないヘッダーに含まれる VDP に依存します。VDP の CDDL 定義は各 VDS に固有です。この文書では、次のセクションで RFC9162_SHA256 の証明について説明します。
New VDSs can require the definition of a profile. The payload in such definitions SHOULD be detached. Detached payloads force verifiers to recompute the root from the proof and protect against implementation errors where the signature is verified but the payload is incompatible with the proof. Profiles of proof signatures that define additional protected header parameters are encouraged to make their presence mandatory to ensure that claims are processed with their intended semantics. One way to include this information in the COSE structure is use of the "typ" (type) header parameter; see [RFC9596] and the similar guidance provided in [RFC9597].
新しい VDS では、プロファイルの定義が必要になる場合があります。そのような定義内のペイロードは切り離されるべきです(SHOULD)。ペイロードが切り離されると、検証者は証明からルートを再計算し、署名は検証されたがペイロードが証明と互換性がない場合の実装エラーから保護する必要があります。追加の保護されたヘッダー パラメーターを定義する証明署名のプロファイルは、クレームが意図されたセマンティクスで処理されることを保証するために、その存在を必須にすることが推奨されます。この情報を COSE 構造に含める 1 つの方法は、「typ」（タイプ）ヘッダー パラメーターを使用することです。[RFC9596] および [RFC9597] で提供されている同様のガイダンスを参照してください。
Each VDS specification applying for inclusion in this registry MUST define how to encode the VDS identifier and its Proof Types in CBOR. Each specification MUST define how to produce and consume the supported Proof Types. See Section 5 as an example.
このレジストリへの登録を申請する各 VDS 仕様は、CBOR で VDS 識別子とそのプルーフ タイプをエンコードする方法を定義しなければなりません (MUST)。各仕様は、サポートされている証明タイプを生成および消費する方法を定義しなければなりません (MUST)。例としてセクション 5 を参照してください。
Where a specification supports a choice of hash algorithm, a separate IANA registration must be made for each supported algorithm. For example, to provide support for SHA256 and SHA3_256 with Merkle inclusion proofs and Merkle consistency proofs defined, respectively, in Section 2.1.3 of [RFC9162] and Section 2.1.4 of [RFC9162], both "RFC9162_SHA256" and "RFC9162_SHA3_256" require entries in the relevant IANA registries. This document only defines "RFC9162_SHA256".
仕様でハッシュ アルゴリズムの選択がサポートされている場合、サポートされるアルゴリズムごとに個別の IANA 登録を行う必要があります。たとえば、[RFC9162] のセクション 2.1.3 と [RFC9162] のセクション 2.1.4 でそれぞれ定義されているマークル包含証明とマークル一貫性証明で SHA256 と SHA3_256 のサポートを提供するには、「RFC9162_SHA256」と「RFC9162_SHA3_256」の両方が関連する IANA レジストリのエントリを必要とします。この文書では「RFC9162_SHA256」のみを定義します。
This section defines how the data structure described in Section 2.1 of [RFC9162] is mapped to the terminology defined in this document, using [RFC8949] and [RFC9053].
このセクションでは、[RFC8949] および [RFC9053] を使用して、[RFC9162] のセクション 2.1 で説明されているデータ構造がこの文書で定義されている用語にどのようにマッピングされるかを定義します。
The integer identifier for this VDS is 1. The string identifier for this VDS is "RFC9162_SHA256", a Merkle Tree where SHA256 is used as the hash algorithm (see Table 2). See Section 2.1.1 of [RFC9162] for a complete description of this VDS.
この VDS の整数識別子は 1 です。この VDS の文字列識別子は「RFC9162_SHA256」です。これは、SHA256 がハッシュ アルゴリズムとして使用されるマークル ツリーです (表 2 を参照)。この VDS の完全な説明については、[RFC9162] のセクション 2.1.1 を参照してください。
See Section 2.1.3.1 of [RFC9162] for a complete description of this VDS Proof Type.
この VDS プルーフタイプの完全な説明については、[RFC9162] のセクション 2.1.3.1 を参照してください。
The CBOR representation of an inclusion proof for RFC9162_SHA256 is:
RFC9162_SHA256 の包含証明の CBOR 表現は次のとおりです。
inclusion-proof-content = [
; tree size at current Merkle Tree root
tree-size: uint
; index of leaf in tree
leaf-index: uint
; path from leaf to current Merkle Tree root
inclusion-path: [ + bstr ]
]
Figure 3: CBOR-Encoded Inclusion Proof for RFC9162_SHA256
図 3: RFC9162_SHA256 の CBOR エンコードされた包含証明
The term leaf-index is used for alignment with the use established in Section 2.1.3.2 of [RFC9162].
リーフインデックスという用語は、[RFC9162] のセクション 2.1.3.2 で確立された使用法と一致させるために使用されます。
Note that [RFC9162] defines inclusion proofs only for leaf nodes, and that:
[RFC9162] はリーフノードに対してのみ包含証明を定義しており、次の点に注意してください。
If leaf_index is greater than or equal to tree_size, then fail the proof verification.
leaf_index がtree_size 以上の場合、証明検証は失敗します。
The identifying index of a leaf node is relative to all nodes in the tree size for which the proof was obtained.
リーフ ノードの識別インデックスは、証明が得られたツリー サイズ内のすべてのノードに関連します。
In a signed proof, the payload is the Merkle Tree root that corresponds to the log at size tree-size. The protected header for an RFC9162_SHA256 inclusion proof signature is:
署名付きプルーフでは、ペイロードはツリーサイズのサイズのログに対応するマークル ツリー ルートです。RFC9162_SHA256 包含証明署名の保護されたヘッダーは次のとおりです。
protected-header-map = {
&(alg: 1) => int
&(vds: 395) => int
* cose-label => cose-value
}
Figure 4: Protected Header for a Receipt of Inclusion
図 4: 封入受領書の保護されたヘッダー
alg (label: 1):
alg (ラベル: 1):
REQUIRED. Signature algorithm identifier. Value type: int.
必須。署名アルゴリズムの識別子。値の型: int.
vds (label: 395):
vds (ラベル: 395):
REQUIRED. VDS algorithm identifier. Value type: int.
必須。VDS アルゴリズム識別子。値の型: int.
The unprotected header for an RFC9162_SHA256 inclusion proof signature is:
RFC9162_SHA256 包含証明署名の保護されていないヘッダーは次のとおりです。
inclusion-proofs = [ + inclusion-proof ]
verifiable-proofs = {
&(inclusion-proof: -1) => inclusion-proofs
}
unprotected-header-map = {
&(vdp: 396) => verifiable-proofs
* cose-label => cose-value
}
Figure 5: A VDP in an Unprotected Header
図 5: 保護されていないヘッダー内の VDP
vdp (label: 396):
vdp (ラベル: 396):
REQUIRED. Verifiable Data Structure Proofs. Value type: Map.
必須。検証可能なデータ構造の証明。値のタイプ: マップ。
inclusion-proof (label: -1):
耐包含性（ラベル：-1）：
REQUIRED. Inclusion proofs. Value type: Array of bstr.
必須。インクルージョンの証明。値の型: bstr の配列。
The payload of an RFC9162_SHA256 inclusion proof signature is the Merkle Tree Hash as defined in [RFC9162].
RFC9162_SHA256 包含証明署名のペイロードは、[RFC9162] で定義されているマークル ツリー ハッシュです。
An EDN example for a Receipt containing an inclusion proof for RFC9162_SHA256 with a detached payload (see Section 4.4) is:
切り離されたペイロードを含む RFC9162_SHA256 の包含証明を含む領収書の EDN の例 (セクション 4.4 を参照) は次のとおりです。
/ cose-sign1 / 18([
/ protected / <<{
/ algorithm / 1 : -7, # ES256
/ vds / 395 : 1, # RFC9162_SHA256
}>>,
/ unprotected / {
/ proofs / 396 : {
/ inclusion / -1 : [
<<[
/ size / 20, / leaf / 17,
/ inclusion path /
[ h'fc9f050f...221c92cb',
h'bd0136ad...6b28cf21',
h'd68af9d6...93b1632b' ]
]>>
],
},
},
/ payload / null,
/ signature / h'de24f0cc...9a5ade89'
])
Figure 6: Receipt of Inclusion
図 6: 包含の受領
The VDS in the protected header is necessary to understand the inclusion proof structure in the unprotected header.
保護されたヘッダー内の VDS は、保護されていないヘッダー内の包含証明構造を理解するために必要です。
Verification of the inclusion proof and signature occurs in two sequential steps:
包含証明と署名の検証は、次の 2 つの連続した手順で行われます。
1. Inclusion Proof Verification: The verifier applies the inclusion proof to the bytes of a candidate entry. If this fails, the proof is invalid. If it succeeds, the resulting Merkle Tree root becomes the COSE_Sign1 payload.
1. 包含証明の検証: 検証者は、候補エントリのバイトに包含証明を適用します。これが失敗した場合、証明は無効になります。成功すると、結果のマークル ツリー ルートが COSE_Sign1 ペイロードになります。
2. Signature Verification: The verifier checks the COSE_Sign1 signature. Successful verification confirms the entry's inclusion in the VDS; otherwise, the signature is invalid.
2. 署名検証: 検証者は COSE_Sign1 署名をチェックします。検証が成功すると、エントリが VDS に含まれていることが確認されます。それ以外の場合、署名は無効です。
See Section 2.1.4.1 of [RFC9162] for a complete description of this VDS Proof Type.
この VDS プルーフタイプの完全な説明については、[RFC9162] のセクション 2.1.4.1 を参照してください。
The CBOR representation of a consistency proof for RFC9162_SHA256 is:
RFC9162_SHA256 の整合性証明の CBOR 表現は次のとおりです。
consistency-proof-content = [
; older Merkle Tree size
tree-size-1: uint
; newer Merkle Tree size
tree-size-2: uint
; path from older Merkle Tree to newer Merkle Tree
consistency-path: [ + bstr ]
]
Figure 7: CBOR-Encoded Consistency Proof for RFC9162_SHA256
図 7: RFC9162_SHA256 の CBOR エンコードされた整合性証明
In a signed consistency proof, the newer Merkle Tree root (proven to be consistent with an older Merkle Tree root) is a detached payload and corresponds to the log at size tree-size-2.
署名された整合性証明では、新しいマークル ツリー ルート (古いマークル ツリー ルートと一貫性があることが証明されている) は切り離されたペイロードであり、サイズ Tree-size-2 のログに対応します。
The protected header for an RFC9162_SHA256 consistency proof signature is:
RFC9162_SHA256 整合性証明署名の保護されたヘッダーは次のとおりです。
protected-header-map = {
&(alg: 1) => int
&(vds: 395) => int
* cose-label => cose-value
}
Figure 8: Protected Header for a Receipt of Consistency
図 8: 一貫性の受信用の保護されたヘッダー
alg (label: 1):
alg (ラベル: 1):
REQUIRED. Signature algorithm identifier. Value type: int.
必須。署名アルゴリズムの識別子。値の型: int.
vds (label: 395):
vds (ラベル: 395):
REQUIRED. VDS algorithm identifier. Value type: int.
必須。VDS アルゴリズム識別子。値の型: int.
The unprotected header for an RFC9162_SHA256 consistency proof signature is:
RFC9162_SHA256 整合性証明署名の保護されていないヘッダーは次のとおりです。
consistency-proofs = [ + consistency-proof ]
verifiable-proofs = {
&(consistency-proof: -2) => consistency-proofs
}
unprotected-header-map = {
&(vdp: 396) => verifiable-proofs
* cose-label => cose-value
}
vdp (label: 396):
vdp (ラベル: 396):
REQUIRED. VDPs. Value type: Map.
必須。VDP。値のタイプ: マップ。
consistency-proof (label: -2):
一貫性の証明 (ラベル: -2):
REQUIRED. Consistency proofs. Value type: Array of bstr.
必須。一貫性の証明。値の型: bstr の配列。
The payload of an RFC9162_SHA256 consistency proof signature is: The newer Merkle Tree Hash as defined in [RFC9162].
RFC9162_SHA256 整合性証明署名のペイロードは次のとおりです: [RFC9162] で定義されている新しいマークル ツリー ハッシュ。
An EDN example for a Receipt containing a consistency proof for RFC9162_SHA256 with a detached payload (see Section 4.4) is:
切り離されたペイロードを含む RFC9162_SHA256 の整合性証明を含む受領書の EDN の例 (セクション 4.4 を参照) は次のとおりです。
/ cose-sign1 / 18([
/ protected / <<{
/ algorithm / 1 : -7, # ES256
/ vds / 395 : 1, # RFC9162_SHA256
}>>,
/ unprotected / {
/ proofs / 396 : {
/ consistency / -2 : [
<<[
/ old / 20, / new / 104,
/ consistency path /
[ h'e5b3e764...c4a813bc',
h'87e8a084...4f529f69',
h'f712f76d...92a0ff36',
h'd68af9d6...93b1632b',
h'249efab6...b7614ccd',
h'85dd6293...38914dc1' ]
]>>
],
},
},
/ payload / null,
/ signature / h'94469f73...52de67a1'
])
Figure 9: Example Consistency Receipt
図 9: 整合性受領書の例
The VDS in the protected header is necessary to understand the consistency proof structure in the unprotected header.
保護されたヘッダー内の VDS は、保護されていないヘッダー内の一貫性証明構造を理解するために必要です。
The signature and consistency proof are verified in order.
署名と整合性証明が順番に検証されます。
First, the verifier checks the signature on the COSE_Sign1. If the verification fails, the consistency proof is not checked. Second, the consistency proof is checked by applying a previous inclusion proof to the consistency proof. If the verification fails, the append-only property of the VDS is not assured. This approach is specific to RFC9162_SHA256; different VDSs may not support consistency proofs. It is recommended that implementations return a single boolean result for Receipt-verification operations to reduce the chance of accepting a valid signature over an invalid consistency proof.
まず、検証者は COSE_Sign1 の署名をチェックします。検証が失敗した場合、整合性証明はチェックされません。次に、一貫性証明は、以前の包含証明を一貫性証明に適用することによってチェックされます。検証が失敗した場合、VDS の追加専用プロパティは保証されません。このアプローチは RFC9162_SHA256 に固有です。異なる VDS は整合性証明をサポートしていない場合があります。無効な整合性証明ではなく有効な署名が受け入れられる可能性を減らすために、実装では受信検証操作に対して単一のブール結果を返すことが推奨されます。
Some structures and proofs leak the size of the log at the time of inclusion. In the case that a log only stores certain kinds of information, this can reveal details that could impact reputation. For example, if a transparency log only stored breach notices, a receipt for a breach notice would reveal the number of previous breaches at the time the notice was made transparent.
一部の構造と証明では、含めた時点でログのサイズが漏洩します。ログに特定の種類の情報のみが保存されている場合、評判に影響を与える可能性のある詳細が明らかになる可能性があります。たとえば、透明性ログに違反通知のみが保存されている場合、違反通知の受領書により、通知が透明化された時点での以前の違反の数が明らかになります。
Additional header parameters can reveal information about the transparency service or its log entries. The receipt producer MUST perform a privacy analysis for all mandatory fields in profiles based on this specification.
追加のヘッダー パラメーターにより、透過性サービスまたはそのログ エントリに関する情報が明らかになります。レシート作成者は、この仕様に基づいて、プロファイル内のすべての必須フィールドに対してプライバシー分析を実行しなければなりません (MUST)。
See the Security Considerations sections of:
次のセキュリティに関する考慮事項のセクションを参照してください。
* [RFC9162]
* [RFC9162]
* [RFC9053]
* [RFC9053]
A security analysis ought to be performed to ensure that the digital signature algorithm alg has the appropriate strength to secure receipts.
デジタル署名アルゴリズム alg が領収書を保護するのに適切な強度を持っていることを確認するには、セキュリティ分析を実行する必要があります。
It is recommended to select signature algorithms that share cryptographic components with the VDS used; for example, both RFC9162_SHA256 and ES256 depend on the SHA256 hash function.
使用する VDS と暗号化コンポーネントを共有する署名アルゴリズムを選択することをお勧めします。たとえば、RFC9162_SHA256 と ES256 は両方とも SHA256 ハッシュ関数に依存します。
In some cases, receipts MAY include strict validity periods, for example, activation not too far in the future or expiration not too far in the past. See the iat, nbf, and exp claims in [RFC8392] for one way to accomplish this. The details of expressing validity periods are out of scope for this document.
場合によっては、レシートには厳密な有効期間が含まれていてもよい（MAY）。たとえば、アクティベーションがそれほど遠い将来ではない、または有効期限がそれほど過去ではない。これを達成する 1 つの方法については、[RFC8392] の iat、nbf、および exp クレームを参照してください。有効期間の表現の詳細については、このドキュメントの範囲外です。
In some cases, receipts should be "revocable" or "suspendable" after being issued, regardless of their validity period. The details of expressing statuses are out of scope for this document.
場合によっては、領収書の有効期間に関係なく、発行後に領収書を「取り消し可能」または「一時停止可能」にする必要があります。ステータスの表現の詳細については、このドキュメントの範囲外です。
IANA has added the COSE header parameters defined in Section 2, and as listed in Table 1, to the "COSE Header Parameters" subregistry [IANA.cose_header-parameters] in the "CBOR Object Signing and Encryption (COSE)" registry group. These COSE header parameters fall in the 'Integer values from 256 to 65535' range (with a Specification Required registration procedure (see [RFC8126])). The Value Registry listed for "vds" is the "COSE Verifiable Data Structure Algorithm" subregistry. The map labels in the "vdp" are assigned from the "COSE Verifiable Data Structure Proofs" subregistry.
IANA は、セクション 2 で定義され、表 1 にリストされている COSE ヘッダー パラメーターを、「CBOR Object Signing and Encryption (COSE)」レジストリ グループの「COSE ヘッダー パラメーター」サブレジストリ [IANA.cose_header-parameters] に追加しました。これらの COSE ヘッダー パラメーターは、「256 ～ 65535 の整数値」の範囲に収まります (仕様が必要な登録手順 ([RFC8126] を参照))。「vds」にリストされている値レジストリは、「COSE Verifiable Data Structure Algorithm」サブレジストリです。「vdp」内のマップ ラベルは、「COSE Verifiable Data Structure Proofs」サブレジストリから割り当てられます。
+==========+=======+=======+============+==============+===========+
| Name | Label | Value | Value | Description | Reference |
| | | Type | Registry | | |
+==========+=======+=======+============+==============+===========+
| receipts | 394 | array | | Priority | RFC 9942, |
| | | | | ordered | Section 2 |
| | | | | sequence of | |
| | | | | CBOR encoded | |
| | | | | Receipts | |
+----------+-------+-------+------------+--------------+-----------+
| vds | 395 | int | COSE | Algorithm | RFC 9942, |
| | | | Verifiable | identifier | Section 2 |
| | | | Data | for | |
| | | | Structure | Verifiable | |
| | | | | Data | |
| | | | | Structures | |
| | | | | that is used | |
| | | | | to produce | |
| | | | | Verifiable | |
| | | | | Data | |
| | | | | Structure | |
| | | | | Proofs | |
+----------+-------+-------+------------+--------------+-----------+
| vdp | 396 | map | map key in | Location for | RFC 9942, |
| | | | COSE | Verifiable | Section 2 |
| | | | Verifiable | Data | |
| | | | Data | Structure | |
| | | | Structure | Proofs in | |
| | | | Proofs | COSE Header | |
| | | | | Parameters | |
+----------+-------+-------+------------+--------------+-----------+
Table 1: Newly Registered COSE Header Parameters
表 1: 新しく登録された COSE ヘッダー パラメーター
IANA has established the "COSE Verifiable Data Structure Algorithms" and "COSE Verifiable Data Structure Proofs" subregistries under a Specification Required policy as described in Section 4.6 of [RFC8126].
IANA は、[RFC8126] のセクション 4.6 に記載されている仕様要求ポリシーに基づいて、「COSE 検証可能なデータ構造アルゴリズム」および「COSE 検証可能なデータ構造証明」サブレジストリを確立しました。
Expert reviewers (see [RFC8126]) should take into consideration the following points:
専門家レビューア ([RFC8126] を参照) は、次の点を考慮する必要があります。
* Experts are advised to assign the next available positive integer for VDSs.
* 専門家は、次に利用可能な正の整数を VDS に割り当てることをお勧めします。
* Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments.
* ポイントスクワットはやめるべきです。レビュー担当者は、使用法がすでに登録されているものと重複しないこと、およびそのポイントが展開で使用される可能性が高いことを確認するために、登録リクエストに関する十分な情報を取得することをお勧めします。
* Specifications are required for all point assignments. Early allocation is permissible, see Section 2 of [RFC7120].
* すべてのポイント割り当てには仕様が必要です。早期割り当ては許容されます。[RFC7120] のセクション 2 を参照してください。
* It is not permissible to assign points in the "COSE Verifiable Data Structure Algorithms" registry for which no corresponding entry in the "COSE Verifiable Data Structure Proofs" registry exists, and vice versa.
* 「COSE Verifiable Data Structure Proofs」レジストリに対応するエントリが存在しない「COSE Verifiable Data Structure Algorithms」レジストリにポイントを割り当てることは許可されておらず、その逆も同様です。
* The change controller for related registrations of structures and proofs should be the same.
* 構造と証明の関連登録の変更コントローラーは同じである必要があります。
Registration Template:
登録テンプレート:
Name:
名前：
This is a descriptive name for the VDS that enables easier reference to the item.
これは、項目を簡単に参照できるようにするための VDS のわかりやすい名前です。
Value:
値：
This is the value used to identify the VDS.
これは、VDS を識別するために使用される値です。
Description:
説明：
This field contains a brief description of the VDS.
このフィールドには、VDS の簡単な説明が含まれます。
Reference:
参照：
This contains a pointer to the public specification for the VDS.
これには、VDS の公開仕様へのポインタが含まれています。
Change Controller:
コントローラを変更します:
For Standards Track RFCs, list the "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Standards Track RFC の場合は、「IETF」をリストします。その他の場合は、責任者の名前を記入してください。その他の詳細 (郵便番号、電子メール アドレス、ホームページ URI など) も含まれる場合があります。
+================+=======+===============+============+===========+
| Name | Value | Description | Change | Reference |
| | | | Controller | |
+================+=======+===============+============+===========+
| Reserved | 0 | Reserved | | RFC 9942 |
+----------------+-------+---------------+------------+-----------+
| RFC9162_SHA256 | 1 | SHA256 Binary | IETF | Section |
| | | Merkle Tree | | 2.1 of |
| | | | | [RFC9162] |
+----------------+-------+---------------+------------+-----------+
Table 2: COSE Verifiable Data Structure Algorithms Initial Registry Contents
表 2: COSE 検証可能なデータ構造アルゴリズムの初期レジストリの内容
Registration Template:
登録テンプレート:
Verifiable Data Structure:
検証可能なデータ構造:
This value used identifies the related VDS.
使用されるこの値は、関連する VDS を識別します。
Name:
名前：
This is a descriptive name for the Proof Type that enables easier reference to the item.
これは、項目を簡単に参照できるようにする、プルーフ タイプの説明的な名前です。
Label:
ラベル：
This is the value used to identify the VDS Proof Type.
これは、VDS プルーフ タイプを識別するために使用される値です。
CBOR Type:
CBOR タイプ:
This contains the CBOR type for the value portion of the label.
これには、ラベルの値部分の CBOR タイプが含まれます。
Description:
説明：
This field contains a brief description of the Proof Type.
このフィールドには、プルーフ タイプの簡単な説明が含まれます。
Reference:
参照：
This contains a pointer to the public specification for the Proof Type.
これには、Proof Type の公開仕様へのポインタが含まれています。
Change Controller:
コントローラを変更します:
For Standards Track RFCs, list the "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Standards Track RFC の場合は、「IETF」をリストします。その他の場合は、責任者の名前を記入してください。その他の詳細 (郵便番号、電子メール アドレス、ホームページ URI など) も含まれる場合があります。
+==========+===========+=====+=====+===========+==========+=========+
|Verifiable|Name |Label|CBOR |Description|Change |Reference|
|Data | | |Type | |Controller| |
|Structure | | | | | | |
+==========+===========+=====+=====+===========+==========+=========+
|1 |inclusion |-1 |array|Proof of |IETF |RFC 9942,|
| |proofs | |(of |inclusion | |Section |
| | | |bstr)| | |5.2 |
+----------+-----------+-----+-----+-----------+----------+---------+
|1 |consistency|-2 |array|Proof of |IETF |RFC 9942,|
| |proofs | |(of |append-only| |Section |
| | | |bstr)|property | |5.3 |
+----------+-----------+-----+-----+-----------+----------+---------+
Table 3: COSE Verifiable Data Structure Proofs Initial Registry Contents
表 3: COSE 検証可能なデータ構造の初期レジストリ内容の証明
[IANA.cose_header-parameters]
IANA, "COSE Header Parameters",
<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>.
[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>.
[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>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and
Encryption (COSE) "typ" (type) Header Parameter",
RFC 9596, DOI 10.17487/RFC9596, June 2024,
<https://www.rfc-editor.org/info/rfc9596>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
<https://www.rfc-editor.org/info/rfc9597>.
[STD96] Internet Standard 96,
<https://www.rfc-editor.org/info/std96>.
At the time of writing, this STD comprises the following:
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>.
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>.
[CBOR-EDN] Bormann, C., "Concise Diagnostic Notation (CDN)", Work in
Progress, Internet-Draft, draft-ietf-cbor-edn-literals-26,
15 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-cbor-edn-literals-26>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[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>.
[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>.
We would like to thank Maik Riechert, Jon Geater, Michael B. Jones, Mike Prorock, Ilari Liusvaara, and Amaury Chamayou for their contributions (some of which substantial) to this document and to the initial set of implementations.
このドキュメントと初期実装セットに対する貢献 (一部は多大) をしていただいた Maik Riechert、Jon Geater、Michael B. Jones、Mike Prorock、Ilari Liusvaara、および Amaury Chamayou に感謝いたします。
Amaury Chamayou
Microsoft
United Kingdom
Email: amaury.chamayou@microsoft.com
Steve Lasker
Email: stevenlasker@hotmail.com
Robert Martin
MITRE Corporation
United States of America
Email: ramartin@mitre.org
Monty Wiseman
United States of America
Email: mwiseman32@acm.org
Roy Williams
United States of America
Email: roywill@msn.com
Orie Steele
Tradeverifyd
United States of America
Email: orie@or13.io
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact
Antoine Delignat-Lavaud
Microsoft
United Kingdom
Email: antdl@microsoft.com
Cédric Fournet
Microsoft
United Kingdom
Email: fournet@microsoft.com