Re-signing

Re-signing involves generating a new claim signature that covers both the original manifest and any new assertions. The new signer's identity is bound via their X.509 certificate, creating a verifiable link in the provenance chain. This process does not invalidate prior signatures but adds a new layer of attestation on top of the existing cryptographic hash chain.

When a digital asset changes hands—from a photographer to an editor, or an editor to a publisher—re-signing formally documents the transfer of custodial responsibility. The new custodian applies their signature over the entire provenance data model, asserting:

• Acceptance of the asset's prior history
• Assumption of responsibility for the current state
• Establishment of a new trust anchor for downstream verification

Re-signing is required whenever a new action assertion is added to a manifest. If an editor crops an image, the editing software must:

1. Generate a new ingredient assertion documenting the source
2. Add an action assertion describing the crop operation
3. Re-sign the entire manifest to bind these new claims to the editor's identity

This ensures every transformation is cryptographically attributable.

A validator engine processes re-signed credentials by:

• Verifying the new signature against the signer's certificate
• Walking the full provenance chain to validate all prior signatures
• Checking each certificate against a trust list of approved issuers
• Performing revocation checks via OCSP for every certificate in the chain

If any link fails, the entire credential's trust status is degraded.

Re-signing behavior differs by binding method:

• Hard Binding: The new manifest is embedded directly into the asset's JUMBF structure, replacing or extending the previous manifest. The file itself is mutated.
• Soft Binding: A new sidecar metadata file is created or the cloud-hosted manifest is updated. The asset's binary remains unchanged, but the content hash reference is updated.

Hard binding provides stronger metadata stripping resistance.

Each re-signing event should be paired with a trusted timestamp from a Timestamp Authority (TSA). This cryptographically proves that the new signature existed before a specific moment, preventing backdating attacks. The combination of a new signature and a trusted timestamp provides non-repudiation—the signer cannot plausibly deny having asserted custodianship or performed the documented edit at that point in time.