From 8e4afd4a605f811bc4798fe736e0afb41ea45d18 Mon Sep 17 00:00:00 2001 From: gregor Date: Fri, 27 Aug 2004 11:28:33 +0000 Subject: =?UTF-8?q?4=20Beispiele=20f=C3=BCr=20XML-Signaturpr=C3=BCfung=20h?= =?UTF-8?q?inzugef=C3=BCgt.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@190 d688527b-c9ab-4aba-bd8d-4036d912da1d --- spss.handbook/handbook/usage/usage.html | 307 ++++++++++++++++++++++++++++++-- 1 file changed, 291 insertions(+), 16 deletions(-) (limited to 'spss.handbook') diff --git a/spss.handbook/handbook/usage/usage.html b/spss.handbook/handbook/usage/usage.html index 078c7b81f..38844c786 100644 --- a/spss.handbook/handbook/usage/usage.html +++ b/spss.handbook/handbook/usage/usage.html @@ -34,15 +34,17 @@
  • Prüfung einer CMS-Signatur
      -
    1. Einfaches Beispiel
      2. -
    2. Erweitertes Beispiel
      3. +
    3. Einfaches Beispiel
      4. +
    4. Erweitertes Beispiel
    • -
  • Prüfung einer XML-Signatur -
      -
    1. Einfaches Beispiel
      2. -
    2. Erweitertes Beispiel
      3. -
    +
  • Prüfung einer XML-Signatur
      +
    1. Einfaches Beispiel
      2. +
    2. Erweitertes Beispiel
      3. +
    3. Prüfung eines XMLDSIG-Manifests
      4. +
    4. Ergänzungsobjekte
      5. +
    5. Signatur-Manifest des Security-Layers
      6. +
    • @@ -92,7 +94,7 @@ </CreateTransformsInfoProfile> Zu jedem Daten-Objekt können optional Transformationen (z.B. XPath, XSLT, Base64-Decodierung, etc.) angegeben werden. Werden - wie hier im Beispiel - keine Transformationen angegeben, so muss zumindest der MIME-Type der zu signierenden Daten spezifiziert werden.

    Response
    -

    CreateXMLSignatureRequest.Simple.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der die dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.

    +

    CreateXMLSignatureRequest.Simple.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass die dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.

    <CreateXMLSignatureResponse
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <SignatureEnvironment>
        <dsig:Signature Id="signature-1-1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
          <dsig:SignedInfo>
@@ -289,7 +291,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
    CreateSignatureEnvironment enthält das XML-Dokument, in das die zu erstellende Signatur integriert werden soll. In diesem Beispiel wird dieses Dokument mit Hilfe von LocRefContent referenziert, d. h. MOA SS wird versuchen, die darin enthaltene URL aufzulösen, um das XML-Dokument zu erhalten. Alternativ könnte auch Base64Content (explizite Angabe des XML-Dokuments in base64 kodierter Form) oder XMLContent (direkte Angabe des XML-Dokuments im Request) verwendet werden.
    
 
    CreateSignatureLocation enthält die Angabe jener Stelle, an der die Signatur in das XML-Dokument eingesetzt werden soll. Der Inhalt dieses Elements bezeichnet mittels XPath-Ausdruck das Parent-Element der Signatur, der Wert des Attributs CreateSignatureLocation/@Index enthält den Offset innerhalb dieses Parent-Elements. Betrachten Sie zur Verdeutlichung das XML-Dokument XMLDocument.xml, in das die Signatur integriert werden soll: Die Signatur soll unmittelbar nach dem zweiten doc:Paragraph Element in das XML-Dokument eingefügt werden. Der Inhalt von CreateSignatureLocation (/doc:XMLDocument) selektiert das zukünftige Parent-Element der Signatur, also doc:XMLDocument. Das Attribut Index enthält deshalb den Wert 4 (und nicht etwa 2 oder 3), da erstens bei 0 zu zählen begonnen wird, und zweitens auch die Text-Knoten, die lediglich Whitespace enthalten, für diesen Offset zählen (um diese Textknoten erkennen zu können, müssen Sie das XML-Dokument in einem Text-Editor öffnen). Beachten Sie weiters, dass  das im XPath-Ausdruck verwendete Namespace-Prefix doc im Kontext des Elements CreateSignatureLocation bekannt sein muss. Deshalb enthält dieses Element auch die entsprechende Namespace-Deklaration (xmlns:doc="urn:document").
    
 
    Response
    
