rfc9942.original.xml   rfc9942.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9942"
4) --> updates="" obsoletes="" docName="draft-ietf-cose-merkle-tree-proofs-18" category
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true"
-ietf-cose-merkle-tree-proofs-18" category="std" consensus="true" submissionType symRefs="true" version="3" xml:lang="en">
="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.31.0 -->
<front> <front>
<title>COSE (CBOR Object Signing and Encryption) Receipts</title> <!-- [rfced] Please note that the title of the document has been
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-merkle-tree-proofs- updated as follows:
18"/>
a) We have flipped the abbreviation and expansion for COSE to match
similar uses in past RFC titles.
Original:
COSE (CBOR Object Signing and Encryption) Receipts
Current:
CBOR Object Signing and Encryption (COSE) Receipts
b) We have updated the "short title" (in the running header of the PDF
version) as follows:
Original:
COSE (CBOR Object Signing and Encryption) Receipts
Current:
COSE Receipts
-->
<title abbrev="COSE Receipts">CBOR Object Signing and Encryption (COSE) Rece
ipts</title>
<seriesInfo name="RFC" value="9942"/>
<author initials="O." surname="Steele" fullname="Orie Steele"> <author initials="O." surname="Steele" fullname="Orie Steele">
<organization>Tradeverifyd</organization> <organization>Tradeverifyd</organization>
<address> <address>
<postal> <postal>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>orie@or13.io</email> <email>orie@or13.io</email>
</address> </address>
</author> </author>
<author initials="H." surname="Birkholz" fullname="Henk Birkholz"> <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization> <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
<address> <address>
<postal> <postal>
<street>Rheinstrasse 75</street> <street>Rheinstrasse 75</street>
<city>Darmstadt</city> <city>Darmstadt</city>
<code>64295</code> <code>64295</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>henk.birkholz@ietf.contact</email> <email>henk.birkholz@ietf.contact</email>
</address> </address>
</author> </author>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-L avaud"> <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-L avaud">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>antdl@microsoft.com</email> <email>antdl@microsoft.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Fournet" fullname="Cedric Fournet"> <author initials="C." surname="Fournet" fullname="Cedric Fournet">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>fournet@microsoft.com</email> <email>fournet@microsoft.com</email>
</address> </address>
</author> </author>
<date year="2025" month="December" day="02"/> <date year="2026" month="March"/>
<area>Security</area>
<workgroup>COSE</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 89?>
<t>COSE (CBOR Object Signing and Encryption) Receipts prove properties of a veri <area>SEC</area>
fiable data structure to a verifier. <workgroup>cose</workgroup>
Verifiable data structures and associated proof types enable security properties
, such as minimal disclosure, transparency and non-equivocation. <!-- [rfced] Please insert any keywords (beyond those that appear in
Transparency helps maintain trust over time, and has been applied to certificate the title) for use on https://www.rfc-editor.org/search. -->
s, end to end encrypted messaging systems, and supply chain security.
This specification enables concise transparency oriented systems, by building on <keyword>example</keyword>
CBOR (Concise Binary Object Representation) and COSE.
<abstract>
<t>CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Veri
fiable Data Structure (VDS) to a verifier.
Verifiable Data Structures 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 fo r Merkle inclusion and consistency proofs.</t> The extensibility of the approach is demonstrated by providing CBOR encodings fo r Merkle inclusion and consistency proofs.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
CBOR Object Signing and Encryption Working Group mailing list (cose@ietf.org
),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
cose/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs"
/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 97?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>COSE Receipts are signed proofs that include metadata about certain sta <t>COSE Receipts are signed proofs that include metadata about certain sta
tes of a verifiable data structure (VDS) that are true when the COSE Receipt was tes of a Verifiable Data Structure (VDS) that are true when the COSE Receipt was
issued. issued.
COSE Receipts can include proofs that a document is in a database (proof of incl COSE Receipts can include proofs that a document is in a database (proof of incl
usion), that a database is append only (proof of consistency), that a smaller se usion), that a database is append only (proof of consistency), that a smaller se
t of statements are contained in a large set of statements (proof of disclosure, t of statements are contained in a large set of statements (proof of disclosure,
a special case of proof of inclusion), or proof that certain data is not yet pr a special case of proof of inclusion), or that certain data is not yet present
esent in a database (proofs of non inclusion). in a database (proof of non-inclusion).
Different VDS can produce different verifiable data structure proofs (VDP). Different VDSs can produce different Verifiable Data structure Proofs (VDP).
The combination of representations of various VDS and VDP can significantly incr The combination of representations of various VDSs and VDP can significantly inc
ease the burden for implementers and create interoperability challenges for tran rease the burden for implementers and create interoperability challenges for tra
sparency services. nsparency services.
This document describes how to convey VDS and associated VDP types in unified CO SE envelopes.</t> This document describes how to convey VDS and associated VDP types in unified CO SE envelopes.</t>
<section anchor="requirements-notation"> <section anchor="requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="param-list"> <section anchor="param-list">
<name>New COSE Header Parameters</name> <name>New COSE Header Parameters</name>
<t>This document defines three new COSE header parameters, which are intro duced up-front in this Section and elaborated on later in this document.</t> <t>This document defines three new COSE header parameters, which are intro duced up front in this section and elaborated on later in this document.</t>
<dl> <dl>
<dt>TBD_0 (requested assignment 394):</dt> <dt>394:</dt>
<dd> <dd>
<t>A COSE header parameter named <tt>receipts</tt> with a value type o f array where the array contains one or more COSE Receipts as specified in this document.</t> <t>A COSE header parameter named <tt>receipts</tt> with a value type o f array where the array contains one or more COSE Receipts as specified in this document.</t>
</dd> </dd>
<dt>TBD_1 (requested assignment 395):</dt> <dt>395:</dt>
<dd> <dd>
<t>A COSE header parameter named <tt>vds</tt> (Verifiable Data Structu <t>A COSE header parameter named <tt>vds</tt> (for Verifiable Data Str
re), which conveys the algorithm identifier for a verifiable data structure. ucture), which conveys the algorithm identifier for a Verifiable Data Structure.
Correspondingly, this document introduces a new registry (<xref target="verifiab Correspondingly, see <xref target="verifiable-data-structure-algorithms-registry
le-data-structure-registry"/>) defining the integers used to identify verifiable "/> for a registry defining the integers used to identify Verifiable Data Struct
data structures.</t> ures.</t>
</dd> </dd>
<dt>TBD_2 (requested assignment 396):</dt> <dt>396:</dt>
<dd> <dd>
<t>A COSE header parameter named <tt>vdp</tt> (short for "verifiable d <t>A COSE header parameter named <tt>vdp</tt> (for Verifiable Data Str
ata structure proofs"), which conveys a map containing verifiable data structure ucture Proofs), which conveys a map containing Verifiable Data Structure Proofs
proofs organized by proof type. organized by proof type.
Correspondingly, this document introduces a new registry (<xref target="verifiab Correspondingly, see <xref target="verifiable-data-structure-proofs-registry"/>
le-data-structure-proofs-registry"/>) defining the integers used to identify ver for a registry defining the integers used to identify Verifiable Data Structure
ifiable data structure proof types.</t> proof types.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<!--[rfced] We had the following questions related to the Terminology
section:
a) Would you like the terms to be alphabetized for the ease of the
reader?
b) The Terminology section of draft-ietf-scitt-architecture has a
sentence introducing terms from [STD96] in its Terminology section
(see below) that are also used in this document.
Original:
The terms "header", "payload", and "to-be-signed bytes" are defined
in [STD96].
Should this sentence (or something similar as "to-be-signed bytes" is
not used in this document) be added along with a reference to [STD96]?
(Same goes for the sentence in the companion document about the
definition of "claim".)
If so, please let us know how/where to add as well as if the reference
entry would be normative or informative.
c) We note that this document uses the following terms that are
defined in the Terminology section of
draft-ietf-scitt-architecture-22. Should any pointers/citations be
added to direct the reader to Section 3 of that document?
envelope
non-equivocation
statement
transparency service
d) Please see our cluster-wide questions related to discrepancies
between the definitions that appear in both documents in this cluster
and variances in their appearance (e.g., capitalization).
-->
<name>Terminology</name> <name>Terminology</name>
<dl> <dl>
<dt>CDDL:</dt> <dt>CDDL:</dt>
<dd> <dd>
<t>Concise Data Definition Language (CDDL) is defined in <xref target= "RFC8610"/>.</t> <t>Concise Data Definition Language (CDDL) is defined in <xref target= "RFC8610"/>.</t>
</dd> </dd>
<dt>EDN:</dt> <dt>EDN:</dt>
<dd> <dd>
<t>CBOR Extended Diagnostic Notation (EDN) is defined in <xref target= "RFC8949"/>, where it is referred to as "diagnostic notation", and is revised in <xref target="I-D.draft-ietf-cbor-edn-literals"/>.</t> <t>CBOR Extended Diagnostic Notation (EDN) is defined in <xref target= "RFC8949"/>, where it is referred to as "diagnostic notation", and is revised in <xref target="I-D.ietf-cbor-edn-literals"/>.</t>
</dd> </dd>
<dt>Verifiable Data Structure (VDS):</dt> <dt>Verifiable Data Structure (VDS):</dt>
<dd> <dd>
<t>A data structure which supports one or more Verifiable Data Structu <t>A data structure that supports one or more Verifiable Data Structur
re Proof Types. e Proof Types.
This property describes an algorithm used to maintain a verifiable data structur This property describes an algorithm used to maintain a Verifiable Data Structur
e, for example a binary Merkle tree algorithm.</t> e, for example, a binary Merkle tree algorithm.</t>
</dd> </dd>
<dt>Verifiable Data Structure Proofs (VDP):</dt> <dt>Verifiable Data Structure Proofs (VDP):</dt>
<dd> <dd>
<t>A data structure used to convey proof types for proving different p roperties, such as authentication, inclusion, consistency, and freshness. <t>A data structure used to convey proof types for proving different p roperties, such as authentication, inclusion, consistency, and freshness.
Parameters can include multiple proofs of a given type, or multiple types of pro of (inclusion and consistency).</t> Parameters can include multiple proofs of a given type or multiple types of proo f (inclusion and consistency).</t>
</dd> </dd>
<dt>Proof Type:</dt> <dt>Proof Type:</dt>
<dd> <dd>
<t>A property that can be obtained by verifying a given proof over one or more entries in a Verifiable Data Structure. <t>A property that can be obtained by verifying a given proof over one or more entries in a Verifiable Data Structure.
For example, a VDS, such as a binary Merkle tree, can support proofs of type "in clusion" where each proof confirms that a given entry is included in a Merkle ro ot.</t> For example, a VDS, such as a binary Merkle tree, can support proofs of type "in clusion" where each proof confirms that a given entry is included in a Merkle ro ot.</t>
</dd> </dd>
<dt>Proof Value:</dt> <dt>Proof Value:</dt>
<dd> <dd>
<t>An encoding of a Proof Type in CBOR <xref target="RFC8949"/>.</t> <t>An encoding of a Proof Type in CBOR <xref target="RFC8949"/>.</t>
</dd> </dd>
<dt>Entry:</dt> <dt>Entry:</dt>
<dd> <dd>
<t>An entry in a verifiable data structure for which proofs can be der ived.</t> <t>An entry in a Verifiable Data Structure for which proofs can be der ived.</t>
</dd> </dd>
<dt>Receipt:</dt> <dt>Receipt:</dt>
<dd> <dd>
<t>A COSE object, as defined in <xref target="RFC9052"/>, containing t he header parameters necessary to convey VDP for an associated VDS.</t> <t>A COSE object, as defined in <xref target="RFC9052"/>, containing t he header parameters necessary to convey VDP for an associated VDS.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-generic-verifiable-data-structures"> <section anchor="sec-generic-verifiable-data-structures">
<name>Verifiable Data Structures in CBOR</name> <name>Verifiable Data Structures in CBOR</name>
<t>This section describes representations of verifiable data structure pro <t>This section describes representations of Verifiable Data Structure Pro
ofs in <xref target="RFC8949"/>. ofs in <xref target="RFC8949"/>.
For example, construction of a Merkle tree leaf, or an inclusion proof from a le For example, construction of a Merkle tree leaf or an inclusion proof from a lea
af to a Merkle root, might have several different representations, depending on f to a Merkle root might have several different representations, depending on th
the verifiable data structure used. e Verifiable Data Structure used.
Differences in representations are necessary to support efficient verification, unique security or privacy properties, and for compatibility with specific imple mentations. Differences in representations are necessary to support efficient verification, unique security or privacy properties, and for compatibility with specific imple mentations.
This document defines two extension points for enabling verifiable data structur es with COSE and provides concrete examples for the structures and proofs define d in <xref section="2.1.3" sectionFormat="of" target="RFC9162"/> and <xref secti on="2.1.4" sectionFormat="of" target="RFC9162"/>. This document defines two extension points for enabling Verifiable Data Structur es with COSE and provides concrete examples for the structures and proofs define d in <xref section="2.1.3" sectionFormat="of" target="RFC9162"/> and <xref secti on="2.1.4" sectionFormat="of" target="RFC9162"/>.
The design of these structures is influenced by the conventions established for COSE Keys.</t> The design of these structures is influenced by the conventions established for COSE Keys.</t>
<section anchor="sec-cose-verifiable-data-structures"> <section anchor="sec-cose-verifiable-data-structures">
<name>Structures</name> <name>Structures</name>
<t>Similar to <eref target="https://www.iana.org/assignments/cose/cose.x
html#key-type">COSE Key Types</eref>, different verifiable data structures suppo <t>Similar to COSE Key Types <xref target="IANA.cose_header-parameters"/
rt different algorithms.</t> >, different Verifiable Data Structures support different algorithms.</t>
<t>This document establishes a registry of verifiable data structure alg <t>This document establishes a registry of Verifiable Data Structure alg
orithms, see <xref target="verifiable-data-structure-registry"/> for details.</t orithms; see <xref target="verifiable-data-structure-algorithms-registry"/> for
> details.</t>
</section> </section>
<section anchor="sec-cose-verifiable-data-structure-proofs"> <section anchor="sec-cose-verifiable-data-structure-proofs">
<name>Proofs</name> <name>Proofs</name>
<t>Similar to <eref target="https://www.iana.org/assignments/cose/cose.x
html#key-type-parameters">COSE Key Type Parameters</eref>, as EC2 keys (1: 2) ke <!--[rfced] This sentence doesn't parse. Please let us know how to
ys require and give meaning to specific parameters, such as -1 (crv), -2 (x), -3 update.
(y), -4 (d), RFC9162_SHA256 (TBD_1 (requested assignment 395) : 1) supports bot
h (-1) inclusion and (-2) consistency proofs.</t> Original:
<t>This document establishes a registry of verifiable data structure alg ...such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256 (TBD_1
orithm proofs, see <xref target="verifiable-data-structure-proofs-registry"/> fo (requested assignment 395) : 1) supports both (-1) inclusion and (-2)
r details.</t> consistency proofs.
<t>Proof types are specific to their associated "verifiable data structu -->
re", for example, different Merkle trees might support different representations
of "inclusion proof" or "consistency proof". <t>Similar to COSE Key Type Parameters <xref target="IANA.cose_header-pa
Implementers should not expect interoperability across "verifiable data structur rameters" format="default"/>, as EC2 keys (1: 2) require and give meaning to spe
es". cific parameters, such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256 (395:
1) supports both (-1) inclusion and (-2) consistency proofs.</t>
<t>This document establishes a registry of Verifiable Data Structure Pro
ofs; see <xref target="verifiable-data-structure-proofs-registry"/> for details.
</t>
<t>Proof types are specific to their associated "Verifiable Data Structu
re"; for example, different Merkle trees might support different representations
of "inclusion proof" or "consistency proof".
Implementers should not expect interoperability across "Verifiable Data Structur
es".
Security analysis <bcp14>MUST</bcp14> be conducted prior to migrating to new str uctures to ensure the new security and privacy assumptions are acceptable for th e use case.</t> Security analysis <bcp14>MUST</bcp14> be conducted prior to migrating to new str uctures to ensure the new security and privacy assumptions are acceptable for th e use case.</t>
</section> </section>
<section anchor="receipt-spec"> <section anchor="receipt-spec">
<name>Usage</name> <name>Usage</name>
<t>This document registers a new COSE Header Parameter <tt>receipts</tt> <t>This document registers a new COSE Header Parameter <tt>receipts</tt>
(TBD_0 (requested assignment 394)) to enable Receipts to be conveyed in the pro (394) to enable Receipts to be conveyed in the protected and unprotected header
tected and unprotected headers of COSE Objects.</t> s of COSE Objects.</t>
<t>When the receipts header parameter is present, the verifier <bcp14>MU <t>When the receipts header parameter is present, the verifier <bcp14>MU
ST</bcp14> confirm that the associated verifiable data structure and verifiable ST</bcp14> confirm that the associated Verifiable Data Structure and Verifiable
data structure proofs match entries present in the registries established in thi Data Structure Proofs match entries present in the registries established in thi
s specification, including values added in subsequent registrations..</t> s specification, including values added in subsequent registrations.</t>
<t>Receipts <bcp14>MUST</bcp14> be tagged as COSE_Sign1.</t> <t>Receipts <bcp14>MUST</bcp14> be tagged as COSE_Sign1.</t>
<t>The following <xref target="RFC8610"/> definition is provided:</t> <t>The following definition from <xref target="RFC8610"/> is provided:</
<figure anchor="fig-receipts-cddl"> t>
<name>CDDL for a COSE Sign1 with attached receipts</name>
<!--[rfced] Please note that Figure 1 exceeds our character limit in
three places (line 319 is 5 characters over the character limit).
Please review how these lines could be broken to fit within the
69 character limit associated with sourcecode.
-->
<figure anchor="fig-receipts-cddl">
<name>CDDL for a COSE Sign1 with Attached Receipts</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
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
Protected_Header = { Protected_Header = {
* cose.label => cose.values * cose.label => cose.values
} }
skipping to change at line 209 skipping to change at line 287
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 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 Verifiable Data Structures 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
] ]
skipping to change at line 277 skipping to change at line 355
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 ]
] ]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<!--[rfced] We had two questions related to this document's use of the
term "SHA256":
a) We note that the EDN provided in Section 4.3 uses RFC9162 SHA-256
while other uses of this term in prose use RFC9162_SHA256. Please
confirm that this is as intended.
b) We see both SHA256 and sha-256 in running text. Should these be
made uniform as SHA256?
-->
<t>The following informative EDN is provided:</t> <t>The following informative EDN is provided:</t>
<figure anchor="fig-receipts-edn">
<name>An example COSE Signature with multiple receipts</name> <figure anchor="fig-receipts-edn">
<name>An Example COSE Signature with Multiple Receipts</name>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
/ 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([ <</ cose-sign1 / 18([
/ protected / <<{ / protected / <<{
skipping to change at line 337 skipping to change at line 429
/ payload / null, / payload / null,
/ signature / h'36581f38...a5581960' / signature / h'36581f38...a5581960'
])>> ])>>
}, },
}, },
/ payload / h'0167c57c...deeed6d4', / payload / h'0167c57c...deeed6d4',
/ signature / h'2544f2ed...5840893b' / signature / h'2544f2ed...5840893b'
]) ])
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The specific structure of COSE Receipts is dependent on the structure
of the COSE_Sign1 payload and the verifiable data structure proofs contained in <t>The specific structure of COSE Receipts is dependent on the structure
the COSE_Sign1 unprotected header. of the COSE_Sign1 payload and the Verifiable Data Structure Proofs contained in
The CDDL definition for verifiable data structure proofs is specific to each ver the COSE_Sign1 unprotected header.
ifiable data structure. The CDDL definition for Verifiable Data Structure Proofs is specific to each Ver
ifiable Data Structure.
This document describes proofs for RFC9162_SHA256 in the following sections.</t> This document describes proofs for RFC9162_SHA256 in the following sections.</t>
</section> </section>
<section anchor="profiles-def"> <section anchor="profiles-def">
<name>Profiles</name> <name>Profiles</name>
<t>New verifiable data structures can require the definition of a profil e. <t>New Verifiable Data Structures can require the definition of a profil e.
The payload in such definitions <bcp14>SHOULD</bcp14> be detached. The payload in such definitions <bcp14>SHOULD</bcp14> be detached.
Detached payloads force verifiers to recompute the root from the proof and prote ct against implementation errors where the signature is verified but the payload is incompatible with the proof. Detached payloads force verifiers to recompute the root from the proof and prote ct 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 proces sed with their intended semantics. Profiles of proof signatures that define additional protected header parameters are encouraged to make their presence mandatory to ensure that claims are proces sed with their intended semantics.
One way to include this information in the COSE structure is use of the typ (typ e) Header Parameter, see <xref target="RFC9596"/> and the similar guidance provi ded in <xref target="RFC9597"/>.</t> One way to include this information in the COSE structure is use of the typ (typ e) Header Parameter; see <xref target="RFC9596"/> and the similar guidance provi ded in <xref target="RFC9597"/>.</t>
<section anchor="registration-requirements"> <section anchor="registration-requirements">
<name>Registration Requirements</name> <name>Registration Requirements</name>
<t>Each verifiable data structure specification applying for inclusion in this registry <bcp14>MUST</bcp14> define how to encode the verifiable data s tructure identifier and its proof types in CBOR. <t>Each Verifiable Data Structure specification applying for inclusion in this registry <bcp14>MUST</bcp14> define how to encode the Verifiable Data S tructure identifier and its proof types in CBOR.
Each specification <bcp14>MUST</bcp14> define how to produce and consume the sup ported proof types. Each specification <bcp14>MUST</bcp14> define how to produce and consume the sup ported proof types.
See <xref target="sec-rfc-9162-verifiable-data-structure-definition"/> as an exa mple.</t> See <xref target="sec-rfc-9162-verifiable-data-structure-definition"/> as an exa mple.</t>
<t>Where a specification supports a choice of hash algorithm, a separa te IANA registration must be made for each supported algorithm. <t>Where a specification supports a choice of hash algorithm, a separa te IANA registration must be made for each supported algorithm.
For example, to provide support for SHA256 and SHA3_256 with Merkle Consistency and Inclusion Proofs defined respectively in <xref section="2.1.3" sectionFormat ="of" target="RFC9162"/> and <xref section="2.1.4" sectionFormat="of" target="RF C9162"/>, both "RFC9162_SHA256" and "RFC9162_SHA3_256" require entries in the re levant IANA registries. For example, to provide support for SHA256 and SHA3_256 with Merkle Inclusion Pr oofs and Merkle Consistency Proofs defined, respectively, in <xref section="2.1. 3" sectionFormat="of" target="RFC9162"/> and <xref section="2.1.4" sectionFormat ="of" target="RFC9162"/>, both "RFC9162_SHA256" and "RFC9162_SHA3_256" require e ntries in the relevant IANA registries.
This document only defines "RFC9162_SHA256".</t> This document only defines "RFC9162_SHA256".</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-rfc-9162-verifiable-data-structure-definition"> <section anchor="sec-rfc-9162-verifiable-data-structure-definition">
<name>RFC9162_SHA256</name> <name>RFC9162_SHA256</name>
<t>This section defines how the data structure described in <xref section= "2.1" sectionFormat="of" target="RFC9162"/> is mapped to the terminology defined in this document, using <xref target="RFC8949"/> and <xref target="RFC9053"/>.< /t> <t>This section defines how the data structure described in <xref section= "2.1" sectionFormat="of" target="RFC9162"/> is mapped to the terminology defined in this document, using <xref target="RFC8949"/> and <xref target="RFC9053"/>.< /t>
<section anchor="verifiable-data-structure"> <section anchor="verifiable-data-structure">
<name>Verifiable Data Structure</name> <name>Verifiable Data Structure</name>
<t>The integer identifier for this Verifiable Data Structure is 1. <t>The integer identifier for this Verifiable Data Structure is 1.
The string identifier for this Verifiable Data Structure is "RFC9162_SHA256", a The string identifier for this Verifiable Data Structure is "RFC9162_SHA256", a
Merkle Tree where SHA256 is used as the hash algorithm. Merkle Tree where SHA256 is used as the hash algorithm
See <xref target="verifiable-data-structure-proofs-registry"/>. (see <xref target="verifiable-data-structure-algorithms-registry-table"/>). See
See <xref section="2.1.1" sectionFormat="of" target="RFC9162"/> (Definition of t <xref section="2.1.1" sectionFormat="of" target="RFC9162"/> for a complete descr
he Merkle Tree), for a complete description of this verifiable data structure.</ iption of this Verifiable Data Structure.</t>
t>
</section> </section>
<section anchor="sec-rfc9162-sha256-inclusion-proof"> <section anchor="sec-rfc9162-sha256-inclusion-proof">
<name>Inclusion Proof</name> <name>Inclusion Proof</name>
<t>See <xref section="2.1.3.1" sectionFormat="of" target="RFC9162"/> (Ge nerating an Inclusion Proof), for a complete description of this verifiable data structure proof type.</t> <t>See <xref section="2.1.3.1" sectionFormat="of" target="RFC9162"/> for a complete description of this Verifiable Data Structure Proof type.</t>
<t>The CBOR representation of an inclusion proof for RFC9162_SHA256 is:< /t> <t>The CBOR representation of an inclusion proof for RFC9162_SHA256 is:< /t>
<figure anchor="rfc9162-sha256-cbor-inclusion-proof"> <figure anchor="rfc9162-sha256-cbor-inclusion-proof">
<name>CBOR Encoded RFC9162 Inclusion Proof</name> <name>CBOR-Encoded Inclusion Proof for RFC9162_SHA256</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
inclusion-proof = bstr .cbor [ inclusion-proof = bstr .cbor [
; tree size at current Merkle root ; tree size at current Merkle root
tree-size: uint tree-size: uint
; index of leaf in tree ; index of leaf in tree
leaf-index: uint leaf-index: uint
; path from leaf to current Merkle root ; path from leaf to current Merkle root
inclusion-path: [ + bstr ] inclusion-path: [ + bstr ]
] ]]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<!-- [rfced] We note that [RFC9162] uses "leaf_index" rather than
"leaf-index". Please review and let us know if updates should be
made.
Current:
The term leaf-index is used for alignment with the use established in
Section 2.1.3.2 of [RFC9162].
-->
<t>The term <tt>leaf-index</tt> is used for alignment with the use estab lished in <xref section="2.1.3.2" sectionFormat="of" target="RFC9162"/>.</t> <t>The term <tt>leaf-index</tt> is used for alignment with the use estab lished in <xref section="2.1.3.2" sectionFormat="of" target="RFC9162"/>.</t>
<t>Note that <xref target="RFC9162"/> defines inclusion proofs only for leaf nodes, and that:</t> <t>Note that <xref target="RFC9162"/> defines inclusion proofs only for leaf nodes, and that:</t>
<ul empty="true"> <blockquote>If leaf_index is greater than or equal to tree_size, the
<li> n fail the proof verification.</blockquote>
<t>If leaf_index is greater than or equal to tree_size, then fail th
e proof verification.</t>
</li>
</ul>
<t>The identifying index of a leaf node is relative to all nodes in the tree size for which the proof was obtained.</t> <t>The identifying index of a leaf node is relative to all nodes in the tree size for which the proof was obtained.</t>
<section anchor="receipt-of-inclusion"> <section anchor="receipt-of-inclusion">
<name>Receipt of Inclusion</name> <name>Receipt of Inclusion</name>
<t>In a signed inclusion proof, the payload is the Merkle tree root th at corresponds to the log at size <tt>tree-size</tt>. <t>In a signed inclusion proof, the payload is the Merkle tree root th at corresponds to the log at size <tt>tree-size</tt>.
The protected header for an RFC9162_SHA256 inclusion proof signature is:</t> The protected header for an RFC9162_SHA256 inclusion proof signature is:</t>
<figure anchor="vds-in-inclusion-receipt-protected-header"> <figure anchor="vds-in-inclusion-receipt-protected-header">
<name>Protected Header for a Receipt of Inclusion</name> <name>Protected Header for a Receipt of Inclusion</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
protected-header-map = { protected-header-map = {
&(alg: 1) => int &(alg: 1) => int
&(vds: 395) => int &(vds: 395) => int
* cose-label => cose-value * cose-label => cose-value
} }]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>alg (label: 1):</dt><dd><bcp14>REQUIRED</bcp14>. Signature algor
<t>alg (label: 1): <bcp14>REQUIRED</bcp14>. Signature algorithm id ithm identifier. Value type: int.</dd>
entifier. Value type: int.</t> <dt>vds (label: 395):</dt><dd> <bcp14>REQUIRED</bcp14>. Verifiable D
</li> ata Structure algorithm identifier. Value type: int.</dd>
<li> </dl>
<t>vds (label: TBD_1 (requested assignment 395)): <bcp14>REQUIRED<
/bcp14>. Verifiable data structure algorithm identifier. Value type: int.</t>
</li>
</ul>
<t>The unprotected header for an RFC9162_SHA256 inclusion proof signat ure is:</t> <t>The unprotected header for an RFC9162_SHA256 inclusion proof signat ure is:</t>
<figure anchor="vdp-in-unprotected-header"> <figure anchor="vdp-in-unprotected-header">
<name>A Verifiable Data Structure Proofs in an Unprotected Header</n ame> <name>A Verifiable Data Structure Proofs in an Unprotected Header</n ame>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
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
} }]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>vdp (label: 396):</dt><dd><bcp14>REQUIRED</bcp14>. Verifiable Da
<t>vdp (label: TBD_2 (requested assignment 396)): <bcp14>REQUIRED< ta Structure Proofs. Value type: Map.</dd>
/bcp14>. Verifiable data structure proofs. Value type: Map.</t> <dt>inclusion-proof (label: -1):</dt><dd><bcp14>REQUIRED</bcp14>. In
</li> clusion proofs. Value type: Array of bstr.</dd>
<li> </dl>
<t>inclusion-proof (label: -1): <bcp14>REQUIRED</bcp14>. Inclusion <!-- [rfced] We note that [RFC9162] uses "Merkle Tree Hash" rather
proofs. Value type: Array of bstr.</t> than "Merkle tree hash". Please note that there is inconsistency
</li> in this document related to Merkle Tree vs. Merkle tree as well.
</ul>
Current:
The payload of an RFC9162_SHA256 inclusion proof signature is the
Merkle tree hash as defined in [RFC9162].
-->
<t>The payload of an RFC9162_SHA256 inclusion proof signature is the M erkle tree hash as defined in <xref target="RFC9162"/>.</t> <t>The payload of an RFC9162_SHA256 inclusion proof signature is the M erkle tree hash as defined in <xref target="RFC9162"/>.</t>
<t>An EDN example for a Receipt containing an inclusion proof for RFC9 162_SHA256 with a detached payload (see <xref target="profiles-def"/>) is:</t> <t>An EDN example for a Receipt containing an inclusion proof for RFC9 162_SHA256 with a detached payload (see <xref target="profiles-def"/>) is:</t>
<figure anchor="rfc9162_sha256_inclusion_receipt"> <figure anchor="rfc9162_sha256_inclusion_receipt">
<name>Receipt of Inclusion</name> <name>Receipt of Inclusion</name>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
/ 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 SHA-256
}>>, }>>,
skipping to change at line 468 skipping to change at line 562
/ inclusion path / / inclusion path /
h'fc9f050f...221c92cb', h'fc9f050f...221c92cb',
h'bd0136ad...6b28cf21', h'bd0136ad...6b28cf21',
h'd68af9d6...93b1632b' h'd68af9d6...93b1632b'
]>> ]>>
], ],
}, },
}, },
/ payload / null, / payload / null,
/ signature / h'de24f0cc...9a5ade89' / signature / h'de24f0cc...9a5ade89'
]) ])]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<t>The VDS in the protected header is necessary to understand the incl usion proof structure in the unprotected header.</t> <t>The VDS in the protected header is necessary to understand the incl usion proof structure in the unprotected header.</t>
<t>The inclusion proof and signature are verified in order. <t>The inclusion proof and signature are verified in order.
First the verifier applies the inclusion proof to a possible entry (set member)
bytes. <!--[rfced] This sentence doesn't seem to parse. Please rephrase.
Original:
First the verifier applies the inclusion proof to a possible entry
(set member) bytes.
-->
First, the verifier applies the inclusion proof to a possible entry (set member)
bytes.
If this process fails, the inclusion proof may have been tampered with. If this process fails, the inclusion proof may have been tampered with.
<!--[rfced] Please review this text for clarity (particularly for a
missing verb after which?).
Original:
If this process succeeds, the result is a Merkle root, which in the
attached as the COSE Sign1 payload.
-->
If this process succeeds, the result is a Merkle root, which in the attached as the COSE Sign1 payload. If this process succeeds, the result is a Merkle root, which in the attached as the COSE Sign1 payload.
Second the verifier checks the signature of the COSE Sign1. Second, the verifier checks the signature of the COSE Sign1.
If the resulting signature verifies, the Receipt has proved inclusion of the ent If the resulting signature can be verified, the Receipt has proved inclusion of
ry in the verifiable data structure. the entry in the Verifiable Data Structure.
If the resulting signature does not verify, the signature may have been tampered If the resulting signature cannot be verified, the signature may have been tampe
with.</t> red with.</t>
</section> </section>
</section> </section>
<section anchor="sec-rfc9162-sha256-consistency-proof"> <section anchor="sec-rfc9162-sha256-consistency-proof">
<name>Consistency Proof</name> <name>Consistency Proof</name>
<t>See <xref section="2.1.4.1" sectionFormat="of" target="RFC9162"/> (Ge nerating a Consistency Proof), for a complete description of this verifiable dat a structure proof type.</t> <t>See <xref section="2.1.4.1" sectionFormat="of" target="RFC9162"/> for a complete description of this Verifiable Data Structure Proof type.</t>
<t>The cbor representation of a consistency proof for RFC9162_SHA256 is: </t> <t>The cbor representation of a consistency proof for RFC9162_SHA256 is: </t>
<figure anchor="rfc9162_sha256_consistency_proof"> <figure anchor="rfc9162_sha256_consistency_proof">
<name>CBOR Encoded RFC9162 Consistency Proof</name> <name>CBOR-Encoded Consistency Proof for RFC9162_SHA256</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
consistency-proof = bstr .cbor [ consistency-proof = bstr .cbor [
; older Merkle root tree size ; older Merkle root tree size
tree-size-1: uint tree-size-1: uint
; newer Merkle root tree size ; newer Merkle root tree size
tree-size-2: uint tree-size-2: uint
; path from older Merkle root to newer Merkle root. ; path from older Merkle root to newer Merkle root.
consistency-path: [ + bstr ] consistency-path: [ + bstr ]
] ]]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<section anchor="receipt-of-consistency"> <section anchor="receipt-of-consistency">
<name>Receipt of Consistency</name> <name>Receipt of Consistency</name>
<t>In a signed consistency proof, the newer Merkle tree root (proven t o be consistent with an older Merkle tree root) is an attached payload and corre sponds to the log at size tree-size-2.</t> <t>In a signed consistency proof, the newer Merkle tree root (proven t o be consistent with an older Merkle tree root), is an attached payload and corr esponds to the log at size tree-size-2.</t>
<t>The protected header for an RFC9162_SHA256 consistency proof signat ure is:</t> <t>The protected header for an RFC9162_SHA256 consistency proof signat ure is:</t>
<figure anchor="vds-in-consistency-receipt-protected-header"> <figure anchor="vds-in-consistency-receipt-protected-header">
<name>Protected Header for a Receipt of Consistency</name> <name>Protected Header for a Receipt of Consistency</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
protected-header-map = { protected-header-map = {
&(alg: 1) => int &(alg: 1) => int
&(vds: 395) => int &(vds: 395) => int
* cose-label => cose-value * cose-label => cose-value
} }]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>alg (label: 1):</dt><dd><bcp14>REQUIRED</bcp14>. Signature algor
<t>alg (label: 1): <bcp14>REQUIRED</bcp14>. Signature algorithm id ithm identifier. Value type: int.</dd>
entifier. Value type: int.</t> <dt>vds (label: 395):</dt><dd><bcp14>REQUIRED</bcp14>. Verifiable Da
</li> ta Structure algorithm identifier. Value type: int.</dd>
<li> </dl>
<t>vds (label: TBD_1 (requested assignment 395)): <bcp14>REQUIRED<
/bcp14>. Verifiable data structure algorithm identifier. Value type: int.</t>
</li>
</ul>
<t>The unprotected header for an RFC9162_SHA256 consistency proof sign ature is:</t> <t>The unprotected header for an RFC9162_SHA256 consistency proof sign ature is:</t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
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
} }]]></sourcecode>
]]></sourcecode> <dl spacing="normal" newline="false">
<ul spacing="normal"> <dt>vdp (label: 396):</dt><dd><bcp14>REQUIRED</bcp14>. Verifiable Da
<li> ta Structure Proofs. Value type: Map.</dd>
<t>vdp (label: TBD_2 (requested assignment 396)): <bcp14>REQUIRED< <dt>consistency-proof (label: -2):</dt><dd><bcp14>REQUIRED</bcp14>.
/bcp14>. Verifiable data structure proofs. Value type: Map.</t> Consistency proofs. Value type: Array of bstr.</dd>
</li> </dl>
<li>
<t>consistency-proof (label: -2): <bcp14>REQUIRED</bcp14>. Consist
ency proofs. Value type: Array of bstr.</t>
</li>
</ul>
<t>The payload of an RFC9162_SHA256 consistency proof signature is: <t>The payload of an RFC9162_SHA256 consistency proof signature is:
The newer Merkle tree hash as defined in <xref target="RFC9162"/>.</t> The newer Merkle tree hash as defined in <xref target="RFC9162"/>.</t>
<t>An example EDN for a Receipt containing a consistency proof for RFC 9162_SHA256 with a detached payload (see <xref target="profiles-def"/>) is:</t> <t>An EDN example for a Receipt containing a consistency proof for RFC 9162_SHA256 with a detached payload (see <xref target="profiles-def"/>) is:</t>
<figure anchor="rfc9162_sha256_consistency_receipt"> <figure anchor="rfc9162_sha256_consistency_receipt">
<name>Example consistency receipt</name> <name>Example Consistency Receipt</name>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
/ 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 SHA-256
}>>, }>>,
/ unprotected / { / unprotected / {
/ proofs / 396 : { / proofs / 396 : {
/ consistency / -2 : [ / consistency / -2 : [
<<[ <<[
skipping to change at line 574 skipping to change at line 674
h'f712f76d...92a0ff36', h'f712f76d...92a0ff36',
h'd68af9d6...93b1632b', h'd68af9d6...93b1632b',
h'249efab6...b7614ccd', h'249efab6...b7614ccd',
h'85dd6293...38914dc1' h'85dd6293...38914dc1'
]>> ]>>
], ],
}, },
}, },
/ payload / null, / payload / null,
/ signature / h'94469f73...52de67a1' / signature / h'94469f73...52de67a1'
]) ])]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<t>The VDS in the protected header is necessary to understand the cons istency proof structure in the unprotected header.</t> <t>The VDS in the protected header is necessary to understand the cons istency proof structure in the unprotected header.</t>
<t>The signature and consistency proof are verified in order.</t> <t>The signature and consistency proof are verified in order.</t>
<t>First the verifier checks the signature on the COSE Sign1. <t>First, the verifier checks the signature on the COSE Sign1.
If the verification fails, the consistency proof is not checked. If the verification fails, the consistency proof is not checked.
Second the consistency proof is checked by applying a previous inclusion proof, Second, the consistency proof is checked by applying a previous inclusion proof
to the consistency proof. to the consistency proof.
If the verification fails, the append only property of the verifiable data struc If the verification fails, the append only property of the Verifiable Data Struc
ture is not assured. ture is not assured.
This approach is specific to RFC9162_SHA256, different verifiable data structure This approach is specific to RFC9162_SHA256; different Verifiable Data Structure
s may not support consistency proofs. s may not support consistency proofs.
It is recommended that implementations return a single boolean result for Receip It is recommended that implementations return a single boolean result for Receip
t verification operations, to reduce the chance of accepting a valid signature o t-verification operations to reduce the chance of accepting a valid signature ov
ver an invalid consistency proof.</t> er an invalid consistency proof.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<!--[rfced] The following may require clarification:
Current:
The privacy considerations section of [RFC9162] and [RFC9053] apply to
this document.
RFCs 9162 and 9053 do not have sections explicitly named "Privacy
Considerations". RFC 9053 doesn't appear to contain the term "privacy" at
all. Please review.
-->
<t>The privacy considerations section of <xref target="RFC9162"/> and <xre f target="RFC9053"/> apply to this document.</t> <t>The privacy considerations section of <xref target="RFC9162"/> and <xre f target="RFC9053"/> apply to this document.</t>
<section anchor="log-length"> <section anchor="log-length">
<name>Log Length</name> <name>Log Length</name>
<t>Some structures and proofs leak the size of the log at the time of in clusion. <t>Some structures and proofs leak the size of the log at the time of in clusion.
In the case that a log only stores certain kinds of information, this can reveal details that could impact reputation. 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 b reach notice would reveal the number of previous breaches at the time the notice was made transparent.</t> For example, if a transparency log only stored breach notices, a receipt for a b reach notice would reveal the number of previous breaches at the time the notice was made transparent.</t>
</section> </section>
<section anchor="header-parameters"> <section anchor="header-parameters">
<name>Header Parameters</name> <name>Header Parameters</name>
<t>Additional header parameters can reveal information about the transpa rency service or its log entries. <t>Additional header parameters can reveal information about the transpa rency service or its log entries.
The receipt producer <bcp14>MUST</bcp14> perform a privacy analysis for all mand atory fields in profiles based on this specification.</t> The receipt producer <bcp14>MUST</bcp14> perform a privacy analysis for all mand atory fields in profiles based on this specification.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>See the security considerations section of:</t> <t>See the Security Considerations sections of:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><xref target="RFC9162"/></t> <xref target="RFC9162"/></li>
</li>
<li> <li>
<t><xref target="RFC9053"/></t> <xref target="RFC9053"/></li>
</li>
</ul> </ul>
<section anchor="choice-of-signature-algorithms"> <section anchor="choice-of-signature-algorithms">
<name>Choice of Signature Algorithms</name> <name>Choice of Signature Algorithms</name>
<t>A security analysis ought to be performed to ensure that the digital signature algorithm <tt>alg</tt> has the appropriate strength to secure receipts .</t> <t>A security analysis ought to be performed to ensure that the digital signature algorithm <tt>alg</tt> has the appropriate strength to secure receipts .</t>
<t>It is recommended to select signature algorithms that share cryptogra <t>It is recommended to select signature algorithms that share cryptogra
phic components with the verifiable data structure used, for example: phic components with the Verifiable Data Structure used; for example,
Both RFC9162_SHA256 and ES256 depend on the sha-256 hash function.</t> both RFC9162_SHA256 and ES256 depend on the sha-256 hash function.</t>
</section> </section>
<section anchor="validity-period"> <section anchor="validity-period">
<name>Validity Period</name> <name>Validity Period</name>
<t>In some cases, receipts <bcp14>MAY</bcp14> include strict validity pe <t>In some cases, receipts <bcp14>MAY</bcp14> include strict validity pe
riods, for example, activation not too far in the future, or expiration, not too riods, for example, activation not too far in the future or expiration not too f
far in the past. ar in the past.
See the <tt>iat</tt>, <tt>nbf</tt>, and <tt>exp</tt> claims in <xref target="RFC See the <tt>iat</tt>, <tt>nbf</tt>, and <tt>exp</tt> claims in <xref target="RFC
8392"/>, for one way to accomplish this. 8392"/> for one way to accomplish this.
The details of expressing validity periods are out of scope for this document.</ t> The details of expressing validity periods are out of scope for this document.</ t>
</section> </section>
<section anchor="status-updates"> <section anchor="status-updates">
<name>Status Updates</name> <name>Status Updates</name>
<t>In some cases, receipts should be "revocable" or "suspendible", after being issued, regardless of their validity period. <t>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.</t> The details of expressing statuses are out of scope for this document.</t>
</section> </section>
</section> </section>
<!--[rfced] We had the following questions/comments related to the
IANA Considerations section:
a) For clarity, we have updated the IANA Considerations section by
breaking Section 8.2.2 up into subsections for each of the two
registries. Please review this reorganization as well as any pointers
to it throughout the text to ensure we have correctly maintained your
intent.
b) Please note that we have updated Tables 2 and 3 to include the
Change Controller column as appears at the corresponding IANA
registries. Please let us know any concerns.
c) Note: Any updates to Section 2 and/or Tables 1-3 that have been
made or resulting from author replies to our separate terminology or
abbreviation queries that would impact the information actually
registered at
https://www.iana.org/assignments/cose/cose.xhtml#verifiable-data-structure-algor
ithms
will be communicate to IANA by the RPC once AUTH48 completes.-->
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="cose-header-parameter"> <section anchor="cose-header-parameter">
<name>COSE Header Parameter</name> <name>COSE Header Parameter</name>
<t>IANA is requested to add the COSE header parameters defined in <xref <t>IANA has added the COSE header parameters defined in <xref target="pa
target="param-list"/>, as listed in <xref target="iana-header-params"/>, to the ram-list"/>, and as listed in <xref target="iana-header-params"/>, to the "COSE
"COSE Header Parameters" registry <xref target="IANA.cose_header-parameters"/> i Header Parameters" subregistry <xref target="IANA.cose_header-parameters"/> in t
n the 'Integer values from 256 to 65535' range ('Specification Required' Registr he "CBOR Object Signing and Encryption (COSE)" registry group. These COSE heade
ation Procedure). r parameters fall in the 'Integer values from 256 to 65535' range (with a Specif
The Value Registry for "vds" is the COSE Verifiable Data Structure registry. ication Required registration procedure (see <xref target="RFC8126" format="defa
The map labels in the "vdp" are assigned from the COSE Verifiable Data Structure ult"/>)).
Proofs registry.</t> The Value Registry listed for "vds" is the "COSE Verifiable Data Structure Algor
ithm" subregistry.
The map labels in the "vdp" are assigned from the "COSE Verifiable Data S
tructure Proofs" subregistry.</t>
<table anchor="iana-header-params"> <table anchor="iana-header-params">
<name>Newly registered COSE Header Parameters</name> <name>Newly Registered COSE Header Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Label</th> <th align="left">Label</th>
<th align="left">Value Type</th> <th align="left">Value Type</th>
<th align="left">Value Registry</th> <th align="left">Value Registry</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<tt>receipts</tt></td> <tt>receipts</tt></td>
<td align="left">TBD_0 (requested assignment: 394)</td> <td align="left">394</td>
<td align="left">array</td> <td align="left">array</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">Priority ordered sequence of CBOR encoded Receipt s</td> <td align="left">Priority ordered sequence of CBOR encoded Receipt s</td>
<td align="left">RFCthis, <xref target="param-list"/></td> <td align="left">RFC 9942, <xref target="param-list"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>vds</tt></td> <tt>vds</tt></td>
<td align="left">TBD_1 (requested assignment: 395)</td> <td align="left">395</td>
<td align="left">int</td> <td align="left">int</td>
<td align="left">COSE Verifiable Data Structure</td> <td align="left">COSE Verifiable Data Structure</td>
<td align="left">Algorithm identifier for verifiable data structur <td align="left">Algorithm identifier for Verifiable Data Structur
es, used to produce verifiable data structure proofs</td> es that is used to produce Verifiable Data Structure Proofs</td>
<td align="left">RFCthis, <xref target="param-list"/></td> <td align="left">RFC 9942, <xref target="param-list"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<tt>vdp</tt></td> <tt>vdp</tt></td>
<td align="left">TBD_2 (requested assignment: 396)</td> <td align="left">396</td>
<td align="left">map</td> <td align="left">map</td>
<td align="left">map key in COSE Verifiable Data Structure Proofs< /td> <td align="left">map key in COSE Verifiable Data Structure Proofs< /td>
<td align="left">Location for verifiable data structure proofs in <td align="left">Location for Verifiable Data Structure Proofs in
COSE Header Parameters</td> COSE Header Parameters</td>
<td align="left">RFCthis, <xref target="param-list"/></td> <td align="left">RFC 9942, <xref target="param-list"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="verifiable-data-structure-registries"> <section anchor="verifiable-data-structure-registries">
<name>Verifiable Data Structure Registries</name> <name>Verifiable Data Structure Registries</name>
<t>IANA established the COSE Verifiable Data Structure Algorithms and CO SE Verifiable Data Structure Proofs registries under a Specification Required po licy as described in <xref section="4.6" sectionFormat="of" target="RFC8126"/>.< /t> <t>IANA established the "COSE Verifiable Data Structure Algorithms" and "COSE Verifiable Data Structure Proofs" subregistries under a Specification Requ ired policy as described in <xref section="4.6" sectionFormat="of" target="RFC81 26"/>.</t>
<section anchor="expert-review"> <section anchor="expert-review">
<name>Expert Review</name> <name>Expert Review</name>
<t>Expert reviewers should take into consideration the following point s:</t> <t>Expert reviewers (see <xref target="RFC8126" format="default"/>) sh ould take into consideration the following points:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Experts are advised to assign the next available positive intege
<t>Experts are advised to assign the next available positive integ r for Verifiable Data Structures.</li>
er for verifiable data structures.</t> <li>Point squatting should be discouraged.
</li> Reviewers are encouraged to get sufficient information for registration requests
<li> to ensure that the usage is not going to duplicate one that is already register
<t>Point squatting should be discouraged. ed and that the point is likely to be used in deployments.</li>
Reviewers are encouraged to get sufficient information for registration requests <li>Specifications are required for all point assignments.
to ensure that the usage is not going to duplicate one that is already register early allocation is permissible, see <xref target="RFC7120" section="2"/>.</li>
ed, and that the point is likely to be used in deployments.</t> <li>It is not permissible to assign points in COSE Verifiable Data S
</li> tructure Algorithms for which no corresponding COSE Verifiable Data Structure Pr
<li> oofs entry exists, and vice versa.</li>
<t>Specifications are required for all point assignments. <li>The change controller for related registrations of structures an
Early Allocation is permissible, see Section 2 of <xref target="RFC7120"/>.</t> d proofs should be the same.</li>
</li>
<li>
<t>It is not permissible to assign points in COSE Verifiable Data
Structure Algorithms, for which no corresponding COSE Verifiable Data Structure
Proofs entry exists, and vice versa.</t>
</li>
<li>
<t>The Change Controller for related registrations of structures a
nd proofs should be the same.</t>
</li>
</ul> </ul>
</section> </section>
<section anchor="verifiable-data-structure-registry"> <section anchor="IANA_registry_info">
<name>COSE Verifiable Data Structure Algorithms</name> <name>Templates and Initial Contents</name>
<t>Registration Template:</t> <section anchor="verifiable-data-structure-algorithms-registry">
<ul spacing="normal"> <name>COSE Verifiable Data Structure Algorithms Registry</name>
<li>
<t>Name: <dl spacing="normal" newline="true">
This is a descriptive name for the verifiable data structure that enables easier <dt>Registration Template:</dt>
reference to the item.</t> <dd>
</li> <dl spacing="normal" newline="true">
<li> <dt>Name:</dt>
<t>Value: <dd>This is a descriptive name for the Verifiable Data Structure
This is the value used to identify the verifiable data structure.</t> that enables easier reference to the item.</dd>
</li> <dt>Value:</dt>
<li> <dd>This is the value used to identify the Verifiable Data Structure.
<t>Description: </dd>
This field contains a brief description of the verifiable data structure.</t> <dt>Description:</dt>
</li> <dd>This field contains a brief description of the Verifiable Data St
<li> ructure.</dd>
<t>Reference: <dt>Reference:</dt>
This contains a pointer to the public specification for the verifiable data stru <dd>This contains a pointer to the public specification for the Verif
cture.</t> iable Data Structure.</dd>
</li> <dt>Change Controller:</dt>
<li> <dd>For Standards Track RFCs, list the "IETF". For others, give the
<t>Change Controller: name of the responsible party. Other details (e.g., postal address, email addre
For Standards Track RFCs, list the "IETF". For others, give the name of the res ss, home page URI) may also be included.</dd>
ponsible party. Other details (e.g., postal address, email address, home page U </dl>
RI) may also be included.</t> </dd>
</li> </dl>
</ul> <table align="left" anchor="verifiable-data-structure-algorithms-reg
<t>Initial contents:</t> istry-table">
<table align="left" anchor="verifiable-data-structure-proofs-registry" <name>COSE Verifiable Data Structure Algorithms Initial Registry Con
> tents</name>
<name>COSE Verifiable Data Structure Algorithms</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Change Controller</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left">Reserved</td> <td align="left"></td>
<td align="left">RFC 9942</td>
</tr> </tr>
<tr> <tr>
<td align="left">RFC9162_SHA256</td> <td align="left">RFC9162_SHA256</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">SHA256 Binary Merkle Tree</td> <td align="left">SHA256 Binary Merkle Tree</td>
<td align="left">IETF</td>
<td align="left"> <td align="left">
<xref section="2.1" sectionFormat="of" target="RFC9162"/></td> <xref section="2.1" sectionFormat="of" target="RFC9162"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Registration Template:</t> </section>
<ul spacing="normal">
<li> <section anchor="verifiable-data-structure-proofs-registry">
<t>Verifiable Data Structure: <name>COSE Verifiable Data Structure Proofs Registry</name>
This value used identifies the related verifiable data structure.</t>
</li> <dl spacing="normal" newline="true">
<li> <dt>Registration Template:</dt>
<t>Name: <dd><dl spacing="normal" newline="true">
This is a descriptive name for the proof type that enables easier reference to t <dt>Verifiable Data Structure:</dt>
he item.</t> <dd>This value used identifies the related Verifiable Data Structure.
</li> </dd>
<li> <dt>Name:</dt>
<t>Label: <dd>This is a descriptive name for the proof type that enables easier
This is the value used to identify the verifiable data structure proof type.</t> reference to the item.</dd>
</li> <dt>Label:</dt>
<li> <dd>This is the value used to identify the Verifiable Data Structure
<t>CBOR Type: Proof type.</dd>
This contains the CBOR type for the value portion of the label.</t> <dt>CBOR Type:</dt>
</li> <dd>This contains the CBOR type for the value portion of the label.</
<li> dd>
<t>Description: <dt>Description:</dt>
This field contains a brief description of the proof type.</t> <dd>This field contains a brief description of the proof type.</dd>
</li> <dt>Reference:</dt>
<li> <dd>This contains a pointer to the public specification for the proof
<t>Reference: type.</dd>
This contains a pointer to the public specification for the proof type.</t> <dt>Change Controller:</dt>
</li> <dd>For Standards Track RFCs, list the "IETF". For others, give the
<li> name of the responsible party. Other details (e.g., postal address, email addre
<t>Change Controller: ss, home page URI) may also be included.</dd>
For Standards Track RFCs, list the "IETF". For others, give the name of the res </dl>
ponsible party. Other details (e.g., postal address, email address, home page U </dd>
RI) may also be included.</t> </dl>
</li> <table align="left" anchor="cose-verifiable-data-structure-proofs-ta
</ul> ble">
<t>Initial contents:</t> <name>COSE Verifiable Data Structure Proofs Initial Registry Content
<table align="left" anchor="cose-verifiable-data-structure-proofs"> s</name>
<name>COSE Verifiable Data Structure Proofs</name>
<thead> <thead>
<tr> <tr>
<th align="left">Verifiable Data Structure</th> <th align="left">Verifiable Data Structure</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Label</th> <th align="left">Label</th>
<th align="left">CBOR Type</th> <th align="left">CBOR Type</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Change Controller</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">inclusion proofs</td> <td align="left">inclusion proofs</td>
<td align="left">-1</td> <td align="left">-1</td>
<td align="left">array (of bstr)</td> <td align="left">array (of bstr)</td>
<td align="left">Proof of inclusion</td> <td align="left">Proof of inclusion</td>
<td align="left">RFCthis, <xref target="sec-rfc9162-sha256-inclu <td align="left">IETF</td>
sion-proof"/></td> <td align="left">RFC 9942, <xref target="sec-rfc9162-sha256-incl
usion-proof"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">consistency proofs</td> <td align="left">consistency proofs</td>
<td align="left">-2</td> <td align="left">-2</td>
<td align="left">array (of bstr)</td> <td align="left">array (of bstr)</td>
<td align="left">Proof of append only property</td> <td align="left">Proof of append only property</td>
<td align="left">RFCthis, <xref target="sec-rfc9162-sha256-consi <td align="left">IETF</td>
stency-proof"/></td> <td align="left">RFC 9942, <xref target="sec-rfc9162-sha256-cons
istency-proof"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section>
</section> </section>
</section> </section>
<section anchor="Acknowledgements">
<name>Acknowledgements</name>
<t>We would like to thank
Maik Riechert,
Jon Geater,
Michael B. Jones,
Mike Prorock,
Ilari Liusvaara,
Amaury Chamayou,
for their contributions (some of which substantial) to this draft and to the ini
tial set of implementations.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-cbor-edn-literals" to="CBOR-EDN"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8610"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 610.xml"/>
<title>Concise Data Definition Language (CDDL): A Notational Convent <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu 949.xml"/>
res</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/> 053.xml"/>
<author fullname="C. Vigano" initials="C." surname="Vigano"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="C. Bormann" initials="C." surname="Bormann"/> 162.xml"/>
<date month="June" year="2019"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 597.xml"/>
<t>This document proposes a notational convention to express Conci <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal 596.xml"/>
is to provide an easy and unambiguous way to express structures for protocol me <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
ssages and data formats that use CBOR or JSON.</t> 119.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 174.xml"/>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC9053">
<front>
<title>CBOR Object Signing and Encryption (COSE): Initial Algorithms
</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="August" year="2022"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need to be able to
define basic security services for this data format. This document defines a se
t of algorithms that can be used with the CBOR Object Signing and Encryption (CO
SE) protocol (RFC 9052).</t>
<t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9053"/>
<seriesInfo name="DOI" value="10.17487/RFC9053"/>
</reference>
<reference anchor="RFC9162">
<front>
<title>Certificate Transparency Version 2.0</title>
<author fullname="B. Laurie" initials="B." surname="Laurie"/>
<author fullname="E. Messeri" initials="E." surname="Messeri"/>
<author fullname="R. Stradling" initials="R." surname="Stradling"/>
<date month="December" year="2021"/>
<abstract>
<t>This document describes version 2.0 of the Certificate Transpar
ency (CT) protocol for publicly logging the existence of Transport Layer Securit
y (TLS) server certificates as they are issued or observed, in a manner that all
ows anyone to audit certification authority (CA) activity and notice the issuanc
e of suspect certificates as well as to audit the certificate logs themselves. T
he intent is that eventually clients would refuse to honor certificates that do
not appear in a log, effectively forcing CAs to add all issued certificates to t
he logs.</t>
<t>This document obsoletes RFC 6962. It also specifies a new TLS e
xtension that is used to send various CT log artifacts.</t>
<t>Logs are network services that implement the protocol operation
s for submissions and queries that are defined in this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9162"/>
<seriesInfo name="DOI" value="10.17487/RFC9162"/>
</reference>
<reference anchor="RFC9597">
<front>
<title>CBOR Web Token (CWT) Claims in COSE Headers</title>
<author fullname="T. Looker" initials="T." surname="Looker"/>
<author fullname="M.B. Jones" initials="M.B." surname="Jones"/>
<date month="June" year="2024"/>
<abstract>
<t>This document describes how to include CBOR Web Token (CWT) cla
ims in the header parameters of any CBOR Object Signing and Encryption (COSE) st
ructure. This functionality helps to facilitate applications that wish to make u
se of CWT claims in encrypted COSE structures and/or COSE structures featuring d
etached signatures, while having some of those claims be available before decryp
tion and/or without inspecting the detached payload. Another use case is using C
WT claims with payloads that are not CWT Claims Sets, including payloads that ar
e not CBOR at all.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9597"/>
<seriesInfo name="DOI" value="10.17487/RFC9597"/>
</reference>
<reference anchor="RFC9596">
<front>
<title>CBOR Object Signing and Encryption (COSE) "typ" (type) Header
Parameter</title>
<author fullname="M.B. Jones" initials="M.B." surname="Jones"/>
<author fullname="O. Steele" initials="O." surname="Steele"/>
<date month="June" year="2024"/>
<abstract>
<t>This specification adds the equivalent of the JSON Object Signi
ng and Encryption (JOSE) "typ" (type) header parameter to CBOR Object Signing an
d Encryption (COSE). This enables the benefits of explicit typing (as defined in
RFC 8725, "JSON Web Token Best Current Practices") to be brought to COSE object
s. The syntax of the COSE type header parameter value is the same as the existin
g COSE content type header parameter.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9596"/>
<seriesInfo name="DOI" value="10.17487/RFC9596"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="IANA.cose_header-parameters" target="https://www.iana .org/assignments/cose"> <reference anchor="IANA.cose_header-parameters" target="https://www.iana .org/assignments/cose">
<front> <front>
<title>COSE Header Parameters</title> <title>COSE Header Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7120"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 120.xml"/>
<title>Early IANA Allocation of Standards Track Code Points</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="M. Cotton" initials="M." surname="Cotton"/> 052.xml"/>
<date month="January" year="2014"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 126.xml"/>
<t>This memo describes the process for early allocation of code po <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ints by IANA from registries for which "Specification Required", "RFC Required", 392.xml"/>
"IETF Review", or "Standards Action" policies apply. This process can be used t <!-- [I-D.ietf-cbor-edn-literals]
o alleviate the problem where code point allocation is needed to facilitate desi draft-ietf-cbor-edn-literals-19
red or required implementation and deployment experience prior to publication of IESG State: I-D Exists as of 2/25/26
an RFC, which would normally trigger code point allocation. The procedures in t -->
his document are intended to apply only to IETF Stream documents.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</abstract> ietf-cbor-edn-literals.xml"/>
</front>
<seriesInfo name="BCP" value="100"/>
<seriesInfo name="RFC" value="7120"/>
<seriesInfo name="DOI" value="10.17487/RFC7120"/>
</reference>
<reference anchor="RFC9052">
<front>
<title>CBOR Object Signing and Encryption (COSE): Structures and Pro
cess</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="August" year="2022"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need to be able to
define basic security services for this data format. This document defines the
CBOR Object Signing and Encryption (COSE) protocol. This specification describes
how to create and process signatures, message authentication codes, and encrypt
ion using CBOR for serialization. This specification additionally describes how
to represent cryptographic keys using CBOR.</t>
<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
</abstract>
</front>
<seriesInfo name="STD" value="96"/>
<seriesInfo name="RFC" value="9052"/>
<seriesInfo name="DOI" value="10.17487/RFC9052"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="BCP205">
<front>
<title>Improving Awareness of Running Code: The Implementation Statu
s Section</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<date month="July" year="2016"/>
<abstract>
<t>This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by including an I
mplementation Status section. This will allow reviewers and working groups to as
sign due consideration to documents that have the benefit of running code, which
may serve as evidence of valuable experimentation and feedback that have made t
he implemented protocols more mature.</t>
<t>This process is not mandatory. Authors of Internet-Drafts are e
ncouraged to consider using the process for their documents, and working groups
are invited to think about applying the process to all of their protocol specifi
cations. This document obsoletes RFC 6982, advancing it to a Best Current Practi
ce.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="205"/>
<seriesInfo name="RFC" value="7942"/>
<seriesInfo name="DOI" value="10.17487/RFC7942"/>
</reference>
<reference anchor="RFC8392">
<front>
<title>CBOR Web Token (CWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/
>
<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="May" year="2018"/>
<abstract>
<t>CBOR Web Token (CWT) is a compact means of representing claims
to be transferred between two parties. The claims in a CWT are encoded in the Co
ncise Binary Object Representation (CBOR), and CBOR Object Signing and Encryptio
n (COSE) is used for added application-layer security protection. A claim is a p
iece of information asserted about a subject and is represented as a name/value
pair consisting of a claim name and a claim value. CWT is derived from JSON Web
Token (JWT) but uses CBOR rather than JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8392"/>
<seriesInfo name="DOI" value="10.17487/RFC8392"/>
</reference>
<reference anchor="I-D.draft-ietf-cbor-edn-literals">
<front>
<title>CBOR Extended Diagnostic Notation (EDN)</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<date day="16" month="October" year="2025"/>
<abstract>
<t> This document formalizes and consolidates the definition of
the
Extended Diagnostic Notation (EDN) of the Concise Binary Object
Representation (CBOR), addressing implementer experience.
Replacing EDN's previous informal descriptions, it updates RFC 8949,
obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G.
It also specifies and uses registry-based extension points, using one
to support text representations of epoch-based dates/times and of IP
addresses and prefixes.
// (This cref will be removed by the RFC editor:) The present -19
// includes the definition of the cri'' application- extension. cri''
// was previously defined in draft-ietf-core-href; however the latter
// document overtook the present document in the approval process.
// As the definition of cri'' is dependent on the present document
// (and conversely has essentially no dependency on the technical
// content of draft-ietf-core-href beyond its mere existence), the
// text (including IANA considerations) has been moved here. -19 is
// intended for use at the CBOR WG meeting at IETF 124.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-edn-literals-
19"/>
</reference>
</references> </references>
</references> </references>
<?line 757?>
<section anchor="implementation-status"> <section anchor="Acknowledgements" numbered="false">
<name>Implementation Status</name> <name>Acknowledgements</name>
<t>Note to RFC Editor: Please remove this section as well as references to <t>We would like to thank <contact fullname="Maik Riechert"/>, <contact
<xref target="BCP205"/> before AUTH48.</t> fullname="Jon Geater"/>, <contact fullname="Michael B. Jones"/>,
<t>This section records the status of known implementations of the protoco <contact fullname="Mike Prorock"/>, <contact fullname="Ilari
l defined by this specification at the time of posting of this Internet-Draft, a Liusvaara"/>, and <contact fullname="Amaury Chamayou"/> for their
nd is based on a proposal described in <xref target="BCP205"/>. contributions (some of which substantial) to this document and to the
The description of implementations in this section is intended to assist the IET initial set of implementations.</t>
F in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does not impl
y endorsement by the IETF.
Furthermore, no effort has been spent to verify the information presented here t
hat was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog of available
implementations or their features.
Readers are advised to note that other implementations may exist.</t>
<t>According to <xref target="BCP205"/>, "this will allow reviewers and wo
rking groups to assign due consideration to documents that have the benefit of r
unning code, which may serve as evidence of valuable experimentation and feedbac
k that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as they see fi
t".</t>
<section anchor="transmute-prototype">
<name>Transmute Prototype</name>
<t>An open-source implementation was initiated and is maintained by the
Transmute Industries Inc. - Transmute.
An application demonstrating the concepts is available at <eref target="https://
github.com/transmute-industries/cose?tab=readme-ov-file#transparent-statement">C
OSE SCITT Receipts</eref></t>
<t>Implementation URL: https://github.com/transmute-industries/cose
Maturity: The code's level of maturity is considered to be "prototype".
Coverage and Version Compatibility: The current version ('main') implements the
verifiable data structure algorithm, inclusion proof and consistency proof conce
pts of this draft.
License: The project and all corresponding code and data maintained on GitHub ar
e provided under the Apache License, version 2.
Contact: Orie Steele (orie@transmute.industries)</t>
</section>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse"> <section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="A." surname="Chamayou" fullname="Amaury Chamayou"> <contact initials="A." surname="Chamayou" fullname="Amaury Chamayou">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>amaury.chamayou@microsoft.com</email> <email>amaury.chamayou@microsoft.com</email>
</address> </address>
</contact> </contact>
<contact initials="S." surname="Lasker" fullname="Steve Lasker"> <contact initials="S." surname="Lasker" fullname="Steve Lasker">
<organization/> <organization/>
<address> <address>
<email>stevenlasker@hotmail.com</email> <email>stevenlasker@hotmail.com</email>
</address> </address>
</contact> </contact>
<contact initials="R. A." surname="Martin" fullname="Robert Martin"> <contact initials="R. A." surname="Martin" fullname="Robert Martin">
<organization>MITRE Corporation</organization> <organization>MITRE Corporation</organization>
<address> <address>
<postal> <postal>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>ramartin@mitre.org</email> <email>ramartin@mitre.org</email>
</address> </address>
</contact> </contact>
<contact initials="M." surname="Wiseman" fullname="Monty Wiseman"> <contact initials="M." surname="Wiseman" fullname="Monty Wiseman">
<organization/> <organization/>
<address> <address>
<postal> <postal>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>mwiseman32@acm.org</email> <email>mwiseman32@acm.org</email>
</address> </address>
</contact> </contact>
<contact initials="R." surname="Williams" fullname="Roy Williams"> <contact initials="R." surname="Williams" fullname="Roy Williams">
<organization/> <organization/>
<address> <address>
<postal> <postal>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>roywill@msn.com</email> <email>roywill@msn.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back>
<!-- ##markdown-source: <!--[rfced] We had the following questions/comments related to
H4sIAAAAAAAAA+09a3PjyHHf8Ssm3KqslJCUSL1p3/l0ks6neF9ZaX3lutrS abbreviations used throughout the document.
DoEhiQgEaACkltbKvyW/Jb8s/ZgZDB58yLtxUuVcubwiMI+enu6efk2j0+l4
i4E48Lw8zCM1EBdvb67EzsWPb9+Lt8P/UH4ubsJxHMZjIeNAXMV+upzlYRLv a) FYI - We have added expansions for abbreviations upon first use per
ivfKV+Esz7wg8WM5hb5BKkd5J1T5qOMnmepMVXofqU6eKtWZpUkyyjq9Uy/L Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
YaQ7GSUxdMnTufLCWUp/ZXl/f/9sv+/JVMmBuFH+PA3zpfcwZri8+4eBuI5z expansion in the document carefully to ensure correctness.
lcYq71zibJ4v84HI8sDL5sNpmGUAWr6cwcjXV7c/ebNw4AmRJ/5ALFUGf2ZJ
CuCMMvt7OS1+enKeT5J04HVEGMOzt11xkysVKWjIK3ybhqp4lqRjGYd/kYiP b) We would like to update to use an abbreviation (instead of its
gbhNZaAWKg1HywBeqqkMowG0CdUPSdo76IYJPPWTeZyny4H4EIe5CmAsmcPM expanded form) after first use in accordance with the guidance at
esKfu+LHML2fJNFf7JQ/q/jefQqTDsRPqZzHk2SkUnFzfQtP5XCYqkXDCw3G https://www.rfc-editor.org/styleguide/part2/#exp_abbrev for the
BEbpDvUoP+AWdX3AlPRzRALuEKDx/UQBGHkqs0yJkyMCNwAQXh4f9s+OXuJv following abbreviations. Please let us know any objections.
2I6BuJTpFHYxyN0F/V6lUxkvzVLOu+JSRUA6Mu+8kgs5D+yKzuM8CWPV8L6M
0NehnyZZMsqLZcg4D6IfpuYFrGFaQuofzPQXXfFTMkc6sdNeqCANfefxxtlG VDS
3HTtfB6iMQ2H8xwJR4hi+RcTOZXLZA4P7cqncp4uy29WQ1Gsmrp1fd2tBk+d VDP
rP4ADBvQOw3PTVe8ktm9Sh1ogI4Xyn2sp8vweRzR8x8mSY5P9Ux6tPddXOBr
meZh7Az4PhmqNHefVxZ3ffv+Slwk6SxJ6ZE7awqLw36wOiDHLvRsXJlmGAvK *Note: In the meantime, we have updated all uses in prose to be
6674JcxgDBeQ1ygESs+Rayrj3Zy7008fuPVB/wfpT/X0xXJ/CaMolNOstNpl capitalized for these two terms. Please review the use of "verifiable
+fHGOdJk+QAdfphmMeHTixPgmTxcKOz3/qeL0+PePhDq5eUr/fvs8Ax+gzDm data structure" (in quotes): may this instance be changed to VDS as
32f7RwdaFPLv3nFfdz07OjsZCP8h70wUyKG040cyJMD45TG8RJkMwtHzwnhU well?
mfmk198f2EnMoKe9PvQLZSxBoMdZCOPSvmWd8Rx+QKMfL971948GNMTZYV93
OzjrA5i/oPy57lx23XNhmKQdFcSdCHYzlRFgt/bI8zwV5yhpoP/N1aufBqIF **Note: We also see "verifiable data structure algorithm proofs".
o+aTMGt5XqfTAWmHUgpkl/f840rASQRkD/8/A2INVSaSkZCCBHcoh5ESgcwl Could this be made "VDP algorithms"?
ysS5n89TBaeHfa3SrvfHVQ0zmhJkZ+KHEkmVjjyBp1EmVEw9Mn2kOdO3RTb3
J9BPTMM4nMpIBGHmR0kGQ7bhVJRxNoPzMPaXNH6cxB3153m4SHzaiq536zaZ c) Things get a bit messy when we look at the expansion of VDP if the
qGgGI8kQZHsY86EqYL2pyMMpjIdDTGCuoVKxkLNZFAKgsEIfgRmFPjJXG6Cl expansion of "P" is plural "proofs".
h/iPYhRCq6nKMjlG1GZLEBHTjEfL5jDKUoBwgvnM+gAq2C2RzZTPowKkGgcZ
0GHsA7OV14bnZIzT2MGHSzGch1GAM0Jv2uOdC933xzCWIEn1nr9XM8A/9Je8 For example, in the following:
1wgXUgaCoYT6nCsg3mEYIeZxS+AhrD1NJCAewAzUNKFzD+cf0uYsQpqXJgX4
EvyVwYGQitek1IBg8KM5ahs0GXEHwI0rYU2ny5Q6DYMAdAXvBeotaRIAqaDc Original:
Y7q1JAk4EBnQrSGaDECUOc8RKMA8HLZIa3KYzHPaK0I2icJN5Lvzx8ubXR4P This document describes how to convey VDS and associated VDP types in
p0GFSzyAOkBYcMEQD0AXoEHNVdCtwOfL2ALjAigF6H7zKSAe0QggSZp9KGGH unified COSE envelopes.
dpj84X8WVbtt2820gm6wE0hoSQxUVHRyMFp0y4A9IqDlTOXYhhCAszMGSaEJ
EYkESSTTsWpoWszhMppkYgX28xEueNsIPxCAZmuEyOwEoRyWEic5KJK50NTY If we were to expand this, we'd get "verifiable data structure proofs
iBHaMOBiZ9iudxmOQGXDLrBbhO4ZEQvspn2zeov1uLDT73aZ5OF0GQKHENvB types" (with the double plurals).
dGmJPwiChUzDZJ7RfEjB0JfmRTIklo1z2A+AEVRx5FUYdDhPA6AbZIJwOosI
nSplsYfNcuQKeIKSTWpuA7EAOxaPFTNPieUzlS5CX2VaWFhSClTmg0YFXSbJ However, sometimes the -s on proof disappears when this was expanded
AwmnJF6opQXVEbEINQtYQPUcAVfM+cC0CxUBJMiIL14AKYPMTDUFvEkYER7h in the text.
6h6GfkjSIBOt1x9ubltt/le8eUt/v7/69w/X768u8e+bn89fvbJ/eLrFzc9v
P7y6LP4qel68ff366s0ld4anovTIa70+/1OLpWjr7bvb67dvzl+1cCV5CR+S For example:
D6GhRi9sJS5dguGlEUUEDyfxf/1n71A8Pv4THJb9Xu/s6Un/OO2dHMIP5Hqe
jXiNf8LGLj1kQZkSuUbIALMwh3O4jYdSBnsQw7ECKpnn/cuviJmPA/HboT/r Original:
HX6vH+CCSw8NzkoPCWf1J7XOjMSGRw3TWGyWnlcwXYb3/E+l3wbvzsPf/i5C ..defining the integers used to identify verifiable data structure
8wRs1d9976HofqMemKh+JtVKvJOgrCqi/ccXM/wBukuWP3k1Qh7BQCgrwb4S proof types...
sRmFFTQxs6O0YS9C1AFS2mLm/EDMZ51RmrAYIYoAgzg3J46K4DDgEwueRPBH
WqMc2LHbHy/v9sVOCuSvMiYb5HAC7+DscHfgeWCWNMNFem4gPqX6GPgkHsJ8 and
goeNjOAQQb6jwydNJVFTymKCf2thDLIGUAmcP03S8nGTEXWxgsAU3AR7byXs
R1vBvggA7B1HZ7tE0XljROeuQT2LmIwXEI1BG8knUwE6bpyT3kfSa80x2wVV Original:
FQwbkLKzJEZlIVq2K2xsdxZWTsSQqjFQDWgxO4+PxcAdHLhjB+6YVk9Pu0xQ A data structure which supports one or more Verifiable Data Structure
qJcgmCgMxkiD84x1OA3tcjWUmcZqfyVWj7fE6gywCqIBrD1ETGvT2dSqIVqC Proof Types.
kjozVIJL2ni8aVvSqmhat/6fw7x2WX3LDXBtAjyYxK1KQe1PomS8BKUQDL8B
YN8ouUSrlzQl8f0rGY/nEpSaHWy5y6rryGg8j4/agnx6gqGvLt/QUKjAXqEC It's also a bit strange for it to be plural here:
HECry1CO4yTLQ9+egWIHWjYPBcbn01Nbc3ZIKl6qQBlJebXAvq2gGDDWA+oD
jRovwswMWLf8CMyVnMl6qybGChKZktDwAAIsS5jV470jzN8y5oUgSa2tsKWj Original:
csjY4X+zsdaeWiMB2sQJ6rNE1QgaDtlC0eYCetiKgdcu/J2jzTWv34Cl9SLX The combination of representations of various VDS and VDP can
zhyxgrpAGi1UxyZrE32dSK5snLULdbTt6t68mSPgrgmcZIQ55/Rz7YLpPMpD significantly increase the burden for implementers and create
XHqh5UoxDhdoaQBopDrbNgysVbJ3VlpToM96xc5pdNhtYyUcgADdKBlq5X+o interoperability challenges for transparency services.
+W9JXgANglbm0RB2yUWh705p02XlluCqfyo2F40FIE4HlQ2b3WZtmmnUwQmd
mi273pZmL4WmKAMJqx+F6dSaWLwAhHTJVhbhWxs5ekbomFtM/RGPZ0ZVbI1X Where we will have to make it "various VDSs and VDP" (the reader will
3o8CldidhAOwJv7LQoPcVrYnzbiW6InemB31EvVuwLEBYIMh6enj3j1WErLa likely expect VDPs).
Sb2sCh10PqHQcQ4GFLU1lQnEuI/+CIDQNRDe8Tkdl22EGxK1K7c3K3DxIlN+
Z6xiaOp3Vp4MmdH0Mq2QFeKjydLadLCxfDSbUCI0n/wS7DTgHXTlSaTkiPhK Is it possible to update to use Verifiable Data Structure Proofs
OtakpiLQHKdoBEMT9mA5lNIW03A8ycVELtBAXqA4dqRFZQ1tWB5a6NoPg9ux (VDPs)?
ekkomgpz1mfcVpGCem5p/wybqBFYnmFh7BrZBJYdaCuF94yEXLiQftmRRqIK
3oH1O4Oe2gQlpdV4ogrLlWGp255aZX9IjN8IUZqEaDeSgEcn1lp9JeMZidIR -->
IvYmab8X2m5me7VJDPis+BA1XZR4w+j+/W6ve4CkoN2/YNdhl3KDw1IDdgkA
BKDmafdXVpqTpMoIhEbss/zMyYUAPBXzhoGiiKvOJooRTGv7A6hxbFw7nMQc <!-- [rfced] See a list below of terms enclosed in <tt> in this
RJ7mtexzE07DCExO2PxfzWh8OH/cmeT5LBvs7T08PHTR94zO+L1CS832cHj6 document. Some of these terms appear both with and without <tt>
v+7nST6NXoAFj35t1Oa3cJdkltyKxvZkJg25RBHF2lHQW81xLWMXw8EhAYy6 (alg, receipts, vdp, vds). Please review to ensure the usage of
nX5PqA0UyL1II1arAtsgVWur61DrnNxfgeROIYR3SYRfXfTRhwIaS28g+rv8 <tt> is correct and consistent. Let us know if any updates are
d8r+FqJNPMDEVEmW5knBi64FbM7SDlh8frqAoTtgpXzGfw/EDvoAO4diJ4B/ needed.
NV3f3fx83j86FjubzEQxEL3dQlscJsCcOx14VFY6djoAe6Mf9xvSgx50M1XU
bI8KcbxzdD7yHhucAn6Be8PUPQFXm2etktbqso9zzmT6uKizTcNp16ocRC0U <tt>alg</tt>
1q0aXltd79r1IYItOY8CcqCqzzP06ddciRKDntmaxWQwqMkZgC2V0RLmFOSg <tt>exp</tt>
GpI8Q+87udjDhNgDloXxLKZKtAsdGUHhj2yufRr0shg6sMcPYHk+nRXHmvR9 <tt>iat</tt>
NcsJOCPc4UgknzKz9IcMDbjHF9qp0sGNqzmOeNvJt1q4jarOJ9cxs7PJz7PL <tt>leaf-index</tt>
CyLArAOGnYqsPBkXDGkluSJE4ULncfGbtTDaZoKIoy9Ijr+YgIIBqe46IHOL <tt>nbf</tt>
iKXt6BDwgjZIK72s85ITpiDfNXwVr3urj9GpzEG0GE3fcc0zvMRg+MY95Iw3 <tt>receipts</tt>
qhTA0jYSKULkAoPtCbQmns2HGeLebp4OlHYLDbggxVyOx7RFhMY7jFj2uuyM <tt>tree-size</tt>
HiVRlDzgDKgSgpUPnB8UHgC2WVGdCECh/utf/yr8IIi8G8qjgDXf/QJS5s4E <tt>vdp</tt>
dL4TL467vdOdYpZdzFcAUozkUEXwHphM7IkcNB1+rpf1ncBMDhQyvPN3mva+ <tt>vds</tt>
E49gCv2LcMf4Xjg9PSDlDwXFlPv9846hjgHRpMDOv/6rwGCu6KJ/wJDmx82z
FGuC0X+F9gWZCpD4zpjVVbShsUvVmFpQhRjbzOQySiQOZwfcE3EY4bvMINy+
8z7ajQaA9F93oMzfXVuBuFd6flHIRM/7DTpkWNZoHkQdnoL0rg+eZAwKlvIh
2IX+b6Ffuk7rmcola/wlv0AxDVCg1wy3oaMbClEWL+7oFNr1vOYXmzamvIZy
79Ju1DZsZc/6Tq7ZyNX7uC1glrDhgCctA+gUWIoeLQIi8yPn4QaSfsaq7MSL
YDYgty2OVxmgMHirO5M9G5g1Y1lY7MnP2stAdHpNYNVgWbd0O8Wv4l83DCQ2
7BwRpEN+SJuo3txl4V/UQMxhj5C10WK+C+NAfS6e2ZXdgV05GRAwNNJHJBdv
BVdX+cZ5VeWc2qtn8k6l/wZ5t6bzM0Wh+A0Gx1Rackugi2Fb3loH+Aruajey
V/vZJL1+2c/lsNoOfhWP1Uez8DiqtOWzfhNwDRCtR8I6XqsT6Ma9bOK3guHu
egV7OU/7zlNnpY18B+qP9zgQL0bhuGM0iw7qQ4Jymb9rof6kA3ekr7K6wEHM
PJc+anqmY+upqoA5SXLi6vJNk+6FIQ0MgXh7nFyX0QR7AngeV7tX4t898dvf
PlI64J64DwP4/0Pgi8nLod8/Oxke9brdrjpUwWg/UC/bul1hOMKg0Lpz0hbi
hbi6AXxDk6fvv2/TPC5/7wkzi1XG91Dfgu78QgAgzQDzf6vANm9d4OXQB/W0
1wfgDw6Pjk9Oz/Y18Kb1hiUUDYGj7d/A2Gi2t6GhJjIBRNZxu+i1mx5NGHCW
g4SNwx47WDCvQ0dB6yCIv5YaILqqT7Ab0iv8c9aG/yM36544bTe0cwxiIGKx
V2syeXlydHQqz45GSAL7fXVwFBy/rDT7+P33pScf3ameih9PLlJcuQ0Cex5F
7ltXQO8BFPv9oN8/UQFA4fvBwcnJ4chA8XG3wPb/E4/7+uuI59ghnqO/kXjO
Do76o7OTQ8Di4WgkT3xVxqJpd3R4un88OkBsj/b3T5Tc/98gsoPjo9Pe6OAU
oJBA9b2z432XyDw7/BNLtvLoQKS94xP/6MSH/oFSKjgODl9yy+pM/aPDw1Gf
yPno9HD/9Oxg+NL7uNt8bKggNqcGhr50FNeeGjwunRw2hlk9OawLrvBAGEeJ
9QBQmB2DKWh96WBKqblJytSmrVk9OjrWB15M+M3NgawMVnflcGSAjknHyYAn
5uagVVbyOVL8ck12zKoMPz1a3aQ18BfnsQ62Fa7xURhRxGGm/+zAGmAvMFtr
jRmMAUrjnc4pLmIXTgE2PRqjxuCfPDywwqJxJnRSGgU7WZnoepf6L9ORVuYX
zi7yuQHhJNPZXJv7qC1ztK4w/HUQCPdKyDGmUeWVwJVQaZrAcEXaVUH+gGk9
XyCGc3an2YVQAFnHxyJN0nbirmfRamPzdlwdkOaoFHq+CA8yElWqcsO0koLs
fjJP5djkUtwr7aJmXxygZwoLlnnCwUDrdsXYPl1ioFFgFowYwiAG5jAlJzFl
ttDdjTz0gTreAnQPkoYyuQnky7P6HOXeFunPBWmHlMpj2DBfzsQOhZVqrlfj
v++YKxU6Csf7wOEXvCEhcXFGaTR5MNUrGhR5f0E5qoXjsJSw6nlXa9mrkmeP
af2U/ECZuvYAMT5NG7Igd6TeTp1pS9kCaoOocbLiKNMnz0opKDqY3mWgy6A1
TGkSnU3iB0gIxiNHG8r3KNDBj4jHeFg68jsoMNbExAp2xQ2i5B4t2tlnjQ61
CoQ2TiSFP0lCn8hhIrNJoYtQsrhCIgcWvj5/c15y+cIBAdw6RKIO2FdHsrFY
jpMFVIr1My6QVGykBXtrcYjogT8P7vAHcYA2uV2HAzYq3HbvymFkzJBDEbpQ
lNj9dTHlNsfRWmWh3eJcZuchwduyAtfJt2Hve6QWwLclLIb1jHDKVzah+eqc
lNxROTw4Yvo8CqnldPB0RKaTGhOUcq9LmCojMkTH62zGso/ESpHx50b4SxmL
bZBDJgZAaSF6PzoosLS8WJ3PwuqIzk6s5rDSPKuTz+Blj48+3Am0gp/bvbo9
7SL35Ba9Q3ximUNeJ09Kzrwt85lh9mdESU0Xl3ArG7JzWTrwcVoHvN22dhjg
GRlhsgZv9Kxob4/XRkUHd6bCggU1EjFmEwlL71S8pRi4r4F+UAP+95ibxDFL
EGaVib4S+FJSLWuGmBRVDvKSktSQbtSgwGXsJtExqsp6q74hUvx/ww5EMo7w
9J+nbixa+xXZXdQpvLamLzltET4yqOj2m1L0Dh90HJ+u6UE2FeleJk9q1ZQO
9HVP1F+NSVHZYvIPVdct8dLzd61IjfKWdVRRli6dvYG1WSuba8wMlB/iU7Gi
T5aJaO8jE/W1mh2qNJXYZpXK+pV8IU8Ho2APOCuPqc+IxMrmZyyfcXpCYwzL
0NlYOARQwffieuQ41hHiMV0YQoEC1ITH4J/noEqijDS+QAoTgzUiw8hRjd3E
ME2lJu2anXaaBmQBC+ciR+zJw1y4KGIYzTFUEF2RzljMiNfiTHKp1dQ40Adv
7S553jWmSuprfBUUtatKuCN2rM9cq7w2lz0zRwacFcgOBOEnS/yftIlS1b51
BmTNnCozrGsulPjUjme0VMzT/1viXJ2S27tDbm/vqWAW6AgU7PCHSYmoQtDI
MjZYYJRzlnxNO4Oc08FjRewQSLiCgTB3lLqOgd9086PL+bSCq0qEeDOlQ+4m
M9im/KPSXCtvD287N+153ZL/2l2vimcTBqhKr4+e5xzHtun6AGB1bIxDOEto
IrRS1KU24zNobIY0Vp+skabON10f4ETx2E0Y0OTHNAbTlchi3T2bLclCZ6GV
COG1nHWp0EV5b8zMnTJ5X1ekdXmsc7qtBb3xNNPkZeQUH/XPIKmaWGOFriHN
2xw05zHFVozDrczEThL4diqHvp8WVLwwYofN9ZKj6GnX5YG/OZKz0UP9DN/0
hnDOCk/0Wh902fts/c79fcfx3DspO93X+JwnL0HDGe0f7WOoot/v+Wd9f1jy
Nk9eDoP93sGxRL/r8bB/6o/6vUqL4PhUjs6CY2hxdjDsHR/0h4UnuvBBa+/z
am+w8TXXfb+B6h+O9n30Ep/JI2DQ0zPj+y1panesqd0VAX59CDXKh1WHC/IM
Xk6uJdBpWRNWrivMY0yjy43HqMZRhTnFAzY5brWNV+5J9RiK0yxVhSMwRC2L
ev4UwtzlFDwuBJE1QkOXB2YJCC+UTnwpZAdv1U/VdKjSXTFc5mixX2vzQvvp
SG/L2o1D2kwkqkKRA+urVPv16uNkc99XKtBDgWo0j+gqWuVGA2ttGmE2uqvt
Sif6qymIMkWTklcd8AB9/Pus4k51vPJCp+pdjxxgyDdtW+uxNLiGYrDkBjp3
SpqhHtjes1nrdVs7aZAoLj7AF5/alRWsxTcarK4PaY3JWks9aDRaD9carfW5
vrnVShZlg9Vaz+7ewmytrRlUlEbLNYmCIg+G1XljVpSN1k6vbITGbgLN2o79
VdZrw9xJfdwu9SstqGrLNhizRkSWsjGeZ8nWthyFZsWOKmVDupZUbdPaJiO7
Ie2IamzQlUOT2sx9tTmMpqaLKtuPLsDitbG8ojmwV3qtRebsj9GftlPO6+T4
f8Yoc4nkG5tlzkb/Axtmz9j7uggyxlldNq01z1ZnjtVn+PuYaH93k6mOMWs0
9UujX1T352vNpk0bftso07axn4zthHbUavtpu8PvH9SAcnGzhxfP1plQcIJY
Cwov5wDY+4dlC6qE67oNpY6GB+rkGDN2/EN52jsY+hUL6fREncr9U87pOeqf
jY7PKi1GJ73+6OQYrayzvtwfjQ6Ot7Cyyi36h2dqJIfYYnhy3Dv0/aAKx1EQ
HPfPDjBD6/Ssdxj4vW9sqZ0dHh6fjU5whqN+oI5PZG+tpeaqIetstSvNFe5W
6PbfwGRr4OatjTbHQGuqHLfKbGuy25rtlXiVveL6zl37rA6DrmVG46uysdTY
WDfEu8M2+wBTadSCiozVveFJ81gbQXWLxc1MGYhktN52MsvBy3opLocCvW4F
QDeVqSwSt7xSjCYWTmEi900XSa91CRWwc6actcJV/so30qEBDMkKcDyGqYZJ
EilKWiLTd1Rckypjie5K6hv7lGVEaRWE5gkloiBt0fVE3h04iUPXXUDFMcjP
xm8aNsfDvCu++HhRqgdq9F5+V64VaiPqaFY+VlMMdEibyYbpolwFCsyEV6Bt
v1LxOJ+AvZlMV92XByzda174izXbtaZOYZ5wqkr1/LpoaBCCuMQdldvADkRe
WZ5Qvpiu8Xcfov5P3W0ekS40xCllC4VVFPiGrgnl4J1W2F/p013Zea7DVqW8
jxBN01JhvDIIwFUppZAAfWG5vDZdO2YC4PO+9F480KwaHjKV5uio4YwuzZDc
A9HnoIba6jGwHCnmrxRw6b2olUADHaRIBasngDm4cROwuJIlB9/qJQExIIhp
RYgInTLCwS6zbp00pC+PAuHjyCRx9LVcc/uXY6KRk2EGgjMKyJFvtBmB1RkD
lpvVO59E8/ZScZXo0flBBGcarKT8Aeq6DvXTL0377IKxyUaF1XNuywgAkt37
x3pxyRyvZbOpq3GggmoKHeWuhGOs6OcePVbr+gR/fiIHlS2LCljE1CbgMmI6
urOPkxc5r4CWBmmGzSLMWWyYR7MEnOJYqRNLyibjVM4mIHPR75PEVJnRBq3X
Vxgp3VofeD9iKlJFk6Xyv6hD6oRbm207kagssmY9mse+2eUXqN+HASL4HUye
BOSGyFDcoHgAtrPXKV6f/8mmFmKaDKx4YfrOqG9WuVcvMe+KKT8m70wCh1pq
c1znXECKeszCVMuWhpYzmeVdS3afYJs+tcWneDj6xPH2T9D/k8ma1HVlfrnF
dC0EJykyI+EgQG9bmE2I6E2JEBZeQIQwDgi/TF91Li2NFBTkXtR6fDh1isSg
stjGUt0gaz7MAirZvRKd+u4/EHELJEXi465z2YBsnlHlGXwACxxhwsBQUZyf
6tTiIGOZBhE6ilngh2kV4HVrywhEte2aOE+tKgWQe5su6MOKsXnI1TDYokXU
B0GhoNUFZsnUc4pLPlGxDfzTvKS63Nowp4YZNtKqVau5YGWrSP98fPwnhK+L
5tqdOww1xNQ1prmX1zqTTF8OJ48jshDMdHx0dHD0UoAIx6p0L29KqZQ6hTV4
Wc5sfYeO/QCLL/LOsFn93oDF9QQDgDR0nPerA7NmPTwYOijIorfJHTDWrMW1
GTLtUrTZ1huG1jHfYgbvi3gD+NH2zxfxilwb6/77opdH9Ve+VNf6RVw6ru6/
x39fYHJdmqn+zvvScf4r/Vjx3/oO24zwbf9bNyMszy2Z8UWsqZmhCxR80cVM
NepquHyHlUS4IFVAIRWuAcHneFE7HF3hRth95e49Pv4zVsRHRi9LB0HLo3Kn
uuka96f2DX+h+g927A3c8KXQR6pZoasNo7YtVmjyvDfeLNlikbPSIle4DLVz
8gvJBLtI/IEVnzFLfSvuBy5PjB261cWYeFWt4K/fYfSH1KW+cXm8UQ/R0taO
MYWw60fA0/r0YSOeQjqz8QRzswe3EJuF2moL8W8tZDEKTb4WUOabTxMxS6KQ
Ku+sysE+7B7rACR+v8Jer7j6jN4CGGcRqgdP/0rpl1OBKMfrKcAWSVmXr9xF
4oJwpNTzQLr6T8AVT6k6KpVb41DVZzAsF6B+0PpnSRZSKqLJ0F7PQfghAfEO
5xPZn+cy59CvVZmwhr2+XdP13tvV1O/djBV6J2yBPdcYG1G81DmiNTtlTbbE
nAoYaY/KONHVk4I5KJP49QhSMtmvAVBEYGcGLk0WaaGsz9K6QtRr7hXb/0Nd
3xTL6qtZlCzpCgxhoUQQvMbUUIUx9HhEp5AZ3kNJYehz2DtNSphdgFn4nNPA
l3lsBNu6KfCTKEQ8HcG2Di7Y6efssq4PuFmmnDuF4Ypc0zhxYoz02YmtWIYT
B9RnQK1OtyXbGUgpkwQ2pXBPSDe7wK8UJfTxBN7tiEorlWoVCdeNWfKsFORG
JhQIEs1T20uCxxdblMDDUhoOGd4qMFEATuIzVLzwgzDku6P8D5smALyEhalt
xa0133JBwjPfIVEywwMstQqRVp3DXE0Jf7qQajEnDU4qXK3k84bkDRjNUfXs
mOSMKGqloysnVKN6AsSmsa1SZ0d2xiTqVKlZ3mwOstyvXHvaiDqapkZMOB06
s27QMy7xGwq3qfTvUfYCSeK5xTo4foyt1eW2YKxTxT8qC0jyUU6tu46ZgPkL
Trd8CZ24spEx4HZUd9xtoxRFjwYYU2jLtfkTS8XPCRqaM5RUH95f75J7VkaZ
/ogCF9BFHwbeA8FPfiR4j5AEeknD10cya+1bKOuOdk26tIcP0KelgqLJvm1a
ftM4GjfBccruDXjZ0430kx9LJYjpqo2jU6y6n8RB/20v2DSnfGwrA1pbyYx3
publ9td+1omNlRNZTnEY2qq1mbmetr4AXfeZgqlIVXqmJCJD81tIonK2VIeN
FC6tXRUcubkARPBaAUGTYozDEU5kcX8DIVcB7ptJteqi/xHE2DpDririROHM
+FKQRPFqveBrkHq9NUKtdnsIH3Z6/JLt7R2dWLHLRjaVbnfiNuXxSgbTFhft
njbAVw/dIXz9zfA1xiY3w1fPqmSpvFW9379FIrOEJTNQnPv3cfIQqWCsv430
+KL6CNr9YqJKqKYzx8n43nstQ+CRUPlA2Hnb+zfYmd/Tra629xr0Wgnk9GNX
wGOV4ZN7mjpN/Pu2dx3JNBSvwnm2kGCZtr3KpzHbnubdMBX2C5ukpO6QDxnv
ZemvQAwxLI/0v1uED/GDg2xpaEGqOUR/DaxWBJy+1TYElicnb7nSAruxzZ04
ig+LqyDE732KdxF9HStV02ShywyYmA/Ypw8KDBKZFXKdDKrHR/5oIlj0QzXC
rxCcf7j9+fC0W7mAjKEVFEWkcrMrHUDHvYlrMeNCfuaJn0TWiUy1vGsf4qvE
Q1EG6S8EUOPyF3bt5zxslIxqZEAnCneWLHCzMFtx3BXwVZhtjVW9XirRkNtQ
EppWWu6i2MXmGBIMYCFGeFA9CBPKGxufPm1+pncK9lbvUWyvNNKJFdo1yxi9
QUG4CAO8glips0G3lW1+Nb5c4ncRkzSjRqZaOoLY9X6apyjk8dMSGL7BevaY
DGA/uIjRDArYcZ62Js3CENcpy5QxYqwVDMXSNxZD3k9ChvPRWXNZXhuoFoVS
24RUjgDf6HxY/ABgwIY2RpKBJCTFm0eOi6JGXoYVR0pqp8R7XQu44vYosEzn
Y20kPMHIYsXcNR8JXDsQCuJpixbRBX4qFU365MHx0uCKHpL0HnuN02Q+yxwz
PJirqtcmsfEbHYCkPHjE+1DFwCQkDtJ5TEly6Ko1NwkQUFK+kYEVVmXQbl1U
gAhJWKc6DQtKoa8PKBWgGHHm4jD6xEEql7QgRs34MyRTqVP8yc8wnxViy5Jl
fdHzrKGwCYdxl+TSgNW1OBJHnwidYsUZzM9NUBGi1EE4o+JOlsyxRE2F7ulj
kCQ1TSXosPiuaPGVgGLk6ziYawfedex3Rad418W56I6JFkDFBzfNBz7w2whK
V0gq6BBwyCXsby6ub2+tE72oXj8Gw2I+xI/p7uVmNrwWrSGh+vW/y+XwO/RD
TVUnWXQw5P/CSWvo2E9D7npeRfR/eP9qIJ4zFxyJOQXpB+R8QYJ6iYkpCzgK
6eILvxWsyhKhGmYUrZnZG9i1C8zGQb2Pvs0IlI/gXLjftdAz6PvqC91k5yXu
0cvdYjuzDQaBU9ak6TpRPd3LbpU5L0jgdr1Xoa/iTDFc0JS+zErfa8RvCpb8
W1RkBl8RLA5VoQYR5j/Ph6bkD1fOYY8wruN8hnkrQs/VtuvuI8roe+alj7SD
pobfX7f71S32a9f7b8rrUyz8fgAA
--> -->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
</back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
939 lines changed or deleted 624 lines changed or added

This html diff was produced by rfcdiff 1.48.