]> VeritasChain Co., Ltd.

kamimura@veritaschain.org

Security Independent Submission provenance timestamp merkle tree RFC 3161 media authenticity content provenance depth analysis screen detection The Content Provenance Profile (CPP) is an open specification for cryptographically verifiable media capture provenance. This document defines the core data model, hashing conventions, Merkle tree construction rules, RFC 3161 Time-Stamp Authority (TSA) anchoring protocol, and offline verification procedures for CPP. CPP enables capture devices to produce tamper-evident provenance records that bind media content to external timestamps via trusted third parties. Unlike self-attestation models, CPP requires independent timestamp verification through RFC 3161 TSA services, providing externally verifiable proof of when media was captured. This revision (-01) incorporates implementation experience from multi-platform deployments, adding self-attested signer identity, hardware-backed key requirements, chain context for partial submission detection, depth analysis extensions for screen detection, and a Pre-Publish Verification Extension for social media sharing workflows. It also defines interoperability mappings with the C2PA specification.

Introduction

Problem Statement Digital media authenticity faces several fundamental challenges:

• Self-Attestation Weakness: Systems where creators sign their own claims provide no independent verification. A verifier must trust that the creator's claimed timestamp is accurate.
• Metadata Stripping: Social media platforms and messaging applications routinely strip embedded metadata, breaking provenance chains that depend on file-level embedding.
• Omission Attacks: Systems that prove individual media authenticity cannot detect when unfavorable evidence has been selectively deleted from a collection.
• Terminology Confusion: Terms like "verified" mislead users into believing content truthfulness has been established, when only provenance has been recorded.
• Analog Hole Attacks: Photographing screens displaying manipulated content can bypass digital provenance systems that only track file-level operations.

Design Goals CPP addresses these challenges through the following design principles:

1. External Timestamp Verification: Timestamps MUST be anchored to independent RFC 3161 Time-Stamp Authorities, enabling third-party verification without trusting the capture device.
2. Omission Detection: The Completeness Invariant mechanism enables detection of deleted events within a collection.
3. Offline Verification: All data necessary for verification is included in the Evidence Pack, enabling verification without network access.
4. Provenance != Truth: CPP proves when and by what device media was captured. It does NOT prove content truthfulness or scene authenticity.
5. Hardware-Backed Security: Private keys SHOULD be stored in hardware security modules where available (Secure Enclave, StrongBox, TPM).

Scope This document specifies:

• The CPP event data model
• Hash computation and canonicalization rules
• Merkle tree construction and proof verification
• RFC 3161 TSA anchoring requirements
• Verification procedures for implementers
• Self-attested signer identity (SignerInfo)
• Chain context for partial submission detection
• Depth analysis extension for screen detection (OPTIONAL)
• Pre-Publish Verification extension (OPTIONAL)

This document does NOT specify:

• Application user interface requirements
• Network protocols for proof distribution
• Key management or certificate policies
• Content authenticity claims

Changes from draft-vso-cpp-core-01 This revision incorporates the following changes: BREAKING CHANGE — Merkle Tree Domain Separation: This document mandates domain-separated Merkle hashing (). LeafHash MUST be computed as SHA256(0x00 || EventHash_bytes) and internal nodes as SHA256(0x01 || Left || Right). Earlier CPP specification documents (v1.0 through v1.4) used non-domain-separated hashing (LeafHash = SHA256(EventHash_bytes), Node = SHA256(Left || Right)). Those constructions are now deprecated. Implementations using the legacy (non-prefixed) construction MUST migrate to the domain-separated construction defined in this document. Test vectors in reflect the domain-separated construction and differ from pre-domain-separation outputs. BREAKING CHANGE — AnchorDigest Verification: Verifiers MUST now perform explicit format and digest matching checks on AnchorDigest, MerkleRoot, and TSA messageImprint fields as specified in . These checks were RECOMMENDED in -01 but are now REQUIRED.

• Added with mandatory format checks, TSA binding verification, and PROHIBITED implementation patterns
• Added Normative Authority and Legacy Migration guidance to
• Strengthened Domain Separation () with MUST/MUST NOT/DEPRECATED language
• Added cross-reference from TSA Verification () to AnchorDigest verification requirements
• Clarified test vector applicability for legacy migration ()
• Corrected author contact email address

Changes from draft-vso-cpp-core-00 The -01 revision incorporated the following changes:

• Added SignerInfo for self-attested identity ()
• Added DeviceInfo structure for cross-platform support ()
• Added CaptureContext for environmental metadata ()
• Added Chain Context for partial submission detection ()
• Added Depth Analysis Extension for screen detection ()
• Added Pre-Publish Verification Extension ()
• Added C2PA interoperability mappings ()
• Clarified hardware-backed key storage requirements
• Added EXPORT and additional event types
• Expanded implementation experience with Android and cross-platform validation

