diff options
| author | Klaus Stranacher <kstranacher@iaik.tugraz.at> | 2013-08-14 16:36:40 +0200 |
|---|---|---|
| committer | Klaus Stranacher <kstranacher@iaik.tugraz.at> | 2013-08-14 16:36:40 +0200 |
| commit | a52d3300d20837b12b45a0d4fb2b0ee520f6e641 (patch) | |
| tree | f2f3259231718a3871ca27b8ee61c857377378ac /spss/handbook/handbook | |
| parent | 8591e43ef7f8e1eb0be50a0726d507904b26b9f5 (diff) | |
| download | moa-id-spss-a52d3300d20837b12b45a0d4fb2b0ee520f6e641.tar.gz moa-id-spss-a52d3300d20837b12b45a0d4fb2b0ee520f6e641.tar.bz2 moa-id-spss-a52d3300d20837b12b45a0d4fb2b0ee520f6e641.zip | |
TSL integration updates:
- Setting of hashcache parameter in MOA
- Update MOA-SP Response (Source attribute in QualifiedCertificate and SecureSignatureCreationDevice element)
- Hidden truststores (for TSL enabled truststore: given certificates are copied to hidden truststore, where TSL certificates are copied)
- Update of QC and SSCD detection
- Update MOA-SPSS config: EU TSL URL can be set via configuration
Diffstat (limited to 'spss/handbook/handbook')
| -rw-r--r-- | spss/handbook/handbook/config/config.html | 1 | ||||
| -rw-r--r-- | spss/handbook/handbook/install/install.html | 5 | ||||
| -rw-r--r-- | spss/handbook/handbook/intro/intro.html | 8 | ||||
| -rw-r--r-- | spss/handbook/handbook/usage/usage.html | 37 |
4 files changed, 33 insertions, 18 deletions
diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html index b0247180c..96270bde1 100644 --- a/spss/handbook/handbook/config/config.html +++ b/spss/handbook/handbook/config/config.html @@ -1218,6 +1218,5 @@ Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall. <h2><a name="beispielkonfigurationen_typspss" id="beispielkonfigurationen_typspss"></a>3.4 Typische Konfiguration für MOA SP/SS</h2> <p>Nachfolgend finden Sie eine typische zentrale Konfigurationsdatei mit Einträgen für den kombinierten Betrieb von MOA SP und SS. Diese Datei wird auch als Konfiguration von MOA SP und SS verwendet, die für das Ausführen der Beispiele des <a href="../usage/usage.html">Anwenderhandbuchs</a> notwendig ist.</p> <p><a href="../../../conf/moa-spss/spss.config.xml">Typische Konfiguration für MOA SP/SS</a> </p> - <p> </p> </body> </html> diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html index 382f9633f..3c3414d29 100644 --- a/spss/handbook/handbook/install/install.html +++ b/spss/handbook/handbook/install/install.html @@ -118,7 +118,7 @@ </ul> <p>Wir <strong>empfehlen</strong> jedoch jeweils aktuelle Version zu verwenden:</p> <ul> - <li><a href="#referenziertesoftware">Java SE 6 Update 41 bzw. Java SE Update SE 6 Update 21</a></li> + <li><a href="#referenziertesoftware">Java SE 6 (neuestes Update) bzw. Java SE Update SE 7 (neuestes Update)</a></li> <li><a href="#referenziertesoftware">Apache Tomcat 6.0.36 bzw. Apache Tomcat 7.0.39</a></li> </ul> <p>In diesem Betriebs-Szenario wird das MOA SP/SS Webservice in Tomcat zum Einsatz gebracht. Tomcat fungiert gleichzeitig als HTTP- und HTTPS-Endpunkt für das MOA SP/SS Webservice. Beide Protokolle werden direkt in Tomcat konfiguriert. Das MOA SP/SS Webservice verwendet Log4j als Logging Toolkit.</p> @@ -377,7 +377,7 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null> </ul> <p>Wir <strong>empfehlen</strong> jedoch jeweils aktuelle Version zu verwenden:</p> <ul> - <li><a href="#referenziertesoftware">Java SE 6 Update 41 bzw. Java SE Update SE 6 Update 21</a></li> + <li><a href="#referenziertesoftware">Java SE 6 (neuestes Update) bzw. Java SE Update SE 7 (neuestes Update)</a></li> </ul> <h3><a name="klassenbibliothek_basisinstallation_vorbereitung" id="klassenbibliothek_basisinstallation_vorbereitung"></a>3.1.2 Vorbereitung </h3> <p>Die folgenden Schritte dienen der Vorbereitung der Installation.</p> @@ -487,5 +487,6 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null> <td>Logging Framework </td> </tr> </table> + </body> </html> diff --git a/spss/handbook/handbook/intro/intro.html b/spss/handbook/handbook/intro/intro.html index 077a1dabe..caa7fcc58 100644 --- a/spss/handbook/handbook/intro/intro.html +++ b/spss/handbook/handbook/intro/intro.html @@ -30,14 +30,14 @@ <hr/> <h1><a name="allgemeines"></a>1 Allgemeines</h1> <p> Die Module Serversignatur (SS) und Signaturprüfung (SP) können von Anwendungen verwendet werden, um elektronische Signaturen zu erstellen bzw. vorliegende elektronische Signaturen zu überprüfen.</p> - <p>Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der <a href="../spec/MOA-SPSS-1.5.2.pdf" target="_blank" class="term">Spezifikation MOA SP/SS (V1.5.2)</a> detailliert beschrieben. Da diese Spezifikation auf der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/" target="_blank" class="term"> Schnittstellenspezifikation des Security-Layers (V 1.2x) TODO</a> aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. </p> + <p>Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der <a href="../spec/MOA-SPSS-1.5.2.pdf" target="_blank" class="term">Spezifikation MOA SP/SS (V1.5.2)</a> detailliert beschrieben. Da diese Spezifikation auf der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/" target="_blank" class="term"> @TODO (Update auf neue abgestimmte Spezifikation) Schnittstellenspezifikation des Security-Layers (V 1.2x)</a> aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. </p> <h1><a name="ss"></a>2 Modul Serversignatur (SS) </h1> - <p> Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/"> </a><a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/" target="_blank" class="term">Schnittstellenspezifikation des Security-Layers (V 1.2x TODO)</a>. Eine Signatur kann entweder rein in Software erstellt werden, oder aber unter Zuhilfenahme eines Hardware Security Modules (HSM), das den privaten Schlüssel geschützt enthält und die Signatur berechnet.</p> + <p> Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/"> </a><a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/" target="_blank" class="term">@TODO (Update auf neue abgestimmte Spezifikation) Schnittstellenspezifikation des Security-Layers (V 1.2x TODO)</a>. Eine Signatur kann entweder rein in Software erstellt werden, oder aber unter Zuhilfenahme eines Hardware Security Modules (HSM), das den privaten Schlüssel geschützt enthält und die Signatur berechnet.</p> <p> Der Zugriff auf einzelne Signaturschlüssel in MOA SS kann basierend auf dem für TLS-Client-Authentisierung verwendeten Zertifikat eingeschränkt werden. </p> <p> Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen. </p> <h1><a name="sp"></a>3 Modul Signaturprüfung (SP) </h1> - <p> Das Modul Signaturprüfung (SP) dient zum Überprüfen von <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" target="_blank">XML-Signaturen</a> und <a href="http://www.ietf.org/rfc/rfc2630.txt" target="_blank">CMS-Signaturen</a> sowie den fortgeschrittenen Signaturen XAdES (TODO Link + Versionen) und CAdES (TODO Link + Versionen).</p> - <p>Im Zuge der Verifikation einer XML-Signatur werden die Signatur, gegebenenfalls vorhandene XMLDSIG-Manifeste, als auch die Gültigkeit und Anwendbarkeit des Zertifikats überprüft. Bei XML-Signaturen kann zusätzlich überprüft werden, ob sie den speziellen Anforderungen <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/" target="_blank" class="term">Schnittstellenspezifikation des Security-Layers (V 1.2x TODO)</a> entsprechen (vgl. Signaturmanifest). </p> + <p> Das Modul Signaturprüfung (SP) dient zum Überprüfen von <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/" target="_blank">XML-Signaturen</a> und <a href="http://www.ietf.org/rfc/rfc2630.txt" target="_blank">CMS-Signaturen</a> sowie den fortgeschrittenen Signaturen XAdES (@TODO Link + Versionen basierend auf Update SL) und CAdES (@TODO Link + Versionen basierend auf Update SL).</p> +<p>Im Zuge der Verifikation einer XML-Signatur werden die Signatur, gegebenenfalls vorhandene XMLDSIG-Manifeste, als auch die Gültigkeit und Anwendbarkeit des Zertifikats überprüft. Bei XML-Signaturen kann zusätzlich überprüft werden, ob sie den speziellen Anforderungen <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/" target="_blank" class="term">@TODO (Update auf neue abgestimmte Spezifikation) Schnittstellenspezifikation des Security-Layers (V 1.2x)</a> entsprechen (vgl. Signaturmanifest). </p> <p> Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen.</p> </body> </html> diff --git a/spss/handbook/handbook/usage/usage.html b/spss/handbook/handbook/usage/usage.html index 8bd1cdc46..53d699689 100644 --- a/spss/handbook/handbook/usage/usage.html +++ b/spss/handbook/handbook/usage/usage.html @@ -77,7 +77,9 @@ </ol> <ol type="A"> <li><a href="#referenzierte_software">Referenzierte Software</a></li> + <li><a href="#referenzierte_spezifikation">Referenzierte Spezifikation</a></li> </ol> + <hr/> <h1><a name="übersicht" id="übersicht"></a>1 Übersicht</h1> <p> Die Module Signaturprüfung (SP) und Serversignatur (SS) sind als plattformunabhängige Module ausgelegt, die entweder als Webservice über HTTP bzw. HTTPS oder als Klassenbibliothek über ein API angesprochen werden können. Dieses Handbuch beschreibt die Anwendung der beiden Module auf jede dieser beiden Arten.</p> @@ -87,14 +89,14 @@ <p>Dieser Abschnitt stellt typische XML-Requests für die Erstellung einer XML/XAdES- und CMS/CAdES-Signatur mittels SS bzw. zur Prüfung einer CMS/CAdES- bzw. XML/XAdES-Signatur mittels SP vor. Zu jedem Request wird jeweils auch eine typische Response des Services besprochen. </p> <p class="remark">Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf <code>localhost</code>, z.B. <code>http://localhost:8080/referencedData/Text.txt</code>. Wenn Sie diese Beispiele ausprobieren möchten, müssen Sie dafür sorgen, dass MOA SS bzw. SP diese Daten auch tatsächlich auflösen kann. Wenn Sie Ihre Tomcat-Installation auf <code>localhost:8080</code> betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation <code><a href="../../clients/common/referencedData/referencedData.war">referencedData.war</a></code> in das Verzeichnis <code>webapps</code> Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen. </p> <h3><a name="webservice_xmlrequests_erstellungcms" id="webservice_xmlrequests_erstellungcms"></a>2.1.1 Erstellung einer CMS bzw. CAdES-Signatur</h3> - <p>MOA-SS ermöglicht die Erstellung einer herkömmlichen CMS-Signatur und einer CAdES-Signatur gemäß der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/core/Core.html#signaturerstellungNachXMLDSIG" target="_blank">Security-Layer Spezifikation V1.2x TODO</a>. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme CAdES-Signatur erstellt wird, erfolgt durch das Attribute <code>SecurityLayerConformity</code> im Signaturerstelltungs-Request (siehe auch folgende Beispiele).</p> + <p>MOA-SS ermöglicht die Erstellung einer herkömmlichen CMS-Signatur und einer CAdES-Signatur gemäß der <a href="#sl"> Security-Layer Spezifikation</a>. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme CAdES-Signatur erstellt wird, erfolgt durch das Attribute <code>SecurityLayerConformity</code> im Signaturerstelltungs-Request (siehe auch folgende Beispiele).</p> <h4><a name="webservice_xmlrequests_erstellungcms_einfach" id="webservice_xmlrequests_erstellungcms_einfach"></a>2.1.1.1 Beispiel (Base64-codiertes Datenobjekt)</h4> <h5>Request</h5> <p><code><a href="../../clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.xml" target="_blank">CreateCMSSignatureRequest.Base64Content.xml</a></code> ist ein einfacher XML-Request zur Erzeugung einer CAdES-Signatur. Sein Aufbau wird nachfolgend analysiert:</p> <pre> <KeyIdentifier>KG_allgemein</KeyIdentifier> </pre> <p><code>KG_allgemein</code> bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. </p> <pre> <SingleSignatureInfo SecurityLayerConformity="true"></pre> - <p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine CAdES-Signatur gemäß <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/core/Core.html#signaturerstellungNachXMLDSIG" target="_blank">Security-Layer Spezifikation V1.2x TODO </a> erzeugt; d.h. es werden signierte Properties (Zeitpunkt der Signaturerstellung, das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten).</p> + <p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine CAdES-Signatur gemäß <a href="#sl"> Security-Layer Spezifikation</a> erzeugt; d.h. es werden signierte Properties (Zeitpunkt der Signaturerstellung, das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten).</p> <pre> <DataObjectInfo Structure="enveloping"> <DataObject> <MetaInfo> @@ -121,7 +123,7 @@ <pre> <KeyIdentifier>KG_allgemein</KeyIdentifier> </pre> <p><code>KG_allgemein</code> bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. </p> <pre> <SingleSignatureInfo SecurityLayerConformity="false"></pre> -<p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine CAdES-Signatur gemäß <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/core/Core.html#signaturerstellungNachXMLDSIG" target="_blank">Security-Layer Spezifikation V1.2x TODO </a> erzeugt; d.h. es werden signierte Properties (Zeitpunkt der Signaturerstellung, das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten).</p> +<p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine CAdES-Signatur gemäß <a href="#sl"> Security-Layer Spezifikation</a> erzeugt; d.h. es werden signierte Properties (Zeitpunkt der Signaturerstellung, das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten).</p> <pre> <DataObjectInfo Structure="detached"> <DataObject> <MetaInfo> @@ -140,7 +142,7 @@ xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" <br> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><br> <CMSSignature>MIAGCSqGSI...SwxhbA9pAAAAAAAA</CMSSignature><br> </CreateCMSSignatureResponse></pre> <p><code>CreateCMSSignatureResponse</code> enthält je erzeugter Signatur ein Element <code>CMSSignature</code> (in diesem Fall genau ein Element). <code>CMSSignature</code> enthält die von SS erzeugte CMS-Signatur (da <code>SecurityLayerConformity="false"</code> im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur nicht enthalten (<code>detached</code>).</p> <h3><a name="webservice_xmlrequests_erstellungxml" id="webservice_xmlrequests_erstellungxml"></a>2.1.2 Erstellung einer XML bzw. XAdES-Signatur</h3> -<p>MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/core/Core.html#signaturerstellungNachXMLDSIG" target="_blank">Security-Layer Spezifikation V1.2x TODO</a>. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute <code>SecurityLayerConformity</code> im Signaturerstelltungs-Request (siehe auch folgende Beispiele). </p> +<p>MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der <a href="#sl"> Security-Layer Spezifikation</a>. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute <code>SecurityLayerConformity</code> im Signaturerstelltungs-Request (siehe auch folgende Beispiele). </p> <p>Im Falle einer XAdES-Signatur, kann entweder eine XAdES-Signatur in der Version 1.1.1 oder in der Version 1.4.2 erstellt werden. Dies hängt von der in der MOA-SS Konfiguration angegeben XAdES-Version ab (siehe hierzu <a href="../config/config.html#konfigurationsparameter_ss_xades">Konfiguration der XAdES Version</a>).</p> <h4><a name="webservice_xmlrequests_erstellungxml_simple" id="webservice_xmlrequests_erstellungxml_simple"></a>2.1.2.1 Einfaches Beispiel</h4> <h5>Request</h5> @@ -148,7 +150,7 @@ <pre> <KeyIdentifier>KG_allgemein</KeyIdentifier> </pre> <p><code>KG_allgemein</code> bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. </p> <pre> <SingleSignatureInfo SecurityLayerConformity="false"></pre> - <p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene XML-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine XML-Signatur gemäß <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20080220/core/Core.html#signaturerstellungNachXMLDSIG" target="_blank">Security-Layer Spezifikation V1.2x TODO </a> erzeugt; d.h. es werden signierte Properties (Zeitpunkt der Signaturerstellung, das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten) und ein Manifest, das alle implizite Transformationsparameter enthält, zur Signatur hinzugefügt (=eine XAdES Signatur).</p> + <p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene XML-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine XML-Signatur gemäß <a href="#sl"> Security-Layer Spezifikation</a> erzeugt; d.h. es werden signierte Properties (Zeitpunkt der Signaturerstellung, das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten) und ein Manifest, das alle implizite Transformationsparameter enthält, zur Signatur hinzugefügt (=eine XAdES Signatur).</p> <pre> <DataObjectInfo Structure="enveloping"> <DataObject> <XMLContent>Diese Daten werden signiert.<XMLContent> @@ -703,13 +705,13 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< <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/20080220/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2x TODO</a>.</p> +<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="#sl"> Security-Layer Spezifikation</a>.</p> <pre> <CertificateCheck> <Code>1</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>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/20080220/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2x TODO</a>.</p> +<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="#sl"> Security-Layer Spezifikation</a>.</p> <h4><a name="webservice_xmlrequests_pruefungcms_erweitert" id="webservice_xmlrequests_pruefungcms_erweitert"></a>2.1.3.2 Erweitertes Beispiel</h4> <h5>Request</h5> <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> @@ -801,13 +803,13 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< <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/20080220/core/Core.html#signaturpruefungNachXMLDSIGAntwort" target="_blank">Security-Layer 1.2x TODO</a>.</p> +<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="#sl"> Security-Layer Spezifikation</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/20080220/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2x TODO</a>.</p> +<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="#sl"> Security-Layer Spezifikation</a>.</p> <h4><a name="webservice_xmlrequests_pruefungxml_erweitert"></a>2.1.4.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> @@ -943,7 +945,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende <code>dsig:Manife </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/20080220/core/Core.html#signaturpruefungNachXMLDSIGAntwort" target="_blank">Security-Layer 1.2x TODO</a>.</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="#sl"> Security-Layer Spezifikation</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> @@ -1184,7 +1186,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </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> <p> </p> -<p>TODO Beispiel-Request mit TSL-Prüfung</p> +<p>@TODO Beispiel-Request mit TSL-Prüfung</p> <h2><a name="webservice_clients" id="webservice_clients"></a>2.2 Webservice-Clients</h2> <p><a href="#webservice_xmlrequests">Abschnitt 2.1</a> bespricht eine Reihe von typischen XML-Requests, die über die Webservice-Schnittstelle an MOA SP/SS gesendet werden können, um entweder Signaturen zu erstellen (MOA SS) oder Signaturen zu prüfen (MOA SP). Dieser Abschnitt zeigt die Verwendung des prototypischen Webservice-Clients, der mit dieser Dokumentation zu MOA SP/SS ausgeliefert wird.</p> <h3><a name="webservice_clients_übersicht" id="webservice_clients_übersicht"></a>2.2.1 Übersicht</h3> @@ -1280,5 +1282,18 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </tr> </tbody> </table> +<h1><a name="referenzierte_spezifikation" id="referenzierte_spezifikation"></a>B Referenzierte Spezifikation</h1> +<table class="fixedWidth" border="1" cellpadding="2"> + <tbody> + <tr> + <th>Spezifikation</th> + <th>Link</th> + </tr> + <tr id="sl"> + <td><p>Security Layer Spezifikation V x.x @TODO Version einfügen</p></td> + <td>@TODO Link</td> + </tr> + </tbody> +</table> </body> </html> |