How C2PA Signing Works

C2PA signing is the operation that turns provenance information into a tamper-evident Content Credential. It is often described as signing an image, video, document, or other asset, but the cryptographic operation is more precise: a claim generator assembles assertions about an asset, connects them to the asset through a content binding, and digitally signs the resulting claim on behalf of a signer.

The finished C2PA manifest contains the assertions, the claim that references them, and the claim signature. A verifier can later check that the claim has not changed, that its referenced assertions still match, that the content binding belongs to the asset being examined, and that the signing credential is acceptable under the verifier’s trust configuration.[1]

What C2PA actually signs

The private-key signature is applied to the serialized claim, not directly to every byte of the asset. The claim contains hashed references to the assertions being claimed. One of those assertions, in a standard manifest, is the hard binding that commits the manifest to the protected asset representation.

This creates a connected protection structure. If a referenced assertion changes, its hash no longer matches the claim. If the claim changes, the claim signature fails. If protected asset content changes, the hard binding fails. The signature therefore protects the relationship among the claim, the declared assertions, and the asset binding without requiring the media bytes themselves to be the signature payload.

The actors in a signing workflow

Several actors may participate in a single signing operation. Keeping their roles separate prevents one of the most common misunderstandings in C2PA: the software that constructs a manifest, the organization whose key signs it, and the person who created the content are not automatically the same identity.

In a small application, the claim generator and signer may run in the same process. In a production service, they are often separated: the application constructs the data to be signed, while a KMS, HSM, secure enclave, subprocess, or remote signing service performs the private-key operation. This separation reduces key exposure, but it does not remove the need to authorize and inspect every signing request.

The complete signing lifecycle

A production C2PA signing workflow can be understood as eleven connected stages. Libraries may hide several of these stages, but the underlying ordering still matters.

1. Choose the manifest intent. Decide whether the operation creates a standard manifest for a new content representation or an update manifest for restricted information added without changing the protected content.

2. Finalize the content pipeline. Complete edits, resizing, encoding, metadata normalization, and any watermark insertion that changes the content.

3. Inspect source provenance. Load and validate relevant ingredients, decide what prior manifests to preserve, and record any redactions or inaccessible provenance.

4. Author the assertions. Select the actions, ingredients, disclosures, metadata, and other statements that the signing policy permits.

5. Choose the storage pattern. Determine whether the Manifest Store will be embedded, external, or both, and account for the format’s placement rules.

6. Construct the content binding. Calculate the format-appropriate hard binding over the final protected representation, using carefully defined exclusions when required.

7. Build the claim. Create deterministic hashed references to the created and gathered assertions, identify the claim generator, and connect the known claim-signature location.

8. Perform the private-key operation. Create the COSE claim signature using an authorized signing credential, preferably across a protected key boundary.

9. Attach validity evidence. Include the signer certificate chain and, when available, trusted time-stamp and credential-status evidence.

10. Complete the output. Embed or publish the finished Manifest Store without altering the protected content afterward.

11. Verify before release. Open the exact output as a new input and run independent C2PA validation before making it available to customers or downstream systems.

1. Choose the correct manifest intent

The first decision is whether the content itself has changed. A new or transformed representation ordinarily receives a standard manifest. In C2PA 2.4, a standard manifest contains exactly one hard-binding assertion appropriate to the asset type. If the protected content is unchanged and only a restricted provenance event is being added, an update manifest can extend the history without introducing a new hard binding; it links to the prior manifest through exactly one parent relationship.

This decision should be explicit in the application’s policy. Cropping an image, transcoding a video, rendering a document, applying generative fill, or inserting an invisible watermark changes the protected representation and therefore belongs before a new standard manifest is issued. Recording an allowed publication or metadata event without altering the protected content may be suitable for an update manifest.[2]

Treating every operation as “sign this file” is too vague. A robust interface asks what happened to the content, which earlier asset is the parent, which other assets are ingredients, and what the resulting output is intended to represent.

2. Finish content-affecting work before binding

The hard binding is calculated against a defined representation of the asset. Once that binding is committed into the signed claim, content-affecting transformations will normally cause validation to fail. The safest rule is simple: complete the media pipeline first and sign the exact deliverable last.

Operations that generally belong before signing include image resizing, color conversion, compression, video transcoding, audio normalization, document rendering, metadata rewriting, thumbnail generation, and content-level watermark insertion. The file name, object-storage key, or public URL can change without affecting the content binding, but changes to covered bytes or structures cannot.

This ordering has an important consequence for CDNs and publication systems. If a CDN automatically converts a signed JPEG to WebP, or a video platform produces lower-resolution renditions, those outputs are new representations. The pipeline should either issue a new manifest for each rendition, preserve the original signed asset alongside them, or use a durable-provenance strategy that helps recover related credentials after transformation. It should not assume that the original hard binding will survive.