Relationship to Other Specifications CPP defines its own Merkle tree construction that is NOT compatible with Certificate Transparency . While inspired by similar principles, CPP uses different domain separation prefixes and padding rules optimized for media provenance use cases. Implementations MUST NOT assume RFC 6962 compatibility. CPP is complementary to the C2PA specification . C2PA tracks edit history of content; CPP proves capture provenance with deletion detection. See for interoperability mappings. Normative Authority: Where the cryptographic algorithms defined in this document (domain-separated Merkle hashing, AnchorDigest computation, verification procedures) conflict with earlier CPP specification documents (v1.0 through v1.5), this document takes precedence. The CPP specification series published by VSO serves as the design-level reference; this Internet-Draft is the normative interoperability specification for implementations seeking cross-platform compatibility. Legacy Migration: Implementations using non-domain-separated Merkle hashing (LeafHash = SHA256(EventHash_bytes) without the 0x00 prefix) MUST migrate to the domain-separated construction defined in . During a transition period, implementations MAY accept both legacy and domain-separated proofs for verification but MUST generate only domain-separated proofs. Implementations SHOULD log a deprecation warning when encountering legacy proofs.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Additionally, this document uses the following terms:

Event

A discrete, signed record representing a provenance action (capture, export, deletion).

EventHash

A SHA-256 hash of the canonicalized event data, formatted as sha256:<64_hex_chars>.

LeafHash

SHA-256(0x00 || EventHash_bytes), used as input to the Merkle tree. The 0x00 prefix provides domain separation from internal nodes.

MerkleRoot

The root hash of a binary Merkle tree containing one or more LeafHashes.

AnchorDigest

The 32-byte value submitted to the TSA. Represented as a 64-character lowercase hexadecimal string without prefix. MUST equal the MerkleRoot value (after stripping the sha256: prefix).

TreeSize

The count of original leaves in the Merkle tree before any padding. An unsigned integer. MUST be >= 1.

PaddedSize

The count of leaves after padding to a power of 2. Computed as the smallest power of 2 greater than or equal to TreeSize.

Evidence Pack

A self-contained data structure containing all information necessary for offline verification.

Tombstone

An event that records the legitimate deletion of a previous event.

Provenance Available

The recommended terminology for UI display, indicating capture provenance is recorded without implying content truth verification.

Genesis PrevHash

The constant value used as PrevHash for the first event in a chain: sha256:0000000000000000000000000000000000000000000000000000000000000000 (64 zeros).

SignerInfo

An OPTIONAL self-attested identity claim included in events. Not independently verified; provides tamper-evident name association.

Chain Context

Metadata embedded in proofs describing the event's position within its chain, enabling detection of partial evidence submission.

DeviceClass

A classification of the capture device: SMARTPHONE, TABLET, EMBEDDED, PHYSICAL_CAMERA, DRONE, or INDUSTRIAL.

Threat Model

Addressed Threats

Threat	Mitigation
Timestamp forgery	RFC 3161 TSA provides independent timestamp
Evidence tampering	EventHash binds content; Merkle proof binds to anchor
Selective deletion	Completeness Invariant detects missing events
TSA token swapping	messageImprint must match AnchorDigest
Partial evidence submission	Chain Context reveals event position and deletion counts
Screen photography (analog hole)	Depth Analysis Extension detects flat surfaces (OPTIONAL)

Explicitly Not Addressed

• Content truthfulness (scene staging, deepfakes)
• Device compromise before capture
• Key extraction from secure hardware
• TSA collusion with adversary
• Identity verification (SignerInfo is self-attested only)

Data Model

Events An Event is the fundamental unit of provenance in CPP. Events are signed records that capture discrete provenance actions.

Event Types

Type	Description
INGEST	Media captured from device sensor
SEAL	Collection sealed with Completeness Invariant
EXPORT	Proof shared externally
TOMBSTONE	Legitimate deletion record

Event Structure The following fields are REQUIRED for all events:

