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>
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-merkle-tree-proofs- <title abbrev="COSE Receipts">CBOR Object Signing and Encryption (COSE) Rece
18"/> 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="Cédric 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="April"/>
<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. <keyword>COSE</keyword>
Transparency helps maintain trust over time, and has been applied to certificate
s, end to end encrypted messaging systems, and supply chain security. <abstract>
This specification enables concise transparency oriented systems, by building on <t>CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Veri
CBOR (Concise Binary Object Representation) and COSE. fiable Data Structure (VDS) to a verifier.
VDSs and associated Proof Types enable security properties, such as minimal disc
losure, 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 (VDPs).
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 of array where the array contains one or more COSE Receipts as specified in thi s 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 S
re), which conveys the algorithm identifier for a verifiable data structure. tructure), which conveys the algorithm identifier for a VDS.
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 VDSs.</t>
data structures.</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 VDPs), which conv
ata structure proofs"), which conveys a map containing verifiable data structure eys a map containing VDPs organized by Proof Type.
proofs organized by proof type. Correspondingly, see <xref target="verifiable-data-structure-proofs-registry"/>
Correspondingly, this document introduces a new registry (<xref target="verifiab for a registry defining the integers used to identify VDP Proof Types.</t>
le-data-structure-proofs-registry"/>) defining the integers used to identify ver
ifiable data structure proof types.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name>
<name>Terminology</name>
<t>The terms "header" and "payload" are defined
in <xref target="STD96"/>.</t>
<t>Additionally, this document uses the following terminology:</t>
<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= <t>CBOR Extended Diagnostic Notation (EDN) is defined in <xref target=
"RFC8949"/>, where it is referred to as "diagnostic notation", and is revised in "RFC8949"/>, where it is referred to as "diagnostic notation", and is revised in
<xref target="I-D.draft-ietf-cbor-edn-literals"/>.</t> <xref target="I-D.ietf-cbor-edn-literals"/>.</t>
</dd>
<dt>Verifiable Data Structure (VDS):</dt>
<dd>
<t>A data structure which supports one or more Verifiable Data Structu
re Proof Types.
This property describes an algorithm used to maintain a verifiable data structur
e, for example a binary Merkle tree algorithm.</t>
</dd> </dd>
<dt>Verifiable Data Structure Proofs (VDP):</dt> <dt>Entry:</dt>
<dd> <dd>
<t>A data structure used to convey proof types for proving different p <t>An entry in a VDS for which proofs can be derived.</t>
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>
</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 <t>A property that can be obtained by verifying a given proof over one
or more entries in a Verifiable Data Structure. or more entries in a VDS.
For example, a VDS, such as a binary Merkle tree, can support proofs of type "in For example, a VDS, such as a binary Merkle Tree, can support inclusion proofs w
clusion" where each proof confirms that a given entry is included in a Merkle ro here each proof confirms that a given entry is included in a Merkle Tree root.</
ot.</t> 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>Receipt:</dt>
<dd> <dd>
<t>An entry in a verifiable data structure for which proofs can be der ived.</t> <t>A COSE Single Signer Data Object, as defined in RFC 9052 <xref targ et="STD96"/>, containing the header parameters necessary to convey one or more V DP for an associated VDS.</t>
</dd> </dd>
<dt>Receipt:</dt> <dt>Verifiable Data Structure (VDS):</dt>
<dd> <dd>
<t>A COSE object, as defined in <xref target="RFC9052"/>, containing t <t>A data structure that supports one or more VDP Proof Types.
he header parameters necessary to convey VDP for an associated VDS.</t> This property describes an algorithm used to maintain a VDS, for example, a bina
ry Merkle Tree algorithm.</t>
</dd>
<dt>Verifiable Data Structure Proofs (VDPs):</dt>
<dd>
<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 proo
f (inclusion and consistency).</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>VDSs in CBOR</name>
<t>This section describes representations of verifiable data structure pro <t>This section describes representations of VDPs 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 Tree root might have several different representations, depending
the verifiable data structure used. on the VDS 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 VDSs with COSE and provi des concrete examples for the structures and proofs defined in <xref section="2. 1.3" sectionFormat="of" target="RFC9162"/> and <xref section="2.1.4" sectionForm at="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 VDSs support different algorithms.</t>
<t>This document establishes a registry of verifiable data structure alg <t>This document establishes a registry of VDS algorithms; see <xref tar
orithms, see <xref target="verifiable-data-structure-registry"/> for details.</t get="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". <!-- [authors] We have updated the sentence as follows for clarity:
Implementers should not expect interoperability across "verifiable data structur
es". ...for example EC2 keys (1: 2) require and give meaning to specific parameters,
such as -1 (crv), -2 (x), -3 (y), -4 (d). RFC9162_SHA256 (395: 1) supports both
(-1) inclusion and (-2) consistency proofs.
Please let us know if you have any further suggestions. -->
<t>As is the case for COSE Key Type Parameters <xref target="IANA.cose_h
eader-parameters" format="default"/>, EC2 keys (1: 2) require and give meaning t
o specific parameters, such as -1 (crv), -2 (x), -3 (y), and -4 (d). RFC9162_SHA
256 (395: 1) supports both (-1) inclusion and (-2) consistency proofs.</t>
<t>This document establishes a registry of VDPs; see <xref target="verif
iable-data-structure-proofs-registry"/> for details.</t>
<t>Proof Types are specific to their associated "VDS"; for example, diff
erent Merkle Trees might support different representations of inclusion proof or
consistency proof.
Implementers should not expect interoperability across "VDSs".
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 head
tected and unprotected headers of COSE Objects.</t> ers of Enveloped COSE Structures.</t>
<t>When the receipts header parameter is present, the verifier <bcp14>MU <t>When the "receipts" header parameter is present, the verifier <bcp14>
ST</bcp14> confirm that the associated verifiable data structure and verifiable MUST</bcp14> confirm that the associated VDS and VDPs match entries present in t
data structure proofs match entries present in the registries established in thi he registries established in this specification, including values added in subse
s specification, including values added in subsequent registrations..</t> quent 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>
<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
} }
Unprotected_Header = { Unprotected_Header = {
&(receipts: 394) => [+ bstr .cbor Receipt] &(receipts: 394) => [+ bstr .cbor Receipt]
* cose.label => cose.values * cose-label => cose-values
} }
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 VDSs may have different proof formats.
Receipt_For_Inclusion = #6.18(Signed_Inclusion_Proof) Receipt_For_Inclusion = /6.18(Signed_Inclusion_Proof)
Signed_Inclusion_Proof = [ Signed_Inclusion_Proof = [
protected : bstr .cbor RFC9162_SHA256_Inclusion_Protected_Header protected :
unprotected : RFC9162_SHA256_Inclusion_Unprotected_Header bstr .cbor RFC9162_SHA256_Inclusion_Protected_Header,
payload : bstr / nil unprotected : RFC9162_SHA256_Inclusion_Unprotected_Header,
payload : bstr / nil,
signature : bstr signature : bstr
] ]
RFC9162_SHA256_Inclusion_Protected_Header = { RFC9162_SHA256_Inclusion_Protected_Header = {
&(alg: 1) => int &(alg: 1) => int
&(vds: 395) => int &(vds: 395) => int
* cose.label => cose.values * cose-label => cose-values
} }
RFC9162_SHA256_Inclusion_Unprotected_Header = { RFC9162_SHA256_Inclusion_Unprotected_Header = {
&(vdp: 396) => RFC9162_SHA256_Verifiable_Inclusion_Proofs &(vdp: 396) => RFC9162_SHA256_Verifiable_Inclusion_Proofs
* cose.label => cose.values * cose-label => cose-values
} }
RFC9162_SHA256_Verifiable_Inclusion_Proofs = { RFC9162_SHA256_Verifiable_Inclusion_Proofs = {
&(inclusion-proof: -1) => RFC9162_SHA256_Inclusion_Proofs &(inclusion-proof: -1) => RFC9162_SHA256_Inclusion_Proofs
} }
RFC9162_SHA256_Inclusion_Proofs = [ + RFC9162_SHA256_Inclusion_Proof ] RFC9162_SHA256_Inclusion_Proofs = [
+ RFC9162_SHA256_Inclusion_Proof
]
RFC9162_SHA256_Inclusion_Proof = bstr .cbor [ RFC9162_SHA256_Inclusion_Proof = bstr .cbor [
tree_size: uint, tree_size: uint,
leaf_index: uint, leaf_index: uint,
inclusion_path: [ + bstr ] inclusion_path: [ + bstr ]
] ]
Receipt_For_Consistency = #6.18(Signed_Consistency_Proof) Receipt_For_Consistency = /6.18(Signed_Consistency_Proof)
Signed_Consistency_Proof = [ Signed_Consistency_Proof = [
protected : bstr .cbor RFC9162_SHA256_Consistency_Protected_Header, protected :
bstr .cbor RFC9162_SHA256_Consistency_Protected_Header,
unprotected : RFC9162_SHA256_Consistency_Unprotected_Header, unprotected : RFC9162_SHA256_Consistency_Unprotected_Header,
payload : bstr / nil, ; Newer Merkle tree root payload : bstr / nil, ; Newer Merkle Tree root
signature : bstr signature : bstr
] ]
RFC9162_SHA256_Consistency_Protected_Header = { RFC9162_SHA256_Consistency_Protected_Header = {
&(alg: 1) => int, &(alg: 1) => int,
&(vds: 395) => int, &(vds: 395) => int,
* cose.label => cose.values * cose-label => cose-values
} }
RFC9162_SHA256_Consistency_Unprotected_Header = { RFC9162_SHA256_Consistency_Unprotected_Header = {
&(vdp: 396) => RFC9162_SHA256_Verifiable_Consistency_Proofs &(vdp: 396) => RFC9162_SHA256_Verifiable_Consistency_Proofs
* cose.label => cose.values * cose-label => cose-values
} }
RFC9162_SHA256_Verifiable_Consistency_Proofs = { RFC9162_SHA256_Verifiable_Consistency_Proofs = {
&(consistency-proof: -2) => RFC9162_SHA256_Consistency_Proofs &(consistency-proof: -2) => RFC9162_SHA256_Consistency_Proofs
} }
RFC9162_SHA256_Consistency_Proofs = [ + RFC9162_SHA256_Consistency_Proof ] RFC9162_SHA256_Consistency_Proofs = [
+ RFC9162_SHA256_Consistency_Proof
]
RFC9162_SHA256_Consistency_Proof = bstr .cbor [ RFC9162_SHA256_Consistency_Proof = bstr .cbor [
tree_size_1: uint, tree_size_1: uint,
tree_size_2: uint, tree_size_2: uint,
consistency_path: [ + bstr ] consistency_path: [ + bstr ]
] ]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<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 / <<{
/ kid / 4 : h'abcdef12...34567890', / kid / 4 : h'abcdef12...34567890',
/ algorithm / 1 : -7, # ES256 / algorithm / 1 : -7, / ES256
/ vds / 395 : 1, # RFC9162 SHA-256 / vds / 395 : 1, / RFC9162_SHA256
}>>, }>>,
/ unprotected / { / unprotected / {
/ proofs / 396 : { / proofs / 396 : {
/ inclusion / -1 : [ / inclusion / -1 : [
<<[ <<[
/ size / 9, / leaf / 8, / size / 9, / leaf / 8,
/ inclusion path / / inclusion path /
h'7558a95f...e02e35d6' h'7558a95f...e02e35d6'
]>> ]>>
], ],
},
}, },
}, / payload / null,
/ payload / null, / signature / h'02d227ed...ccd3774f'
/ signature / h'02d227ed...ccd3774f' ])>>,
])>>, <</ cose-sign1 / 18([
<</ cose-sign1 / 18([ / protected / <<{
/ protected / <<{ / kid / 4 : h'abcdef12...34567890',
/ kid / 4 : h'abcdef12...34567890', / algorithm / 1 : -7, / ES256
/ algorithm / 1 : -7, # ES256 / vds / 395 : 1, / RFC9162_SHA256
/ vds / 395 : 1, # RFC9162 SHA-256 }>>,
}>>, / unprotected / {
/ unprotected / { / proofs / 396 : {
/ proofs / 396 : { / inclusion / -1 : [
/ inclusion / -1 : [ <<[
<<[ / size / 6, / leaf / 5,
/ size / 6, / leaf / 5, / inclusion path /
/ inclusion path / [ h'9352f974...4ffa7ce0',
h'9352f974...4ffa7ce0', h'54806f32...f007ea06' ]
h'54806f32...f007ea06' ]>>
]>> ],
], },
}, },
}, / 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 VDPs contained in the COSE_Sign1 unprotected
The CDDL definition for verifiable data structure proofs is specific to each ver header.
ifiable data structure. The CDDL definition for VDPs is specific to each VDS.
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 VDSs can require the definition of a profile.
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" (t ype) header parameter; see <xref target="RFC9596"/> and the similar guidance pro vided 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 <t>Each VDS specification applying for inclusion in this registry <bcp
in this registry <bcp14>MUST</bcp14> define how to encode the verifiable data s 14>MUST</bcp14> define how to encode the VDS identifier and its Proof Types in C
tructure identifier and its proof types in CBOR. BOR.
Each specification <bcp14>MUST</bcp14> define how to produce and consume the sup Each specification <bcp14>MUST</bcp14> define how to produce and consume the sup
ported proof types. 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 VDS is 1.
The string identifier for this Verifiable Data Structure is "RFC9162_SHA256", a The string identifier for this VDS is "RFC9162_SHA256", a Merkle Tree where SHA2
Merkle Tree where SHA256 is used as the hash algorithm. 56 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 VDS.</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 VDP 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 Tree 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 Tree root
inclusion-path: [ + bstr ] inclusion-path: [ + bstr ]
] ]]]></sourcecode>
]]></sourcecode>
</figure> </figure>
<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 proof, the payload is the Merkle Tree root that corresp onds 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>. VDS algorith
</li> m 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 VDP in an Unprotected Header</name>
<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
proofs. Value type: Array of bstr.</t> <t>The payload of an RFC9162_SHA256 inclusion proof signature is the M
</li> erkle Tree Hash as defined in <xref target="RFC9162"/>.</t>
</ul>
<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_SHA256
}>>, }>>,
/ unprotected / { / unprotected / {
/ proofs / 396 : { / proofs / 396 : {
/ inclusion / -1 : [ / inclusion / -1 : [
<<[ <<[
/ size / 20, / leaf / 17, / size / 20, / leaf / 17,
/ inclusion path / / inclusion path /
h'fc9f050f...221c92cb', [ h'fc9f050f...221c92cb',
h'bd0136ad...6b28cf21', h'bd0136ad...6b28cf21',
h'd68af9d6...93b1632b' h'd68af9d6...93b1632b' ]
]>> ]>>
], ],
}, },
}, },
/ 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.
If this process fails, the inclusion proof may have been tampered with.
If this process succeeds, the result is a Merkle root, which in the attached as Original:
the COSE Sign1 payload. First the verifier applies the inclusion proof to a possible entry
Second the verifier checks the signature of the COSE Sign1. (set member) bytes.
If the resulting signature verifies, the Receipt has proved inclusion of the ent
ry in the verifiable data structure. -->
If the resulting signature does not verify, the signature may have been tampered
with.</t> <!--[authors] We think the current sentence with the comma parses correctly.
-->
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 succeeds, the result is a Merkle Tree root, which is then attached as t
he COSE_Sign1 payload.
Second, the verifier checks the signature of the COSE_Sign1.
If the resulting signature can be verified, the Receipt has proved inclusion of
the entry in the VDS.
If the resulting signature cannot be verified, the signature may have been tampe
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 VDP 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 Tree size
tree-size-1: uint tree-size-1: uint
; newer Merkle root tree size ; newer Merkle Tree size
tree-size-2: uint tree-size-2: uint
; path from older Merkle root to newer Merkle root. ; path from older Merkle Tree to newer Merkle Tree
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 a detached payload and corres ponds 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>. VDS algorithm
</li> 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>. VDPs. Value t
<li> ype: 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 <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> 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_SHA256
}>>, }>>,
/ unprotected / { / unprotected / {
/ proofs / 396 : { / proofs / 396 : {
/ consistency / -2 : [ / consistency / -2 : [
<<[ <<[
/ old / 20, / new / 104, / old / 20, / new / 104,
/ consistency path / / consistency path /
h'e5b3e764...c4a813bc', h'e5b3e764...c4a813bc',
h'87e8a084...4f529f69', h'87e8a084...4f529f69',
h'f712f76d...92a0ff36', h'f712f76d...92a0ff36',
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 VDS
ture is not assured. is not assured.
This approach is specific to RFC9162_SHA256, different verifiable data structure This approach is specific to RFC9162_SHA256; different VDSs
s may not support consistency proofs. 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>
<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 VDS used; for example,
Both RFC9162_SHA256 and ES256 depend on the sha-256 hash function.</t> both RFC9162_SHA256 and ES256 depend on the SHA256 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:
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.
[authors] Thank you, these changes look good to us. -->
<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>VDS Registries</name>
<t>IANA established the COSE Verifiable Data Structure Algorithms and CO <t>IANA has established the "COSE Verifiable Data Structure Algorithms"
SE Verifiable Data Structure Proofs registries under a Specification Required po and "COSE Verifiable Data Structure Proofs" subregistries under a Specification
licy as described in <xref section="4.6" sectionFormat="of" target="RFC8126"/>.< Required policy as described in <xref section="4.6" sectionFormat="of" target="R
/t> FC8126"/>.</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 VDSs.</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 the "COSE Verifiable D
</li> ata Structure Algorithms" registry for which no corresponding entry in the "COSE
<li> Verifiable Data Structure Proofs" registry 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 VDS
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 VDS.</dd>
<t>Description: <dt>Description:</dt>
This field contains a brief description of the verifiable data structure.</t> <dd>This field contains a brief description of the VDS.</dd>
</li> <dt>Reference:</dt>
<li> <dd>This contains a pointer to the public specification for the VDS.<
<t>Reference: /dd>
This contains a pointer to the public specification for the verifiable data stru <dt>Change Controller:</dt>
cture.</t> <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
<li> ss, home page URI) may also be included.</dd>
<t>Change Controller: </dl>
For Standards Track RFCs, list the "IETF". For others, give the name of the res </dd>
ponsible party. Other details (e.g., postal address, email address, home page U </dl>
RI) may also be included.</t> <table align="left" anchor="verifiable-data-structure-algorithms-reg
</li> istry-table">
</ul> <name>COSE Verifiable Data Structure Algorithms Registry Initial Con
<t>Initial contents:</t> tents</name>
<table align="left" anchor="verifiable-data-structure-proofs-registry"
>
<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 VDS.</dd>
</li> <dt>Name:</dt>
<li> <dd>This is a descriptive name for the Proof Type that enables easier
<t>Label: reference to the item.</dd>
This is the value used to identify the verifiable data structure proof type.</t> <dt>Label:</dt>
</li> <dd>This is the value used to identify the VDP Proof Type.</dd>
<li> <dt>CBOR Type:</dt>
<t>CBOR Type: <dd>This contains the CBOR type for the value portion of the label.</
This contains the CBOR type for the value portion of the label.</t> dd>
</li> <dt>Description:</dt>
<li> <dd>This field contains a brief description of the Proof Type.</dd>
<t>Description: <dt>Reference:</dt>
This field contains a brief description of the proof type.</t> <dd>This contains a pointer to the public specification for the Proof
</li> Type.</dd>
<li> <dt>Change Controller:</dt>
<t>Reference: <dd>For Standards Track RFCs, list the "IETF". For others, give the
This contains a pointer to the public specification for the proof type.</t> name of the responsible party. Other details (e.g., postal address, email addre
</li> ss, home page URI) may also be included.</dd>
<li> </dl>
<t>Change Controller: </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 <table align="left" anchor="cose-verifiable-data-structure-proofs-ta
RI) may also be included.</t> ble">
</li> <name>COSE Verifiable Data Structure Proofs Registry Initial Content
</ul> s</name>
<t>Initial contents:</t>
<table align="left" anchor="cose-verifiable-data-structure-proofs">
<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"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
<seriesInfo name="DOI" value="10.17487/RFC8610"/> 96.xml" />
</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.8
<author fullname="M. Cotton" initials="M." surname="Cotton"/> 126.xml"/>
<date month="January" year="2014"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 392.xml"/>
<t>This memo describes the process for early allocation of code po <!-- [I-D.ietf-cbor-edn-literals]
ints by IANA from registries for which "Specification Required", "RFC Required", draft-ietf-cbor-edn-literals-19
"IETF Review", or "Standards Action" policies apply. This process can be used t IESG State: I-D Exists as of 2/25/26
o alleviate the problem where code point allocation is needed to facilitate desi -->
red or required implementation and deployment experience prior to publication of <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
an RFC, which would normally trigger code point allocation. The procedures in t ietf-cbor-edn-literals.xml"/>
his document are intended to apply only to IETF Stream documents.</t>
</abstract>
</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> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+09a3PjyHHf8Ssm3KqslJCUSL1p3/l0ks6neF9ZaX3lutrS
DoEhiQgEaACkltbKvyW/Jb8s/ZgZDB58yLtxUuVcubwiMI+enu6efk2j0+l4
i4E48Lw8zCM1EBdvb67EzsWPb9+Lt8P/UH4ubsJxHMZjIeNAXMV+upzlYRLv
ivfKV+Esz7wg8WM5hb5BKkd5J1T5qOMnmepMVXofqU6eKtWZpUkyyjq9Uy/L
YaQ7GSUxdMnTufLCWUp/ZXl/f/9sv+/JVMmBuFH+PA3zpfcwZri8+4eBuI5z
lcYq71zibJ4v84HI8sDL5sNpmGUAWr6cwcjXV7c/ebNw4AmRJ/5ALFUGf2ZJ
CuCMMvt7OS1+enKeT5J04HVEGMOzt11xkysVKWjIK3ybhqp4lqRjGYd/kYiP
gbhNZaAWKg1HywBeqqkMowG0CdUPSdo76IYJPPWTeZyny4H4EIe5CmAsmcPM
esKfu+LHML2fJNFf7JQ/q/jefQqTDsRPqZzHk2SkUnFzfQtP5XCYqkXDCw3G
BEbpDvUoP+AWdX3AlPRzRALuEKDx/UQBGHkqs0yJkyMCNwAQXh4f9s+OXuJv
2I6BuJTpFHYxyN0F/V6lUxkvzVLOu+JSRUA6Mu+8kgs5D+yKzuM8CWPV8L6M
0NehnyZZMsqLZcg4D6IfpuYFrGFaQuofzPQXXfFTMkc6sdNeqCANfefxxtlG
3HTtfB6iMQ2H8xwJR4hi+RcTOZXLZA4P7cqncp4uy29WQ1Gsmrp1fd2tBk+d
rP4ADBvQOw3PTVe8ktm9Sh1ogI4Xyn2sp8vweRzR8x8mSY5P9Ux6tPddXOBr
meZh7Az4PhmqNHefVxZ3ffv+Slwk6SxJ6ZE7awqLw36wOiDHLvRsXJlmGAvK
6674JcxgDBeQ1ygESs+Rayrj3Zy7008fuPVB/wfpT/X0xXJ/CaMolNOstNpl
+fHGOdJk+QAdfphmMeHTixPgmTxcKOz3/qeL0+PePhDq5eUr/fvs8Ax+gzDm
32f7RwdaFPLv3nFfdz07OjsZCP8h70wUyKG040cyJMD45TG8RJkMwtHzwnhU
mfmk198f2EnMoKe9PvQLZSxBoMdZCOPSvmWd8Rx+QKMfL971948GNMTZYV93
OzjrA5i/oPy57lx23XNhmKQdFcSdCHYzlRFgt/bI8zwV5yhpoP/N1aufBqIF
o+aTMGt5XqfTAWmHUgpkl/f840rASQRkD/8/A2INVSaSkZCCBHcoh5ESgcwl
ysS5n89TBaeHfa3SrvfHVQ0zmhJkZ+KHEkmVjjyBp1EmVEw9Mn2kOdO3RTb3
J9BPTMM4nMpIBGHmR0kGQ7bhVJRxNoPzMPaXNH6cxB3153m4SHzaiq536zaZ
qGgGI8kQZHsY86EqYL2pyMMpjIdDTGCuoVKxkLNZFAKgsEIfgRmFPjJXG6Cl
h/iPYhRCq6nKMjlG1GZLEBHTjEfL5jDKUoBwgvnM+gAq2C2RzZTPowKkGgcZ
0GHsA7OV14bnZIzT2MGHSzGch1GAM0Jv2uOdC933xzCWIEn1nr9XM8A/9Je8
1wgXUgaCoYT6nCsg3mEYIeZxS+AhrD1NJCAewAzUNKFzD+cf0uYsQpqXJgX4
EvyVwYGQitek1IBg8KM5ahs0GXEHwI0rYU2ny5Q6DYMAdAXvBeotaRIAqaDc
Y7q1JAk4EBnQrSGaDECUOc8RKMA8HLZIa3KYzHPaK0I2icJN5Lvzx8ubXR4P
p0GFSzyAOkBYcMEQD0AXoEHNVdCtwOfL2ALjAigF6H7zKSAe0QggSZp9KGGH
dpj84X8WVbtt2820gm6wE0hoSQxUVHRyMFp0y4A9IqDlTOXYhhCAszMGSaEJ
EYkESSTTsWpoWszhMppkYgX28xEueNsIPxCAZmuEyOwEoRyWEic5KJK50NTY
iBHaMOBiZ9iudxmOQGXDLrBbhO4ZEQvspn2zeov1uLDT73aZ5OF0GQKHENvB
dGmJPwiChUzDZJ7RfEjB0JfmRTIklo1z2A+AEVRx5FUYdDhPA6AbZIJwOosI
nSplsYfNcuQKeIKSTWpuA7EAOxaPFTNPieUzlS5CX2VaWFhSClTmg0YFXSbJ
AwmnJF6opQXVEbEINQtYQPUcAVfM+cC0CxUBJMiIL14AKYPMTDUFvEkYER7h
6h6GfkjSIBOt1x9ubltt/le8eUt/v7/69w/X768u8e+bn89fvbJ/eLrFzc9v
P7y6LP4qel68ff366s0ld4anovTIa70+/1OLpWjr7bvb67dvzl+1cCV5CR+S
D6GhRi9sJS5dguGlEUUEDyfxf/1n71A8Pv4THJb9Xu/s6Un/OO2dHMIP5Hqe
jXiNf8LGLj1kQZkSuUbIALMwh3O4jYdSBnsQw7ECKpnn/cuviJmPA/HboT/r
HX6vH+CCSw8NzkoPCWf1J7XOjMSGRw3TWGyWnlcwXYb3/E+l3wbvzsPf/i5C
8wRs1d9976HofqMemKh+JtVKvJOgrCqi/ccXM/wBukuWP3k1Qh7BQCgrwb4S
sRmFFTQxs6O0YS9C1AFS2mLm/EDMZ51RmrAYIYoAgzg3J46K4DDgEwueRPBH
WqMc2LHbHy/v9sVOCuSvMiYb5HAC7+DscHfgeWCWNMNFem4gPqX6GPgkHsJ8
goeNjOAQQb6jwydNJVFTymKCf2thDLIGUAmcP03S8nGTEXWxgsAU3AR7byXs
R1vBvggA7B1HZ7tE0XljROeuQT2LmIwXEI1BG8knUwE6bpyT3kfSa80x2wVV
FQwbkLKzJEZlIVq2K2xsdxZWTsSQqjFQDWgxO4+PxcAdHLhjB+6YVk9Pu0xQ
qJcgmCgMxkiD84x1OA3tcjWUmcZqfyVWj7fE6gywCqIBrD1ETGvT2dSqIVqC
kjozVIJL2ni8aVvSqmhat/6fw7x2WX3LDXBtAjyYxK1KQe1PomS8BKUQDL8B
YN8ouUSrlzQl8f0rGY/nEpSaHWy5y6rryGg8j4/agnx6gqGvLt/QUKjAXqEC
HECry1CO4yTLQ9+egWIHWjYPBcbn01Nbc3ZIKl6qQBlJebXAvq2gGDDWA+oD
jRovwswMWLf8CMyVnMl6qybGChKZktDwAAIsS5jV470jzN8y5oUgSa2tsKWj
csjY4X+zsdaeWiMB2sQJ6rNE1QgaDtlC0eYCetiKgdcu/J2jzTWv34Cl9SLX
zhyxgrpAGi1UxyZrE32dSK5snLULdbTt6t68mSPgrgmcZIQ55/Rz7YLpPMpD
XHqh5UoxDhdoaQBopDrbNgysVbJ3VlpToM96xc5pdNhtYyUcgADdKBlq5X+o
+W9JXgANglbm0RB2yUWh705p02XlluCqfyo2F40FIE4HlQ2b3WZtmmnUwQmd
mi273pZmL4WmKAMJqx+F6dSaWLwAhHTJVhbhWxs5ekbomFtM/RGPZ0ZVbI1X
3o8CldidhAOwJv7LQoPcVrYnzbiW6InemB31EvVuwLEBYIMh6enj3j1WErLa
Sb2sCh10PqHQcQ4GFLU1lQnEuI/+CIDQNRDe8Tkdl22EGxK1K7c3K3DxIlN+
Z6xiaOp3Vp4MmdH0Mq2QFeKjydLadLCxfDSbUCI0n/wS7DTgHXTlSaTkiPhK
OtakpiLQHKdoBEMT9mA5lNIW03A8ycVELtBAXqA4dqRFZQ1tWB5a6NoPg9ux
ekkomgpz1mfcVpGCem5p/wybqBFYnmFh7BrZBJYdaCuF94yEXLiQftmRRqIK
3oH1O4Oe2gQlpdV4ogrLlWGp255aZX9IjN8IUZqEaDeSgEcn1lp9JeMZidIR
IvYmab8X2m5me7VJDPis+BA1XZR4w+j+/W6ve4CkoN2/YNdhl3KDw1IDdgkA
BKDmafdXVpqTpMoIhEbss/zMyYUAPBXzhoGiiKvOJooRTGv7A6hxbFw7nMQc
RJ7mtexzE07DCExO2PxfzWh8OH/cmeT5LBvs7T08PHTR94zO+L1CS832cHj6
v+7nST6NXoAFj35t1Oa3cJdkltyKxvZkJg25RBHF2lHQW81xLWMXw8EhAYy6
nX5PqA0UyL1II1arAtsgVWur61DrnNxfgeROIYR3SYRfXfTRhwIaS28g+rv8
d8r+FqJNPMDEVEmW5knBi64FbM7SDlh8frqAoTtgpXzGfw/EDvoAO4diJ4B/
NV3f3fx83j86FjubzEQxEL3dQlscJsCcOx14VFY6djoAe6Mf9xvSgx50M1XU
bI8KcbxzdD7yHhucAn6Be8PUPQFXm2etktbqso9zzmT6uKizTcNp16ocRC0U
1q0aXltd79r1IYItOY8CcqCqzzP06ddciRKDntmaxWQwqMkZgC2V0RLmFOSg
GpI8Q+87udjDhNgDloXxLKZKtAsdGUHhj2yufRr0shg6sMcPYHk+nRXHmvR9
NcsJOCPc4UgknzKz9IcMDbjHF9qp0sGNqzmOeNvJt1q4jarOJ9cxs7PJz7PL
CyLArAOGnYqsPBkXDGkluSJE4ULncfGbtTDaZoKIoy9Ijr+YgIIBqe46IHOL
iKXt6BDwgjZIK72s85ITpiDfNXwVr3urj9GpzEG0GE3fcc0zvMRg+MY95Iw3
qhTA0jYSKULkAoPtCbQmns2HGeLebp4OlHYLDbggxVyOx7RFhMY7jFj2uuyM
HiVRlDzgDKgSgpUPnB8UHgC2WVGdCECh/utf/yr8IIi8G8qjgDXf/QJS5s4E
dL4TL467vdOdYpZdzFcAUozkUEXwHphM7IkcNB1+rpf1ncBMDhQyvPN3mva+
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
</rfc> </rfc>
 End of changes. 139 change blocks. 
1052 lines changed or deleted 530 lines changed or added

This html diff was produced by rfcdiff 1.48.