IdentityAssertionSigner produces claimSignature.mismatch on every signed manifest

[marmarko]

Description

Using IdentityAssertionSigner with CallbackCredentialHolder produces manifests where validation_status always contains claimSignature.mismatch. The identity assertion (cawg.identity) is embedded correctly, but the claim signature is invalid.

Reproduction

Using @contentauth/c2pa-node@0.5.3 on Node.js 24, macOS arm64.

The credential holder callback follows the pattern from IdentityAssertion.spec.js:

import { encode } from 'cbor2';

class TestCawgSigner {
  constructor(manifestSigner) { this.manifestSigner = manifestSigner; }
  sign = async (payload) => {
    const cborBytes = Buffer.from(encode(payload));
    return this.manifestSigner.sign(cborBytes);
  };
}

const cawgSigner = CallbackCredentialHolder.newCallbackCredentialHolder(
  10240, 'cawg.x509.cose', cawgTestSigner.sign
);
const iab = await IdentityAssertionBuilder.identityBuilderForCredentialHolder(cawgSigner);
iab.addReferencedAssertions(['cawg.training-mining']);
const iaSigner = IdentityAssertionSigner.new(c2paSigner.getHandle());
iaSigner.addIdentityAssertion(iab);
await builder.signAsync(iaSigner, source, dest);

Test Matrix

Tested all combinations of directCoseHandling (true/false), with/without ingredients:

directCoseHandling	Identity	Ingredient	cawg.identity present	claimSignature.mismatch
true	yes	no	✅	❌ mismatch
false	yes	no	✅	❌ mismatch
true	yes	yes	✅	❌ mismatch
false	yes	yes	✅	❌ mismatch
false	no	no	n/a	✅ valid
false	no	yes	n/a	✅ valid

Without identity assertion, manifests validate correctly. The issue is 100% reproducible and appears on every call.

Suspected Cause

IdentityAssertionBuilder implements AsyncDynamicAssertion. The content() method calls the credential holder's sign() which is non-deterministic (produces a different signature each time). If content() is called more than once during the signing process (e.g., once for size estimation and once for actual embedding), the claim signature computed over the first result won't match the second result that gets embedded.

Note: The existing IdentityAssertion.spec.js test calls Reader.fromAsset() but does not check validation_status, so this issue would not be caught by the test suite.

Environment

• @contentauth/c2pa-node: 0.5.3 (also reproduced on 0.5.2)
• Node.js: 24.14.0
• Platform: macOS arm64 (Apple Silicon)
• Certificate: ECDSA P-256 (es256), self-signed with CA chain

[marmarko]

Additional Investigation

We forked the repo, traced the c2pa-rs source (v0.77.0 and v0.78.4), and found:

Root cause is in c2pa-rs, not the Neon binding

The save_to_stream flow in c2pa-rs/src/store.rs calls signer.dynamic_assertions() once and reuses the result for both add_dynamic_assertion_placeholders() and write_dynamic_assertions_async(). So the drain in NeonIdentityAssertionSigner::dynamic_assertions() (via split_off(0)) is NOT the cause — we tested a clone-based fix and the claimSignature.mismatch persists.

Tested with c2pa 0.78.4

Updated the fork's Cargo.toml to c2pa = "0.78.4", rebuilt the native binary, and re-ran all tests. Same claimSignature.mismatch on every configuration (directCoseHandling true/false, with/without ingredients).

The IdentityAssertion.spec.js test doesn't catch this

The existing test only checks that Reader.fromAsset() doesn't throw — it never inspects validation_status. Adding a check like:

const store = reader.json();
const errors = store.validation_status?.filter(s => 
  !s.code.startsWith('signingCredential.') && !s.code.startsWith('trust.')
);
expect(errors).toHaveLength(0);

...would reproduce this bug in the test suite.

Test matrix (all produce claimSignature.mismatch)

• c2pa 0.77.0 + directCoseHandling: true/false
• c2pa 0.78.4 + directCoseHandling: true/false
• With and without ingredients
• With and without the split_off(0) → clone fix

The dynamic assertion (cawg.identity) IS embedded correctly in every case — it's the claim signature that doesn't match the final manifest content.

[marmarko]

Definitive Reproduction in c2pa-node-v2 Repo

We reproduced the claimSignature.mismatch in the c2pa-node-v2 repo itself using the existing test fixtures (es256.pem, es256.pub, CA.jpg), the exact same code pattern from IdentityAssertion.spec.ts, and a locally-built binary from source (c2pa 0.78.4).

Steps to reproduce

1. Build from source: cargo build --release
2. Copy binary: cp target/release/libc2pa_node.dylib js-src/index.node
3. Add this test to js-src/IdentityValidation.spec.ts (code below)
4. Run: npx vitest run js-src/IdentityValidation.spec.ts

Result

All validation status: [ 'signingCredential.untrusted', 'claimSignature.mismatch' ]
Integrity errors: [ 'claimSignature.mismatch' ]

The existing IdentityAssertion.spec.ts test passes because it only checks that Reader.fromAsset() doesn't throw — it never inspects validation_status. Adding a validation check reveals the signing is fundamentally broken.