Field	Type	Required	Description
EventID	string	REQUIRED	Unique identifier (UUID per )
ChainID	string	REQUIRED	Identifier linking events in a sequence
PrevHash	string	REQUIRED	Hash of previous event in chain
Timestamp	string	REQUIRED	ISO 8601 timestamp with millisecond precision
EventType	string	REQUIRED	One of: INGEST, SEAL, EXPORT, TOMBSTONE
HashAlgo	string	REQUIRED	Always "SHA256"
SignAlgo	string	REQUIRED	"ES256" or "Ed25519"
EventHash	string	REQUIRED	SHA-256 hash of canonicalized event
Signature	string	REQUIRED	Raw Base64-encoded signature (no prefix)
SignerInfo	object	OPTIONAL	Self-attested identity claim
DeviceInfo	object	OPTIONAL	Device metadata
CaptureContext	object	OPTIONAL	Environmental capture metadata

Encoding Requirements All Base64-encoded fields (Signature, TSA.Token, public_key) MUST conform to:

• Section 4 (standard base64 alphabet, NOT base64url)
• No whitespace characters (no line breaks, spaces, or tabs)
• Padding characters (=) MUST be included when required

PROHIBITED:

• base64:MEUCIQDx... - Prefixes not allowed
• data:application/octet-stream;base64,... - Data URIs not allowed
• Base64url alphabet (- and _ instead of + and /)
• Line wrapping or embedded whitespace

INGEST Event INGEST events MUST include:

Field	Type	Required	Description
Asset.AssetHash	string	REQUIRED	SHA-256 hash of media bytes
Asset.AssetType	string	REQUIRED	IMAGE or VIDEO
Asset.MimeType	string	REQUIRED	MIME type of asset
Asset.AssetID	string	OPTIONAL	Unique asset identifier
Asset.AssetName	string	OPTIONAL	Original filename
Asset.AssetSize	integer	OPTIONAL	File size in bytes

SEAL Event SEAL events finalize a collection and commit the Completeness Invariant. A SEAL event MUST include:

Field	Type	Required	Description
CollectionID	string	REQUIRED	Identifier for the sealed collection
EventCount	integer	REQUIRED	Number of events in collection (excluding SEAL)
CompletenessInvariant	object	REQUIRED	Completeness verification data
MerkleRoot	string	REQUIRED	Root hash of events in collection

CompletenessInvariant Object

Field	Type	Required	Description
ExpectedCount	integer	REQUIRED	Number of events that MUST be present
HashSum	string	REQUIRED	XOR of all EventHash values (sha256: format)
FirstTimestamp	string	REQUIRED	ISO 8601 timestamp of first event
LastTimestamp	string	REQUIRED	ISO 8601 timestamp of last event

The HashSum is computed as: Where XOR operates on the 32-byte binary values of each EventHash.

SEAL Anchoring Pattern The recommended anchoring pattern for SEAL events:

1. Compute the Merkle tree over all INGEST events in the collection
2. Create the SEAL event with MerkleRoot referencing this tree
3. Include the SEAL event's EventHash as an additional leaf in a NEW Merkle tree
4. Anchor this new tree (containing the SEAL event) to a TSA

This pattern ensures the Completeness Invariant itself is bound to an external timestamp. The SEAL event's EventHash covers all CI fields, so the TSA anchor proves the CI existed at GenTime. Alternative Pattern (NOT RECOMMENDED): Including the SEAL event in the same Merkle tree it references creates a circular dependency and is prohibited.

TOMBSTONE Event TOMBSTONE events MUST additionally include:

Field	Type	Required	Description
DeletedEventId	string	REQUIRED	EventID being invalidated
Reason	string	REQUIRED	Deletion reason code
DeletedAt	string	REQUIRED	ISO 8601 deletion timestamp

SignerInfo SignerInfo provides self-attested identity claims. It is OPTIONAL and MUST NOT be interpreted as verified identity.

Field	Type	Required	Description
Name	string	REQUIRED	Self-attested display name
Identifier	string	OPTIONAL	Self-attested identifier (email, URL)
AttestedAt	string	REQUIRED	ISO 8601 timestamp of attestation

Verification Semantics When a third party verifies a CPP proof with SignerInfo:

What CPP Proves	What CPP Does NOT Prove
Someone claimed this name at capture time	The name is real or legal
The claim is tamper-evident (signed)	Identity verification occurred
The claim existed before TSA timestamp	The person is who they claim

Implementations displaying SignerInfo MUST use terminology such as "Self-Attested Name" and MUST NOT use "Verified Identity" or similar phrases that imply independent verification.

DeviceInfo DeviceInfo provides metadata about the capture device. It is OPTIONAL but RECOMMENDED for INGEST events.

Field	Type	Required	Description
Manufacturer	string	OPTIONAL	Device manufacturer
Model	string	OPTIONAL	Device model identifier
DeviceClass	string	OPTIONAL	One of: SMARTPHONE, TABLET, EMBEDDED, PHYSICAL_CAMERA, DRONE, INDUSTRIAL
OSName	string	OPTIONAL	Operating system name
OSVersion	string	OPTIONAL	Operating system version
AppVersion	string	OPTIONAL	Capture application version

