Release note · August 4, 2026
Declared coverage is not signature validity
A Word package can keep its document text and ordinary package structure stable while a package signature’s declared coverage changes. That is useful handoff evidence: a Manifest can stop naming a Word part or a selected relationship. It is not evidence that a signature verifies, that a certificate is trusted, that every package surface is effectively protected, or that an Office client will accept the file.
DocFence 0.40 exposes this narrow static boundary, and Document Change Assurance Benchmark (DCAB) 0.30 makes it independently reproducible. Both releases take the distinction seriously: they review what the package declares, not a cryptographic or client-side result they did not compute.
Correction, August 4, 2026: the 0.40 implementation did not recognize the standard relationship-type selector element correctly. DocFence 0.41 and DCAB 0.31 correct that exact form: RelationshipReference/@SourceId selects an individual relationship, while RelationshipsGroupReference/@SourceType selects relationship types. The earlier parser failed closed on the standard type form rather than crediting it, but this post's original selector wording was too broad.
Three questions that must stay separate
The OPC digital-signature rules define an origin part related from the package root, XML Signature parts related from that origin, and a package-specific signature object with a Manifest. A Manifest can name package parts directly or select individual relationships through the OPC Relationships Transform.
That gives a reviewer three different questions:
- What package-signature material is stored?
- Which bounded Word parts and relationships does its Manifest declare?
- Does the signature cryptographically validate and meet a consumer’s trust policy?
The first two can be useful static observations. The third needs digest calculation, canonicalization, XMLDSIG validation, certificate and revocation handling, signing policy, and ultimately a consumer-specific decision. Treating a Manifest declaration as an answer to that third question produces a false assurance.
What the corrected static audit resolves
DocFence follows a deliberately small declaration chain. For each recognized XML signature, it requires a direct local-fragment SignedInfo reference to a direct ds:Object with exactly one direct package ds:Manifest. It then resolves exact local part URI and case-sensitive content-type declarations, plus standard relationships-transform RelationshipReference/@SourceId and RelationshipsGroupReference/@SourceType selectors.
Public reports contain aggregate counts only: signatures with and without a usable declaration chain; covered and uncovered Word parts; covered and uncovered root office-document relationships; covered and uncovered relationships sourced by Word parts; and unresolved or unsupported manifest references. They do not disclose package paths, object identifiers, Manifest URIs, relationship IDs or types, selectors, digest material, certificate data, or fingerprints. A private semantic comparison still lets a same-count reassignment become review-visible.
The candidate-state gate covers the union of all bound Manifests, while requiring every recognized signature to provide a bound Manifest. It is intentionally not a claim about all package content or every possible client input:
version: 1
rules:
require_complete_package_signature_coverage: trueThis emits DFP092 when the bounded declaration scope is incomplete, unresolvable, or unsupported. A controlled workflow can instead preserve an approved declaration baseline:
version: 1
rules:
no_package_signature_coverage_changes: trueDFP093 catches a material declaration change, including a same-count selector reassignment. Neither rule recomputes a digest or canonicalization, executes arbitrary transforms, verifies XMLDSIG, validates a certificate chain, checks revocation or timestamps, establishes signer identity, or predicts a client’s trust decision. The tagged policy reference and threat model define the exact corrected boundary.
A 41st deterministic DCAB pair
DCAB 0.30 adds review.package_signature_declared_coverage_changed. Its baseline and candidate retain the same package-member set, signature-origin topology, every non-signature package byte, and the same sequence of stored Word text. Only one synthetic XMLDSIG-shaped signature member differs: the candidate omits one private relationship-selection declaration from an otherwise fixed Manifest.
The pair is intentionally non-cryptographic. Its digest and signature values are deterministic placeholders, not a sample valid signature. DCAB’s independent structural verifier checks the origin/signature topology, Manifest shape, transform ordering, exact one-member boundary, deterministic regeneration, and target-free truth. Its independent reader check establishes that the packages can be opened as OPC/WordprocessingML inputs; it makes no rendering or runtime claim.
The optional adapter recognizes only DocFence’s public package_signature_coverage_changed evidence and exact aggregate counts. Raw selectors, reference URIs, part paths, object IDs, and synthetic signature values remain in the fixture contract rather than its public oracle. The 41-case corpus is mirrored on Hugging Face.
Released and verified
Both tagged releases passed hosted CI. DCAB 0.30 ran its full source, distribution, and adapter matrix on Python 3.11, 3.12, and 3.13 with the released DocFence 0.40 adapter. Fresh tag checkouts produced validated wheel and source artifacts; their public GitHub downloads were byte-compared against those builds. The dataset mirror’s manifest, new truth file, and pair archives were downloaded and byte-compared as well.
python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.40.0/docfence-0.40.0-py3-none-any.whl
python -m pip install https://github.com/SybilGambleyyu/document-change-benchmark/releases/download/v0.30.0/document_change_benchmark-0.30.0-py3-none-any.whl
docfence diff approved.docx candidate.docx --format markdown
dcab validateUse this evidence as a disciplined review signal: a declared coverage change deserves attention, but it remains a declared coverage change until a separate cryptographic and consumer-specific validation process establishes more.