Diff: rfc9942v2.txt - rfc9942.txt

	rfc9942v2.txt	rfc9942.txt

	skipping to change at line 16 ¶	skipping to change at line 16 ¶
	A. Delignat-Lavaud	A. Delignat-Lavaud
	C. Fournet	C. Fournet
	Microsoft	Microsoft
	April 2026	April 2026

	CBOR Object Signing and Encryption (COSE) Receipts	CBOR Object Signing and Encryption (COSE) Receipts

	Abstract	Abstract

	CBOR Object Signing and Encryption (COSE) Receipts prove properties	CBOR Object Signing and Encryption (COSE) Receipts prove properties

	of a Verifiable Data Structure (VDS) to a verifier. Verifiable Data	of a Verifiable Data Structure (VDS) to a verifier. VDSs and
	Structures and associated Proof Types enable security properties,	associated Proof Types enable security properties, such as minimal
	such as minimal disclosure, transparency, and non-equivocation.	disclosure, transparency, and non-equivocation. Transparency helps
	Transparency helps maintain trust over time and has been applied to	maintain trust over time and has been applied to certificates, end-
	certificates, end-to-end encrypted messaging systems, and supply	to-end encrypted messaging systems, and supply chain security. This
	chain security. This specification enables concise transparency-	specification enables concise transparency-oriented systems by
	oriented systems by building on Concise Binary Object Representation	building on Concise Binary Object Representation (CBOR) and COSE.
	(CBOR) and COSE. The extensibility of the approach is demonstrated	The extensibility of the approach is demonstrated by providing CBOR
	by providing CBOR encodings for Merkle inclusion and consistency	encodings for Merkle inclusion and consistency proofs.
	proofs.

	Status of This Memo	Status of This Memo

	This is an Internet Standards Track document.	This is an Internet Standards Track document.

	This document is a product of the Internet Engineering Task Force	This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has	(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the	received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on	Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.	Internet Standards is available in Section 2 of RFC 7841.

	skipping to change at line 62 ¶	skipping to change at line 61 ¶
	include Revised BSD License text as described in Section 4.e of the	include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described	Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.	in the Revised BSD License.

	Table of Contents	Table of Contents

	1. Introduction	1. Introduction
	1.1. Requirements Notation	1.1. Requirements Notation
	2. New COSE Header Parameters	2. New COSE Header Parameters
	3. Terminology	3. Terminology

	4. Verifiable Data Structures in CBOR	4. VDSs in CBOR
	4.1. Structures	4.1. Structures
	4.2. Proofs	4.2. Proofs
	4.3. Usage	4.3. Usage
	4.4. Profiles	4.4. Profiles
	4.4.1. Registration Requirements	4.4.1. Registration Requirements
	5. RFC9162_SHA256	5. RFC9162_SHA256
	5.1. Verifiable Data Structure	5.1. Verifiable Data Structure
	5.2. Inclusion Proof	5.2. Inclusion Proof
	5.2.1. Receipt of Inclusion	5.2.1. Receipt of Inclusion
	5.3. Consistency Proof	5.3. Consistency Proof
	5.3.1. Receipt of Consistency	5.3.1. Receipt of Consistency
	6. Privacy Considerations	6. Privacy Considerations
	6.1. Log Length	6.1. Log Length
	6.2. Header Parameters	6.2. Header Parameters
	7. Security Considerations	7. Security Considerations
	7.1. Choice of Signature Algorithms	7.1. Choice of Signature Algorithms
	7.2. Validity Period	7.2. Validity Period
	7.3. Status Updates	7.3. Status Updates
	8. IANA Considerations	8. IANA Considerations
	8.1. COSE Header Parameter	8.1. COSE Header Parameter

	8.2. Verifiable Data Structure Registries	8.2. VDS Registries
	8.2.1. Expert Review	8.2.1. Expert Review
	8.2.2. Templates and Initial Contents	8.2.2. Templates and Initial Contents
	9. References	9. References
	9.1. Normative References	9.1. Normative References
	9.2. Informative References	9.2. Informative References
	Acknowledgements	Acknowledgements
	Contributors	Contributors
	Authors' Addresses	Authors' Addresses

	1. Introduction	1. Introduction

	COSE Receipts are signed proofs that include metadata about certain	COSE Receipts are signed proofs that include metadata about certain
	states of a Verifiable Data Structure (VDS) that are true when the	states of a Verifiable Data Structure (VDS) that are true when the
	COSE Receipt was issued. COSE Receipts can include proofs that a	COSE Receipt was issued. COSE Receipts can include proofs that a
	document is in a database (proof of inclusion), that a database is	document is in a database (proof of inclusion), that a database is
	append-only (proof of consistency), that a smaller set of statements	append-only (proof of consistency), that a smaller set of statements
	are contained in a large set of statements (proof of disclosure, a	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	special case of proof of inclusion), or that certain data is not yet
	present in a database (proof of non-inclusion). Different VDSs can	present in a database (proof of non-inclusion). Different VDSs can

	produce different Verifiable Data structure Proofs (VDP). The	produce different Verifiable Data Structure Proofs (VDPs). The
	combination of representations of various VDSs and VDP can	combination of representations of various VDSs and VDP can
	significantly increase the burden for implementers and create	significantly increase the burden for implementers and create
	interoperability challenges for transparency services. This document	interoperability challenges for transparency services. This document
	describes how to convey VDS and associated VDP types in unified COSE	describes how to convey VDS and associated VDP types in unified COSE
	envelopes.	envelopes.

	1.1. Requirements Notation	1.1. Requirements Notation

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

	skipping to change at line 129 ¶	skipping to change at line 128 ¶

	This document defines three new COSE header parameters, which are	This document defines three new COSE header parameters, which are
	introduced up front in this section and elaborated on later in this	introduced up front in this section and elaborated on later in this
	document.	document.

	394: A COSE header parameter named "receipts" with a value type of	394: A COSE header parameter named "receipts" with a value type of
	array where the array contains one or more COSE Receipts as	array where the array contains one or more COSE Receipts as
	specified in this document.	specified in this document.

	395: A COSE header parameter named "vds" (for Verifiable Data	395: A COSE header parameter named "vds" (for Verifiable Data

	Structure), which conveys the algorithm identifier for a	Structure), which conveys the algorithm identifier for a VDS.
	Verifiable Data Structure. Correspondingly, see Section 8.2.2.1	Correspondingly, see Section 8.2.2.1 for a registry defining the
	for a registry defining the integers used to identify Verifiable	integers used to identify VDSs.
	Data Structures.


	396: A COSE header parameter named "vdp" (for Verifiable Data	396: A COSE header parameter named "vdp" (for VDPs), which conveys a
	Structure Proofs), which conveys a map containing Verifiable Data	map containing VDPs organized by Proof Type. Correspondingly, see
	Structure Proofs organized by Proof Type. Correspondingly, see
	Section 8.2.2.2 for a registry defining the integers used to	Section 8.2.2.2 for a registry defining the integers used to

	identify Verifiable Data Structure Proof Types.	identify VDP Proof Types.

	3. Terminology	3. Terminology


		The terms "header" and "payload" are defined in [STD96].

		Additionally, this document uses the following terminology:

	CDDL: Concise Data Definition Language (CDDL) is defined in	CDDL: Concise Data Definition Language (CDDL) is defined in
	[RFC8610].	[RFC8610].

	EDN: CBOR Extended Diagnostic Notation (EDN) is defined in	EDN: CBOR Extended Diagnostic Notation (EDN) is defined in
	[RFC8949], where it is referred to as "diagnostic notation", and	[RFC8949], where it is referred to as "diagnostic notation", and
	is revised in [CBOR-EDN].	is revised in [CBOR-EDN].


	Verifiable Data Structure (VDS): A data structure that supports one	Entry: An entry in a VDS for which proofs can be derived.
	or more Verifiable Data Structure Proof Types. This property
	describes an algorithm used to maintain a Verifiable Data
	Structure, for example, a binary Merkle Tree algorithm.

	Verifiable Data Structure Proofs (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).

	Proof Type: A property that can be obtained by verifying a given	Proof Type: A property that can be obtained by verifying a given

	proof over one or more entries in a Verifiable Data Structure.	proof over one or more entries in a VDS. For example, a VDS, such
	For example, a VDS, such as a binary Merkle Tree, can support	as a binary Merkle Tree, can support inclusion proofs where each
	inclusion proofs where each proof confirms that a given entry is	proof confirms that a given entry is included in a Merkle Tree
	included in a Merkle Tree root.	root.

	Proof Value: An encoding of a Proof Type in CBOR [RFC8949].	Proof Value: An encoding of a Proof Type in CBOR [RFC8949].


	Entry: An entry in a Verifiable Data Structure for which proofs can	Receipt: A COSE Single Signer Data Object, as defined in RFC 9052
	be derived.	[STD96], containing the header parameters necessary to convey one
		or more VDP for an associated VDS.


	Receipt: A COSE Single Signer Data Object, as defined in [RFC9052],	Verifiable Data Structure (VDS): A data structure that supports one
	containing the header parameters necessary to convey one or more	or more VDP Proof Types. This property describes an algorithm
	VDP for an associated VDS.	used to maintain a VDS, for example, a binary Merkle Tree
		algorithm.


	4. Verifiable Data Structures in CBOR	Verifiable Data Structure Proofs (VDPs): 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 Verifiable Data Structure	4. VDSs in CBOR
	Proofs in [RFC8949]. For example, construction of a Merkle Tree leaf
	or an inclusion proof from a leaf to a Merkle Tree root might have	This section describes representations of VDPs in [RFC8949]. For
	several different representations, depending on the Verifiable Data	example, construction of a Merkle Tree leaf or an inclusion proof
	Structure used. Differences in representations are necessary to	from a leaf to a Merkle Tree root might have several different
	support efficient verification, unique security or privacy	representations, depending on the VDS used. Differences in
	properties, and for compatibility with specific implementations.	representations are necessary to support efficient verification,
	This document defines two extension points for enabling Verifiable	unique security or privacy properties, and for compatibility with
	Data Structures with COSE and provides concrete examples for the	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	structures and proofs defined in Section 2.1.3 of [RFC9162] and
	Section 2.1.4 of [RFC9162]. The design of these structures is	Section 2.1.4 of [RFC9162]. The design of these structures is
	influenced by the conventions established for COSE Keys.	influenced by the conventions established for COSE Keys.

	4.1. Structures	4.1. Structures

	Similar to COSE Key Types [IANA.cose_header-parameters], different	Similar to COSE Key Types [IANA.cose_header-parameters], different

	Verifiable Data Structures support different algorithms.	VDSs support different algorithms.


	This document establishes a registry of Verifiable Data Structure	This document establishes a registry of VDS algorithms; see
	algorithms; see Section 8.2.2.1 for details.	Section 8.2.2.1 for details.

	4.2. Proofs	4.2. Proofs


	Similar to COSE Key Type Parameters [IANA.cose_header-parameters], as	As is the case for COSE Key Type Parameters
	EC2 keys (1: 2) require and give meaning to specific parameters, such	[IANA.cose_header-parameters], EC2 keys (1: 2) require and give
	as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256 (395: 1) supports	meaning to specific parameters, such as -1 (crv), -2 (x), -3 (y), and
	both (-1) inclusion and (-2) consistency proofs.	-4 (d). RFC9162_SHA256 (395: 1) supports both (-1) inclusion and
		(-2) consistency proofs.


	This document establishes a registry of Verifiable Data Structure	This document establishes a registry of VDPs; see Section 8.2.2.2 for
	Proofs; see Section 8.2.2.2 for details.	details.


	Proof Types are specific to their associated "Verifiable Data	Proof Types are specific to their associated "VDS"; for example,
	Structure"; for example, different Merkle Trees might support	different Merkle Trees might support different representations of
	different representations of inclusion proof or consistency proof.	inclusion proof or consistency proof. Implementers should not expect
	Implementers should not expect interoperability across "Verifiable	interoperability across "VDSs". Security analysis MUST be conducted
	Data Structures". Security analysis MUST be conducted prior to	prior to migrating to new structures to ensure the new security and
	migrating to new structures to ensure the new security and privacy	privacy assumptions are acceptable for the use case.
	assumptions are acceptable for the use case.

	4.3. Usage	4.3. Usage

	This document registers a new COSE header parameter "receipts" (394)	This document registers a new COSE header parameter "receipts" (394)
	to enable Receipts to be conveyed in the protected and unprotected	to enable Receipts to be conveyed in the protected and unprotected
	headers of Enveloped COSE Structures.	headers of Enveloped COSE Structures.

	When the "receipts" header parameter is present, the verifier MUST	When the "receipts" header parameter is present, the verifier MUST

	confirm that the associated Verifiable Data Structure and Verifiable	confirm that the associated VDS and VDPs match entries present in the
	Data Structure Proofs match entries present in the registries	registries established in this specification, including values added
	established in this specification, including values added in	in subsequent registrations.
	subsequent registrations.

	Receipts MUST be tagged as COSE_Sign1.	Receipts MUST be tagged as COSE_Sign1.

	The following definition from [RFC8610] is provided:	The following definition from [RFC8610] is provided:

	Signature_With_Receipt = /6.18(COSE_Sign1)	Signature_With_Receipt = /6.18(COSE_Sign1)

	cose-label = int / text	cose-label = int / text
	cose-values = any	cose-values = any


	skipping to change at line 256 ¶	skipping to change at line 254 ¶
	COSE_Sign1 = [	COSE_Sign1 = [
	protected : bstr .cbor Protected_Header,	protected : bstr .cbor Protected_Header,
	unprotected : Unprotected_Header,	unprotected : Unprotected_Header,
	payload : bstr / nil,	payload : bstr / nil,
	signature : bstr	signature : bstr
	]	]

	Receipt = Receipt_For_Inclusion / Receipt_For_Consistency	Receipt = Receipt_For_Inclusion / Receipt_For_Consistency

	; Note the proof formats shown here are for RFC9162_SHA256.	; Note the proof formats shown here are for RFC9162_SHA256.

	; Other Verifiable Data Structures may have different proof formats.	; Other VDSs may have different proof formats.

	Receipt_For_Inclusion = /6.18(Signed_Inclusion_Proof)	Receipt_For_Inclusion = /6.18(Signed_Inclusion_Proof)

	Signed_Inclusion_Proof = [	Signed_Inclusion_Proof = [

	protected : bstr .cbor RFC9162_SHA256_Inclusion_Protected_Header,	protected :
		bstr .cbor RFC9162_SHA256_Inclusion_Protected_Header,
	unprotected : RFC9162_SHA256_Inclusion_Unprotected_Header,	unprotected : RFC9162_SHA256_Inclusion_Unprotected_Header,
	payload : bstr / nil,	payload : bstr / nil,
	signature : bstr	signature : bstr
	]	]

	RFC9162_SHA256_Inclusion_Protected_Header = {	RFC9162_SHA256_Inclusion_Protected_Header = {
	&(alg: 1) => int	&(alg: 1) => int
	&(vds: 395) => int	&(vds: 395) => int
	* cose-label => cose-values	* cose-label => cose-values
	}	}

	RFC9162_SHA256_Inclusion_Unprotected_Header = {	RFC9162_SHA256_Inclusion_Unprotected_Header = {
	&(vdp: 396) => RFC9162_SHA256_Verifiable_Inclusion_Proofs	&(vdp: 396) => RFC9162_SHA256_Verifiable_Inclusion_Proofs
	* cose-label => cose-values	* cose-label => cose-values
	}	}

	RFC9162_SHA256_Verifiable_Inclusion_Proofs = {	RFC9162_SHA256_Verifiable_Inclusion_Proofs = {
	&(inclusion-proof: -1) => RFC9162_SHA256_Inclusion_Proofs	&(inclusion-proof: -1) => RFC9162_SHA256_Inclusion_Proofs
	}	}


	RFC9162_SHA256_Inclusion_Proofs = [ + RFC9162_SHA256_Inclusion_Proof ]	RFC9162_SHA256_Inclusion_Proofs = [
		+ RFC9162_SHA256_Inclusion_Proof
		]

	RFC9162_SHA256_Inclusion_Proof = bstr .cbor [	RFC9162_SHA256_Inclusion_Proof = bstr .cbor [
	tree_size: uint,	tree_size: uint,
	leaf_index: uint,	leaf_index: uint,
	inclusion_path: [ + bstr ]	inclusion_path: [ + bstr ]
	]	]

	Receipt_For_Consistency = /6.18(Signed_Consistency_Proof)	Receipt_For_Consistency = /6.18(Signed_Consistency_Proof)

	Signed_Consistency_Proof = [	Signed_Consistency_Proof = [

	protected : bstr .cbor RFC9162_SHA256_Consistency_Protected_Header,	protected :
		bstr .cbor RFC9162_SHA256_Consistency_Protected_Header,
	unprotected : RFC9162_SHA256_Consistency_Unprotected_Header,	unprotected : RFC9162_SHA256_Consistency_Unprotected_Header,
	payload : bstr / nil, ; Newer Merkle Tree root	payload : bstr / nil, ; Newer Merkle Tree root
	signature : bstr	signature : bstr
	]	]

	RFC9162_SHA256_Consistency_Protected_Header = {	RFC9162_SHA256_Consistency_Protected_Header = {
	&(alg: 1) => int,	&(alg: 1) => int,
	&(vds: 395) => int,	&(vds: 395) => int,
	* cose-label => cose-values	* cose-label => cose-values
	}	}

	RFC9162_SHA256_Consistency_Unprotected_Header = {	RFC9162_SHA256_Consistency_Unprotected_Header = {
	&(vdp: 396) => RFC9162_SHA256_Verifiable_Consistency_Proofs	&(vdp: 396) => RFC9162_SHA256_Verifiable_Consistency_Proofs
	* cose-label => cose-values	* cose-label => cose-values
	}	}

	RFC9162_SHA256_Verifiable_Consistency_Proofs = {	RFC9162_SHA256_Verifiable_Consistency_Proofs = {
	&(consistency-proof: -2) => RFC9162_SHA256_Consistency_Proofs	&(consistency-proof: -2) => RFC9162_SHA256_Consistency_Proofs
	}	}


	RFC9162_SHA256_Consistency_Proofs = [ + RFC9162_SHA256_Consistency_Proof ]	RFC9162_SHA256_Consistency_Proofs = [
		+ RFC9162_SHA256_Consistency_Proof
		]

	RFC9162_SHA256_Consistency_Proof = bstr .cbor [	RFC9162_SHA256_Consistency_Proof = bstr .cbor [
	tree_size_1: uint,	tree_size_1: uint,
	tree_size_2: uint,	tree_size_2: uint,
	consistency_path: [ + bstr ]	consistency_path: [ + bstr ]
	]	]

	Figure 1: CDDL for a COSE_Sign1 with Attached Receipts	Figure 1: CDDL for a COSE_Sign1 with Attached Receipts

	The following informative EDN is provided:	The following informative EDN is provided:

	/ cose-sign1 / 18([	/ cose-sign1 / 18([
	/ protected / <<{	/ protected / <<{
	/ kid / 4 : h'bc297b51...e4edf0de',	/ kid / 4 : h'bc297b51...e4edf0de',
	/ algorithm / 1 : -7, / ES256	/ algorithm / 1 : -7, / ES256
	}>>,	}>>,
	/ unprotected / {	/ unprotected / {

	/ receipts / 394 : { [ << ... >> ]	/ receipts / 394 : [
	}
	<</ cose-sign1 / 18([
	/ protected / <<{
	/ kid / 4 : h'abcdef12...34567890',
	/ algorithm / 1 : -7, / ES256
	/ vds / 395 : 1, / RFC9162 SHA-256
	}>>,
	/ unprotected / {
	/ proofs / 396 : {
	/ inclusion / -1 : [
	<<[
	/ size / 9, / leaf / 8,
	/ inclusion path /
	h'7558a95f...e02e35d6'
	]>>
	],
	},
	},
	/ payload / null,
	/ signature / h'02d227ed...ccd3774f'
	])>>,
	<</ cose-sign1 / 18([	<</ cose-sign1 / 18([

	/ protected / <<{	/ protected / <<{
	/ kid / 4 : h'abcdef12...34567890',	/ kid / 4 : h'abcdef12...34567890',
	/ algorithm / 1 : -7, / ES256	/ algorithm / 1 : -7, / ES256
	/ vds / 395 : 1, / RFC9162 SHA-256	/ vds / 395 : 1, / RFC9162_SHA256
	}>>,	}>>,
	/ unprotected / {	/ unprotected / {
	/ proofs / 396 : {	/ proofs / 396 : {
	/ inclusion / -1 : [	/ inclusion / -1 : [
	<<[	<<[
	/ size / 6, / leaf / 5,	/ size / 9, / leaf / 8,
	/ inclusion path /	/ inclusion path /
	[ h'9352f974...4ffa7ce0',	h'7558a95f...e02e35d6'
	h'54806f32...f007ea06' ]	]>>
	]>>	],
	],	},
	},	},

	},	/ payload / null,
	/ payload / null,	/ signature / h'02d227ed...ccd3774f'
	/ signature / h'36581f38...a5581960'	])>>,
	])>>	<</ 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',	/ payload / h'0167c57c...deeed6d4',
	/ signature / h'2544f2ed...5840893b'	/ signature / h'2544f2ed...5840893b'
	])	])

	Figure 2: An Example COSE Signature with Multiple Receipts	Figure 2: An Example COSE Signature with Multiple Receipts

	The specific structure of COSE Receipts is dependent on the structure	The specific structure of COSE Receipts is dependent on the structure

	of the COSE_Sign1 payload and the Verifiable Data Structure Proofs	of the COSE_Sign1 payload and the VDPs contained in the COSE_Sign1
	contained in the COSE_Sign1 unprotected header. The CDDL definition	unprotected header. The CDDL definition for VDPs is specific to each
	for Verifiable Data Structure Proofs is specific to each Verifiable	VDS. This document describes proofs for RFC9162_SHA256 in the
	Data Structure. This document describes proofs for RFC9162_SHA256 in	following sections.
	the following sections.

	4.4. Profiles	4.4. Profiles


	New Verifiable Data Structures can require the definition of a	New VDSs can require the definition of a profile. The payload in
	profile. The payload in such definitions SHOULD be detached.	such definitions SHOULD be detached. Detached payloads force
	Detached payloads force verifiers to recompute the root from the	verifiers to recompute the root from the proof and protect against
	proof and protect against implementation errors where the signature	implementation errors where the signature is verified but the payload
	is verified but the payload is incompatible with the proof. Profiles	is incompatible with the proof. Profiles of proof signatures that
	of proof signatures that define additional protected header	define additional protected header parameters are encouraged to make
	parameters are encouraged to make their presence mandatory to ensure	their presence mandatory to ensure that claims are processed with
	that claims are processed with their intended semantics. One way to	their intended semantics. One way to include this information in the
	include this information in the COSE structure is use of the "typ"	COSE structure is use of the "typ" (type) header parameter; see
	(type) header parameter; see [RFC9596] and the similar guidance	[RFC9596] and the similar guidance provided in [RFC9597].
	provided in [RFC9597].

	4.4.1. Registration Requirements	4.4.1. Registration Requirements


	Each Verifiable Data Structure specification applying for inclusion	Each VDS specification applying for inclusion in this registry MUST
	in this registry MUST define how to encode the Verifiable Data	define how to encode the VDS identifier and its Proof Types in CBOR.
	Structure identifier and its Proof Types in CBOR. Each specification	Each specification MUST define how to produce and consume the
	MUST define how to produce and consume the supported Proof Types.	supported Proof Types. See Section 5 as an example.
	See Section 5 as an example.

	Where a specification supports a choice of hash algorithm, a separate	Where a specification supports a choice of hash algorithm, a separate
	IANA registration must be made for each supported algorithm. For	IANA registration must be made for each supported algorithm. For
	example, to provide support for SHA256 and SHA3_256 with Merkle	example, to provide support for SHA256 and SHA3_256 with Merkle
	inclusion proofs and Merkle consistency proofs defined, respectively,	inclusion proofs and Merkle consistency proofs defined, respectively,
	in Section 2.1.3 of [RFC9162] and Section 2.1.4 of [RFC9162], both	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	"RFC9162_SHA256" and "RFC9162_SHA3_256" require entries in the
	relevant IANA registries. This document only defines	relevant IANA registries. This document only defines
	"RFC9162_SHA256".	"RFC9162_SHA256".

	5. RFC9162_SHA256	5. RFC9162_SHA256

	This section defines how the data structure described in Section 2.1	This section defines how the data structure described in Section 2.1
	of [RFC9162] is mapped to the terminology defined in this document,	of [RFC9162] is mapped to the terminology defined in this document,
	using [RFC8949] and [RFC9053].	using [RFC8949] and [RFC9053].

	5.1. Verifiable Data Structure	5.1. Verifiable Data Structure


	The integer identifier for this Verifiable Data Structure is 1. The	The integer identifier for this VDS is 1. The string identifier for
	string identifier for this Verifiable Data Structure is	this VDS is "RFC9162_SHA256", a Merkle Tree where SHA256 is used as
	"RFC9162_SHA256", a Merkle Tree where SHA256 is used as the hash	the hash algorithm (see Table 2). See Section 2.1.1 of [RFC9162] for
	algorithm (see Table 2). See Section 2.1.1 of [RFC9162] for a	a complete description of this VDS.
	complete description of this Verifiable Data Structure.

	5.2. Inclusion Proof	5.2. Inclusion Proof

	See Section 2.1.3.1 of [RFC9162] for a complete description of this	See Section 2.1.3.1 of [RFC9162] for a complete description of this

	Verifiable Data Structure Proof Type.	VDP Proof Type.

	The CBOR representation of an inclusion proof for RFC9162_SHA256 is:	The CBOR representation of an inclusion proof for RFC9162_SHA256 is:

	inclusion-proof = bstr .cbor [	inclusion-proof = bstr .cbor [

	; tree size at current Merkle Tree root	; tree size at current Merkle Tree root
	tree-size: uint	tree-size: uint

	; index of leaf in tree	; index of leaf in tree
	leaf-index: uint	leaf-index: uint

	skipping to change at line 485 ¶	skipping to change at line 484 ¶
	&(alg: 1) => int	&(alg: 1) => int
	&(vds: 395) => int	&(vds: 395) => int
	* cose-label => cose-value	* cose-label => cose-value
	}	}

	Figure 4: Protected Header for a Receipt of Inclusion	Figure 4: Protected Header for a Receipt of Inclusion

	alg (label: 1): REQUIRED. Signature algorithm identifier. Value	alg (label: 1): REQUIRED. Signature algorithm identifier. Value
	type: int.	type: int.


	vds (label: 395): REQUIRED. Verifiable Data Structure algorithm	vds (label: 395): REQUIRED. VDS algorithm identifier. Value type:
	identifier. Value type: int.	int.

	The unprotected header for an RFC9162_SHA256 inclusion proof	The unprotected header for an RFC9162_SHA256 inclusion proof
	signature is:	signature is:

	inclusion-proofs = [ + inclusion-proof ]	inclusion-proofs = [ + inclusion-proof ]

	verifiable-proofs = {	verifiable-proofs = {
	&(inclusion-proof: -1) => inclusion-proofs	&(inclusion-proof: -1) => inclusion-proofs
	}	}

	unprotected-header-map = {	unprotected-header-map = {
	&(vdp: 396) => verifiable-proofs	&(vdp: 396) => verifiable-proofs
	* cose-label => cose-value	* cose-label => cose-value
	}	}


	Figure 5: A Verifiable Data Structure Proofs in an Unprotected Header	Figure 5: A VDP in an Unprotected Header

	vdp (label: 396): REQUIRED. Verifiable Data Structure Proofs.	vdp (label: 396): REQUIRED. Verifiable Data Structure Proofs.
	Value type: Map.	Value type: Map.

	inclusion-proof (label: -1): REQUIRED. Inclusion proofs. Value	inclusion-proof (label: -1): REQUIRED. Inclusion proofs. Value
	type: Array of bstr.	type: Array of bstr.

	The payload of an RFC9162_SHA256 inclusion proof signature is the	The payload of an RFC9162_SHA256 inclusion proof signature is the

	Merkle Tree hash as defined in [RFC9162].	Merkle Tree Hash as defined in [RFC9162].

	An EDN example for a Receipt containing an inclusion proof for	An EDN example for a Receipt containing an inclusion proof for
	RFC9162_SHA256 with a detached payload (see Section 4.4) is:	RFC9162_SHA256 with a detached payload (see Section 4.4) is:

	/ cose-sign1 / 18([	/ cose-sign1 / 18([
	/ protected / <<{	/ protected / <<{
	/ algorithm / 1 : -7, / ES256	/ algorithm / 1 : -7, / ES256

	/ vds / 395 : 1, / RFC9162 SHA-256	/ vds / 395 : 1, / RFC9162_SHA256
	}>>,	}>>,
	/ unprotected / {	/ unprotected / {
	/ proofs / 396 : {	/ proofs / 396 : {
	/ inclusion / -1 : [	/ inclusion / -1 : [
	<<[	<<[
	/ size / 20, / leaf / 17,	/ size / 20, / leaf / 17,
	/ inclusion path /	/ inclusion path /
	[ h'fc9f050f...221c92cb',	[ h'fc9f050f...221c92cb',
	h'bd0136ad...6b28cf21',	h'bd0136ad...6b28cf21',
	h'd68af9d6...93b1632b' ]	h'd68af9d6...93b1632b' ]

	skipping to change at line 547 ¶	skipping to change at line 546 ¶

	Figure 6: Receipt of Inclusion	Figure 6: Receipt of Inclusion

	The VDS in the protected header is necessary to understand the	The VDS in the protected header is necessary to understand the
	inclusion proof structure in the unprotected header.	inclusion proof structure in the unprotected header.

	The inclusion proof and signature are verified in order. First, the	The inclusion proof and signature are verified in order. First, the
	verifier applies the inclusion proof to a possible entry (set member)	verifier applies the inclusion proof to a possible entry (set member)
	bytes. If this process fails, the inclusion proof may have been	bytes. If this process fails, the inclusion proof may have been
	tampered with. If this process succeeds, the result is a Merkle Tree	tampered with. If this process succeeds, the result is a Merkle Tree

	root, which in the attached as the COSE_Sign1 payload. Second, the	root, which is then attached as the COSE_Sign1 payload. Second, the
	verifier checks the signature of the COSE_Sign1. If the resulting	verifier checks the signature of the COSE_Sign1. If the resulting
	signature can be verified, the Receipt has proved inclusion of the	signature can be verified, the Receipt has proved inclusion of the

	entry in the Verifiable Data Structure. If the resulting signature	entry in the VDS. If the resulting signature cannot be verified, the
	cannot be verified, the signature may have been tampered with.	signature may have been tampered with.

	5.3. Consistency Proof	5.3. Consistency Proof

	See Section 2.1.4.1 of [RFC9162] for a complete description of this	See Section 2.1.4.1 of [RFC9162] for a complete description of this

	Verifiable Data Structure Proof Type.	VDP Proof Type.

	The cbor representation of a consistency proof for RFC9162_SHA256 is:	The cbor representation of a consistency proof for RFC9162_SHA256 is:

	consistency-proof = bstr .cbor [	consistency-proof = bstr .cbor [

	; older Merkle Tree size	; older Merkle Tree size
	tree-size-1: uint	tree-size-1: uint

	; newer Merkle Tree size	; newer Merkle Tree size
	tree-size-2: uint	tree-size-2: uint

	skipping to change at line 595 ¶	skipping to change at line 594 ¶
	&(alg: 1) => int	&(alg: 1) => int
	&(vds: 395) => int	&(vds: 395) => int
	* cose-label => cose-value	* cose-label => cose-value
	}	}

	Figure 8: Protected Header for a Receipt of Consistency	Figure 8: Protected Header for a Receipt of Consistency

	alg (label: 1): REQUIRED. Signature algorithm identifier. Value	alg (label: 1): REQUIRED. Signature algorithm identifier. Value
	type: int.	type: int.


	vds (label: 395): REQUIRED. Verifiable Data Structure algorithm	vds (label: 395): REQUIRED. VDS algorithm identifier. Value type:
	identifier. Value type: int.	int.

	The unprotected header for an RFC9162_SHA256 consistency proof	The unprotected header for an RFC9162_SHA256 consistency proof
	signature is:	signature is:

	consistency-proofs = [ + consistency-proof ]	consistency-proofs = [ + consistency-proof ]

	verifiable-proofs = {	verifiable-proofs = {
	&(consistency-proof: -2) => consistency-proofs	&(consistency-proof: -2) => consistency-proofs
	}	}

	unprotected-header-map = {	unprotected-header-map = {
	&(vdp: 396) => verifiable-proofs	&(vdp: 396) => verifiable-proofs
	* cose-label => cose-value	* cose-label => cose-value
	}	}


	vdp (label: 396): REQUIRED. Verifiable Data Structure Proofs.	vdp (label: 396): REQUIRED. VDPs. Value type: Map.
	Value type: Map.

	consistency-proof (label: -2): REQUIRED. Consistency proofs. Value	consistency-proof (label: -2): REQUIRED. Consistency proofs. Value
	type: Array of bstr.	type: Array of bstr.

	The payload of an RFC9162_SHA256 consistency proof signature is: The	The payload of an RFC9162_SHA256 consistency proof signature is: The

	newer Merkle Tree hash as defined in [RFC9162].	newer Merkle Tree Hash as defined in [RFC9162].

	An EDN example for a Receipt containing a consistency proof for	An EDN example for a Receipt containing a consistency proof for
	RFC9162_SHA256 with a detached payload (see Section 4.4) is:	RFC9162_SHA256 with a detached payload (see Section 4.4) is:

	/ cose-sign1 / 18([	/ cose-sign1 / 18([
	/ protected / <<{	/ protected / <<{
	/ algorithm / 1 : -7, / ES256	/ algorithm / 1 : -7, / ES256

	/ vds / 395 : 1, / RFC9162 SHA-256	/ vds / 395 : 1, / RFC9162_SHA256
	}>>,	}>>,
	/ unprotected / {	/ unprotected / {
	/ proofs / 396 : {	/ proofs / 396 : {
	/ consistency / -2 : [	/ consistency / -2 : [
	<<[	<<[
	/ old / 20, / new / 104,	/ old / 20, / new / 104,
	/ consistency path /	/ consistency path /
	h'e5b3e764...c4a813bc',	h'e5b3e764...c4a813bc',
	h'87e8a084...4f529f69',	h'87e8a084...4f529f69',
	h'f712f76d...92a0ff36',	h'f712f76d...92a0ff36',

	skipping to change at line 660 ¶	skipping to change at line 658 ¶

	The VDS in the protected header is necessary to understand the	The VDS in the protected header is necessary to understand the
	consistency proof structure in the unprotected header.	consistency proof structure in the unprotected header.

	The signature and consistency proof are verified in order.	The signature and consistency proof are verified in order.

	First, the verifier checks the signature on the COSE_Sign1. If the	First, the verifier checks the signature on the COSE_Sign1. If the
	verification fails, the consistency proof is not checked. Second,	verification fails, the consistency proof is not checked. Second,
	the consistency proof is checked by applying a previous inclusion	the consistency proof is checked by applying a previous inclusion
	proof to the consistency proof. If the verification fails, the	proof to the consistency proof. If the verification fails, the

	append-only property of the Verifiable Data Structure is not assured.	append-only property of the VDS is not assured. This approach is
	This approach is specific to RFC9162_SHA256; different Verifiable	specific to RFC9162_SHA256; different VDSs may not support
	Data Structures may not support consistency proofs. It is	consistency proofs. It is recommended that implementations return a
	recommended that implementations return a single boolean result for	single boolean result for Receipt-verification operations to reduce
	Receipt-verification operations to reduce the chance of accepting a	the chance of accepting a valid signature over an invalid consistency
	valid signature over an invalid consistency proof.	proof.

	6. Privacy Considerations	6. Privacy Considerations


	The privacy considerations section of [RFC9162] and [RFC9053] apply
	to this document.

	6.1. Log Length	6.1. Log Length

	Some structures and proofs leak the size of the log at the time of	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	inclusion. In the case that a log only stores certain kinds of
	information, this can reveal details that could impact reputation.	information, this can reveal details that could impact reputation.
	For example, if a transparency log only stored breach notices, a	For example, if a transparency log only stored breach notices, a
	receipt for a breach notice would reveal the number of previous	receipt for a breach notice would reveal the number of previous
	breaches at the time the notice was made transparent.	breaches at the time the notice was made transparent.

	6.2. Header Parameters	6.2. Header Parameters

	skipping to change at line 703 ¶	skipping to change at line 698 ¶

	* [RFC9053]	* [RFC9053]

	7.1. Choice of Signature Algorithms	7.1. Choice of Signature Algorithms

	A security analysis ought to be performed to ensure that the digital	A security analysis ought to be performed to ensure that the digital
	signature algorithm alg has the appropriate strength to secure	signature algorithm alg has the appropriate strength to secure
	receipts.	receipts.

	It is recommended to select signature algorithms that share	It is recommended to select signature algorithms that share

	cryptographic components with the Verifiable Data Structure used; for	cryptographic components with the VDS used; for example, both
	example, both RFC9162_SHA256 and ES256 depend on the sha-256 hash	RFC9162_SHA256 and ES256 depend on the SHA256 hash function.
	function.

	7.2. Validity Period	7.2. Validity Period

	In some cases, receipts MAY include strict validity periods, for	In some cases, receipts MAY include strict validity periods, for
	example, activation not too far in the future or expiration not too	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	far in the past. See the iat, nbf, and exp claims in [RFC8392] for
	one way to accomplish this. The details of expressing validity	one way to accomplish this. The details of expressing validity
	periods are out of scope for this document.	periods are out of scope for this document.

	7.3. Status Updates	7.3. Status Updates

	skipping to change at line 769 ¶	skipping to change at line 763 ¶
	\| \| \| \| COSE \| Verifiable \| Section 2 \|	\| \| \| \| COSE \| Verifiable \| Section 2 \|
	\| \| \| \| Verifiable \| Data \| \|	\| \| \| \| Verifiable \| Data \| \|
	\| \| \| \| Data \| Structure \| \|	\| \| \| \| Data \| Structure \| \|
	\| \| \| \| Structure \| Proofs in \| \|	\| \| \| \| Structure \| Proofs in \| \|
	\| \| \| \| Proofs \| COSE Header \| \|	\| \| \| \| Proofs \| COSE Header \| \|
	\| \| \| \| \| Parameters \| \|	\| \| \| \| \| Parameters \| \|
	+----------+-------+-------+------------+--------------+-----------+	+----------+-------+-------+------------+--------------+-----------+

	Table 1: Newly Registered COSE Header Parameters	Table 1: Newly Registered COSE Header Parameters


	8.2. Verifiable Data Structure Registries	8.2. VDS Registries


	IANA established the "COSE Verifiable Data Structure Algorithms" and	IANA has established the "COSE Verifiable Data Structure Algorithms"
	"COSE Verifiable Data Structure Proofs" subregistries under a	and "COSE Verifiable Data Structure Proofs" subregistries under a
	Specification Required policy as described in Section 4.6 of	Specification Required policy as described in Section 4.6 of
	[RFC8126].	[RFC8126].

	8.2.1. Expert Review	8.2.1. Expert Review

	Expert reviewers (see [RFC8126]) should take into consideration the	Expert reviewers (see [RFC8126]) should take into consideration the
	following points:	following points:

	* Experts are advised to assign the next available positive integer	* Experts are advised to assign the next available positive integer

	for Verifiable Data Structures.	for VDSs.

	* Point squatting should be discouraged. Reviewers are encouraged	* Point squatting should be discouraged. Reviewers are encouraged
	to get sufficient information for registration requests to ensure	to get sufficient information for registration requests to ensure
	that the usage is not going to duplicate one that is already	that the usage is not going to duplicate one that is already
	registered and that the point is likely to be used in deployments.	registered and that the point is likely to be used in deployments.

	* Specifications are required for all point assignments. early	* Specifications are required for all point assignments. early
	allocation is permissible, see Section 2 of [RFC7120].	allocation is permissible, see Section 2 of [RFC7120].


	* It is not permissible to assign points in COSE Verifiable Data	* It is not permissible to assign points in the "COSE Verifiable
	Structure algorithms for which no corresponding COSE Verifiable	Data Structure Algorithms" registry for which no corresponding
	Data Structure Proofs entry exists, and vice versa.	entry in the "COSE Verifiable Data Structure Proofs" registry
		exists, and vice versa.

	* The change controller for related registrations of structures and	* The change controller for related registrations of structures and
	proofs should be the same.	proofs should be the same.

	8.2.2. Templates and Initial Contents	8.2.2. Templates and Initial Contents

	8.2.2.1. COSE Verifiable Data Structure Algorithms Registry	8.2.2.1. COSE Verifiable Data Structure Algorithms Registry

	Registration Template:	Registration Template:
	Name:	Name:

	This is a descriptive name for the Verifiable Data Structure	This is a descriptive name for the VDS that enables easier
	that enables easier reference to the item.	reference to the item.

	Value:	Value:

	This is the value used to identify the Verifiable Data	This is the value used to identify the VDS.
	Structure.

	Description:	Description:

	This field contains a brief description of the Verifiable Data	This field contains a brief description of the VDS.
	Structure.

	Reference:	Reference:
	This contains a pointer to the public specification for the	This contains a pointer to the public specification for the

	Verifiable Data Structure.	VDS.

	Change Controller:	Change Controller:
	For Standards Track RFCs, list the "IETF". For others, give	For Standards Track RFCs, list the "IETF". For others, give
	the name of the responsible party. Other details (e.g., postal	the name of the responsible party. Other details (e.g., postal
	address, email address, home page URI) may also be included.	address, email address, home page URI) may also be included.

	+================+=======+===============+============+===========+	+================+=======+===============+============+===========+
	\| Name \| Value \| Description \| Change \| Reference \|	\| Name \| Value \| Description \| Change \| Reference \|
	\| \| \| \| Controller \| \|	\| \| \| \| Controller \| \|
	+================+=======+===============+============+===========+	+================+=======+===============+============+===========+
	\| Reserved \| 0 \| Reserved \| \| RFC 9942 \|	\| Reserved \| 0 \| Reserved \| \| RFC 9942 \|
	+----------------+-------+---------------+------------+-----------+	+----------------+-------+---------------+------------+-----------+
	\| RFC9162_SHA256 \| 1 \| SHA256 Binary \| IETF \| Section \|	\| RFC9162_SHA256 \| 1 \| SHA256 Binary \| IETF \| Section \|
	\| \| \| Merkle Tree \| \| 2.1 of \|	\| \| \| Merkle Tree \| \| 2.1 of \|
	\| \| \| \| \| [RFC9162] \|	\| \| \| \| \| [RFC9162] \|
	+----------------+-------+---------------+------------+-----------+	+----------------+-------+---------------+------------+-----------+


	Table 2: COSE Verifiable Data Structure Algorithms Initial	Table 2: COSE Verifiable Data Structure Algorithms Registry
	Registry Contents	Initial Contents

	8.2.2.2. COSE Verifiable Data Structure Proofs Registry	8.2.2.2. COSE Verifiable Data Structure Proofs Registry

	Registration Template:	Registration Template:
	Verifiable Data Structure:	Verifiable Data Structure:

	This value used identifies the related Verifiable Data	This value used identifies the related VDS.
	Structure.

	Name:	Name:
	This is a descriptive name for the Proof Type that enables	This is a descriptive name for the Proof Type that enables
	easier reference to the item.	easier reference to the item.

	Label:	Label:

	This is the value used to identify the VDS Proof Type.	This is the value used to identify the VDP Proof Type.

	CBOR Type:	CBOR Type:
	This contains the CBOR type for the value portion of the label.	This contains the CBOR type for the value portion of the label.

	Description:	Description:
	This field contains a brief description of the Proof Type.	This field contains a brief description of the Proof Type.

	Reference:	Reference:
	This contains a pointer to the public specification for the	This contains a pointer to the public specification for the
	Proof Type.	Proof Type.

	skipping to change at line 882 ¶	skipping to change at line 874 ¶
	+==========+===========+=====+=====+===========+==========+=========+	+==========+===========+=====+=====+===========+==========+=========+
	\|1 \|inclusion \|-1 \|array\|Proof of \|IETF \|RFC 9942,\|	\|1 \|inclusion \|-1 \|array\|Proof of \|IETF \|RFC 9942,\|
	\| \|proofs \| \|(of \|inclusion \| \|Section \|	\| \|proofs \| \|(of \|inclusion \| \|Section \|
	\| \| \| \|bstr)\| \| \|5.2 \|	\| \| \| \|bstr)\| \| \|5.2 \|
	+----------+-----------+-----+-----+-----------+----------+---------+	+----------+-----------+-----+-----+-----------+----------+---------+
	\|1 \|consistency\|-2 \|array\|Proof of \|IETF \|RFC 9942,\|	\|1 \|consistency\|-2 \|array\|Proof of \|IETF \|RFC 9942,\|
	\| \|proofs \| \|(of \|append-only\| \|Section \|	\| \|proofs \| \|(of \|append-only\| \|Section \|
	\| \| \| \|bstr)\|property \| \|5.3 \|	\| \| \| \|bstr)\|property \| \|5.3 \|
	+----------+-----------+-----+-----+-----------+----------+---------+	+----------+-----------+-----+-----+-----------+----------+---------+


	Table 3: COSE Verifiable Data Structure Proofs Initial Registry	Table 3: COSE Verifiable Data Structure Proofs Registry Initial
	Contents	Contents

	9. References	9. References

	9.1. Normative References	9.1. Normative References

	[IANA.cose_header-parameters]	[IANA.cose_header-parameters]
	IANA, "COSE Header Parameters",	IANA, "COSE Header Parameters",
	<https://www.iana.org/assignments/cose>.	<https://www.iana.org/assignments/cose>.


	skipping to change at line 930 ¶	skipping to change at line 922 ¶

	[RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and	[RFC9596] Jones, M.B. and O. Steele, "CBOR Object Signing and
	Encryption (COSE) "typ" (type) Header Parameter",	Encryption (COSE) "typ" (type) Header Parameter",
	RFC 9596, DOI 10.17487/RFC9596, June 2024,	RFC 9596, DOI 10.17487/RFC9596, June 2024,
	<https://www.rfc-editor.org/info/rfc9596>.	<https://www.rfc-editor.org/info/rfc9596>.

	[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in	[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
	COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,	COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
	<https://www.rfc-editor.org/info/rfc9597>.	<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>.

	9.2. Informative References	9.2. Informative References

	[CBOR-EDN] Bormann, C., "CBOR Extended Diagnostic Notation (EDN)",	[CBOR-EDN] Bormann, C., "CBOR Extended Diagnostic Notation (EDN)",
	Work in Progress, Internet-Draft, draft-ietf-cbor-edn-	Work in Progress, Internet-Draft, draft-ietf-cbor-edn-

	literals-21, 30 March 2026,	literals-22, 6 April 2026,
	<https://datatracker.ietf.org/doc/html/draft-ietf-cbor-	<https://datatracker.ietf.org/doc/html/draft-ietf-cbor-

	edn-literals-21>.	edn-literals-22>.

	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
	2014, <https://www.rfc-editor.org/info/rfc7120>.	2014, <https://www.rfc-editor.org/info/rfc7120>.

	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,	Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,	RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.	<https://www.rfc-editor.org/info/rfc8126>.

	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.	May 2018, <https://www.rfc-editor.org/info/rfc8392>.


	[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>.

	Acknowledgements	Acknowledgements

	We would like to thank Maik Riechert, Jon Geater, Michael B. Jones,	We would like to thank Maik Riechert, Jon Geater, Michael B. Jones,
	Mike Prorock, Ilari Liusvaara, and Amaury Chamayou for their	Mike Prorock, Ilari Liusvaara, and Amaury Chamayou for their
	contributions (some of which substantial) to this document and to the	contributions (some of which substantial) to this document and to the
	initial set of implementations.	initial set of implementations.

	Contributors	Contributors

	Amaury Chamayou	Amaury Chamayou

End of changes. 63 change blocks.
	198 lines changed or deleted	199 lines changed or added
This html diff was produced by rfcdiff 1.48.