CaptureContext CaptureContext provides environmental metadata at capture time. It is OPTIONAL for INGEST events.

Field	Type	Required	Description
SensorData	object	OPTIONAL	Sensor readings (GPS, accelerometer)
HumanAttestation	object	OPTIONAL	Biometric verification record (boolean result only)
DepthAnalysis	object	OPTIONAL	Screen detection results (see )

Hash Chain Events form a hash chain through the PrevHash field: Verification of chain integrity:

1. For each event after the first, the verifier MUST compute EventHash of the previous event.
2. The computed hash MUST match the current event's PrevHash field.
3. If any mismatch is detected, verification MUST fail with status CHAIN_INTEGRITY_VIOLATION.

Merkle Tree Structure CPP defines its own binary Merkle tree construction optimized for media provenance. This construction uses domain separation prefixes to prevent attacks where leaf values could be confused with internal node values. Important: CPP Merkle trees are NOT compatible with RFC 6962 (Certificate Transparency). Implementations MUST use the exact algorithms specified in this section.

Domain Separation CPP MUST use single-byte prefixes to separate leaf and internal node domains. This construction prevents second preimage attacks where an attacker substitutes a leaf value for an internal node or vice versa. Implementations MUST apply these prefixes. The legacy (non-prefixed) construction where LeafHash = SHA256(EventHash_bytes) and Node = SHA256(Left || Right) is DEPRECATED and MUST NOT be used for generating new proofs.

Domain	Prefix Byte	Description
Leaf	0x00	Applied to EventHash bytes
Internal	0x01	Applied to concatenated child hashes

Leaf Nodes Where:

• 0x00 is a single byte with value zero
• EventHash_bytes is the 32-byte binary representation of EventHash (after stripping the sha256: prefix)
• || denotes byte concatenation

Internal Nodes Where:

• 0x01 is a single byte with value one
• Left_bytes is the 32-byte hash of the left child
• Right_bytes is the 32-byte hash of the right child
• || denotes byte concatenation

Tree Construction Step 1: Compute Leaf Hashes For each event, compute LeafHash = SHA256(0x00 || EventHash_bytes). Step 2: Determine Padding PaddedSize is the smallest power of 2 >= TreeSize: = 1 paddedSize = 1 while paddedSize < treeSize: paddedSize = paddedSize * 2 return paddedSize ]]> Step 3: Pad Leaf Array If TreeSize < PaddedSize, duplicate the last leaf hash until the array length equals PaddedSize. Step 4: Build Tree 1: nextLevel = [] for i in range(0, current.length, 2): left = current[i] right = current[i + 1] parent = SHA256(0x01 || left || right) nextLevel.append(parent) levels.append(nextLevel) current = nextLevel return levels // levels[0] = leaves, levels[-1] = [root] ]]>

Merkle Proof Structure

Field	Type	Description
TreeSize	integer	Original leaf count (before padding), unsigned, MUST be >= 1
LeafHashMethod	string	MUST be exactly SHA256(0x00||EventHash) (18 ASCII characters)
LeafHash	string	Computed LeafHash for this event with sha256: prefix
LeafIndex	integer	0-based position in tree, range [0, TreeSize-1]
Proof	array	Sibling hashes from bottom to top, each with sha256: prefix
Root	string	MerkleRoot with sha256: prefix

Anchor Structure

Field	Type	Description
AnchorID	string	Unique anchor identifier
AnchorType	string	MUST be "RFC3161"
AnchorDigest	string	MerkleRoot without prefix, 64 lowercase hex chars
AnchorDigestAlgorithm	string	MUST be "sha-256"
Merkle	object	Merkle proof structure
TSA	object	TSA response data

The TSA object MUST include:

Field	Type	Description
Token	string	Complete DER-encoded TimeStampToken, Base64
MessageImprint	object	Extracted messageImprint from TSTInfo
GenTime	string	Extracted GenTime from TSTInfo, ISO 8601
Service	string	TSA service URL (informational)

The MessageImprint object MUST include:

Field	Type	Description
HashAlgorithm	string	MUST be "sha-256"
HashedMessage	string	64 lowercase hex chars, MUST equal AnchorDigest

Chain Context Chain Context is OPTIONAL metadata embedded in Evidence Packs to enable partial submission detection. It describes the event's position within its chain without requiring the full chain for initial assessment.

