Altova StyleVision 2024 Enterprise Edition

Im Dialogfeld "XML-Signatureinstellungen" (Abbildung unten) können Sie das Standardzertifikat/-Passwort definieren, das für die Signatur verwendet werden soll, wo die Signatur platziert werden soll, Transformationsoptionen, ob die Zertifikatschlüsselinformationen mit der XML-Datei gespeichert werden sollen, usw. Die einzelnen Einstellungen werden im Folgenden erläutert.

 

XMLSignatureSettings

 

 

Authentifizierungsmethode: Zertifikat oder Passwort

Die Signatur kann auf einem Zertifikat oder einem Passwort basieren. Wählen Sie das Optionsfeld für die gewünschte Methode aus.

 

Zertifikat: Klicken Sie auf die Schaltfläche Auswählen und navigieren Sie zum gewünschten Zertifikat. Das ausgewählte Zertifikat muss einen privaten Schlüssel (private key) haben. Die Signatur wird anhand des privaten Schlüssels des Zertifikats generiert. Zur Überprüfung der Signatur muss Zugriff auf das Zertifikat (oder eine Public-Key-Version davon) bestehen. Der öffentliche Schlüssel (public key) des Zertifikats dient zur Überprüfung der Signatur. Nähere Informationen über Zertifikate finden Sie im Abschnitt Arbeiten mit Zertifikaten. Alternativ dazu können die Daten des Zertifikatschlüssels mit der Signatur gespeichert werden. Aktivieren Sie dazu das Kontrollkästchen Keyinfo anhängen am unteren Rand des Dialogfelds. In diesem Fall wird kein Zertifikat zur Überprüfung der Signatur referenziert; die Schlüsselinformationen werden mit der verwendeten Signatur gespeichert. Anmerkung: Die XML-Signaturfunktion von StyleVision unterstützt nur Zertifikate vom Typ RSA-SHA1 und DSA-SHA1.

Passwort: Geben Sie ein Passwort mit einer Länge von fünf bis 16 Zeichen ein. Dieses Passwort wird später benötigt, um die Signatur zu überprüfen. Alternativ dazu kann das Passwort mit der SPS-Datei gespeichert werden. In diesem Fall wird die Überprüfung direkt ausgeführt, ohne dass der Benutzer in der Authentic View-Ansicht aufgefordert wird, ein Passwort anzugeben.

 

Das von Ihnen definierte Zertifikat/Passwort wird als Standardzertifikat/-passwort für die Signatur verwendet.

 

Transformationen

Die XML-Daten werden transformiert und das Ergebnis der Transformation wird zur Erstellung der Signatur verwendet. Sie können den Kanonisierungsalgorithmus, der auf die XML-Daten der Datei (den SignedInfo-Inhalt) anzuwenden ist, definieren, bevor die Signatur berechnet wird. Im Folgenden einige wichtige Unterschiede zwischen den Algorithmen:

 

Canonical XML mit oder ohne Kommentare: Wenn Kommentare bei der Berechnung der Signatur einbezogen werden, so führt jede Änderung an den Kommentaren in den XML-Daten zu einem Fehler bei der Überprüfung der Signatur. Im anderen Fall dürfen Kommentare nach der Signierung des Dokuments geändert oder hinzugefügt werden, ohne dass die Signatur dadurch ungültig wird. Die Option Kommentare steht für "detached", also separate Signaturen, zur Verfügung und ist bei "enveloped" Signaturen deaktiviert.

Base64: Das Root- (oder Dokument-) Element des XML-Dokuments wird als Base64-kodiert betrachtet und in seiner Binärform gelesen. Wenn das Root-Element nicht in Base64 kodiert ist, wird ein Fehler zurückgegeben oder das Element als leer gelesen, je nachdem, welcher Elementtyp verwendet wird.

Keine: Es wird keine Transformation durchgeführt und die XML-Daten aus der auf der Festplatte gespeicherten Binärdatei werden direkt an die Signaturüberprüfung übergeben. Alle späteren Änderungen an den Daten führen dazu, dass die Signatur nicht verifiziert werden kann. Wenn allerdings das Kontrollkästchen Whitespaces entfernen aktiviert ist, so werden alle Whitespace-Zeichen entfernt und Änderungen an Whitespace-Zeichen werden bei der Signaturüberprüfung ignoriert. Ein grundlegender Unterschied zwischen der Option Keine und einer der Canonical-Optionen ist, dass bei der Kanonisierung ein XML-Datenstrom erzeugt wird, in dem einige Unterschiede wie z.B. die Reihenfolge der Attribute normalisiert wird. Als Folge davon werden Änderungen wie eine andere Attributreihenfolge bei einer Kanonisierungstransformation normalisiert (sodass die Signatur verifiziert werden kann), während eine solche Änderung berücksichtigt wird, wenn keine Transformation durchgeführt wird (d.h. die Signatur kann nicht verifiziert werden). Beachten Sie allerdings, dass standardmäßig eine Kanonisierung erfolgt, wenn die Signatur (mittels enveloped) eingebettet wird. Die XML-Daten werden also in ihrem aktuellen Zustand (d.h. ohne Transformation) verwendet, wenn die Signatur "detached" ist, wenn Keine ausgewählt ist und wenn die Option Whitespaces entfernen deaktiviert ist.

 

Platzierung der Signatur

Die Signatur kann in die XML-Datei platziert oder als separate Datei erstellt werden. Es stehen die folgenden Optionen zur Verfügung:

 

Enveloped: Das Signaturelement wird als das letzte Child-Element des Root (Dokument)-Elements erstellt.

Detached: Die XML-Signatur wird in Form einer separaten Datei erstellt. In diesem Fall können Sie die Dateierweiterung der Signatur definieren und festlegen ob: (i) die Erweiterung an den Namen der XML-Datei angehängt werden soll (z.B. test.xml.xsig) oder (ii) ob die Erweiterung die XML-Erweiterung der Datei ersetzen soll (z.B. test.xsig). Außerdem können Sie festlegen, ob die Referenz auf die XML-Datei in der Signaturdatei ein relativer oder absoluter Pfad sein soll.

 

Schlüsselinformationen anhängen

Die Option KeyInfo anhängen steht zur Verfügung, wenn die Signatur auf einem Zertifikat basiert. Wenn die Signatur auf einem Passwort basiert, steht sie nicht zur Verfügung.

 

Wenn die Option aktiv ist, werden die Daten des öffentlichen Schlüssels in die Signatur platziert. Im anderen Fall werden die Schlüsselinformationen nicht in die Signatur inkludiert. Der Vorteil bei der Inkludierung der Schlüsselinformationen ist, dass das Zertifikat selbst (insbesondere die Daten des öffentlichen Schlüssels) für die Überprüfung nicht benötigt werden (da die Schlüsselinformationen ja in der Signatur vorhanden sind).

 

© 2018-2024 Altova GmbH