Code change:
2.2. <del> Each leaf in a CCF Merkle Tree carries the following components: </del> <ins> Each leaf in a CCF ledger carries the following components: </ins> <del> The "internal_hash" and "internal_data" bytestrings are internal to </del> <ins> The "internal_hash" and "internal_data" byte strings are internal to </ins> the CCF implementation.  Similarly, the auxiliary tree entries are internal to CCF.  They are opaque to receipt Verifiers, but they commit the TS to the whole tree contents and may be used for additional, CCF-specific auditing. <del> 2.3. </del> <ins> 3. </ins> <del> CCF inclusion proofs are one of the tree-specific fields of a "signed-inclusion-proof".  They consist of a list of digests tagged with a single left-or-right bit. </del> <ins> CCF inclusion proofs consist of a list of digests tagged with a single left-or-right bit. </ins> Unlike some other tree algorithms, the index of the element in the tree is not explicit in the inclusion proof, but the list of left-or- right bits can be treated as the binary decomposition of the index, from the least significant (leaf) to the most significant (root). <del> 2.4. </del> <ins> 3.1. </ins> <del> When a client has received an inclusion proof and wishes to verify inclusion of a signed inclusion proof: </del> <ins> The proof signature for a CCF inclusion proof is a COSE signature (encoded with the "COSE_Sign1" CBOR type) which includes the following additional requirements for protected and unprotected headers.  Please note that there may be additional headers defined by the application. </ins> <del> 2.5. </del> <ins> The protected headers for the CCF inclusion proof signature MUST include the following: </ins> <del> TBD </del> <ins> "verifiable-data-structure: int/tstr".  This header MUST be set to the verifiable data structure algorithm identifier for "ccf- ledger" (TBD_1). </ins> <del> 3. </del> <ins> "proof-type: int".  This header MUST be set to the value of the "inclusion" proof type in the IANA registry of Verifiable Data Structure Proof Type. </ins> <del> Privacy Considerations </del> <ins> The unprotected header for a CCF inclusion proof signature MUST include the following: "inclusion-proof: bstr .cbor CCF-inclusion-proof".  This contains the serialized CCF inclusion proof, as defined above. "leaf" (label TBD_2): "bstr .cbor CCF-leaf".  This contains the CCF-specific serialization of the leaf element The payload of the signature is the CCF ledger Markle root digest, and MUST be detached in order to force verifiers to recompute the root from the inclusion proof in the unprotected header.  This provides a safeguard against implementation errors that use the payload of the signature but do not recompute the root from the inclusion proof. 3.2. CCF uses the following algorithm to recompute the payload of the signature based on the "inclusion-proof" header: </ins> 4. <del> Security Considerations </del> <ins> Privacy Considerations </ins> 5. <del> 5.1. </del> <ins> Security Considerations 6. 6.1. 6.1.1. This document requests IANA to add the following new value to the 'COSE Header Parameters' registry: Label: TBD_2 Value type: "bstr" Reference: This document </ins> <del> 5.1.1. </del> <ins> 6.1.2. </ins> This document requests IANA to add the following new value to the 'Tree Algorithms' registry: <del> Identifier: TBD_1 </del> <ins> Identifier: TBD_1 (requested assignment 2) </ins> <del> Tree Algorithm: ccf_ledger </del> <ins> Tree Algorithm: ccf-ledger </ins> Reference: This document

Related discussion:
text: This uses the new proof type registry and redefines the signature type. Unlike the CT-style log algorithm the proof type is part of the trusted headers