-
    CreateXMLSignatureRequest.Refs.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der die  dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    CreateXMLSignatureRequest.Refs.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass  die  dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
 
     <CreateXMLSignatureResponse 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -476,7 +478,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
    Abschließend soll, wie in der Spezifikation der XSLT-Transformation empfohlen, eine Kanonisierungstransformation angewendet werden. Damit können Unterschiede im Output unterschiedlicher XSLT-Engines, wie sie in der Praxis vorkommen, abgefangen werden. Beachten Sie, dass als Voraussetzung dazu die Output-Methode im Stylesheet auf xml festgelegt werden muss (<xsl:output method="xml">), denn nur XML-Output kann anschließend kanonisiert werden. Das Attribut dsig:Transform/@Algorithm ist für die Canonical XML Transformation auf den Wert http://www.w3.org/TR/2001/REC-xml-c14n-20010315 zu setzen. Die Transformation benötigt keine Transformationsparameter.
    
 
    Das Ergebnis der drei hintereinandergeschalteten Transformationen, welches der Hashwert-Berechnung zufließt, finden Sie hier. 
    
 
    Response
    
-
    CreateXMLSignatureRequest.Transforms.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der die  dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    CreateXMLSignatureRequest.Transforms.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass  die  dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
 
     <CreateXMLSignatureResponse 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -523,7 +525,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
    Die zweite dsig:Reference wurde auf Grund des zweiten DataObjectInfo im Request erstellt. Man erkennt auch hier gut, dass die URL auf die Referenz-Eingangsdaten (Wert des Attributs dsig:Reference/@URI) aus DataObject/@Reference übernommen und die drei Transformationen wie im Request angegeben eingefügt wurden. 
    
 
    2.1.1.4 Ergänzungsobjekte 
    
 
    Request
    
-
    Dieses Beispiel (CreateXMLSignatureRequest.Supplements.xml) erläutert die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem DataObject) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit CreateSignatureEnvironment). Es muss dann angegeben werden, wenn in einem zu signierenden Datum bzw. im Einfügedokument auf Daten per Referenz verwiesen wird, diese referenzierten Daten aber von MOA SS nicht aufgelöst werden können. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.
    
+
    Dieses Beispiel (CreateXMLSignatureRequest.Supplements.xml) stellt die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem DataObject) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit CreateSignatureEnvironment). Es muss dann angegeben werden, wenn in einem zu signierenden Datum bzw. im Einfügedokument auf Daten per Referenz verwiesen wird, diese referenzierten Daten aber von MOA SS nicht aufgelöst werden können. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.
    
 
     <CreateXMLSignatureRequest 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -588,7 +590,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
    Response
    
 
    CreateXMLSignatureRequest.Supplements.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
    
 
    2.1.2 Prüfung einer CMS-Signatur
    
-
    2.1.2.1 Einfaches Beispiel
    
+
    2.1.2.1 Einfaches Beispiel
    
 
    Request
    
 
    Dieses Beispiel (VerifyCMSSignatureRequest.Simple.xml) ist ein einfacher Request zur Prüfung einer CMS-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der nachfolgende Ausschnitt aus dem Request aus Gründen der Übersichtlichkeit gekürzt wurde.
    
 
    @@ -601,7 +603,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
    Der Request enthält zunächst in CMSSignature die zu prüfende CMS-Signatur, und zwar in base64 kodierter Form. In diesem Beispiel wird davon ausgegangen, dass es sich dabei um eine Enveloping Signature handelt, d. h. dass die signierten Daten als Teil der CMS-Struktur vorhanden sind. Für die Behandlung einer Detached Signature sei auf das nächste Beispiel verwiesen.
    
 
    Abschließend enthält der Request in TrustProfileID die Angabe des Vertrauensprofils, gegen das die Vertrauensprüfung des Zertifikats durchgeführt werden soll. Ein Vertrauensprofil mit dem angegebenen Namen muss in der für die Signaturprüfung verwendeten Instanz von MOA SP eingerichtet sein. 
    
 
    Response
    
