Release note · August 6, 2026

A canonicalization method has a boundary

A structure-only package-signature audit still has to distinguish a declared OPC signature from generic XMLDSIG-shaped markup. In SignedInfo, OPC makes that distinction explicit: the canonicalization method has exactly two permitted Algorithm URIs. Counting the element without reading that declaration makes the boundary looser than the package format itself.

OPC permits two methods

ECMA-376 Open Packaging Conventions §10.5.5 says that packages shall use only XML Canonicalization or XML Canonicalization with Comments. Their Algorithm values are:

http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

That is deliberately different from the neighboring SignatureMethod guidance, which uses recommendations and permits other algorithms. A parser can enforce this exact package-format requirement without pretending to decide cryptographic strength, signature validity, or trust.

What DocFence 0.51 changes

A recognized package XML signature must now contain one direct SignedInfo/CanonicalizationMethod whose Algorithm is exactly one of those two URIs. A missing attribute or another URI fails the recognized XML-signature shape closed. Both standard C14N and the comments-preserving form remain accepted.

This is intentionally upstream of the bounded declaration-coverage inventory. It prevents generic or malformed XMLDSIG markup from being reported as an OPC package signature in the first place; it does not expand DFP092 or DFP093 into a cryptographic policy.

No canonicalization is performed

DocFence reads the stored Algorithm URI only. It does not execute canonicalization, evaluate transforms, decode or recompute a digest, validate a SignatureMethod, verify XMLDSIG, inspect certificates, establish trust, or predict what an Office client will accept. Algorithm values, reference URIs, selectors, paths, digest material, and document contents stay out of public reports.

version: 1
rules:
  require_complete_package_signature_coverage: true
  no_package_signature_coverage_changes: true

Those remain bounded stored-declaration gates, not a substitute for a verifier and a trust policy.

Evidence and compatibility

The 69-test suite now covers ordinary C14N, C14N with comments, a missing Algorithm attribute, and an unsupported Algorithm. The public OOXML Signature Security artifacts contain 22 XML signature parts: all 21 parseable declarations use standard C14N, while the remaining attacker part is empty and already fails XML parsing.

Aggregate DocFence profiles for all 29 DOCX fixtures are identical between 0.50 and 0.51. Main and tagged CI passed, and an isolated wheel accepts both permitted methods while rejecting a targeted unsupported mutation. The public wheel and source archive were then byte-compared with the reproducible release build.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.51.0/docfence-0.51.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 define the contract. An exact conformance declaration is useful precisely because it says less than a trust verdict—and can be tested reliably.