docx/digital-signature-detection

Detect whether a .docx package carries an ECMA-376 Part 2 digital signature.

Library verdicts: python-docx: — docxjs: —

Metadata

Feature iddocx/digital-signature-detection
Formatdocx
Categorypackaging
Spececma-376-5-part-2 § 12

XPath assertions

ID / partPredicateXPathpython-docxdocxjs
origin-sigs-marker-present
exist
The package MUST carry a zero-byte `_xmlsignatures/origin.sigs` marker part. This is how Word and the ECMA-376 Part 2 origin-relationship pattern signal 'this package is signed' at the OPC level.
signature-xml-part-present
exist
At least one signature XML part is present. The conventional name is `sig1.xml`; multi-signature packages add `sig2.xml`, etc.
signature-element-present
_xmlsignatures/sig1.xml
exist
The signature part MUST contain a root XMLDSIG <Signature> element (http://www.w3.org/2000/09/xmldsig#).
/ds:Signature

Render assertions

No render assertions declared.

Manifest (expanded)

{
  "$schema": "../manifest.schema.json",
  "id": "docx/digital-signature-detection",
  "title": "Digital signature detection",
  "format": "docx",
  "category": "packaging",
  "summary": "Detect whether a .docx package carries an ECMA-376 Part 2 digital signature.",
  "roles": [
    "authoring"
  ],
  "spec": {
    "source": "ecma-376-5-part-2",
    "clause": "12",
    "notes": "An OOXML digital signature lives in a package-level `_xmlsignatures/` folder. A zero-byte `_xmlsignatures/origin.sigs` marker part is the canonical entry point; `_xmlsignatures/_rels/origin.sigs.rels` then holds relationships of type `http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/signature` whose targets are `_xmlsignatures/sigN.xml` parts containing XMLDSIG <Signature> elements. This manifest is detection-only: we check for the origin marker and for at least one <Signature> element. Authoring (producing a cryptographically valid signature) is out of scope — it requires X509 credentials and XMLDSIG canonicalisation which none of the loadfix libraries currently implement."
  },
  "fixtures": {
    "machine": "docx/digital-signature-detection"
  },
  "assertions": [
    {
      "id": "origin-sigs-marker-present",
      "kind": "zip_contains_path",
      "path": "_xmlsignatures/origin.sigs",
      "must": "exist",
      "description": "The package MUST carry a zero-byte `_xmlsignatures/origin.sigs` marker part. This is how Word and the ECMA-376 Part 2 origin-relationship pattern signal 'this package is signed' at the OPC level."
    },
    {
      "id": "signature-xml-part-present",
      "kind": "zip_contains_path",
      "path": "_xmlsignatures/sig1.xml",
      "must": "exist",
      "description": "At least one signature XML part is present. The conventional name is `sig1.xml`; multi-signature packages add `sig2.xml`, etc."
    },
    {
      "id": "signature-element-present",
      "part": "_xmlsignatures/sig1.xml",
      "namespaces": {
        "ds": "http://www.w3.org/2000/09/xmldsig#"
      },
      "xpath": "/ds:Signature",
      "must": "exist",
      "description": "The signature part MUST contain a root XMLDSIG <Signature> element (http://www.w3.org/2000/09/xmldsig#)."
    }
  ]
}

Fixture

Download digital-signature-detection.docx (38.1 KB)

Reference preview

No rendered reference is available for this case.

Spec notes

An OOXML digital signature lives in a package-level `_xmlsignatures/` folder. A zero-byte `_xmlsignatures/origin.sigs` marker part is the canonical entry point; `_xmlsignatures/_rels/origin.sigs.rels` then holds relationships of type `http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/signature` whose targets are `_xmlsignatures/sigN.xml` parts containing XMLDSIG <Signature> elements. This manifest is detection-only: we check for the origin marker and for at least one <Signature> element. Authoring (producing a cryptographically valid signature) is out of scope — it requires X509 credentials and XMLDSIG canonicalisation which none of the loadfix libraries currently implement.