Field	Type	Description
ChainID	string	Unique chain identifier
TotalEvents	integer	Total events in chain (including Tombstones)
ActiveEvents	integer	Non-invalidated events
TombstoneCount	integer	Number of deleted events
EventPosition	integer	Position of this event (1-indexed)
CompletenessInvariant	object	XOR-based completeness data for the chain
GeneratedAt	string	ISO 8601 timestamp of context generation

Chain Context is informational when embedded in a single proof. Full completeness verification requires the complete chain (Forensic Export). Verifiers SHOULD use Chain Context to alert users when:

• TombstoneCount > 0 (events have been deleted)
• ActiveEvents < TotalEvents (some events invalidated)
• Only a subset of the chain is presented

Canonicalization and Hashing

JSON Canonicalization Events MUST be canonicalized using (JSON Canonicalization Scheme) before hashing. The following fields MUST be excluded from canonicalization:

• EventHash
• Signature

All other fields, including SignerInfo if present, MUST be included. Field names in the canonical event object use PascalCase (e.g., EventID, ChainID, PrevHash).

EventHash Computation The resulting EventHash is a 71-character string: the prefix "sha256:" followed by 64 lowercase hexadecimal characters. Note: SignerInfo, DeviceInfo, and CaptureContext are included in the EventHash computation when present. This ensures these fields are tamper-evident and bound to the TSA timestamp.

LeafHash Computation

Internal Node Hash Computation

AnchorDigest Computation AnchorDigest is the MerkleRoot value WITHOUT the sha256: prefix, represented as 64 lowercase hexadecimal characters. PROHIBITED:

• SHA256(merkleRoot) - This would create double hashing
• SHA256(stringEncode(merkleRoot)) - This would hash the string representation
• Any transformation other than prefix removal
• Mixed case output - MUST be lowercase

Anchoring Protocol

TSA Request Construction The messageImprint in TimeStampReq MUST contain:

• hashAlgorithm: SHA-256 (OID 2.16.840.1.101.3.4.2.1)
• hashedMessage: AnchorDigest as 32-byte OCTET STRING

certReq Recommendation Producers SHOULD set certReq to TRUE to request the TSA's signing certificate be included in the response. This enables:

• Offline verification without fetching certificates separately
• Long-term verification even if TSA infrastructure changes
• Self-contained Evidence Packs

If certReq is FALSE and the TSA certificate is not included in the response, verifiers MUST attempt to obtain the certificate through other means (e.g., AIA extension, local cache) or return VALID_WARNING.

TSA Response Processing Upon receiving TimeStampResp, the producer:

1. MUST verify the response status is granted (0) or grantedWithMods (1)
2. MUST extract the TimeStampToken from the response
3. MUST store the complete DER-encoded TimeStampToken
4. MUST extract and store the messageImprint from TSTInfo
5. MUST extract and store GenTime from TSTInfo

Single-Leaf Tree Rules When TreeSize equals 1, the following invariants MUST hold:

• LeafIndex MUST equal 0
• Proof MUST be an empty array
• Root MUST equal LeafHash
• LeafHash MUST equal SHA256(0x00 || EventHash_bytes)

If any of these conditions fail, verification MUST return INVALID.

Multi-Leaf Tree Rules For TreeSize greater than 1:

• LeafIndex MUST be in range [0, TreeSize-1]
• PaddedSize = smallest power of 2 >= TreeSize
• Proof length MUST NOT exceed log2(PaddedSize)
• Sibling hashes are ordered from bottom (leaf level) to top (root level)
• Index parity determines pairing order: even=left, odd=right
• All internal nodes use SHA256(0x01 || left || right)

Verification Procedures

Verification Result Codes

Code	Meaning
VALID	All checks passed, including TSA signature verification
VALID_WARNING	Cryptographic checks passed, but TSA certificate chain could not be fully validated
INVALID	Cryptographic verification failed
CHAIN_INTEGRITY_VIOLATION	Hash chain is broken
COMPLETENESS_VIOLATION	Completeness Invariant mismatch

Event Verification

Merkle Proof Verification = 1") if leafIndex < 0 or leafIndex >= treeSize: return INVALID("LeafIndex out of range") paddedSize = computePaddedSize(treeSize) maxProofLength = log2(paddedSize) if proof.length > maxProofLength: return INVALID("Proof too long") // Step 2: Compute leaf hash with domain separation currentHash = computeLeafHash(eventHash) // Step 3: Handle single-leaf case if treeSize == 1: if leafIndex != 0: return INVALID("LeafIndex must be 0 for single-leaf") if proof.length != 0: return INVALID("Proof must be empty for single-leaf") if lowercase(currentHash) != lowercase(expectedRoot): return INVALID("Root != LeafHash for single-leaf") return VALID // Step 4: Traverse proof from bottom to top index = leafIndex for siblingHash in proof: if index % 2 == 0: currentHash = computeInternalHash(currentHash, siblingHash) else: currentHash = computeInternalHash(siblingHash, currentHash) index = floor(index / 2) // Step 5: Compare with expected root if lowercase(currentHash) != lowercase(expectedRoot): return INVALID("Computed root != expected root") return VALID ]]>