-
    VerifyCMSSignatureRequest.Simple.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der die  dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    VerifyCMSSignatureRequest.Simple.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass  die  dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
 
     <VerifyCMSSignatureResponse 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -637,7 +639,7 @@ O=A-Trust Ges. f
 
    Abschließend enthält die Response mit CertificateCheck/Code das Resultat der Prüfung des Signatorzertifikats. Zunächst prüft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugehörigen Vertrauensprofil konfigurierten sog. Trust Anchor gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält Code den Wert 1, d. h. MOA SP konnte die oben erläuterte Zertifikatskette nicht bilden. Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
    
 
    2.1.2.2 Erweitertes Beispiel
    
 
    Request
    
-
    Dieses erweiterte Bespiel zur Prüfung einer CMS-Signatur (VerifyCMSSignatureRequest.Extended.xml) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer Detached Signature, d. h. einer Signatur in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. 
    
+
    Dieses erweiterte Beispiel zur Prüfung einer CMS-Signatur (VerifyCMSSignatureRequest.Extended.xml) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer Detached Signature, d. h. einer Signatur in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. 
    
 
     <VerifyCMSSignatureRequest 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -652,9 +654,282 @@ O=A-Trust Ges. f
   <TrustProfileID>Test-Signaturdienste</TrustProfileID>
 </VerifyCMSSignatureRequest>
 
    
-
     Liegt eine zu prüfende CMS-Signatur vor, die von mehreren Unterzeichnenden signiert worden ist, kann das Attribut VerifyCMSSignatureRequest/@Signatories verwendet werden, um jene Unterzeichnenden auszuwählen, deren Unterschriften von MOA SP geprüft werden sollen. Der Default-Wert für dieses optionale Attribut ist 1. Soll nicht die Unterschrift allein des ersten Unterzeichnenden geprüft werden, muss das Attribut angegeben werden. Es enthält dann eine oder mehrere Ganzzahlwerte, getrennt durch Leerzeichen. Jede Ganzzahl bezeichnet einen Unterzeichnenden, wobei die Reihenfolge der Auflistung der Unterzeichner in der CMS-Signatur entspricht. Der Wert "1 3" würde beispielsweise aussagen, dass MOA SP die Unterschrift des ersten sowie des dritten Unterzeichnenden prüfen soll.
    
-
      
    
+
     Liegt eine zu prüfende CMS-Signatur vor, die von mehreren Unterzeichnenden signiert worden ist, kann das Attribut VerifyCMSSignatureRequest/@Signatories verwendet werden, um jene Unterzeichnenden auszuwählen, deren Unterschriften von MOA SP geprüft werden sollen. Der Default-Wert für dieses optionale Attribut ist 1. Soll nicht die Unterschrift allein des ersten Unterzeichnenden geprüft werden, muss das Attribut explizit angegeben werden. Es enthält dann eine oder mehrere Ganzzahlwerte, getrennt durch Leerzeichen. Jede Ganzzahl bezeichnet einen Unterzeichnenden, wobei die Reihenfolge der Auflistung der Unterzeichner in der CMS-Signatur entspricht. Der Wert "1 3" würde beispielsweise aussagen, dass MOA SP die Unterschrift des ersten sowie des dritten Unterzeichnenden prüfen soll.
    
+
    Mit dem optionalen Element DateTime kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp dateTime. Enthält der angegebene Zeitpunkt keinen Zeitzonen-Offset zur UTC, wird der Zeitpunkt als lokale Zeit des Servers interpretiert, auf dem MOA SP läuft. Wird DateTime nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs SigningTime). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. 
    
+
    Das optionale Element DataObject muss dann angegeben werden, wenn eine Detached Signature geprüft werden soll, d. h. wenn in der CMS-Signatur die signierten Daten nicht mitkodiert sind. In DataObject/Content/Base64Content sind in einem solchen Fall diese Daten in base64 kodierter Form bereit zu stellen.
    
+
    Response
    
+
    VerifyCMSSignatureRequest.Extended.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
    
+
    2.1.3 Prüfen einer XML-Signatur
    
+
    2.1.3.1 Einfaches Beispiel
    
+
    Request
    
+
    VerifyXMLSignatureRequest.Simple.xml ist ein einfacher XML-Request zur Prüfung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    +<VerifyXMLSignatureRequest xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#">
