Release note · August 4, 2026

A part reference is not transform-agnostic

A package Manifest can reference an ordinary stored Word part directly, without selecting a relationship subset. That does not make its XMLDSIG Transforms list irrelevant. OPC permits only canonicalization and relationship transforms in Manifest references; an arbitrary transform cannot be silently ignored while still being credited as static part coverage.

Correction, August 4, 2026: 0.44 constrained transform lists on direct package-part references but did not require the ordered XMLDSIG DigestMethod/DigestValue child shape before crediting a bound Manifest reference. DocFence 0.45 now keeps missing, misordered, malformed, or extra digest children as aggregate unsupported evidence. The 0.44 parser did not claim XMLDSIG validity, but this was a separate structural declaration gap.

A different input deserves a different transform boundary

The OPC digital-signature requirements require a consumer to treat transforms other than XML Canonicalization and the package-specific relationships transform as errors. A relationships transform operates on a Relationships part; it is not a substitute for a transform declaration on an ordinary package part.

Manifest Reference → word/document.xml

accepted: no transform list
accepted: one nonempty C14N-only list
rejected: relationship, unknown, empty, or duplicate list

DocFence 0.44 checks that narrow structural condition before crediting a direct package-part reference. It accepts no ds:Transforms element, or exactly one direct nonempty list whose children are XMLDSIG Transform elements using XML Canonicalization or XML Canonicalization with Comments. It refuses a relationship transform, any unknown algorithm, an empty list, or multiple lists.

Refusing to credit is not executing a transform

The release does not calculate a canonical form, recompute a digest, validate an XML signature, inspect a certificate, establish trust, or predict an Office client decision. It asks only whether the static transform declaration stays inside the small OPC subset the coverage audit is prepared to recognize.

An unsupported declaration is reported as aggregate evidence and does not cover the part. Public output keeps the part path, reference URI, transform algorithm, digest material, certificate data, and private semantic fingerprint out of the report.

version: 1
rules:
  require_complete_package_signature_coverage: true
  no_package_signature_coverage_changes: true

DFP092 and DFP093 remain bounded review gates, not signature-validity or trust claims.

Evidence and compatibility

The regression suite now tests direct Word-part references with both accepted C14N forms, plus unknown, relationship, empty, and duplicate transform-list cases. The full 67-test suite passed. DCAB’s optional DocFence adapter also passed across its 42 deterministic fixtures, including its existing standards-shaped package-signature relationship-type reassignment case.

The tagged source passed hosted CI on Python 3.11 and 3.13 plus the distribution build. Fresh wheel installation exercised the DCAB fixture, and both public GitHub release files were downloaded and byte-compared against the verified local builds.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.44.0/docfence-0.44.0-py3-none-any.whl

docfence check approved.docx candidate.docx --policy docfence.yml --format sarif --output docfence.sarif

The tagged policy reference, threat model, and validation notes set out the exact boundary. Static coverage becomes more useful when it is explicit about the transform declarations it declines to interpret.