TSA Verification TSA verification ensures the timestamp token was legitimately issued by a Time-Stamp Authority and binds the correct digest. Implementations MUST also perform the format and binding checks specified in prior to or as part of this procedure.

CMS Signature Verification Requirements Per , verifiers MUST:

1. Parse the TimeStampToken as a ContentInfo structure
2. Extract the SignedData from the content field
3. Locate the SignerInfo corresponding to the TSA
4. Verify the signature over the encapsulated TSTInfo
5. Verify the signer's certificate was valid at signing time

Verifiers SHOULD:

1. Build and validate the certificate chain to a trust anchor
2. Verify the TSA certificate contains the id-kp-timeStamping extended key usage
3. Check for certificate revocation

AnchorDigest Verification Requirements This section consolidates the mandatory checks for AnchorDigest, MerkleRoot, and TSA messageImprint consistency. These checks are REQUIRED and failure of any single check MUST result in INVALID. Format Requirements:

1. MerkleRoot MUST be a 71-character string consisting of the prefix sha256: followed by exactly 64 lowercase hexadecimal characters (regex: ^sha256:[0-9a-f]{64}$). Verifiers MUST reject MerkleRoot values containing uppercase characters, missing prefix, or incorrect length.
2. AnchorDigest MUST be exactly 64 lowercase hexadecimal characters (regex: ^[0-9a-f]{64}$) representing the 32-byte binary digest. No prefix, no whitespace, no uppercase.
3. AnchorDigest MUST exactly equal MerkleRoot with the sha256: prefix stripped. No rehashing, no encoding transformation — purely prefix removal.

TSA Binding Requirements:

1. Verifiers MUST extract messageImprint from TSTInfo within the TimeStampToken.
2. Verifiers MUST confirm that messageImprint.hashAlgorithm equals the SHA-256 OID (2.16.840.1.101.3.4.2.1). If the OID differs, verification MUST return INVALID.
3. Verifiers MUST confirm that the lowercase hexadecimal encoding of messageImprint.hashedMessage (32 bytes) is identical to AnchorDigest. This is a byte-for-byte comparison after hex encoding; case-insensitive comparison is NOT sufficient because AnchorDigest is already required to be lowercase.
4. If an implementation transmits AnchorDigest to the TSA as a UTF-8 string rather than a 32-byte binary OCTET STRING, the TSA will timestamp a 64-byte value (the hex encoding) rather than the correct 32-byte digest. This is a known implementation error. Verifiers MUST detect this by comparing the messageImprint length: if hashedMessage is not exactly 32 bytes, verification MUST return INVALID.

PROHIBITED Patterns (known implementation errors):

• Submitting the hex string of AnchorDigest (64 ASCII bytes) instead of the decoded binary (32 bytes) to the TSA — results in messageImprint mismatch
• Computing SHA256(MerkleRoot) as the TSA input — results in double-hashing
• Computing SHA256(AnchorDigest_as_string) — results in hashing the hex encoding rather than the binary value
• Using the MerkleRoot string (with sha256: prefix) directly as the TSA hashedMessage — results in a 71-byte input instead of 32 bytes

Chain Integrity Verification

Completeness Invariant Verification ci.LastTimestamp: return COMPLETENESS_VIOLATION("After collection end") return VALID ]]>

Attack Detection

Attack	Detection
Delete event	Hash sum mismatch and/or count mismatch
Add fake event	Count mismatch and/or hash sum mismatch
Reorder events	Chain integrity violation (PrevHash mismatch)
Modify event	EventHash mismatch in chain

Depth Analysis Extension The Depth Analysis Extension is OPTIONAL and provides screen detection capabilities to mitigate analog hole attacks (photographing screens displaying manipulated content).

DepthAnalysis Structure When present in CaptureContext, DepthAnalysis MUST include:

Field	Type	Required	Description
SensorType	string	REQUIRED	Type of depth sensor used
FlatnessScore	number	REQUIRED	0.0 (natural scene) to 1.0 (flat screen)
DepthVariance	number	REQUIRED	Statistical variance of depth values
ScreenDetected	boolean	REQUIRED	Whether a screen was detected
Confidence	number	REQUIRED	Detection confidence 0.0 to 1.0
AnalysisVersion	string	REQUIRED	Version of analysis algorithm