+  <VerifySignatureInfo>
+    <VerifySignatureEnvironment>
+      <XMLContent>
+        <dsig:Signature Id="signature-1-1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+          <dsig:SignedInfo>
+            <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
+            <dsig:SignatureMethod 
+              Algorithm="http://www.buergerkarte.at/namespaces/ecdsa/200206030#ecdsa-sha1"/>
+            <dsig:Reference Id="reference-1-1" URI="#xpointer(id('signed-data-1-1-1')/node())">
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>tLODyeiWFbAkQKwhrR23jtcgu4k=</dsig:DigestValue>
+            </dsig:Reference>
+          </dsig:SignedInfo>
+          <dsig:SignatureValue>...</dsig:SignatureValue>
+          <dsig:KeyInfo>...</dsig:KeyInfo>
+          <dsig:Object Id="signed-data-1-1-1">Diese Daten werden signiert.</dsig:Object>
+        </dsig:Signature>
+      </XMLContent>
+    </VerifySignatureEnvironment>
+
    
+
    Das Element VerifySignatureEnvironment enthält jenes XML-Dokument, das die zu prüfende XML-Signatur enthält. Auch hier stehen eine Reihe von Möglichkeiten zur Verfügung, dieses XML-Dokument anzugeben. Im Beispiel wurde das Element XMLContent verwendet; alternativ stehen die Elemente Base64Content und LocRefContent bzw. gleichwertig zu LocRefContent das Attribut Reference zur Verfügung.
    
+
    Im konkreten Beispiel enthält das angegebene XML-Dokument direkt als Root-Element die zu prüfende Signatur (dsig:Signature). Es handelt sich dabei um eine Enveloping Signature, d. h. die signierten Daten sind in einem dsig:Object als Teil der XML-Struktur der Signatur kodiert. Tatsächlich signiert ist hier die Zeichenkette Diese Daten werden signiert.
    
+
    +    <VerifySignatureLocation
+      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">/dsig:Signature</VerifySignatureLocation>
+  </VerifySignatureInfo>
+
    
+
    Das Element VerifySignatureLocation enthält als Text den XPath-Ausdruck zur Selektion der XML-Signatur innerhalb des zu prüfenden XML-Dokuments. Die Auswertung des XPath-Ausdrucks muss genau ein Element dsig:Signature ergeben. Bitte beachten Sie, dass im Kontext des Elements VerifySignatureLocation alle im XPath-Ausdruck verwendeten Namespace-Präfixe bekannt sein müssen (hier das Präfix dsig). 
    
+
    +  <TrustProfileID>Test-Signaturdienste</TrustProfileID>
+</VerifyXMLSignatureRequest>
+
    
+
    Das Element TrustProfileID schließlich enthält den Bezeichner des Vertrauensprofils, gegen das die Zertifikatsprüfung von MOA SP durchgeführt wird. Ein Vertrauensprofil enthält die Zertifikate jene Zertifizierungsdiensteanbieter, denen als Aussteller von Signatorzertifikaten vertraut wird. Ein Vertrauensprofil mit dem gewählten Namen (hier Test-Signaturdienste) muss in der Konfiguration von MOA SP hinterlegt sein. 
    
+
    Response
    
+
    VerifyXMLSignatureRequest.Simple.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass die dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    +<VerifyXMLSignatureResponse
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  <SignerInfo>
+    <dsig:X509Data>
+      <dsig:X509SubjectName>CN=Test: Signaturdienst aller Kunden: ECDSA (P192v1),OU=Technik und Standards,
+      O=Stabsstelle IKT-Strategie des Bundes,C=AT</dsig:X509SubjectName>
+      <dsig:X509IssuerSerial>
+        <dsig:X509IssuerName>CN=Test CA - Signaturdienste,OU=Technik und Standards,
+        O=Stabstelle IKT-Strategie des Bundes,C=AT</dsig:X509IssuerName>
+        <dsig:X509SerialNumber>9</dsig:X509SerialNumber>
+      </dsig:X509IssuerSerial>
+      <dsig:X509Certificate>...</dsig:X509Certificate>
+      <PublicAuthority>
+        <Code>BKA-IKT</Code>
+      </PublicAuthority>
+    </dsig:X509Data>
+  </SignerInfo>
+
    