3. Validate and preserve ingredient provenance

When an asset is derived from or composed with existing assets, the claim generator should inspect those ingredients before constructing the new manifest. If an ingredient carries Content Credentials, the workflow should validate them, capture their status, and preserve the relevant manifests in the new asset’s Manifest Store where appropriate.

The claim generator should not silently treat imported provenance as trustworthy merely because it is present. A source credential may be valid but untrusted, malformed, inaccessible, or associated with content that does not match the ingredient. The new claim can record the observed state, but it should not rewrite the earlier signer’s assertions or imply stronger validation than actually occurred.

This is also the point to apply any permitted redactions and data-minimization choices. Once the new claim is signed, its own fields and asserted references cannot be edited without invalidating the signature. Sensitive information that may need to be removed later should be placed in an assertion designed for controlled redaction rather than in an unredactable claim field.

4. Author the assertions under a signing policy

Assertions are the substantive statements in the Content Credential. A signing service should not accept an arbitrary manifest body and blindly apply a trusted key. It should construct or validate assertions against a policy that defines which types are allowed, how many instances are expected, which values are required, and which data must be excluded for privacy or safety reasons.

The claim separates created assertions from gathered assertions. Created assertions are attributed to the signer through the signed claim. Gathered assertions are included and integrity-protected but are recorded as having originated elsewhere in the workflow. Misclassifying user-supplied or third-party data as created can make the signer appear to endorse information it did not originate.

A practical policy might require an actions assertion, a hard binding, claim-generator information, an AI disclosure for covered model outputs, and one or more ingredient assertions. It might prohibit free-form identity data, precise location, or raw prompts unless the customer has deliberately enabled them. The goal is not to maximize the amount of provenance; it is to produce accurate, useful, and appropriately minimized provenance.

5. Choose how the Manifest Store will be placed

The Manifest Store can be embedded in the asset, stored externally, or made available through both approaches. The choice affects file size, portability, retrieval dependencies, and the mechanics of the signing operation, but not the need for a valid hard binding.

Embedded manifests travel with the asset and can often be verified offline. External manifests can be useful when the format cannot carry a store, when the store is large, or when modifying the original asset is undesirable. An external store must be published reliably and discoverably, and the validator must still confirm that its hard binding describes the asset being examined.

For some formats, placement must be planned before the final claim and signature are known. That leads to the multiple-step process described below. A signing implementation should delegate these format-specific details to a mature C2PA library rather than attempting to treat every media type as an arbitrary byte blob.

6. Calculate the hard binding

A standard manifest needs one format-appropriate hard binding. Depending on the asset, this may hash byte ranges, defined boxes or segments, a BMFF structure, a collection, or another supported representation. The calculation must cover the content that matters while excluding only the regions that must remain mutable for manifest insertion or format operation.

Exclusions are security-sensitive. If an excluded region can be changed in a way that alters how the asset is interpreted, an attacker may be able to modify meaningful content without breaking the binding. The claim generator should use the narrowest format-defined exclusions possible and should include non-C2PA asset metadata in the protected region where the workflow can safely do so.

Any watermark or other durable marker intended to survive redistribution should already be present before this calculation. A fingerprint can be computed before or after without modifying the content, but a watermark changes the content and therefore must be inserted first.

Why some formats require a two-pass signing process

Embedding creates a circular sizing problem. The Manifest Store changes the size and layout of the asset, yet the final content binding may depend on that layout. The claim signature also has a size that is not completely known until the claim and certificate information are finalized. C2PA resolves this through multiple-step processing for formats that require fixed offsets or reserved space.

In the first pass, the claim generator creates provisional binding information and a temporary signature structure with padding. It assembles a provisional Manifest Store and places it into the asset so that the final offsets and excluded regions become known. The generator can then calculate the actual binding values over the intended representation.

In the second pass, the generator writes the final binding information into the reserved structure without changing its total size, serializes the completed claim, obtains the real signature, and replaces the temporary signature while shrinking unprotected padding as needed. If the completed signature structure is larger than the reserved region, the process must be repeated with more space.[3]

Most application developers should not manually implement this procedure. Its operational lesson is what matters: the signing library must control final serialization, no unplanned processor may rewrite the file between passes, and the released output must be validated after all placeholders have been replaced.

7. Build and sign the claim

After the assertions and binding values are complete, the claim generator creates the claim. C2PA 2.4 uses a deterministic CBOR representation for current claims. The claim includes claim-generator information, asset identifiers, the media type, a reference to the known location of the claim signature, and hashed references to every created and gathered assertion being claimed.

The signature itself cannot be part of the signed payload, so the claim points to the predefined signature location. The serialized claim becomes the detached payload for a COSE Sign1 operation. The signer’s private key produces the digital signature, and the completed COSE structure is written into the claim-signature box.