Sensor Types

Value	Description
LIDAR	LiDAR time-of-flight sensor
STRUCTURED_LIGHT	Structured light projection
STEREO	Stereo camera pair
TOF	Non-LiDAR time-of-flight
RADAR	Millimeter-wave radar
ULTRASONIC	Ultrasonic depth sensing
MONOCULAR_ESTIMATED	AI-estimated depth from single camera
MULTI_CAMERA	Multi-camera triangulation
ACTIVE_IR	Active infrared projection
HYBRID	Multiple sensor fusion
UNKNOWN	Sensor type not determined
NONE	No depth sensor available

Depth Analysis Verification Depth analysis data is included in the EventHash computation, making it tamper-evident. Verifiers MAY use DepthAnalysis to assess capture environment but MUST NOT treat it as definitive proof of scene authenticity. Depth sensors can be spoofed by sophisticated adversaries. When ScreenDetected is true, implementations SHOULD display a warning to users but MUST NOT automatically reject the proof.

Pre-Publish Verification Extension The Pre-Publish Verification Extension is OPTIONAL and enables verification of CPP provenance at the moment of social media sharing. It allows users to indicate their content has traceable origin without blocking the sharing flow or making truth claims.

Design Principles

• Silent Failure: If verification fails or times out, sharing MUST proceed without any user-visible error or delay.
• No Truth Claims: The indicator communicates provenance availability, not content truthfulness.
• Performance Budget: Verification MUST complete within 200ms or short-circuit to silent passthrough.

VerificationResult

Status	Behavior
PROVENANCE_AVAILABLE	Show indicator, attach metadata
PROVENANCE_PARTIAL	Silent passthrough (no indicator)
PROVENANCE_UNAVAILABLE	Silent passthrough
VERIFICATION_TIMEOUT	Silent passthrough
VERIFICATION_ERROR	Silent passthrough

Only PROVENANCE_AVAILABLE results in visible indication. All other statuses MUST result in silent passthrough where the original content is shared without modification or delay.

Prohibited Terminology Implementations MUST NOT use the following terms in user-facing displays related to CPP provenance:

• "Verified" or "Verified Content"
• "Authentic" or "Authenticated"
• "True" or "Truthful"
• "Certified"
• "Guaranteed"
• "Real"
• "Trustworthy"

Recommended terminology: "Provenance Available", "Capture Provenance Recorded", "Origin Traceable".

C2PA Interoperability Implementations MAY support both CPP and C2PA manifests. This section defines field mappings for dual-standard implementations.

Field Mapping

CPP Field	C2PA Equivalent	Notes
DeviceInfo.Manufacturer	claim_generator	Partial mapping
DeviceInfo.Model	claim_generator	Partial mapping
Timestamp	dc:created	ISO 8601 format
SensorData.GPS	Exif:GPS*	Standard EXIF mapping
Anchor.TSA	c2pa.time_stamp	RFC 3161 compatible
DepthAnalysis	No equivalent	CPP-specific extension
HumanAttestation	No equivalent	CPP-specific extension
CompletenessInvariant	No equivalent	CPP-specific extension

Dual-Standard Output Implementations generating both CPP and C2PA manifests MUST ensure shared fields (Timestamp, GPS, DeviceInfo) are consistent across both manifests. CPP-specific fields (DepthAnalysis, HumanAttestation, CompletenessInvariant) have no C2PA equivalent and are carried only in the CPP manifest.

Privacy Considerations

Location Data Location collection SHOULD be disabled by default. When enabled, implementations SHOULD:

• Clearly indicate when location is being recorded
• Allow users to delete location from individual events
• Consider privacy implications of location precision
• Support approximate location modes that reduce GPS precision

Biometric Data Implementations MUST NOT store raw biometric data (fingerprints, face images). Human presence verification, if implemented, SHOULD:

• Process biometrics locally on-device
• Store only verification results (boolean flags)
• Never transmit biometric data to external services

Tombstone Privacy When events are deleted via TOMBSTONE:

• Original event content is removed
• TOMBSTONE preserves chain integrity
• Reason codes allow selective disclosure

Shareable vs Forensic Proofs

Level	Includes	Use Case
Shareable	Timestamp, device info, asset hash	Social sharing
Forensic	All metadata including location, chain context	Legal proceedings

Security Considerations

Hash Algorithm Agility This specification mandates SHA-256 for all hash computations. Future versions MAY define additional algorithms via the HashAlgo field. Verifiers MUST reject unknown hash algorithms. Post-quantum consideration: ML-DSA-65 (NIST Module-Lattice Digital Signature Algorithm) is RESERVED for future adoption. XOR-based accumulators used in the Completeness Invariant, being purely symmetric operations, face fewer quantum vulnerabilities than public-key constructions.