+
    Die Response enthält zunächst in SignerInfo/dsig:X509Data Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind. 
    
+
    dsig:X509SubjectName ist immer vorhanden und enthält den Namen des Signators. dsig:X509IssuerSerial ist ebenfalls immer vorhanden und enthält den Namen des Austellers des Signatorzertifikats (dsig:X509IssuerName) sowie die Seriennummer des Zertifikats (dsig:X509SerialNumber). Auch dsig:X509Certificate ist ist immer vorhanden und enthält das Signatorzertifikat in base64 kodierter Form. 
    
+
    Optional vorhanden  - in diesem Beispiel nicht ersichtlich - ist das inhaltslose Element QualifiedCertificate, und zwar dann, wenn es sich beim Signatorzertifikat um ein qualifiziertes Zertifikat handelt. Ebenfalls optional vorhanden ist schließlich das Element PublicAuthority, und zwar dann, wenn das Signatorzertifikat die österreichspezifische Zertifikatserweiterung Verwaltungseigenschaft aufweist. Ist in dieser Zertifikatserweiterung das Verwaltungskennzeichen mitkodiert, wird dieses Kennzeichen als Textinhalt des optionalen Elements PublicAuthority/Code geliefert.
    
+
    +  <SignatureCheck>
+    <Code>0</Code>
+  </SignatureCheck>
+
    
+
     Anschließend an SignerInfo enthält die Response mit SignatureCheck/Code das Resultat der kryptographischen Prüfung der Signatur. In unserem Beispiel ist dort der Wert 0 enthalten, d. h. die Signatur konnte erfolgreich validiert werden. Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
    
+
    +  <CertificateCheck>
+    <Code>0</Code>
+  </CertificateCheck>
+
    
+
    Abschließend enthält die Response mit CertificateCheck/Code das Resultat der Prüfung des Signatorzertifikats. Zunächst prüft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugehörigen Vertrauensprofil konfigurierten sog. Trust Anchor gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält Code den Wert 0, d. h. MOA SP konnte die Kette bilden, und alle Zertifikate der Kette sind gültig. Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
    
+
    2.1.3.2 Erweitertes Beispiel 
    
+
    Request
    
+
    Dieses erweiterte Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.Enveloped.xml) demonstriert die Prüfung einer Enveloped Signature, d. h. einer Signatur, die in ein XML-Dokument integriert ist, die Angabe des Prüfzeitpunkts sowie die Anweisung an MOA SP, in der Response die von der Signatur abgedeckten Daten zu retournieren.
    
+
    +<VerifyXMLSignatureRequest xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#">
+  <DateTime>2004-08-18T17:00:00+02:00</DateTime>
+
    
+
    Mit dem optionalen Element DateTime kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp dateTime. Enthält der angegebene Zeitpunkt keinen Zeitzonen-Offset zur UTC, wird der Zeitpunkt als lokale Zeit des Servers interpretiert, auf dem MOA SP läuft. Wird DateTime nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs SigningTime). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft.
    
+
    +  <VerifySignatureInfo>
+    <VerifySignatureEnvironment Reference="http://localhost:8080/referencedData/XMLDocument.signed.xml"/>
+    <VerifySignatureLocation xmlns:doc="urn:document"
+      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">/doc:XMLDocument/dsig:Signature</VerifySignatureLocation>
+  </VerifySignatureInfo>
+
    
+
    Das Element VerifySignatureEnvironment enthält in diesem Fall mit dem Attribut Reference eine Referenz auf das XML-Dokument (XMLDocument.signed.xml), das die zu prüfende Signatur beinhaltet. Als Textinhalt von VerifySignatureLocation ist ein XPath-Ausdruck angegeben, der die zu prüfende Signatur innerhalb des XML-Dokuments auswählt. Bitte beachten Sie, dass im Kontext des Elements VerifySignatureLocation alle im XPath-Ausdruck verwendeten Namespace-Präfixe bekannt sein müssen (hier die Präfixe doc und dsig). 
    
+
    +  <ReturnHashInputData/>
+  <TrustProfileID>Test-Signaturdienste</TrustProfileID>
+</VerifyXMLSignatureRequest>
+
    
