XAdES

Short definition

XAdES (XML Advanced Electronic Signatures) is the ETSI standard for electronic signatures in XML documents, published as EN 319 132. XAdES builds on W3C XMLDSig (XML Digital Signature) and extends it with the timestamping and validation data required for eIDAS conformance.

Typical use cases: XML invoices (XRechnung, Peppol BIS Billing 3.0), XML-based e-government submissions, SEPA XML payment files with mandatory signatures, and structured documents in vertical industries (healthcare, logistics).

Three signature types

XMLDSig (and therefore XAdES) places the signature in three possible positions relative to the signed content:

Type	Description	Typical use
Enveloped	<Signature> sits inside the signed XML document	invoices, individual documents
Enveloping	the signed XML sits inside the signature container	transport containers
Detached	signature and signed XML live in separate documents	manifest signatures, multi-file signatures

For a signed XRechnung the usual choice is enveloped — the signature is part of the same XML stream and travels with the document.

Profiles as in PAdES and CAdES

XAdES defines the same baseline profiles as PAdES/CAdES:

• XAdES-B-B (Basic) — signature + certificate
• XAdES-B-T — plus timestamp over the signature
• XAdES-B-LT — plus OCSP/CRL validation data
• XAdES-B-LTA — plus archive timestamp for long-term validity

All profiles are eIDAS-compatible and — with a qualified certificate and a QSCD — can carry a QES.

XAdES and XRechnung

Pure XRechnung XML is typically not signed — integrity flows from the transport path (Peppol, protected channel) and organisational archiving. In regulated industries or for audit-safe archives, however, a XAdES-B-LT signature at the root element can be useful to cryptographically prove immutability.

Important: the EN 16931 validation must not fail because of the added <Signature> element. Validators usually ignore the signature block correctly, as long as it sits in the right place (inside <Invoice> or after the root element, depending on the CIUS rule).

Canonicalization — the tricky part

Unique characteristic of XML signatures: before hashing, the XML must be put into a canonical form so that identical content with different formatting (whitespace, namespaces, attribute order) yields the same hash. XAdES typically uses:

• Canonical XML 1.0 (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
• Canonical XML 1.1 (http://www.w3.org/2006/12/xml-c14n11)
• Exclusive Canonical XML (http://www.w3.org/2001/10/xml-exc-c14n#) — important for nested signatures

Wrong canonicalization is the most frequent reason a correctly produced signature fails verification on the receiver side.

Creating XAdES signatures with the Dokmatiq API

# Sign an XRechnung XML (enveloped, XAdES-B-LT)
curl -X POST https://api.dokmatiq.com/v1/sign/xades \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@invoice.xml" \
  -F "certificate=@signing.p12" \
  -F "passphrase=..." \
  -F "profile=XAdES-B-LT" \
  -F "mode=enveloped" \
  -o invoice-signed.xml

The API picks the appropriate canonicalization automatically, embeds timestamps via the configured TSA and validates the result against the EN 319 132 Schematron before returning it.

Verifying a signature

curl -X POST https://api.dokmatiq.com/v1/sign/xades/verify \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  --data-binary "@invoice-signed.xml"

Response: profile, canonicalization, certificate chain, signing time, any post-signature modifications.

XAdES, PAdES, CAdES — when to use which

• XAdES — data is XML (XRechnung, SEPA XML, e-government filings)
• PAdES — data is PDF (ZUGFeRD, contracts, signed reports)
• CAdES — everything else (ZIP, binary formats, ASiC containers)

For ZUGFeRD PDFs, PAdES is the correct choice — even though there is XML inside; the outer PDF is the signed object.

Common pitfalls

1. Wrong canonicalization — the receiver expects a different algorithm → signature fails despite an internally correct hash
2. Whitespace shift after signing — any formatting step after signing invalidates the signature
3. Signature in the wrong location — some CIUS (e.g. for Peppol) only allow <Signature> in specific child elements
4. Missing timestamps — without XAdES-B-T or higher, the signature is no longer verifiable after the certificate expires