XAdES

Kurzdefinition

XAdES (XML Advanced Electronic Signatures) ist der ETSI-Standard für elektronische Signaturen in XML-Dokumenten, veröffentlicht als EN 319 132. XAdES baut auf W3C XMLDSig (XML Digital Signature) auf und ergänzt es um die für eIDAS-Konformität nötigen Zeitstempel- und Validierungsdaten.

Typisches Einsatz­szenario: XML-Rechnungen (XRechnung, Peppol BIS Billing 3.0), XML-basierte Anträge im E-Government, SEPA-XML-Zahlungs­dateien mit Signatur­pflicht, sowie strukturierte Dokumente in vertikalen Branchen (Healthcare, Logistik).

Drei Signaturtypen

XMLDSig (und damit XAdES) kennt drei Positionierungen der Signatur relativ zum signierten Inhalt:

Typ	Beschreibung	Typischer Einsatz
Enveloped	<Signature> liegt im signierten XML-Dokument	Rechnungen, einzelne Dokumente
Enveloping	Das signierte XML liegt im Signatur­container	Transport-Container
Detached	Signatur und signiertes XML liegen in getrennten Dokumenten	Manifest-Signaturen, Multi-Datei-Signaturen

Für eine signierte XRechnung nutzt man in aller Regel enveloped — die Signatur ist Teil desselben XML-Stroms und wandert mit dem Dokument.

Profile wie bei PAdES und CAdES

XAdES definiert die gleichen Baseline-Profile wie PAdES/CAdES:

• XAdES-B-B (Basic) — Signatur + Zertifikat
• XAdES-B-T — plus Zeitstempel über die Signatur
• XAdES-B-LT — plus OCSP/CRL-Validierungsdaten
• XAdES-B-LTA — plus Archiv-Zeitstempel für Langzeit-Gültigkeit

Alle Profile sind eIDAS-kompatibel und können — mit qualifiziertem Zertifikat und QSCD — eine QES tragen.

XAdES und XRechnung

Die reine XRechnung-XML wird üblicherweise nicht signiert — die Integrität folgt aus dem Transportweg (Peppol, geschützter Kanal) und der organisatorischen Archivierung. In regulierten Branchen oder bei revisions­sicheren Archiven kann jedoch eine XAdES-B-LT-Signatur am Wurzelelement nützlich sein, um die Unveränderbarkeit kryptografisch zu belegen.

Wichtig: Die EN-16931-Validierung darf durch das zusätzliche <Signature>-Element nicht scheitern. Validatoren ignorieren den Signatur­block in der Regel korrekt, solange er am richtigen Platz steht (innerhalb von <Invoice> oder nach dem Wurzelelement, je nach CIUS-Regel).

Canonicalization — der heikle Teil

Einzigartiges Merkmal von XML-Signaturen: Vor dem Hashen muss das XML in eine kanonische Form gebracht werden, damit identischer Inhalt mit unterschiedlicher Formatierung (Whitespace, Namespaces, Attribut-Reihenfolge) denselben Hash ergibt. XAdES nutzt typisch:

• 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#) — wichtig bei geschachtelten Signaturen

Falsche Kanonisierung ist der häufigste Grund, warum eine korrekt erzeugte Signatur beim Empfänger nicht verifiziert werden kann.

Mit der Dokmatiq-API XAdES-Signaturen erzeugen

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

Die API wählt automatisch die passende Canonicalization, bettet Zeitstempel über die konfigurierte TSA ein und validiert das Ergebnis gegen EN 319 132 Schematron, bevor es zurückgegeben wird.

Signatur prüfen

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

Antwort: Profil, Canonicalization, Zertifikats­kette, Signatur­zeitpunkt, etwaige nachträgliche Änderungen.

XAdES, PAdES, CAdES — wann welches?

• XAdES — Daten liegen als XML vor (XRechnung, SEPA-XML, E-Government-Anträge)
• PAdES — Daten liegen als PDF vor (ZUGFeRD, Verträge, signierte Berichte)
• CAdES — alles andere (ZIP, Binärformate, ASiC-Container)

Bei ZUGFeRD-PDFs ist PAdES die richtige Wahl — auch wenn innen XML liegt; das äußere PDF ist das signierte Objekt.

Häufige Stolpersteine

1. Falsche Canonicalization — Empfänger rechnet mit anderem Algorithmus → Signatur scheitert, obwohl Hash intern korrekt
2. Whitespace-Verschiebung nach Signatur — jeder Formatting-Schritt nach der Signatur invalidiert sie
3. Signatur an falscher Stelle — manche CIUS (z.B. für Peppol) erlauben die <Signature> nur in bestimmten Kind-Elementen
4. Vergessene Zeitstempel — ohne XAdES-B-T oder höher ist die Signatur nach Zertifikats­ablauf nicht mehr prüfbar