+
    Durch Angabe des optionalen, leeren Elements Return HashInputData wird MOA SP angewiesen, im Response jene Daten zurückzuliefern, die von der Signatur abgedeckt sind, d. h. tatsächlich signiert wurden (siehe unten). Diese Information ist für die MOA SP verwendende Anwendung essentiell, da sie wissen muss, ob tatsächlich die von ihr geforderten Daten signiert wurden. Wird HashInputData im Request nicht angegeben, muss die Anwendung selbst die Signatur analysieren, um diese Information zu erhalten. 
    
 
    Response
    
+
    VerifyXMLSignatureRequest.Enveloped.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass die dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    +<VerifyXMLSignatureResponse 
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  <SignerInfo>
+    <dsig:X509Data>...</dsig:X509Data>
+  </SignerInfo>
+
    
+
    Die Response enthält zunächst in SignerInfo/dsig:X509Data Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind (siehe Einfaches Beispiel).
    
+
    +  <HashInputData>
+    <Base64Content>PGRvYzp...hNTERvY3VtZW50Pg==</Base64Content>
+  </HashInputData>
+
    
+
    Wurde im Request - so wie in diesem Beispiel - das Element ReturnHashInputData angegeben, enthält die Response nach SignerInfo für jede dsig:Reference in dsig:SignedInfo der XML-Signatur ein Element HashInputData, wobei die Reihenfolge der HashInputData-Elemente der Reihenfolge der dsig:Reference Element in dsig:SignedInfo der XML-Signatur entspricht. Der Inhalt wird dabei stets mittels Base64Content in base64-kodierter Form geliefert.
    
+
    +  <SignatureCheck>
+    <Code>0</Code>
+  </SignatureCheck>
+  <CertificateCheck>
+    <Code>0</Code>
+  </CertificateCheck>
+</VerifyXMLSignatureResponse>
+
    
+
    Die Elemente SignatureCheck und CertificateCheck enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe Einfaches Beispiel).
    
+
    2.1.3.3 Prüfung eines XMLDSIG-Manifests 
    
+
    Request
    
+
    Dieses  Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.XMLDSigManifest.xml) demonstriert die Prüfung eines in der zu XML-Signatur vorhandenden Manifests nach XMLDSig. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    +<VerifyXMLSignatureRequest
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  <VerifySignatureInfo>
+    <VerifySignatureEnvironment>
+      <XMLContent>
+        <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="signature-1-1">
+          <dsig:SignedInfo>
+            <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
+            <dsig:SignatureMethod 
+              Algorithm="http://www.buergerkarte.at/namespaces/ecdsa/200206030#ecdsa-sha1"/>
+            <dsig:Reference Type="http://www.w3.org/2000/09/xmldsig#Manifest" URI="#dsig-manifest-1-1">
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>nUUaW6OtcsNvV/QhqmkU2QXT1Mw=</dsig:DigestValue>
+            </dsig:Reference>
+          </dsig:SignedInfo>
+          <dsig:SignatureValue>315gCwZI...OXFwr+</dsig:SignatureValue>
+          <dsig:KeyInfo>...</dsig:KeyInfo>
+          <dsig:Object Id="signed-data-1-1-1">Diese Daten sind signiert.</dsig:Object>
+          <dsig:Object>
+            <dsig:Manifest Id="dsig-manifest-1-1">
+              <dsig:Reference Id="reference-1-1" URI="#xpointer(id('signed-data-1-1-1')/node())">
+                <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+                <dsig:DigestValue>EYxznGxNRAIcHQeUsj+zsK+uaHA=</dsig:DigestValue>
+              </dsig:Reference>
+            </dsig:Manifest>
+          </dsig:Object>
+        </dsig:Signature>
+      </XMLContent>
+    </VerifySignatureEnvironment>
+
    