The signature should also carry the signer’s leaf certificate and all intermediate certificates required to propose a path toward a trust anchor. The root trust-anchor certificate is normally omitted because the validator obtains trust anchors from its own configured trust stores. Certificate-chain data included with a manifest is still untrusted input until the validator builds and evaluates the path.[4]

Local, remote, and customer-controlled signing

The claim generator does not need to possess exportable private-key bytes. It can send the exact bytes required for the signature operation to a protected signer and receive only the resulting signature. This allows the C2PA construction logic and the key-custody boundary to evolve independently.

The strongest abstraction is a signer interface that exposes the algorithm, certificate chain, expected signature capacity, optional TSA configuration, and a method that signs an exact byte sequence. The C2PA layer remains responsible for constructing the manifest correctly; the signer remains responsible for key authorization and cryptographic execution.

8. Add trusted time and credential-status evidence

A signing certificate has a validity period and may later be revoked. A trusted RFC 3161 time-stamp records that the completed claim signature existed at an attested time. This is different from a self-reported creation time or a claimed signing-time field: the time-stamp is issued by a separate authority and validated through its own trust configuration.

C2PA 2.4 uses the completed signature value for the current time-stamp payload, allowing the time-stamp to countersign the entire signature structure, including the actual certificate information. A manifest contains at most one time-stamp. When a trusted time-stamp is present, validators can evaluate the signing credential at the attested time rather than relying only on the current date.

Claim generators should also retrieve and staple available OCSP freshness information for the signer and included intermediates. If revocation information is attached to the signature, a trusted time-stamp is needed to establish when that status evidence applied. When a device cannot reach a TSA or status service during initial signing, a later update manifest can add permitted time-stamp or certificate-status evidence without rewriting the original signed claim.[5]

9. Complete the output without changing protected content

Once the real signature and any associated evidence are available, the claim generator completes the Manifest Store and places it according to the chosen storage pattern. For an embedded store, all reserved structures and offsets must remain valid. For an external store, publication and asset release should be coordinated so that the referenced manifest is available when the asset reaches validators.

The signing system should preserve the exact released output in content-addressed storage or record its final hash. It should also retain the manifest label, certificate fingerprint or serial number, signing operation identifier, policy version, time-stamp status, and destination information. These records do not replace the Content Credential, but they make operations auditable and help investigate later failures.

Do not treat a successful response from a KMS or signing API as evidence that the asset is valid. That response proves only that a private-key operation completed. The manifest may still be malformed, embedded at the wrong offset, missing an assertion, bound to the wrong bytes, or altered during output assembly.

10. Independently validate before release

The final stage of signing is verification. The exact output that will be returned to a customer or published should be reopened by a reader or validator that is independent of the builder’s in-memory state. This catches serialization, embedding, hashing, certificate, time-stamp, and pipeline errors that cannot be detected by observing the signing call alone.

A release-gate validation should confirm at least that the Manifest Store can be located and parsed, the active claim and signature are present, the claim signature validates, the certificate chain is acceptable for the intended environment, the assertion hashes match, the correct hard binding matches the final asset, and required policy assertions are present.

The signing service should define whether warnings or an untrusted signer block release. In a development environment, an otherwise valid manifest signed with a test credential may be acceptable. In a production environment that promises trusted Content Credentials, a valid-but-untrusted result should normally be treated as a failed release condition.

Securing the signing boundary

The claim-signing key is the authority that allows a system to issue provenance under a signer’s identity. If the key is stolen, an attacker can create cryptographically valid claims. If the key remains protected but an attacker gains permission to invoke it, the attacker can still misuse the legitimate signing system. HSMs and KMSs reduce key-extraction risk, but they do not solve authorization, application compromise, or abuse by themselves.

Production systems should keep private keys non-exportable, separate sandbox and production credentials, scope keys to a defined claim generator or product, rotate certificates deliberately, and maintain a tested revocation plan. Signing APIs should authenticate both users and workloads, authorize each operation, enforce tenant and environment boundaries, and reject assertions outside an explicit allow list.

The system should also limit request volume, inspect unusual signing behavior, preserve tamper-evident audit records, and support immediate signer suspension. A public service that will sign arbitrary customer content needs additional anti-abuse and identity controls because a technically valid credential can be used to make misleading provenance appear to originate from the service.[6]

A practical signing example: an AI image API

Consider an API that generates a PNG from a text prompt and returns it to a customer. The service wants to disclose AI generation, preserve any permitted input provenance, and issue a trusted Content Credential for every production output.

1. Generate the image. The model produces a candidate result, and the service completes all safety processing, upscaling, color conversion, and final PNG encoding.

2. Apply durability features. If the product uses an invisible watermark, the service inserts it now, before the content binding is calculated.

