Release note · August 1, 2026

A Word file can carry a signature without proving trust

A signed Word file is not a yes-or-no security fact. An Office Open XML package can carry an OPC signature origin, XML Signature parts, optional certificate parts, and inline certificate data—yet whether a signature is valid or trustworthy depends on cryptographic validation, certificate and policy evaluation, and the consuming application. A review gate first needs a narrower, reliable question: did the package’s stored signature material change?

DocFence 0.12 makes that package state review-visible without treating a signature as a trust verdict. It emits bounded aggregate evidence that can drive a handoff or baseline policy, while retaining the actual signature material only in a local comparison digest.

What a Word package can retain

The Open Packaging Conventions define package signatures as package components: an origin points to XML Signature parts, which may reference certificate parts and contain inline X.509 material. The same specification makes the package consumer responsible for deciding what a signer or certificate means. That separation matters: a package can contain recognizable signature material without a locally valid, trusted, current, or sufficiently covering signature.

It also matters because structurally valid-looking Office signatures have had real implementation and workflow security consequences. Public research on OOXML signature security is a useful reminder that “signed” is not a substitute for understanding the exact validation and trust model. DocFence therefore never turns presence into a passing security claim.

Counts in reports; signature material stays private

Profile JSON, Markdown, and SARIF expose only origin, XML-signature, and certificate-part counts, plus SignedInfo reference, manifest-reference, relationship-reference, inline-X.509-certificate, and signature-property counts. They do not print signature values, signer or certificate material, algorithms, signing times, comments, provider data, reference URIs, relationship IDs, package paths, or fingerprints.

The full recognized inventory is privately fingerprinted so a same-count mutation to signature XML or certificate bytes still changes a protected baseline. Re-signing a package deliberately changes stored signature material; DocFence does not normalize that away. The point is an explicit and reviewable package-state boundary, not a claim that two re-signed files are equivalent.

Choose a clean handoff or freeze the expected material

For an external handoff that must carry no stored package-signature material:

rules:
  require_no_package_digital_signatures: true

This produces DFP037. It fails for any nonzero signature inventory count, including an otherwise empty recognized signature origin. For a controlled workflow where an approved package is expected to retain its signature material:

rules:
  no_package_digital_signature_changes: true

DFP038 detects a private-inventory change from the approved baseline. Neither rule validates a signature or declares an author trustworthy.

Strict discovery, intentionally limited scope

DocFence recognizes an origin through the conventional path, exact OPC content type, or the standard root origin relationship. It then constrains recognized signature and certificate relationships to expected sources, internal stored targets, and exact content types; it accepts correctly declared content-type defaults as well as overrides. It allows only one origin and root origin relationship, checks bounded XMLDSIG structure, and fails closed on malformed recognized topology or shape.

This is stored-package evidence, not cryptographic verification. DocFence does not validate a signature or referenced digest; build a certificate chain; check revocation, timestamps, signer identity, coverage, policy, or algorithm suitability; or reproduce Microsoft Office’s trust decision. It also does not claim that a document was ever signed, or is presently safe, merely because a signature part is stored inside it.

Release evidence

The 0.12 suite has 33 tests covering same-count signature and certificate mutations, redaction across all report formats, policies and SARIF findings, conventional, relationship, and content-type discovery, malformed XMLDSIG structure, external and missing targets, wrong content types, duplicate/non-root origins, and relationship-ID semantics. It passed Python 3.11 and 3.13 CI, Ruff, and compilation checks. The wheel and source archive were independently rebuilt from the release commit and matched byte-for-byte.

An installed wheel profiled a public signed-package fixture without disclosing its signature data: it reported one origin, one XML Signature, three SignedInfo references, eight manifest references, six relationship references, one inline X.509 certificate, and two signature properties. Stable ordinary Open XML SDK Word document and template fixtures both reported zero signature counts.

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

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

The public release includes the wheel, source archive, and SHA-256 manifest. The precise semantics and limits are in the policy reference and threat model. For the preceding information-governance boundary, read A sensitivity label can retain your tenant’s metadata.