+
    Das Element VerifySignatureEnvironment enthält als XMLContent die zu prüfende XML-Signatur. Man erkennt, dass sich die einzige dsig:Reference im dsig:SignedInfo der XML-Signatur auf ein Manifest nach XMLDSig bezieht (erkennbar am Attribut Type, das auf den Wert http://www.w3.org/2000/09/xmldsig#Manifest gesetzt ist). Im Response (siehe unten) werden wir deshalb ein eigenes Resultat für die Manifest-Prüfung erhalten.
    
+
    Das Manifest selbst ist in einem dsig:Object, also innerhalb der XML-Struktur der XML-Signatur kodiert. Es enthält eine dsig:Reference, welche sich auf die Zeichenkette Diese Daten sind signiert. bezieht.
    
+
    +    <VerifySignatureLocation>//dsig:Signature</VerifySignatureLocation>
+  </VerifySignatureInfo>
+  <TrustProfileID>Test-Signaturdienste</TrustProfileID>
+</VerifyXMLSignatureRequest>
+
    
+
    Das Element VerifySignatureLocation wählt die zu prüfende Signatur innerhalb des in VerifySignatureEnvironment angegebenen XML-Dokuments aus. Das Element TrustProfileID wählt das Vertrauensprofil aus, gegen das die Zertifikatsprüfung durchgeführt werden soll. 
    
+
    Response
    
+
    VerifyXMLSignatureRequest.XMLDSigManifest.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass die dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    +<VerifyXMLSignatureResponse 
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  <SignerInfo>
+    <dsig:X509Data>...</dsig:X509Data>
+  </SignerInfo>
+  <SignatureCheck>
+    <Code>0</Code>
+  </SignatureCheck>
+
    
+
    Die Response enthält zunächst in SignerInfo/dsig:X509Data Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind (siehe Einfaches Beispiel). Das Element SignatureCheck enthält das Resultat der kryptographischen Prüfung der Signatur (siehe Einfaches Beispiel).
    
+
    +  <XMLDSIGManifestCheck>
+    <Code>0</Code>
+    <Info>
+      <ReferringSigReference>1</ReferringSigReference>
+    </Info>
+  </XMLDSIGManifestCheck>
+
    
+
    Neu ist in dieser Response das an SignatureCheck anschließende Element XMLDSIGManifestCheck. Ein oder mehrere solche Elemente werden immer dann zurückgeliefert, wenn in dsig:SignedInfo der XML-Signatur dsig:Reference Elemente existieren, die sich auf ein Manifest nach XMLDSIG beziehen (siehe oben). Je solcher dsig:Reference enthält die Antwort ein korrespondierendes Element XMLDSIGManifestCheck, im konkreten Beispiel als eines.
    
+
    Das Element Code gibt das Ergebnis der durchgeführten Prüfung des XMLDSIG-Manifests an. In diesem Fall bedeutet 0, dass die Prüfung jeder dsig:Reference im dsig:Manifest (im konkreten Beispiel also genau einer dsig:Reference) erfolgreich durchgeführt werden konnte.  Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
    
+
    Das Element Info/ReferringSigReference enthält als Textinhalt die Nummer jenes dsig:Reference Elements in dsig:SignedInfo der XML-Signatur, welches auf das untersuchte Manifest nach XMLDSIG verweist, wobei mit 1 zu zählen begonnen wird.
    
+
    +  <CertificateCheck>
+    <Code>0</Code>
+  </CertificateCheck>
+</VerifyXMLSignatureResponse>
+
    
+
    Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).
    
+
    2.3.1.4 Ergänzungsobjekte 
    
+
    Dieses Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.Supplements.xml) demonstriert die Verwendung von Ergänzungsobjekten. Ein Ergänzungsobjekt betrifft entweder ein signiertes Datum (Zusammenhang mit einem dsig:Reference der XML-Signatur) oder jenes Dokument, in dem sich die zu prüfende XML-Signatur befindet (Zusammenhang mit VerifySignatureEnvironment). Es muss dann angegeben werden, wenn auf ein signiertes Datum bzw. in einem signierten Datum bzw. in dem die XML-Signatur enthaltende XML-Dokument auf weitere Daten  per Referenz verwiesen wird, diese Referenz aber von MOA SP nicht aufgelöst werden kann. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.
    
+
    Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
    
+
    +<VerifyXMLSignatureRequest xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#">