Signature Algorithm Requirements Implementations MUST support ES256 (ECDSA with P-256 and SHA-256, per ) for mobile device compatibility. Ed25519 MAY be supported for non-mobile implementations. Private keys SHOULD be stored in hardware security modules where available:

• iOS: Secure Enclave (kSecAttrTokenIDSecureEnclave)
• Android: StrongBox or TEE via Android Keystore
• Desktop/Server: TPM 2.0 or HSM

Hardware-backed keys provide non-exportability guarantees that strengthen the binding between device and signature.

TSA Trust Security of timestamp proofs depends on TSA trustworthiness. Implementations:

• MUST verify the CMS signature in the TimeStampToken per
• SHOULD validate the certificate chain to a configured trust anchor
• SHOULD use TSAs with published certificate policies
• MAY support multiple TSA services for redundancy

Merkle Tree Security The 0x00/0x01 prefix bytes ensure leaf hashes cannot equal internal node hashes for any input. This prevents second preimage attacks on the tree structure. This construction differs from Certificate Transparency which uses a similar but incompatible scheme.

Clock Accuracy Device timestamps (Timestamp field) are self-attested and may be inaccurate. The authoritative timestamp is GenTime from the TSA response. Implementations SHOULD warn users when device time differs significantly from TSA GenTime (e.g., more than 5 minutes).

Deletion Detection Limitations The Completeness Invariant detects deletions within a sealed collection. It does NOT detect:

• Events never created (adversary captured but never recorded)
• Events in other collections
• Deletions before sealing

XOR is commutative and self-inverse. An attacker who can forge TWO events with EventHashes that XOR to zero can delete both without detection. The CI is designed to work WITH the Merkle tree anchor, not replace it.

Depth Analysis Security Depth sensors can be spoofed by sophisticated adversaries using 3D displays or structured light interference. Depth analysis provides an additional signal but is not a definitive screen detection mechanism. Implementations MUST NOT represent depth analysis as conclusive proof of scene authenticity.

Canonicalization Attacks JSON canonicalization per prevents ordering and whitespace attacks. Implementations MUST ensure field names exactly match the specification (PascalCase for events) and Unicode normalization is handled consistently.

IANA Considerations This document has no IANA actions.

Implementation Experience

VeraSnap iOS (Non-Normative) VeraSnap is a consumer iOS application implementing CPP, available in 175 countries with 10-language localization. It demonstrates:

• Secure Enclave key storage with ES256 signatures
• RFC 3161 TSA integration with multiple providers (failover)
• Merkle tree construction per this specification
• Offline proof verification
• LiDAR-based depth analysis for screen detection
• Cross-platform proof export and QR code sharing

VeraSnap Android (Non-Normative) A Kotlin-based Android implementation validates cross-platform interoperability:

• Android Keystore (StrongBox/TEE) key storage with ES256
• RFC 8785 JSON canonicalization producing identical hashes to iOS
• Proof JSON verification across platforms
• QR code generation and scanning interoperability

Cross-platform testing confirmed that proofs generated on iOS verify correctly on Android and vice versa, validating the canonicalization and hashing specifications.

References Normative References Informative References Coalition for Content Provenance and Authenticity National Institute of Standards and Technology

JSON Examples

Canonical Event with SignerInfo (Normative) The canonical event structure uses PascalCase field names. This is the structure that MUST be used for EventHash computation.

Anchor Structure with MessageImprint (Normative)

Chain Context Example (Non-Normative)

Depth Analysis Example (Non-Normative)

Test Vectors All test vectors in this section use the domain-separated hash construction defined in this specification. These vectors are identical to those in draft-vso-cpp-core-00 and -01, which also used domain separation. Note: implementations migrating from legacy (non-domain-separated) CPP hashing will produce different LeafHash and MerkleRoot values for the same EventHash inputs. The domain-separated outputs below are the only correct values for compliant implementations.

Test Vector 1: Single-Leaf Tree Input: Computation:

Test Vector 2: Two-Leaf Tree

Test Vector 3: TSA messageImprint Verification

Acknowledgements The authors thank:

• The VeritasChain Standards Organization (VSO) for developing the CPP specification series (v1.0 through v1.5)
• The implementers of VeraSnap (iOS and Android) for cross-platform validation feedback that improved this specification
• Early reviewers who identified the domain separation and Completeness Invariant modeling issues
• Contributors to the depth analysis and pre-publish verification extensions