3. Apply provenance policy. The service creates an action describing generation, an AI disclosure, claim-generator information, and selected ingredient references. It omits the raw prompt unless the customer has chosen to include it.

4. Construct the final manifest layout. The C2PA library reserves the required space and prepares the format-specific embedding structure.

5. Calculate the hard binding. The library hashes the final protected PNG representation according to the applicable rules.

6. Request the signature. The service sends the exact bytes to be signed to a tenant-appropriate KMS or remote signer after authorization and policy checks.

7. Add validity evidence. The completed signature includes the certificate chain, a trusted time-stamp, and available status information.

8. Complete and validate the output. The manifest is embedded, the final file is reopened, and the service requires signature, assertion, and hard-binding validation to pass.

9. Release and record. The API returns the validated PNG and stores the final asset hash, manifest identifier, policy version, signer, timestamp status, and verification report.

The resulting credential can provide evidence about the signed provenance record and the exact protected output. It does not independently prove that every input statement is complete, that the generated image is factually accurate, or that the implementation satisfies every applicable law. Those are separate policy and interpretation questions.

Common signing failures

Production readiness checklist

• The workflow explicitly distinguishes creation, editing, rendition, composition, and update-manifest operations.
• All content-changing work, including watermark insertion, is complete before the final hard binding is calculated.
• Ingredient manifests are validated at ingestion and their observed status is preserved accurately.
• Created and gathered assertions are classified correctly, and sensitive fields are minimized by policy.
• The implementation uses a maintained C2PA library for format-aware hashing, embedding, and multiple-step processing.
• Production private keys are non-exportable and accessible only through authenticated, authorized signing operations.
• The signing certificate, algorithm, certificate chain, and intended trust environment are checked before activation.
• Trusted time-stamps and available revocation freshness information are attached whenever possible.
• Every operation is idempotent, auditable, tenant-scoped, and associated with a stable signing-operation identifier.
• The exact final output is independently parsed and validated before release.
• The service retains sufficient evidence to investigate later failures without logging unnecessary sensitive content.
• Rotation, emergency suspension, certificate revocation, and customer notification procedures have been tested.

What signing establishes—and what it does not

A successful C2PA signing operation establishes a tamper-evident relationship among the signed claim, its referenced assertions, the signer’s credential, and the protected asset representation. With a valid and trusted credential, it can support attribution of the signed claim to the identified claim generator and signer under a validator’s trust configuration.

Signing does not make every assertion factually true, verify the identity of every human mentioned, guarantee that the provenance history is complete, prevent the entire Manifest Store from being stripped, or automatically establish legal compliance. It creates verifiable provenance evidence. The strength of the resulting conclusion still depends on the signer, the security of the generation workflow, the quality of the assertions, and the context in which a validator uses them.

The simplest mental model

• Finalize the asset before signing.
• Describe the workflow through policy-controlled assertions.
• Bind a standard manifest to the exact protected representation.
• Serialize the claim deterministically and sign the claim—not an informal metadata object.
• Keep production private keys behind a secure and authorized signing boundary.
• Attach the certificate chain, trusted time, and status evidence needed for durable validation.
• Place the completed Manifest Store without rewriting the protected output.
• Reopen and validate the exact released asset as the final step.

When these stages are treated as one controlled pipeline, C2PA signing becomes more than a cryptographic API call. It becomes a repeatable process for issuing provenance records that other systems can independently inspect, validate, monitor, and preserve.

Sources and notes

[1] C2PA Technical Specification 2.4, “Technical Overview” and “Claims”. These sections define the claim generator, signer, assertions, claim, claim signature, and the cryptographic relationship among them.

[2] C2PA Technical Specification 2.4, “Creating a Claim” and “Types of Manifests”. These sections specify how assertions and ingredients are added and distinguish the hard-binding requirements of standard and update manifests.

[3] C2PA Technical Specification 2.4, “Multiple Step Processing”. This section defines the provisional claim, reserved signature structure, final offset and binding updates, and in-place completion process used by formats that require fixed layout before signing.

[4] C2PA Technical Specification 2.4, “Digital Signatures” and “X.509 Certificates”. These sections define COSE claim signing, supported cryptography, protected certificate-chain carriage, and the requirement to include the signer certificate and intermediates while normally omitting the trust anchor.

[5] C2PA Technical Specification 2.4, “Time-stamps” and “Credential Revocation Information”, together with C2PA Implementation Guidance 2.4, “Revocation information and time-stamps.” These sections explain trusted time-stamping, stapled status evidence, and the value of collecting both at signing time.

[6] C2PA Security Considerations 2.4, “Spoofing signed C2PA Manifests via a stolen key” and “Spoofing signed C2PA Manifests via misuse of claim generator”, and the CAI SDK guide “Using a signing certificate in production.” These sources address HSM/KMS protection, key scoping, request authorization, assertion allow lists, and production key handling.