+  <VerifySignatureInfo>
+    <VerifySignatureEnvironment>
+      <XMLContent>
+        <doc:XMLDocument ... xsi:schemaLocation="urn:document urn:XMLDocument.xsd">
+          <doc:Paragraph>Ich bin der erste Absatz in diesem Dokument.</doc:Paragraph>
+          <doc:Paragraph ParaId="Para2">Und ich bin der zweite Absatz in diesem Dokument.
+Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
+          <dsig:Signature Id="signature-1-1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+            <dsig:SignedInfo>
+              ...
+              <dsig:Reference Id="reference-1-1" URI="#Para2">
+                <dsig:Transforms>
+                  <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
+                    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+                      <xsl:include href="XMLDocument.Para.xsl"/>
+                    </xsl:stylesheet>
+                  </dsig:Transform>
+                  <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
+                </dsig:Transforms>
+                ...
+              </dsig:Reference>
+            </dsig:SignedInfo>
+            <dsig:SignatureValue>5rXIIkbP/djWmTgQEICy...0Sf8jvnz+d</dsig:SignatureValue>
+            <dsig:KeyInfo>...</dsig:KeyInfo>
+          </dsig:Signature>
+        </doc:XMLDocument>
+      </XMLContent>
+    </VerifySignatureEnvironment>
+
    
+
    Das Element VerifySignatureEnvironment enthält das XML-Dokument mit der zu prüfenden XML-Signatur. 
    
+
    Man erkennt, dass das Attribut dsig:Reference/@URI das Element doc:Paragraph mit dem auf den Wert Para2 gesetzten ID-Attribut ParaId referenziert. MOA kann jedoch den Umstand, dass es sich bei doc:Paragraph/@ParaId um ein ID-Attribut handelt, nur dann erkennen, wenn es das XML-Dokument validierend parst. Der dazu nötige Verweis auf das passende XML-Schema ist zwar mit dem Attribut xsi:schemaLocation vorhanden, jedoch handelt es sich dabei mit urn:XMLDocument.xsd um eine nicht auflösbare Referenz. Deshalb wird im Request ein passendes Ergänzungsobjekt benötigt (siehe unten).
    
+
    Weiters erkennt man, dass dsig:Reference ein XSLT-Transformation enthält. Im darin kodierten Stylesheet-Parameter (dsig:Transform/xsl:stylesheet) wird ein weiterer Stylesheet inkludiert (XMLDocument.Para.xsl). Diese Referenz ist aber wiederum für MOA SP nicht auflösbar. Auch hier wird also ein passendes Ergänzungsobjekt benötigt (siehe unten). 
    
+
    +    <VerifySignatureLocation xmlns:doc="urn:document" 
+      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">/doc:XMLDocument/dsig:Signature</VerifySignatureLocation>
+  </VerifySignatureInfo>
+
    
+
    Das Element VerifySignatureLocation wählt die zu prüfende Signatur innerhalb des in VerifySignatureEnvironment angegebenen XML-Dokuments aus.
    
+
    +  <SupplementProfile>
+    <Content Reference="XMLDocument.Para.xsl">
+      <LocRefContent>http://localhost:8080/referencedData/XMLDocument.Para.xsl</LocRefContent>
+    </Content>
+  </SupplementProfile>
+
    
+
    Das erste Element SupplementProfile enthält nun das Ergänzungsobjekt für den oben beschriebenen inkludierten Stylesheet. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsl:stylesheet/@href angegeben wurde. Im Inhalt von Content werden entweder explizit jene Daten angegeben, die von MOA statt dem Auflösen der Referenz verwendet werden sollen (Base64Content oder - wie im konkreten Beispiel -  XMLContent), oder aber es wird mit LocRefContent eine auflösbare Referenz für diese Daten an MOA SP übergeben. 
    
+
    +  <SupplementProfile>
+    <Content Reference="urn:XMLDocument.xsd">
+      <XMLContent>
+        <xs:schema targetNamespace="urn:document" xmlns:xs="http://www.w3.org/2001/XMLSchema" 
+          xmlns="urn:document" elementFormDefault="qualified" attributeFormDefault="unqualified">
+          ...
+        </xs:schema>
+      </XMLContent>
+    </Content>
+  </SupplementProfile>
+  <TrustProfileID>Test-Signaturdienste</TrustProfileID>
+</VerifyXMLSignatureRequest>
+
    
+
    Das zweite Element SupplementProfile enthält analog das Ergänzungsobjekt für das oben beschriebene XML-Schema. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsi:schemaLocation angegeben wurde. 
    
+
    Response
    
+
    VerifyXMLSignatureRequest.Supplements.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
    
+
    2.1.3.5 Signatur-Manifest des Security-Layers 
    
+
    Request
    
 
     
    
 
 
-- 
cgit v1.2.3