Minimal failing test

it("should produce valid claimSignature with identity assertion", async () => {
  // ... (same setup as IdentityAssertion.spec.ts) ...
  
  await builder.signAsync(iaSigner, source, dest);
  const reader = await Reader.fromAsset({ buffer: dest.buffer!, mimeType: "image/jpeg" });
  const store = reader!.json();
  const integrityErrors = store.validation_status
    ?.filter(s => !s.code.startsWith("signingCredential.") && !s.code.startsWith("trust."));
  
  // THIS FAILS:
  expect(integrityErrors.filter(s => s.code === "claimSignature.mismatch")).toHaveLength(0);
});

This confirms the bug is in c2pa-rs's DynamicAssertion + save_to_stream flow, not in any consumer code.

[marmarko]

ROOT CAUSE FOUND + FIX

We traced the bug to two separate issues, both required for identity assertions to work:

Fix 1: c2pa-rs store.rs — stale JUMBF after dynamic assertions

In save_to_stream, after write_dynamic_assertions modifies the claim:

1. to_jumbf_internal() generates JUMBF with claim hash X
2. save_jumbf_to_stream() embeds JUMBF into the asset — this updates DataHash, changing the claim
3. sign_claim() signs claim with hash Y (different from X due to DataHash update)
4. finish_save_stream() patches the signature into the JUMBF from step 1 (which has stale hash X)

Result: JUMBF has claim hash X, but signature was over claim hash Y → claimSignature.mismatch

Fix: Regenerate jumbf_bytes via to_jumbf_internal() right before finish_save_stream, after all claim modifications are finalized:

// In save_to_stream, after the `if modified` block and before finish_save_stream:
if modified {
    jumbf_bytes = self.to_jumbf_internal(signer.reserve_size())?;
}

Fix 2: Credential holder callback must return COSE_Sign1, not raw signature

The sig_type "cawg.x509.cose" tells the verifier to parse the identity assertion's signature field as a COSE_Sign1 structure. The existing test fixture returns a raw DER signature, which fails CoseSign1::from_tagged_slice with "extraneous data in CBOR input" (70 bytes) or "got map, expected bstr" (when naively wrapped).

Correct callback implementation:

import { encode, Tag } from 'cbor2';

const ES256_ALG_ID = -7;

async function sign(payload: SignerPayload): Promise<Buffer> {
  // 1. CBOR-encode the payload (detached content)
  const payloadCbor = new Uint8Array(encode(payload));
  
  // 2. Protected header { 1: -7 } — MUST be Uint8Array for cbor2 bstr encoding
  const protectedBytes = new Uint8Array(encode(new Map([[1, ES256_ALG_ID]])));
  
  // 3. Build Sig_structure per RFC 9052 §4.4
  const sigStructure = ["Signature1", protectedBytes, new Uint8Array(0), payloadCbor];
  const sigStructureCbor = Buffer.from(encode(sigStructure));
  
  // 4. Sign with IEEE P1363 format (required by COSE ES256)
  const rawSignature = new Uint8Array(crypto.sign(sigStructureCbor, key, { dsaEncoding: 'ieee-p1363' }));
  
  // 5. Return COSE_Sign1 = Tag(18, [protected, {}, nil, signature])
  return Buffer.from(encode(new Tag(18, [protectedBytes, new Map(), null, rawSignature])));
}

Key detail: cbor2 (JavaScript) encodes Buffer objects by unwrapping CBOR content, but encodes Uint8Array as raw byte strings. The protected header MUST be Uint8Array to be encoded as a CBOR bstr, not unwrapped as a map.

Verification

With both fixes applied, the test passes with zero integrity errors:

All validation status: [ 'signingCredential.untrusted' ]
Integrity errors: []
Assertions: [ 'c2pa.actions.v2', 'cawg.training-mining', 'cawg.identity' ]
Has cawg.identity: true
✓ Tests  1 passed

Suggested action

1. Fix 1 should be a PR to contentauth/c2pa-rs — the save_to_stream JUMBF regeneration bug affects all dynamic assertions
2. Fix 2 should update the IdentityAssertion.spec.js test to use proper COSE_Sign1 wrapping AND add validation_status checking
3. The existing test should be updated to catch this: add expect(integrityErrors).toHaveLength(0) after Reader.fromAsset()

[marmarko]

Our CallbackCredentialHolder callback was returning a raw signature instead of a COSE_Sign1 structure. Once we updated it to return a proper COSE_Sign1 envelope, the claimSignature.mismatch went away.

The credential holder now:

CBOR-encodes the SignerPayload
Builds protected header { 1: -7 } (ES256)
Constructs Sig_structure = ["Signature1", protected, b"", payload_cbor]
Signs CBOR(Sig_structure)
Returns CBOR(Tag(18, [protected, unprotected, nil, signature]))

So the issue was on our end, not in the SDK. The c2pa-node PRs still fix the SDK's own test (which has the same raw-signature pattern), but they're not needed for app-level usage if you build the COSE_Sign1 correctly.