Release note · August 6, 2026

A signature has an order

An XML package signature is not a bag of familiar element names. Its core grammar fixes the direct order of the elements that give a signature its meaning. DocFence 0.60 makes that order part of the recognized OPC signature boundary before it records package-signature or declared-coverage evidence.

The direct grammar matters

ECMA-376 Open Packaging Conventions §10.5.1 requires a Digital Signature XML Signature part to be schema-valid against the XMLDSIG and OPC signature schemas. The XMLDSIG core schema begins a signature with this direct sequence:

ds:Signature
  ds:SignedInfo
  ds:SignatureValue
  ds:KeyInfo?       # optional
  ds:Object*        # zero or more

Its SignedInfo child has an equally fixed sequence:

ds:SignedInfo
  ds:CanonicalizationMethod
  ds:SignatureMethod
  ds:Reference+

Before 0.60, DocFence counted the required elements but did not insist on their direct sequence. A reordered or stray element could therefore retain a recognizable-looking inventory even though it was not the XMLDSIG structure that OPC requires.

A bounded grammar check

DocFence now requires those two direct sequences. At this boundary SignedInfo and SignatureValue may carry only their optional Id attribute; SignatureValue cannot contain child XML; and SignatureMethod/@Algorithm must be present and nonblank.

This remains intentionally smaller than full schema validation. DocFence does not validate base64 lexical content, method parameters, KeyInfo or application-defined Object payloads, reference digests, XMLDSIG cryptography, certificates, revocation, signer identity, or trust. It checks the stored grammar needed before a bounded inventory can say that it recognized a signature part.

version: 1
rules:
  require_no_package_digital_signatures: true
  no_package_digital_signature_changes: true

Evidence and use

The 70-test suite covers a missing SignatureMethod/@Algorithm, reordering and unexpected direct Signature and SignedInfo children, nested and extra-attribute SignatureValue markup, plus permitted Id attributes. Across the 29 DOCX fixtures in the public OOXML Signature Security artifacts, all 21 parseable XML signature roots use these sequences; their public profiles remain identical to 0.59.

Main and tagged CI passed. Two independent epoch-fixed builds were byte-identical; anonymous downloads of the published wheel and source distribution matched those artifacts byte-for-byte. SHA-256: wheel e1431e08fcffb9ce84cdb624ca741d0d0a81c52523063546c9dade0afbcd9571; source distribution 4b8dd4141a4573d450de9e69e9c56c5122289979eaa93a123d68b05b9f1a28cd.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.60.0/docfence-0.60.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 explain the direct grammar and its limits. Recognition should begin with the structure a signature actually declares.