diff options
| author | gregor <gregor@d688527b-c9ab-4aba-bd8d-4036d912da1d> | 2004-08-27 11:28:33 +0000 |
|---|---|---|
| committer | gregor <gregor@d688527b-c9ab-4aba-bd8d-4036d912da1d> | 2004-08-27 11:28:33 +0000 |
| commit | 8e4afd4a605f811bc4798fe736e0afb41ea45d18 (patch) | |
| tree | 2840f15e1f59121791ae96bb8b600ea070896886 /spss.handbook/handbook | |
| parent | 6e77c60a76b6e52310e0c754188b579a7875c6d0 (diff) | |
| download | moa-id-spss-8e4afd4a605f811bc4798fe736e0afb41ea45d18.tar.gz moa-id-spss-8e4afd4a605f811bc4798fe736e0afb41ea45d18.tar.bz2 moa-id-spss-8e4afd4a605f811bc4798fe736e0afb41ea45d18.zip | |
4 Beispiele für XML-Signaturprüfung hinzugefügt.
git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@190 d688527b-c9ab-4aba-bd8d-4036d912da1d
Diffstat (limited to 'spss.handbook/handbook')
| -rw-r--r-- | spss.handbook/handbook/usage/usage.html | 307 |
1 files changed, 291 insertions, 16 deletions
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 @@ </ol> </li> <li><a href="#webservice_xmlrequests_pruefungcms">Prüfung einer CMS-Signatur </a> <ol> - <li><a href="#webservice_xmlrequests_pruefungcms_simple">Einfaches Beispiel</a></li> - <li><a href="#webservice_xmlrequests_pruefungcms_extended">Erweitertes Beispiel</a> </li> + <li><a href="#webservice_xmlrequests_pruefungcms_einfach">Einfaches Beispiel</a></li> + <li><a href="#webservice_xmlrequests_pruefungcms_erweitert">Erweitertes Beispiel</a> </li> </ol> </li> - <li>Prüfung einer XML-Signatur - <ol> - <li>Einfaches Beispiel</li> - <li>Erweitertes Beispiel</li> - </ol> + <li><a href="#webservice_xmlrequests_pruefungxml">Prüfung einer XML-Signatur </a> <ol> + <li><a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a></li> + <li><a href="#webservice_xmlrequests_pruefungxml_erweitert">Erweitertes Beispiel</a></li> + <li><a href="#webservice_xmlrequests_pruefungxml_xmldsigmanifest">Prüfung eines XMLDSIG-Manifests</a></li> + <li><a href="#webservice_xmlrequests_pruefungxml_ergaenzungsobjekte">Ergänzungsobjekte</a></li> + <li><a href="#webservice_xmlrequests_pruefungxml_signaturmanifest">Signatur-Manifest des Security-Layers</a></li> + </ol> </li> </ol> </li> @@ -92,7 +94,7 @@ </CreateTransformsInfoProfile></pre> 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. </p> <h5>Response</h5> - <p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.resp.xml" target="_blank">CreateXMLSignatureRequest.Simple.resp.xml</a></code> 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.</p> + <p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.resp.xml" target="_blank">CreateXMLSignatureRequest.Simple.resp.xml</a></code> 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.</p> <p> <pre><CreateXMLSignatureResponse xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" <br> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><br> <SignatureEnvironment><br> <dsig:Signature Id="signature-1-1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><br> <dsig:SignedInfo> @@ -289,7 +291,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <p><code>CreateSignatureEnvironment</code> enthält das XML-Dokument, in das die zu erstellende Signatur integriert werden soll. In diesem Beispiel wird dieses Dokument mit Hilfe von <code>LocRefContent</code> referenziert, d. h. MOA SS wird versuchen, die darin enthaltene URL aufzulösen, um das XML-Dokument zu erhalten. Alternativ könnte auch <code>Base64Content</code> (explizite Angabe des XML-Dokuments in base64 kodierter Form) oder <code>XMLContent</code> (direkte Angabe des XML-Dokuments im Request) verwendet werden.</p> <p><a name="webservice_xmlrequests_erstellungxml_daten_hinweisCreateSignatureLocation"></a><code>CreateSignatureLocation</code> enthält die Angabe jener Stelle, an der die Signatur in das XML-Dokument eingesetzt werden soll. Der Inhalt dieses Elements bezeichnet mittels <span class="term">XPath</span>-Ausdruck das <span class="term">Parent</span>-Element der Signatur, der Wert des Attributs <code>CreateSignatureLocation/@Index</code> enthält den Offset innerhalb dieses <span class="term">Parent</span>-Elements. Betrachten Sie zur Verdeutlichung das XML-Dokument <a href="../../clients/common/referencedData/XMLDocument.xml" target="_blank"><code>XMLDocument.xml</code></a>, in das die Signatur integriert werden soll: Die Signatur soll unmittelbar nach dem zweiten <code>doc:Paragraph</code> Element in das XML-Dokument eingefügt werden. Der Inhalt von <code>CreateSignatureLocation</code> (<code>/doc:XMLDocument</code>) selektiert das zukünftige <span class="term">Parent</span>-Element der Signatur, also <code>doc:XMLDocument</code>. Das Attribut <code>Index</code> enthält deshalb den Wert <code>4</code> (und nicht etwa <code>2</code> oder <code>3</code>), da erstens bei <code>0</code> 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 <span class="term">XPath</span>-Ausdruck verwendete Namespace-Prefix <code>doc</code> im Kontext des Elements <code>CreateSignatureLocation</code> bekannt sein muss. Deshalb enthält dieses Element auch die entsprechende Namespace-Deklaration (<code>xmlns:doc="urn:document"</code>).</p> <h5>Response</h5> -<p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Refs.resp.xml" target="_blank">CreateXMLSignatureRequest.Refs.resp.xml</a></code> 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.</p> +<p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Refs.resp.xml" target="_blank">CreateXMLSignatureRequest.Refs.resp.xml</a></code> 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.</p> <pre> <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> <p>Abschließend soll, wie in der Spezifikation der<span class="term"> XSLT-Transformation</span> <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-XSLT" target="_blank">empfohlen</a>, 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 <code>xml</code> festgelegt werden muss (<code><xsl:output method="xml"></code>), denn nur XML-Output kann anschließend kanonisiert werden. Das Attribut <code>dsig:Transform/@Algorithm</code> ist für die <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-c14nAlg" target="_blank"><span class="term">Canonical XML Transformation</span></a> auf den Wert http://www.w3.org/TR/2001/REC-xml-c14n-20010315 zu setzen. Die Transformation benötigt keine Transformationsparameter.</p> <p>Das Ergebnis der drei hintereinandergeschalteten Transformationen, welches der Hashwert-Berechnung zufließt, finden Sie <a href="../../clients/webservice/resources/requests/transformResults/CreateXMLSignatureRequest.Transforms.hashinput.ref2.txt" target="_blank">hier</a>. </p> <h5>Response</h5> -<p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Transforms.resp.xml" target="_blank">CreateXMLSignatureRequest.Transforms.resp.xml</a></code> 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.</p> +<p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Transforms.resp.xml" target="_blank">CreateXMLSignatureRequest.Transforms.resp.xml</a></code> 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.</p> <pre> <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> <p>Die zweite <code>dsig:Reference</code> wurde auf Grund des zweiten <code>DataObjectInfo</code> im Request erstellt. Man erkennt auch hier gut, dass die URL auf die Referenz-Eingangsdaten (Wert des Attributs <code>dsig:Reference/@URI</code>) aus <code>DataObject/@Reference</code> übernommen und die drei Transformationen wie im Request angegeben eingefügt wurden. </p> <h4><a name="webservice_xmlrequests_erstellungxml_ergaenzungsobjekte"></a>2.1.1.4 Ergänzungsobjekte </h4> <h5>Request</h5> -<p>Dieses Beispiel (<a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.xml" target="_blank"><code>CreateXMLSignatureRequest.Supplements.xml</code></a>) erläutert die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem <code>DataObject</code>) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit <code>CreateSignatureEnvironment</code>). 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.</p> +<p>Dieses Beispiel (<a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.xml" target="_blank"><code>CreateXMLSignatureRequest.Supplements.xml</code></a>) stellt die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem <code>DataObject</code>) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit <code>CreateSignatureEnvironment</code>). 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.</p> <pre> <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> <h5>Response</h5> <p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.resp.xml" target="_blank">CreateXMLSignatureRequest.Supplements.resp.xml</a></code> 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.</p> <h3><a name="webservice_xmlrequests_pruefungcms" id="webservice_xmlrequests_pruefungcms"></a>2.1.2 Prüfung einer CMS-Signatur</h3> -<h4><a name="webservice_xmlrequests_pruefungcms_simple" id="webservice_xmlrequests_pruefungcms_simple"></a>2.1.2.1 Einfaches Beispiel</h4> +<h4><a name="webservice_xmlrequests_pruefungcms_einfach" id="webservice_xmlrequests_pruefungcms_einfach"></a>2.1.2.1 Einfaches Beispiel</h4> <h5>Request</h5> <p>Dieses Beispiel (<a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Simple.xml" target="_blank"><code>VerifyCMSSignatureRequest.Simple.xml</code></a>) 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.</p> <pre> @@ -601,7 +603,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <p>Der Request enthält zunächst in <code>CMSSignature</code> die zu prüfende CMS-Signatur, und zwar in base64 kodierter Form. In diesem Beispiel wird davon ausgegangen, dass es sich dabei um eine <span class="term">Enveloping</span> Signature handelt, d. h. dass die signierten Daten als Teil der CMS-Struktur vorhanden sind. Für die Behandlung einer <span class="term">Detached</span> Signature sei auf das <a href="#webservice_xmlrequests_pruefungcms_detached">nächste Beispiel</a> verwiesen.</p> <p>Abschließend enthält der Request in <code>TrustProfileID</code> 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. </p> <h5>Response</h5> -<p><code><a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Simple.resp.xml" target="_blank">VerifyCMSSignatureRequest.Simple.resp.xml</a></code> 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.</p> +<p><code><a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Simple.resp.xml" target="_blank">VerifyCMSSignatureRequest.Simple.resp.xml</a></code> 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.</p> <pre> <VerifyCMSSignatureResponse xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" @@ -637,7 +639,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT</dsig <p>Abschließend enthält die Response mit <code>CertificateCheck/Code</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. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält <code>Code</code> den Wert <code>1</code>, d. h. MOA SP konnte die oben erläuterte Zertifikatskette nicht bilden. Für eine Übersicht der möglichen Kodes siehe <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2</a>.</p> <h4><a name="webservice_xmlrequests_pruefungcms_erweitert" id="webservice_xmlrequests_pruefungcms_erweitert"></a>2.1.2.2 Erweitertes Beispiel</h4> <h5>Request</h5> -<p>Dieses erweiterte Bespiel zur Prüfung einer CMS-Signatur (<a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.xml" target="_blank"><code>VerifyCMSSignatureRequest.Extended.xml</code></a>) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer <span class="term">Detached Signature</span>, d. h. einer Signatur in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. </p> +<p>Dieses erweiterte Beispiel zur Prüfung einer CMS-Signatur (<a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.xml" target="_blank"><code>VerifyCMSSignatureRequest.Extended.xml</code></a>) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer <span class="term">Detached Signature</span>, d. h. einer Signatur in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. </p> <pre> <VerifyCMSSignatureRequest xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" @@ -652,9 +654,282 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT</dsig <TrustProfileID>Test-Signaturdienste</TrustProfileID> </VerifyCMSSignatureRequest> </pre> -<p> Liegt eine zu prüfende CMS-Signatur vor, die von mehreren Unterzeichnenden signiert worden ist, kann das Attribut <code>VerifyCMSSignatureRequest/@Signatories</code> 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 <code>1</code>. 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 <code>"1 3"</code> würde beispielsweise aussagen, dass MOA SP die Unterschrift des ersten sowie des dritten Unterzeichnenden prüfen soll.</p> -<p> </p> +<p> Liegt eine zu prüfende CMS-Signatur vor, die von mehreren Unterzeichnenden signiert worden ist, kann das Attribut <code>VerifyCMSSignatureRequest/@Signatories</code> 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 <code>1</code>. 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 <code>"1 3"</code> würde beispielsweise aussagen, dass MOA SP die Unterschrift des ersten sowie des dritten Unterzeichnenden prüfen soll.</p> +<p>Mit dem optionalen Element <code>DateTime</code> kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime" target="_blank"><span class="term">dateTime</span></a>. 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 <code>DateTime</code> nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#ref-etsicms" target="_blank" class="term">SigningTime</a>). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. </p> +<p>Das optionale Element <code>DataObject</code> muss dann angegeben werden, wenn eine <span class="term">Detached Signature</span> geprüft werden soll, d. h. wenn in der CMS-Signatur die signierten Daten nicht mitkodiert sind. In <code>DataObject/Content/Base64Content</code> sind in einem solchen Fall diese Daten in base64 kodierter Form bereit zu stellen.</p> +<h5>Response</h5> +<p><code><a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.resp.xml" target="_blank">VerifyCMSSignatureRequest.Extended.resp.xml</a></code> 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.</p> +<h3><a name="webservice_xmlrequests_pruefungxml"></a>2.1.3 Prüfen einer XML-Signatur</h3> +<h4><a name="webservice_xmlrequests_pruefungxml_einfach"></a>2.1.3.1 Einfaches Beispiel</h4> +<h5>Request</h5> +<p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Simple.xml" target="_blank">VerifyXMLSignatureRequest.Simple.xml</a></code> 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.</p> +<pre> +<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> +</pre> +<p>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 <code>XMLContent</code> verwendet; alternativ stehen die Elemente <code>Base64Content</code> und <code>LocRefContent</code> bzw. gleichwertig zu <code>LocRefContent</code> das Attribut <code>Reference</code> zur Verfügung.</p> +<p>Im konkreten Beispiel enthält das angegebene XML-Dokument direkt als Root-Element die zu prüfende Signatur (<code>dsig:Signature</code>). Es handelt sich dabei um eine <span class="term">Enveloping Signature</span>, d. h. die signierten Daten sind in einem <code>dsig:Object</code> als Teil der XML-Struktur der Signatur kodiert. Tatsächlich signiert ist hier die Zeichenkette <code>Diese Daten werden signiert.</code></p> +<pre> + <VerifySignatureLocation + xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">/dsig:Signature</VerifySignatureLocation> + </VerifySignatureInfo> +</pre> +<p>Das Element <code>VerifySignatureLocation</code> 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 <code>dsig:Signature</code> ergeben. Bitte beachten Sie, dass im Kontext des Elements <code>VerifySignatureLocation</code> alle im XPath-Ausdruck verwendeten Namespace-Präfixe bekannt sein müssen (hier das Präfix <code>dsig</code>). </p> +<pre> + <TrustProfileID>Test-Signaturdienste</TrustProfileID> +</VerifyXMLSignatureRequest> +</pre> +<p>Das Element <code>TrustProfileID</code> 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 <code>Test-Signaturdienste</code>) muss in der Konfiguration von MOA SP hinterlegt sein. </p> +<h5>Response</h5> +<p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Simple.resp.xml" target="_blank">VerifyXMLSignatureRequest.Simple.resp.xml</a></code> 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.</p> +<pre> +<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> +</pre> +<p>Die Response enthält zunächst in <code>SignerInfo/dsig:X509Data</code> Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind. </p> +<p><code>dsig:X509SubjectName</code> ist immer vorhanden und enthält den Namen des Signators. <code>dsig:X509IssuerSerial</code> ist ebenfalls immer vorhanden und enthält den Namen des Austellers des Signatorzertifikats (<code>dsig:X509IssuerName</code>) sowie die Seriennummer des Zertifikats (<code>dsig:X509SerialNumber</code>). Auch <code>dsig:X509Certificate</code> ist ist immer vorhanden und enthält das Signatorzertifikat in base64 kodierter Form. </p> +<p>Optional vorhanden - in diesem Beispiel nicht ersichtlich - ist das inhaltslose Element <code>QualifiedCertificate</code>, und zwar dann, wenn es sich beim Signatorzertifikat um ein qualifiziertes Zertifikat handelt. Ebenfalls optional vorhanden ist schließlich das Element <code>PublicAuthority</code>, und zwar dann, wenn das Signatorzertifikat die österreichspezifische Zertifikatserweiterung <a href="http://www.cio.gv.at/it-infrastructure/pki/" target="_blank">Verwaltungseigenschaft</a> aufweist. Ist in dieser Zertifikatserweiterung das Verwaltungskennzeichen mitkodiert, wird dieses Kennzeichen als Textinhalt des optionalen Elements <code>PublicAuthority/Code</code> geliefert.</p> +<pre> + <SignatureCheck> + <Code>0</Code> + </SignatureCheck> +</pre> +<p> Anschließend an <code>SignerInfo</code> enthält die Response mit <code>SignatureCheck/Code</code> das Resultat der kryptographischen Prüfung der Signatur. In unserem Beispiel ist dort der Wert <code>0</code> enthalten, d. h. die Signatur konnte erfolgreich validiert werden. Für eine Übersicht der möglichen Kodes siehe <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturpruefungNachXMLDSIGAntwort" target="_blank">Security-Layer 1.2</a>.</p> +<pre> + <CertificateCheck> + <Code>0</Code> + </CertificateCheck> +</pre> +<p>Abschließend enthält die Response mit <code>CertificateCheck/Code</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. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält <code>Code</code> den Wert <code>0</code>, 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 <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2</a>.</p> +<h4><a name="webservice_xmlrequests_pruefungxml_erweitert"></a>2.1.3.2 Erweitertes Beispiel </h4> +<h5>Request</h5> +<p>Dieses erweiterte Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Enveloped.xml" target="_blank"><code>VerifyXMLSignatureRequest.Enveloped.xml</code></a>) demonstriert die Prüfung einer <span class="term">Enveloped Signature</span>, 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.</p> +<pre> +<VerifyXMLSignatureRequest xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"> + <DateTime>2004-08-18T17:00:00+02:00</DateTime> +</pre> +<p>Mit dem optionalen Element <code>DateTime</code> kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime" target="_blank"><span class="term">dateTime</span></a>. 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 <code>DateTime</code> nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#ref-etsicms" target="_blank" class="term">SigningTime</a>). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft.</p> +<pre> + <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> +</pre> +<p>Das Element <code>VerifySignatureEnvironment</code> enthält in diesem Fall mit dem Attribut <code>Reference</code> eine Referenz auf das XML-Dokument (<code><a href="../../clients/common/referencedData/XMLDocument.signed.xml" target="_blank">XMLDocument.signed.xml</a></code>), das die zu prüfende Signatur beinhaltet. Als Textinhalt von <code>VerifySignatureLocation</code> 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 <code>VerifySignatureLocation</code> alle im XPath-Ausdruck verwendeten Namespace-Präfixe bekannt sein müssen (hier die Präfixe <code>doc</code> und <code>dsig</code>). </p> +<pre> + <ReturnHashInputData/> + <TrustProfileID>Test-Signaturdienste</TrustProfileID> +</VerifyXMLSignatureRequest> +</pre> +<p>Durch Angabe des optionalen, leeren Elements Return <code>HashInputData</code> 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 <code>HashInputData</code> im Request nicht angegeben, muss die Anwendung selbst die Signatur analysieren, um diese Information zu erhalten. </p> <h5>Response</h5> +<p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Enveloped.resp.xml" target="_blank">VerifyXMLSignatureRequest.Enveloped.resp.xml</a></code> 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.</p> +<pre> +<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> +</pre> +<p>Die Response enthält zunächst in <code>SignerInfo/dsig:X509Data</code> Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>).</p> +<pre> + <HashInputData> + <Base64Content>PGRvYzp...hNTERvY3VtZW50Pg==</Base64Content> + </HashInputData> +</pre> +<p>Wurde im Request - so wie in diesem Beispiel - das Element <code>ReturnHashInputData</code> angegeben, enthält die Response nach <code>SignerInfo</code> für jede <code>dsig:Reference</code> in <code>dsig:SignedInfo</code> der XML-Signatur ein Element <code>HashInputData</code>, wobei die Reihenfolge der <code>HashInputData</code>-Elemente der Reihenfolge der <code>dsig:Reference</code> Element in <code>dsig:SignedInfo</code> der XML-Signatur entspricht. Der Inhalt wird dabei stets mittels <code>Base64Content</code> in base64-kodierter Form geliefert.</p> +<pre> + <SignatureCheck> + <Code>0</Code> + </SignatureCheck> + <CertificateCheck> + <Code>0</Code> + </CertificateCheck> +</VerifyXMLSignatureResponse> +</pre> +<p>Die Elemente <code>SignatureCheck</code> und <code>CertificateCheck</code> enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>).</p> +<h4><a name="webservice_xmlrequests_pruefungxml_xmldsigmanifest"></a>2.1.3.3 Prüfung eines XMLDSIG-Manifests </h4> +<h5>Request</h5> +<p>Dieses Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.XMLDSigManifest.xml" target="_blank"><code>VerifyXMLSignatureRequest.XMLDSigManifest.xml</code></a>) demonstriert die Prüfung eines in der zu XML-Signatur vorhandenden <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-Manifest" target="_blank">Manifests nach XMLDSig</a>. Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.</p> +<pre> +<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> +</pre> +<p>Das Element <code>VerifySignatureEnvironment</code> enthält als <code>XMLContent</code> die zu prüfende XML-Signatur. Man erkennt, dass sich die einzige <code>dsig:Reference</code> im <code>dsig:SignedInfo</code> der XML-Signatur auf ein Manifest nach XMLDSig bezieht (erkennbar am Attribut <code>Type</code>, das auf den Wert <code>http://www.w3.org/2000/09/xmldsig#Manifest</code> gesetzt ist). Im Response (siehe unten) werden wir deshalb ein eigenes Resultat für die Manifest-Prüfung erhalten.</p> +<p>Das Manifest selbst ist in einem <code>dsig:Object</code>, also innerhalb der XML-Struktur der XML-Signatur kodiert. Es enthält eine <code>dsig:Reference</code>, welche sich auf die Zeichenkette <code>Diese Daten sind signiert.</code> bezieht.</p> +<pre> + <VerifySignatureLocation>//dsig:Signature</VerifySignatureLocation> + </VerifySignatureInfo> + <TrustProfileID>Test-Signaturdienste</TrustProfileID> +</VerifyXMLSignatureRequest> +</pre> +<p>Das Element <code>VerifySignatureLocation</code> wählt die zu prüfende Signatur innerhalb des in <code>VerifySignatureEnvironment</code> angegebenen XML-Dokuments aus. Das Element <code>TrustProfileID</code> wählt das Vertrauensprofil aus, gegen das die Zertifikatsprüfung durchgeführt werden soll. </p> +<h5>Response</h5> +<p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.XMLDSigManifest.resp.xml" target="_blank">VerifyXMLSignatureRequest.XMLDSigManifest.resp.xml</a></code> 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.</p> +<pre> +<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> +</pre> +<p>Die Response enthält zunächst in <code>SignerInfo/dsig:X509Data</code> Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>). Das Element<code> SignatureCheck</code> enthält das Resultat der kryptographischen Prüfung der Signatur (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>).</p> +<pre> + <XMLDSIGManifestCheck> + <Code>0</Code> + <Info> + <ReferringSigReference>1</ReferringSigReference> + </Info> + </XMLDSIGManifestCheck> +</pre> +<p>Neu ist in dieser Response das an <code>SignatureCheck</code> anschließende Element <code>XMLDSIGManifestCheck</code>. Ein oder mehrere solche Elemente werden immer dann zurückgeliefert, wenn in <code>dsig:SignedInfo</code> der XML-Signatur <code>dsig:Reference</code> Elemente existieren, die sich auf ein Manifest nach XMLDSIG beziehen (siehe oben). Je solcher <code>dsig:Reference</code> enthält die Antwort ein korrespondierendes Element <code>XMLDSIGManifestCheck</code>, im konkreten Beispiel als eines.</p> +<p>Das Element <code>Code</code> gibt das Ergebnis der durchgeführten Prüfung des XMLDSIG-Manifests an. In diesem Fall bedeutet <code>0</code>, dass die Prüfung jeder <code>dsig:Reference </code>im <code>dsig:Manifest</code> (im konkreten Beispiel also genau einer <code>dsig:Reference</code>) erfolgreich durchgeführt werden konnte. Für eine Übersicht der möglichen Kodes siehe <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturpruefungNachXMLDSIGAntwort" target="_blank">Security-Layer 1.2</a>.</p> +<p>Das Element <code>Info/ReferringSigReference</code> enthält als Textinhalt die Nummer jenes <code>dsig:Reference</code> Elements in <code>dsig:SignedInfo</code> der XML-Signatur, welches auf das untersuchte Manifest nach XMLDSIG verweist, wobei mit <code>1</code> zu zählen begonnen wird.</p> +<pre> + <CertificateCheck> + <Code>0</Code> + </CertificateCheck> +</VerifyXMLSignatureResponse> +</pre> +<p>Das Element<code> CertificateCheck</code> enthält das Resultat der Zertifikatsprüfung (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>).</p> +<h4><a name="webservice_xmlrequests_pruefungxml_ergaenzungsobjekte"></a>2.3.1.4 Ergänzungsobjekte </h4> +<p>Dieses Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.xml" target="_blank"><code>VerifyXMLSignatureRequest.Supplements.xml</code></a>) demonstriert die Verwendung von Ergänzungsobjekten. Ein Ergänzungsobjekt betrifft entweder ein signiertes Datum (Zusammenhang mit einem <code>dsig:Reference</code> der XML-Signatur) oder jenes Dokument, in dem sich die zu prüfende XML-Signatur befindet (Zusammenhang mit <code>VerifySignatureEnvironment</code>). 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.</p> +<p>Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.</p> +<pre> +<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> +</pre> +<p>Das Element <code>VerifySignatureEnvironment</code> enthält das XML-Dokument mit der zu prüfenden XML-Signatur. </p> +<p>Man erkennt, dass das Attribut <code>dsig:Reference/@URI</code> das Element<code> doc:Paragraph</code> mit dem auf den Wert <code>Para2</code> gesetzten ID-Attribut <code>ParaId</code> referenziert. MOA kann jedoch den Umstand, dass es sich bei <code>doc:Paragraph/@ParaId</code> 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 <code>xsi:schemaLocation</code> vorhanden, jedoch handelt es sich dabei mit <code>urn:XMLDocument.xsd</code> um eine nicht auflösbare Referenz. Deshalb wird im Request ein passendes Ergänzungsobjekt benötigt (siehe unten).</p> +<p>Weiters erkennt man, dass <code>dsig:Reference</code> ein XSLT-Transformation enthält. Im darin kodierten Stylesheet-Parameter (<code>dsig:Transform/xsl:stylesheet</code>) wird ein weiterer Stylesheet inkludiert (<code>XMLDocument.Para.xsl</code>). Diese Referenz ist aber wiederum für MOA SP nicht auflösbar. Auch hier wird also ein passendes Ergänzungsobjekt benötigt (siehe unten). </p> +<pre> + <VerifySignatureLocation xmlns:doc="urn:document" + xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">/doc:XMLDocument/dsig:Signature</VerifySignatureLocation> + </VerifySignatureInfo> +</pre> +<p>Das Element <code>VerifySignatureLocation</code> wählt die zu prüfende Signatur innerhalb des in <code>VerifySignatureEnvironment</code> angegebenen XML-Dokuments aus.</p> +<pre> + <SupplementProfile> + <Content Reference="XMLDocument.Para.xsl"> + <LocRefContent>http://localhost:8080/referencedData/XMLDocument.Para.xsl</LocRefContent> + </Content> + </SupplementProfile> +</pre> +<p>Das erste Element <code>SupplementProfile</code> enthält nun das Ergänzungsobjekt für den oben beschriebenen inkludierten Stylesheet. <code>Content/@Reference</code> enthält die Referenz genau so, wie sie oben im Attribut <code>xsl:stylesheet/@href</code> angegeben wurde. Im Inhalt von <code>Content</code> werden entweder explizit jene Daten angegeben, die von MOA statt dem Auflösen der Referenz verwendet werden sollen (<code>Base64Content</code> oder - wie im konkreten Beispiel - <code>XMLContent</code>), oder aber es wird mit <code>LocRefContent</code> eine auflösbare Referenz für diese Daten an MOA SP übergeben. </p> +<pre> + <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> +</pre> +<p>Das zweite Element SupplementProfile enthält analog das Ergänzungsobjekt für das oben beschriebene XML-Schema. <code>Content/@Reference</code> enthält die Referenz genau so, wie sie oben im Attribut <code>xsi:schemaLocation</code> angegeben wurde. </p> +<h5>Response</h5> +<p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.resp.xml" target="_blank">VerifyXMLSignatureRequest.Supplements.resp.xml</a></code> 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.</p> +<h4><a name="webservice_xmlrequests_pruefungxml_ergaenzungsobjekte"></a>2.1.3.5 Signatur-Manifest des Security-Layers </h4> +<h5>Request</h5> <p> </p> </body> </html> |