From 1ad814ccbbe4f65f430ac738104e3f3c8256c229 Mon Sep 17 00:00:00 2001 From: Klaus Stranacher Date: Tue, 16 Apr 2013 14:44:08 +0200 Subject: Update digest algorithm, XAdES version, whitelisting --- .../clients/referencedData/.settings/org.eclipse.wst.common.component | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'spss/handbook') diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component index 8d9b0c1c1..0929e364c 100644 --- a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component +++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component @@ -1,8 +1,8 @@ - +

- + \ No newline at end of file -- cgit v1.2.3 From dcaa12f3f801363bf6034a48b80fab60cfe9a39f Mon Sep 17 00:00:00 2001 From: Klaus Stranacher Date: Tue, 23 Apr 2013 12:07:03 +0200 Subject: Update textkeys and testcertificates Update signature algorithm selection Update repository Updates documentation --- spss/handbook/clients/api/pom.xml | 6 +- spss/handbook/clients/webservice/.classpath | 64 +++++++----------- spss/handbook/clients/webservice/.project | 74 ++++++++++++--------- spss/handbook/clients/webservice/pom.xml | 7 +- .../resources/sslKeys/customer1/moa-ssl-kunde1.cer | Bin 0 -> 1075 bytes .../resources/sslKeys/customer1/moa-ssl-kunde1.der | Bin 882 -> 0 bytes .../customer1/moa-ssl-kunde1[pwd=kunde1].p12 | Bin 3926 -> 4126 bytes .../customer1/trustedServers[pwd=servers].keystore | Bin 943 -> 1185 bytes .../resources/sslKeys/customer2/moa-ssl-kunde2.cer | Bin 0 -> 1075 bytes .../resources/sslKeys/customer2/moa-ssl-kunde2.der | Bin 882 -> 0 bytes .../customer2/moa-ssl-kunde2[pwd=kunde2].p12 | Bin 3926 -> 4126 bytes .../customer2/trustedServers[pwd=servers].keystore | Bin 943 -> 1185 bytes .../resources/sslKeys/server/localhost.cer | Bin 0 -> 1091 bytes .../sslKeys/server/tomcat[pwd=server].keystore | Bin 0 -> 2473 bytes .../server/trustedClients[pwd=clients].keystore | Bin 0 -> 2318 bytes .../moa/spss/handbook/clients/webservice/HTTP.java | 1 + .../keys/common/moa-signaturdienst-allekunden.cer | Bin 0 -> 1071 bytes .../keys/common/moa-signaturdienst-allekunden.der | Bin 1074 -> 0 bytes ...a-signaturdienst-allekunden[pwd=allekunden].p12 | Bin 3901 -> 2995 bytes .../keys/customer1/moa-signaturdienst-kunde1.cer | Bin 0 -> 1067 bytes .../keys/customer1/moa-signaturdienst-kunde1.der | Bin 1106 -> 0 bytes .../moa-signaturdienst-kunde1[pwd=kunde1].p12 | Bin 4877 -> 4150 bytes .../keys/customer2/moa-signaturdienst-kunde2.cer | Bin 0 -> 1067 bytes .../keys/customer2/moa-signaturdienst-kunde2.der | Bin 1254 -> 0 bytes .../moa-signaturdienst-kunde2[pwd=kunde2].p12 | Bin 4133 -> 4303 bytes spss/handbook/handbook/config/config.html | 21 ++++-- spss/handbook/handbook/install/install.html | 37 ++++++++--- spss/handbook/handbook/intro/intro.html | 5 +- spss/handbook/handbook/usage/usage.html | 9 ++- 29 files changed, 125 insertions(+), 99 deletions(-) create mode 100644 spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.cer delete mode 100644 spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.der create mode 100644 spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.cer delete mode 100644 spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.der create mode 100644 spss/handbook/clients/webservice/resources/sslKeys/server/localhost.cer create mode 100644 spss/handbook/clients/webservice/resources/sslKeys/server/tomcat[pwd=server].keystore create mode 100644 spss/handbook/clients/webservice/resources/sslKeys/server/trustedClients[pwd=clients].keystore create mode 100644 spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.cer delete mode 100644 spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.der create mode 100644 spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.cer delete mode 100644 spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.der create mode 100644 spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.cer delete mode 100644 spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.der (limited to 'spss/handbook') diff --git a/spss/handbook/clients/api/pom.xml b/spss/handbook/clients/api/pom.xml index 6a38fbb2d..5a978964b 100644 --- a/spss/handbook/clients/api/pom.xml +++ b/spss/handbook/clients/api/pom.xml @@ -22,11 +22,11 @@ axis - axis + org.apache.axis axis-jaxrpc - axis + org.apache.axis axis-saaj @@ -64,7 +64,7 @@ javax.servlet servlet-api - provided + xalan-bin-dist diff --git a/spss/handbook/clients/webservice/.classpath b/spss/handbook/clients/webservice/.classpath index cb29bfb96..d687b9b02 100644 --- a/spss/handbook/clients/webservice/.classpath +++ b/spss/handbook/clients/webservice/.classpath @@ -1,41 +1,27 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/spss/handbook/clients/webservice/.project b/spss/handbook/clients/webservice/.project index d23223048..cddae3823 100644 --- a/spss/handbook/clients/webservice/.project +++ b/spss/handbook/clients/webservice/.project @@ -1,34 +1,44 @@ - moa-spss-handbook-webserviceClient - NO_M2ECLIPSE_SUPPORT: Project files created with the maven-eclipse-plugin are not supported in M2Eclipse. - - moa-common - moa-spss-lib - - - - org.eclipse.jdt.core.javabuilder - - - org.eclipse.wst.common.project.facet.core.builder - - - org.eclipse.wst.validation.validationbuilder - - - org.maven.ide.eclipse.maven2Builder - - - org.eclipse.m2e.core.maven2Builder - - - - org.eclipse.m2e.core.maven2Nature - org.maven.ide.eclipse.maven2Nature - org.eclipse.wst.common.project.facet.core.nature - org.eclipse.jdt.core.javanature - org.eclipse.wst.common.modulecore.ModuleCoreNature - org.eclipse.jem.workbench.JavaEMFNature - - \ No newline at end of file + moa-spss-handbook-webserviceClient + NO_M2ECLIPSE_SUPPORT: Project files created with the maven-eclipse-plugin are not supported in M2Eclipse. + + moa-common + moa-spss-lib + + + + org.eclipse.jdt.core.javabuilder + + + + + org.eclipse.wst.common.project.facet.core.builder + + + + + org.eclipse.wst.validation.validationbuilder + + + + + org.maven.ide.eclipse.maven2Builder + + + + + org.eclipse.m2e.core.maven2Builder + + + + + + org.eclipse.m2e.core.maven2Nature + org.maven.ide.eclipse.maven2Nature + org.eclipse.wst.common.project.facet.core.nature + org.eclipse.jdt.core.javanature + org.eclipse.wst.common.modulecore.ModuleCoreNature + org.eclipse.jem.workbench.JavaEMFNature + + diff --git a/spss/handbook/clients/webservice/pom.xml b/spss/handbook/clients/webservice/pom.xml index 70aefa4bc..4221e6cc1 100644 --- a/spss/handbook/clients/webservice/pom.xml +++ b/spss/handbook/clients/webservice/pom.xml @@ -22,11 +22,11 @@ axis - axis + org.apache.axis axis-jaxrpc - axis + org.apache.axis axis-saaj @@ -61,10 +61,9 @@ postgresql postgresql - + javax.servlet servlet-api - provided xalan-bin-dist diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.cer b/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.cer new file mode 100644 index 000000000..dc8a6921f Binary files /dev/null and b/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.cer differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.der b/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.der deleted file mode 100644 index b6091332c..000000000 Binary files a/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1.der and /dev/null differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1[pwd=kunde1].p12 b/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1[pwd=kunde1].p12 index 33f76bf9c..ea67e4ae0 100644 Binary files a/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1[pwd=kunde1].p12 and b/spss/handbook/clients/webservice/resources/sslKeys/customer1/moa-ssl-kunde1[pwd=kunde1].p12 differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer1/trustedServers[pwd=servers].keystore b/spss/handbook/clients/webservice/resources/sslKeys/customer1/trustedServers[pwd=servers].keystore index 9c6c55359..db78c54ab 100644 Binary files a/spss/handbook/clients/webservice/resources/sslKeys/customer1/trustedServers[pwd=servers].keystore and b/spss/handbook/clients/webservice/resources/sslKeys/customer1/trustedServers[pwd=servers].keystore differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.cer b/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.cer new file mode 100644 index 000000000..63f5dc755 Binary files /dev/null and b/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.cer differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.der b/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.der deleted file mode 100644 index 20bc38e14..000000000 Binary files a/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2.der and /dev/null differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2[pwd=kunde2].p12 b/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2[pwd=kunde2].p12 index ec7bf8e48..db7072544 100644 Binary files a/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2[pwd=kunde2].p12 and b/spss/handbook/clients/webservice/resources/sslKeys/customer2/moa-ssl-kunde2[pwd=kunde2].p12 differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/customer2/trustedServers[pwd=servers].keystore b/spss/handbook/clients/webservice/resources/sslKeys/customer2/trustedServers[pwd=servers].keystore index d32a22f0f..cbf43b046 100644 Binary files a/spss/handbook/clients/webservice/resources/sslKeys/customer2/trustedServers[pwd=servers].keystore and b/spss/handbook/clients/webservice/resources/sslKeys/customer2/trustedServers[pwd=servers].keystore differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/server/localhost.cer b/spss/handbook/clients/webservice/resources/sslKeys/server/localhost.cer new file mode 100644 index 000000000..7bee8af02 Binary files /dev/null and b/spss/handbook/clients/webservice/resources/sslKeys/server/localhost.cer differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/server/tomcat[pwd=server].keystore b/spss/handbook/clients/webservice/resources/sslKeys/server/tomcat[pwd=server].keystore new file mode 100644 index 000000000..a24520345 Binary files /dev/null and b/spss/handbook/clients/webservice/resources/sslKeys/server/tomcat[pwd=server].keystore differ diff --git a/spss/handbook/clients/webservice/resources/sslKeys/server/trustedClients[pwd=clients].keystore b/spss/handbook/clients/webservice/resources/sslKeys/server/trustedClients[pwd=clients].keystore new file mode 100644 index 000000000..44a40723b Binary files /dev/null and b/spss/handbook/clients/webservice/resources/sslKeys/server/trustedClients[pwd=clients].keystore differ diff --git a/spss/handbook/clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTP.java b/spss/handbook/clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTP.java index 518017fd2..ffea02533 100644 --- a/spss/handbook/clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTP.java +++ b/spss/handbook/clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTP.java @@ -1,5 +1,6 @@ /* * Copyright 2003 Federal Chancellery Austria + * MOA-SPSS has been developed in a cooperation between BRZ, the Federal * Chancellery Austria - ICT staff unit, and Graz University of Technology. * diff --git a/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.cer b/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.cer new file mode 100644 index 000000000..ad989001a Binary files /dev/null and b/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.cer differ diff --git a/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.der b/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.der deleted file mode 100644 index a4a327a3a..000000000 Binary files a/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden.der and /dev/null differ diff --git a/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden[pwd=allekunden].p12 b/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden[pwd=allekunden].p12 index fe837fd6e..9c6669eba 100644 Binary files a/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden[pwd=allekunden].p12 and b/spss/handbook/conf/moa-spss/keys/common/moa-signaturdienst-allekunden[pwd=allekunden].p12 differ diff --git a/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.cer b/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.cer new file mode 100644 index 000000000..65e33329e Binary files /dev/null and b/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.cer differ diff --git a/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.der b/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.der deleted file mode 100644 index 505e7dd05..000000000 Binary files a/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1.der and /dev/null differ diff --git a/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1[pwd=kunde1].p12 b/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1[pwd=kunde1].p12 index a8073b02b..29585f1ce 100644 Binary files a/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1[pwd=kunde1].p12 and b/spss/handbook/conf/moa-spss/keys/customer1/moa-signaturdienst-kunde1[pwd=kunde1].p12 differ diff --git a/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.cer b/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.cer new file mode 100644 index 000000000..a3ebd91f7 Binary files /dev/null and b/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.cer differ diff --git a/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.der b/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.der deleted file mode 100644 index 3c21c9b2b..000000000 Binary files a/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2.der and /dev/null differ diff --git a/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2[pwd=kunde2].p12 b/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2[pwd=kunde2].p12 index dce18ac78..cc28f167d 100644 Binary files a/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2[pwd=kunde2].p12 and b/spss/handbook/conf/moa-spss/keys/customer2/moa-signaturdienst-kunde2[pwd=kunde2].p12 differ diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html index 5561a3696..2421deb1b 100644 --- a/spss/handbook/handbook/config/config.html +++ b/spss/handbook/handbook/config/config.html @@ -115,6 +115,7 @@

1.1.1 Namenskonventionen

Folgende Namenraum-Präfixe werden in diesem Handbuch zur Kennzeichnung der Namenräume von XML-Elementen verwendet:

TODO Weitere Namespaces? Aktuell?

@@ -213,6 +214,7 @@

Präfix

2.1.2 Auflösen externer URIs

TODO Update Whitelisting

@@ -325,7 +327,8 @@ - - +

TODO Default-wert wenn XAdES 1.4.2?

http://www.w3.org/2000/09/xmldsig#sha1

Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.

Name

Erläuterung

Mit diesem Element wird in MOA SS eine Schlüsselgruppe definiert. Eine Schlüsselgruppe +

TODO Update DigestMethod

Mit diesem Element wird in MOA SS eine Schlüsselgruppe definiert. Eine Schlüsselgruppe ist eine Zusammenfassung von einem oder mehreren privaten Schlüsseln, die in Hardware- bzw. Softwareschlüsselspeichern (vergleiche Abschnitte 2.2.1.1 bzw. 2.2.1.2) verwaltet werden. Die Schlüsselgruppe wird vom Kunden von MOA SS über einen eindeutigen Bezeichner @@ -334,7 +337,7 @@ es, dass MOA SS selbst entscheidet, welcher konkrete Schlüssel aus der Schlüsselgruppe zur Erstellung der Signatur verwendet wird. Durch die somit mögliche Parallelisierung (mehrere private Schlüssel werden parallel für Anfragen, die auf die gleiche Schlüsselgruppe - referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern.

+ referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern.

Das Element cfg:SignatureCreation/cfg:KeyGroup hat folgenden Element-Inhalt:

Element cfg:Id: Dieses obligatorische Element vom Typ xs:token enthält @@ -481,13 +484,15 @@ IssuerDN (RFC2253) :

Erläuterung

Als Inhalt des Elements kann der Digest-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:Reference/dsig:DigestMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:

TODO Update Beschreibung hinsichtlich XAdES 1.4.2

http://www.w3.org/2000/09/xmldsig#sha1 +

http://www.w3.org/2000/09/xmldsig#sha1

Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:

http://www.w3.org/2000/09/xmldsig#sha1

Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.

2.2.5 Profil für Transformationen

@@ -561,8 +566,9 @@ IssuerDN (RFC2253) : +

TODO XAdES 1.4.2 Möglichkeit

2.3 - Parameter für MOA SP

+Parameter für MOA SP

2.3.1 Zertifikatsvalidierung

2.3.1.1 @@ -1124,7 +1130,8 @@ Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall.

3 Beispielkonfigurationen

3.1 Minimale Konfiguration für MOA SS

TODO Update Konfigurations (Simple, Expert)

3.1 Minimale Konfiguration für MOA SS

Nachfolgend finden Sie eine zentrale Konfigurationsdatei mit den minimal notwendigen Einträgen für den alleinigen Betrieb von MOA SS. Darin sind als Kinder des Wurzelelements cfg:MOAConfiguration folgende Konfigurationselemente enthalten:

diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html index 7abb103bd..5de55163f 100644 --- a/spss/handbook/handbook/install/install.html +++ b/spss/handbook/handbook/install/install.html @@ -113,36 +113,43 @@

2.1.1 Einführung

Die Basisinstallation des Webservices stellt einerseits die minimalen Anforderungen für den Betrieb von MOA SP/SS als Webservices dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.

Folgende Software ist Voraussetzung für die Basisinstallation des Webservices:

TODO: Update Versions

J2SE 1.4.x SDK oder J2SE 5.0 SDK
Java SE 5, Java SE 6 oder Java SE 7
Apache Tomcat 4.1.18 oder höher

TODO Empfohlene Versionen?

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.

2.1.2 Installation

2.1.2.1 Vorbereitung

Die folgenden Schritte dienen der Vorbereitung der Installation.

Installation von J2SE SDK

TODO Update Versions

Installieren Sie J2SE 1.4.x SDK oder J2SE 5.0 SDK in ein beliebiges Verzeichnis. Wir empfehlen die Installation von J2SE 5.0 SDK. Das Wurzelverzeichnis der J2SE SDK Installation wird im weiteren Verlauf als $JAVA_HOME bezeichnet.

Installation von Apache Tomcat 4.1

TODO Update Versions

Installieren Sie Apache Tomcat 4.1.18 oder höher in ein Verzeichnis, das keine Leerzeichen im Pfadnamen enthält. Wir empfehlen die Installation von Apache Tomcat 4.1.31. Verwenden Sie bitte die zu Ihrem J2SE SDK passende Distribution von Tomcat. Das Wurzelverzeichnis der Tomcat-Installation wird im weiteren Verlauf als $CATALINA_HOME bezeichnet.

Entpacken der MOA SP/SS Webservice Distribution

TODO Update Versions

Entpacken Sie die Datei moa-spss-1.5.1.zip in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren Verlauf als $MOA_SPSS_INST bezeichnet.

Installation der Krypographiebibliotheken von SIC/IAIK

Die Installation der Kryptographiebibliotheken von SIC/IAIK:

J2SE 1.4.2 SDK oder JSE 5.0 SDK: TODO Update Versions; Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext in das Verzeichnis $JAVA_HOME/jre/lib/ext. Zusätzlich müssen Sie die Rechtedateien Ihres J2SE 1.4.x SDK bzw. J2SE 5.0 SDK austauschen. Laden Sie dazu die Unlimited Strength - - - Jurisdiction Policy Files von der J2SE 1.4.x SDK Downloadseite bzw. J2SE 5.0 SDK Downloadseite und folgen Sie der darin enthaltenen Installationsanweisung.

2.1.2.2 Konfiguration von Apache Tomcat

Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast enthält und viele Ports offen lässt.

2.1.2.2.1 Konfiguration des HTTP Connectors

2.1.2.2 Konfiguration von Apache Tomcat

TODO Update Beispiel server.xml für empfohlenen Tomcat-Version

2.1.2.2.1 Konfiguration des HTTP Connectors

Die Datei $MOA_SPSS_INST/tomcat/server.xml enthält eine minimale Tomcat-Konfiguration, die ausschließlich den Connector für HTTP auf Port 8080 freischaltet. Durch kopieren dieser Datei nach $CATALINA_HOME/conf/server.xml kann Tomcat mit dieser Konfiguration gestartet werden. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.

2.1.2.2.2 Konfiguration des HTTPS Connectors

Wird das MOA SP/SS Webservice in einer nicht abgeschlossenen Umgebung (z.B. Erreichbarkeit über das Internet) betrieben, ist die gegenseitige Identitätsfeststellung von Kunde und Webservice essentiell:

@@ -171,7 +178,8 @@

Die Datei $MOA_SPSS_INST/moa-spss.war enthält das einsatzfertige MOA SP/SS Webarchiv und muss ins Verzeichnis $CATALINA_HOME/webapps kopiert werden. Dort wird sie beim ersten Start von Tomcat automatisch ins Verzeichnis $CATALINA_HOME/webapps/moa-spss entpackt.
Die zentrale Konfigurationsdatei für MOA SP/SS und die zugehörigen Profil-Verzeichnisse müssen in ein beliebiges Verzeichnis im Dateisystem kopiert werden (z.B. $CATALINA_HOME/conf/moa-spss). Eine funktionsfähige Konfiguration, die als Ausgangspunkt für die Konfiguration des MOA SP/SS Webservices dienen kann, finden Sie hier.
Wird Tomcat unter J2SE 1.4.x SDK oder höher betrieben, müssen die Dateien xalan.jar, xercesImpl.jar, serializer.jar und xml-apis.jar aus dem Verzeichnis $MOA_SPSS_INST/endorsed in das Tomcat-Verzeichnis $CATALINA_HOME/common/endorsed kopiert werden. Sind gleichnamige Dateien dort bereits vorhanden, müssen sie überschrieben werden. Die ggf. in diesem Verzeichnis vorhandene Datei xmlParserAPIs.jar muss gelöscht werden.
TODO Update Versions
+ Wird Tomcat unter J2SE 1.4.x SDK oder höher betrieben, müssen die Dateien xalan.jar, xercesImpl.jar, serializer.jar und xml-apis.jar aus dem Verzeichnis $MOA_SPSS_INST/endorsed in das Tomcat-Verzeichnis $CATALINA_HOME/common/endorsed kopiert werden. Sind gleichnamige Dateien dort bereits vorhanden, müssen sie überschrieben werden. Die ggf. in diesem Verzeichnis vorhandene Datei xmlParserAPIs.jar muss gelöscht werden.

Folgende System Properties können gesetzt werden (wird beim Starten von Tomcat der Java Virtual Machine in der Umgebungsvariablen CATALINA_OPTS in der Form -D<name>=<wert> übergeben):

moa.spss.server.configuration: Pfad und Name der zentralen Konfigurationsdatei für MOA SP/SS. Eine beispielhafte Konfigurationsdatei finden Sie hier. Wird ein relativer Pfad angegeben, wird dieser relativ zum Startverzeichnis der Java Virtual Machine interpretiert. Ist diese System Property nicht gesetzt, wird automatisch eine im Webarchiv unter WEB-INF/conf enthaltene Default-Konfiguration herangezogen.

2.2 Erweiterungsmöglichkeiten

Ausgehend von der Basisinstallation können die optionalen Erweiterungen, die in den nachfolgenden Abschnitten beschrieben werden, unabhängig und in beliebiger Kombination aufgesetzt werden.

2.2.1 Vorgeschalteter Webserver

TODO Update Versions?

2.2.1 Vorgeschalteter Webserver

2.2.1.1 Microsoft Internet Information Server (MS IIS)

Den MOA SP/SS Webservices kann optional ein MS IIS vorgeschaltet sein. In diesem Fall übernimmt der MS IIS die HTTP- bzw. HTTPS-Kommunikation mit dem Aufrufer des Webservices. Die Kommunikation zwischen MS IIS und dem in Tomcat eingerichteten MOA SP/SS Webservice wird durch Jakarta mod_jk durchgeführt. Die angeführten Konfigurationsschritte gehen von einer MS IIS Standard-Installation aus.

2.2.1.1.1 Konfiguration von Jakarta mod_jk im MS IIS

3.1.1 Einführung

Die Basisinstallation der Klassenbibliothek stellt einerseits die minimalen Anforderungen für den Einsatz von MOA SP/SS als Klassenbibliothek dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.

Folgende Software ist Voraussetzung für die Basisinstallation der Klassenbibliothek:

TODO Update Versions

J2SE 1.4.x JRE oder J2SE 5.0 JRE

Die folgenden Schritte dienen der Vorbereitung der Installation.

Installation von J2SE SDK

TODO Update Versions

Entpacken der MOA SP/SS Klassenbibliotheks-Distribution

TODO Update Versions

Entpacken Sie die Datei moa-spss-1.5.1-lib.zip in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren Verlauf als $MOA_SPSS_INST bezeichnet.

Installation der Krypographiebibliotheken von SIC/IAIK

Die Installation der Kryptographiebibliotheken von SIC/IAIK:

J2SE 1.4.x SDK oder JSE 5.0 SDK: TODO Update Versions; Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext in das Verzeichnis $JAVA_HOME/jre/lib/ext. Zusätzlich müssen Sie die Rechtedateien Ihres J2SE 1.4.x SDK bzw. J2SE 5.0 SDK austauschen. Laden Sie dazu die Unlimited Strength Jurisdiction Policy Files von der J2SE 1.4.x SDK Downloadseite bzw. J2SE 5.0 SDK Downloadseite und folgen Sie der darin enthaltenen Installationsanweisung.

3.1.3 Verwendung

Um die MOA SP/SS Klassenbibliothek in einer Applikation verwenden zu können, müssen die mit MOA SP/SS ausgelieferten Bibliotheken in den Java Klassenpfad der Applikation eingebunden werden.

Die nachfolgende Tabelle listet diese Klassenbibliotheken auf; die Einträge in der Spalte Dateien sind relativ zum Verzeichnis $MOA_SPSS_INST zu interpretieren.

TODO Update Versions

Die im Abschnitt 2.2 angeführten Erweiterungsmöglichkeiten für die MOA SP/SS Webservices gelten in analoger Weise auch für die Klassenbibliothek.

A Referenzierte Software

Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:

TODO Update Versions

Klassenbibliothek	Version	Dateien

1 Allgemeines

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.

Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V1.3) detailliert beschrieben. Da diese Spezifikation auf der Schnittstellenspezifikation des Security-Layers (V 1.1) aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich.

2 Modul Serversignatur (SS)

TODO: CAdES auf SL1.2x aufbauend - wie siehts mir Rest aus?

2 Modul Serversignatur (SS)

Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die Schnittstellenspezifikation des Security-Layers (V 1.1). 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.

Der Zugriff auf einzelne Signaturschlüssel in MOA SS kann basierend auf dem für TLS-Client-Authentisierung verwendeten Zertifikat eingeschränkt werden.

Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen.

2.1 XML-Requests

Dieser Abschnitt stellt typische XML-Requests für die Erstellung einer XML-Signatur mittels SS bzw. zur Prüfung einer CMS- bzw. XML-Signatur mittels SP vor. Zu jedem Request wird jeweils auch eine typische Response des Services besprochen.

Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf localhost, z.B. http://localhost:8080/referencedData/Text.txt. 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 localhost:8080 betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation referencedData.war in das Verzeichnis webapps Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen.

2.1.1 Erstellung einer XML-Signatur

TODO Erstellung einer CMS/CAdES Signatur

2.1.1 Erstellung einer XML-Signatur

2.1.1.1 Einfaches Beispiel

Request

CreateXMLSignatureRequest.Simple.xml ist ein einfacher XML-Request zur Erzeugung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert:

Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).

TODO Beispiel-Request mit TSL-Prüfung

2.2 Webservice-Clients

Abschnitt 2.1 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.

2.2.1 Übersicht

2.2.2 Gemeinsamkeiten

Dieser Abschnitt beschreibt die Gemeinsamkeiten aller drei Varianten des Webservice-Clients.

Zunächst einmal benötigen alle drei Varianten die folgenden Java-Bibliotheken, die im Ordner clients/webservice/lib/ dieses Handbuchs bereits enthalten sind:

TODO Update Versions

TODO kein lib Verzeichnis

Name

A Referenzierte Software

Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:

TODO Update Versions

Date: Tue, 23 Apr 2013 16:48:24 +0200 Subject: Update Dokumentation: Installation --- spss/handbook/handbook/install/install.html | 250 ++++++++++++++-------------- 1 file changed, 121 insertions(+), 129 deletions(-) (limited to 'spss/handbook') diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html index 5de55163f..7c78969c3 100644 --- a/spss/handbook/handbook/install/install.html +++ b/spss/handbook/handbook/install/install.html @@ -58,30 +58,30 @@ -

Erweiterungsmöglichkeiten

Vorgeschalteter Webserver
1. Microsoft Internet Information Server (MS IIS)
  1. Konfiguration von Jakarta mod_jk im MS IIS
  2. Konfiguration von Tomcat
  3. Konfiguration von SSL
  4. Erweiterungsmöglichkeiten
    1. Vorgeschalteter Webserver
    @@ -111,46 +111,41 @@
    Dieser Abschnitt beschreibt die Installation von MOA SP/SS als Webservice. Im ersten Unterkapitel wird eine minimale Basisinstallation beschrieben. Das zweite Unterkapitel zeigt eine Reihe von optionalen Erweiterungsmöglichkeiten auf.
    
    2.1 Basisinstallation
    
    2.1.1 Einführung
    -
    Die Basisinstallation des Webservices stellt einerseits die minimalen Anforderungen für den Betrieb von MOA SP/SS als Webservices dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.
    -
    Folgende Software ist Voraussetzung für die Basisinstallation des Webservices:
    -
    TODO: Update Versions
    +
    Die Basisinstallation des Webservices stellt einerseits die minimalen Anforderungen für den Betrieb von MOA SP/SS als Webservices dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.
    +
    Die Mindestanforderungen für die Basisinstallation sind:
    -
    TODO Empfohlene Versionen?
    +
    Wir empfehlen jedoch jeweils aktuelle Version zu verwenden:
    +
    - Java SE 6 Update 41 bzw. Java SE Update SE 6 Update 21
    - Apache Tomcat 6.0.36 bzw. Apache Tomcat 7.0.39
    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.
    
    2.1.2 Installation
    -
    2.1.2.1 Vorbereitung
    -
    Die folgenden Schritte dienen der Vorbereitung der Installation.
    +
    2.1.2.1 Vorbereitung
    +
    Die folgenden Schritte dienen der Vorbereitung der Installation.
    
    -
    Installation von J2SE SDK
    -
    TODO Update Versions
    -
    Installieren Sie J2SE 1.4.x SDK oder J2SE 5.0 SDK in ein beliebiges Verzeichnis. Wir empfehlen die Installation von J2SE 5.0 SDK. Das Wurzelverzeichnis der J2SE SDK Installation wird im weiteren Verlauf als $JAVA_HOME bezeichnet.
    -
    Installation von Apache Tomcat 4.1
    -
    TODO Update Versions
    -
    Installieren Sie Apache Tomcat 4.1.18 oder höher in ein Verzeichnis, das keine Leerzeichen im Pfadnamen enthält. Wir empfehlen die Installation von Apache Tomcat 4.1.31. Verwenden Sie bitte die zu Ihrem J2SE SDK passende Distribution von Tomcat. Das Wurzelverzeichnis der Tomcat-Installation wird im weiteren Verlauf als $CATALINA_HOME bezeichnet.
    +
    Installation von Java SE
    +
    Installieren Sie Java SE in ein beliebiges Verzeichnis. Das Wurzelverzeichnis der Java SE Installation wird im weiteren Verlauf als $JAVA_HOME bezeichnet.
    +
    Installation von Apache Tomcat
    +
    Installieren Sie Apache Tomcat in ein Verzeichnis, das keine Leerzeichen im Pfadnamen enthält. Verwenden Sie bitte die zu Ihrer Java SE passende Distribution von Tomcat. Das Wurzelverzeichnis der Tomcat-Installation wird im weiteren Verlauf als $CATALINA_HOME bezeichnet.
    
    Entpacken der MOA SP/SS Webservice Distribution
    -
    TODO Update Versions
    -
    Entpacken Sie die Datei moa-spss-1.5.1.zip in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren Verlauf als $MOA_SPSS_INST bezeichnet.
    -
    Installation der Krypographiebibliotheken von SIC/IAIK
    +
    Entpacken Sie die Datei moa-spss-1.5.2.zip in ein beliebiges Verzeichnis. Dieses Verzeichnis wird im weiteren Verlauf als $MOA_SPSS_INST bezeichnet.
    +
    Installation der Kryptographiebibliotheken von SIC/IAIK
    
    -
    Die Installation der Kryptographiebibliotheken von SIC/IAIK:
    -
    -
    J2SE 1.4.2 SDK oder JSE 5.0 SDK
    -
    TODO Update Versions
    -
    Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext in das Verzeichnis $JAVA_HOME/jre/lib/ext. Zusätzlich müssen Sie die Rechtedateien Ihres J2SE 1.4.x SDK bzw. J2SE 5.0 SDK austauschen. Laden Sie dazu die Unlimited Strength +
    Kopieren Sie alle Dateien aus dem Verzeichnis $MOA_SPSS_INST/ext in das Verzeichnis $JAVA_HOME/jre/lib/ext. Zusätzlich müssen Sie die Rechtedateien Ihrer Java SE austauschen. Laden Sie dazu die passenden Unlimited Strength - Jurisdiction Policy Files von der J2SE 1.4.x SDK Downloadseite bzw. J2SE 5.0 SDK Downloadseite und folgen Sie der darin enthaltenen Installationsanweisung.
    -
    + Jurisdiction Policy Files von der Java SE Downloadseite und achten Sie darauf die für ihre verwendete Java SE Installation richtige Version zu nehmen. Anschließend folgen Sie der darin enthaltenen Installationsanweisung.
    
    2.1.2.2 Konfiguration von Apache Tomcat
    -
    TODO Update Beispiel server.xml für empfohlenen Tomcat-Version
    
    Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast enthält und viele Ports offen lässt.
    
    2.1.2.2.1 Konfiguration des HTTP Connectors
    -
    Die Datei $MOA_SPSS_INST/tomcat/server.xml enthält eine minimale Tomcat-Konfiguration, die ausschließlich den Connector für HTTP auf Port 8080 freischaltet. Durch kopieren dieser Datei nach $CATALINA_HOME/conf/server.xml kann Tomcat mit dieser Konfiguration gestartet werden. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.
    +
    TODO: server.xml auf 7 umstellen
    +
    Die Datei $MOA_SPSS_INST/tomcat/server.xml enthält eine minimale Tomcat-Konfiguration für Apache Tomcat 7, die ausschließlich den Connector für HTTP auf Port 8080 freischaltet. Durch Kopieren dieser Datei nach $CATALINA_HOME/conf/server.xml kann Tomcat mit dieser Konfiguration gestartet werden. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.
    
    2.1.2.2.2 Konfiguration des HTTPS Connectors
    
    Wird das MOA SP/SS Webservice in einer nicht abgeschlossenen Umgebung (z.B. Erreichbarkeit über das Internet) betrieben, ist die gegenseitige Identitätsfeststellung von Kunde und Webservice essentiell:
    - Nutzt ein Kunde MOA SS, ist es für ihn wesentlich, dass nur er Zugriff auf die für ihn vom Webservice verwalteten privaten Schlüssel hat, um elektronische Signaturen zu erstellen. Das Webservice muss also die Identität des Kunden prüfen.
    Beide Identitätsprüfungen können mit hoher Qualität vorgenommen werden, wenn die Erreichbarkeit des Webservice auf SSL mit Server- (für MOA SP) bzw. Client- und Serverauthentisierung (für MOA SS) eingeschränkt wird.
    -
    Für die dazu notwendige Konfiguration kann die im vorigen Abschnitt besprochene minimale Tomcat-Konfiguration als Ausgangspunkt verwendet werden: Zunächst ist der HTTP Connector abzuschalten (auszukommentieren). Anschließend ist der HTTPS Connector zu konfigurieren. Das Dokument Tomcat SSL Configuration HOW-TO gibt einen guten Überblick dazu. Grob zusammengefasst sind folgende Schritte durchzuführen:
    +
    Für die dazu notwendige Konfiguration kann die im vorigen Abschnitt besprochene minimale Tomcat-Konfiguration als Ausgangspunkt verwendet werden: Zunächst ist der HTTP Connector abzuschalten (auszukommentieren). Anschließend ist der HTTPS Connector zu konfigurieren. Das Dokument Tomcat SSL Configuration HOW-TO gibt einen guten Überblick dazu. Grob zusammengefasst sind folgende Schritte durchzuführen:
    - Erstellung eines Server-Keystores, der den privaten Schlüssel sowie das zugehörige Zertifikat des Webservices enthält, mit dem es sich bei Aufbau einer SSL-Verbindung gegenüber dem Kunden ausweist.sowie das dazugehörige ZertiServer-Zertifikat enthält. Sie können diesen Keystore z.B. mit keytool erstellen, einem Programm, das Ihrem J2SE SDK beiliegt.
    - Erstellung eines Server-Keystores, der den privaten Schlüssel sowie das zugehörige Zertifikat des Webservices enthält, mit dem es sich bei Aufbau einer SSL-Verbindung gegenüber dem Kunden ausweist sowie das dazugehörige Server-Zertifikat enthält. Sie können diesen Keystore z.B. mit keytool erstellen, einem Programm, das Ihrer Java SE beiliegt.
    - Erstellung eines Client-Keystores, der die Zertifikate aller Kunden des Webservices enthält. Nur Kunden des Webservices, die sich beim Aufbau einer SSL-Verbindung gegenüber dem Webservice mit einem im Client-Keystore enthaltenen Zertifikat ausweisen, erhalten grundsätzlich Zugriff zu den Diensten des Webservices (für die Konfiguration, welcher Kunde welche Schlüssel von MOA SS verwenden darf, siehe Abschnitt 2.2.3 des Konfigurationshandbuchs). Auch dieser Keystore kann z.B. mit keytool erstellt werden. Dieser Keystore ist optional und braucht nur erstellt zu werden, wenn sich die Kunden gegenüber dem Webservice authentisieren müssen.
    - Konfiguration des HTTPS Connectors in $CATALINA_HOME/conf/server.xml.
    -
    Die Konfiguration des HTTPS Connectors kann entfallen, wenn Tomcat ein Webserver vorgeschaltet ist, und dieser die SSL-Kommunikation mit dem Kunden übernimmt (siehe Abschnitt 2.2.1).
    +
    Die Konfiguration des HTTPS Connectors kann entfallen, wenn Tomcat ein Webserver vorgeschaltet ist, und dieser die SSL-Kommunikation mit dem Kunden übernimmt (siehe Abschnitt 2.2.1).
    
    2.1.2.2.3 Einrichten des MOA SP/SS Administrators
    
    Das MOA SP/SS Webservice kann remote durch den Aufruf einer speziellen URL des Webservices dazu veranlasst werden, seine Konfiguration neu einzulesen (vergleiche Abschnitt 2.1.2.5). Der Zugriff auf diese URL ist durch eine Passwort-Abfrage geschützt, und kann nur von Tomcat-Benutzern aufgerufen werden, denen die Tomcat-Benutzer-Rolle moa-admin zugeordnet wurde.
    
    Um diese Benutzer-Rolle und einen oder mehrere Benutzer einzurichten, müssen in der Datei $CATALINA_HOME/conf/tomcat-users.xml unter dem Element <tomcat-users> sinngemäß folgende Einträge hinzugefügt werden:
    @@ -177,9 +172,9 @@
    Um das MOA SP/SS Webservice in Tomcat für den Einsatz vorzubereiten, sind folgende Schritte notwendig:
    - Die Datei $MOA_SPSS_INST/moa-spss.war enthält das einsatzfertige MOA SP/SS Webarchiv und muss ins Verzeichnis $CATALINA_HOME/webapps kopiert werden. Dort wird sie beim ersten Start von Tomcat automatisch ins Verzeichnis $CATALINA_HOME/webapps/moa-spss entpackt.
    - Die zentrale Konfigurationsdatei für MOA SP/SS und die zugehörigen Profil-Verzeichnisse müssen in ein beliebiges Verzeichnis im Dateisystem kopiert werden (z.B. $CATALINA_HOME/conf/moa-spss). Eine funktionsfähige Konfiguration, die als Ausgangspunkt für die Konfiguration des MOA SP/SS Webservices dienen kann, finden Sie hier.
    - TODO Update Versions
      - Wird Tomcat unter J2SE 1.4.x SDK oder höher betrieben, müssen die Dateien xalan.jar, xercesImpl.jar, serializer.jar und xml-apis.jar aus dem Verzeichnis $MOA_SPSS_INST/endorsed in das Tomcat-Verzeichnis $CATALINA_HOME/common/endorsed kopiert werden. Sind gleichnamige Dateien dort bereits vorhanden, müssen sie überschrieben werden. Die ggf. in diesem Verzeichnis vorhandene Datei xmlParserAPIs.jar muss gelöscht werden.
    - Die zentrale Konfigurationsdatei für MOA SP/SS und die zugehörigen Profil-Verzeichnisse müssen in ein beliebiges Verzeichnis im Dateisystem kopiert werden (z.B. $CATALINA_HOME/conf/moa-spss). Eine funktionsfähige Konfiguration, die als Ausgangspunkt für die Konfiguration des MOA SP/SS Webservices dienen kann, finden Sie hier.
      +
    - Die Dateien xalan.jar, xercesImpl.jar, serializer.jar und xml-apis.jar aus dem Verzeichnis $MOA_SPSS_INST/endorsed müssen in das Tomcat-Verzeichnis $CATALINA_HOME/endorsed (bzw. $CATALINA_HOME/common/endorsed bis Apache Tomcat Version 5.5) kopiert werden. Sind gleichnamige Dateien dort bereits vorhanden, müssen sie überschrieben werden. Die ggf. in diesem Verzeichnis vorhandene Datei xmlParserAPIs.jar muss gelöscht werden. Sollte das Verzeichnis endorsed nicht vorhanden sein, dann muss dieses zuerst erstellt werden.
    - Folgende System Properties können gesetzt werden (wird beim Starten von Tomcat der Java Virtual Machine in der Umgebungsvariablen CATALINA_OPTS in der Form -D<name>=<wert> übergeben):
      - moa.spss.server.configuration: Pfad und Name der zentralen Konfigurationsdatei für MOA SP/SS. Eine beispielhafte Konfigurationsdatei finden Sie hier. Wird ein relativer Pfad angegeben, wird dieser relativ zum Startverzeichnis der Java Virtual Machine interpretiert. Ist diese System Property nicht gesetzt, wird automatisch eine im Webarchiv unter WEB-INF/conf enthaltene Default-Konfiguration herangezogen.

Bitte beachten Sie: Wenn Sie keine Datenbank für MOA SP/SS verwenden (vergleiche 2.2.2), benötigen Sie diese Bibliothek nicht.

Klassenbibliothek	Version	Dateien
MOA SP/SS	1.5.1	1.5.2	`moa-spss.jar`, `moa-common.jar`
MOA IAIK	1.32	`lib/iaik_moa-1.32.jar`, - `lib/iaik_cms-3.2.jar`, `lib/iaik_ixsil-1.2.2.5.jar` +	1.33.1 + TODO: Update Version (auf 1.5 laut Harald)	`lib/iaik_moa-1.33.1.jar`, + `lib/iaik_cms-4.1.jar`, `lib/iaik_ixsil-1.2.2.5.jar`
Activation	1.4	1.1	`lib/activation-1.1.jar`
Xerces-J	2.7.1	2.9.0	`lib/xercesImpl.jar`
Xalan-J	2.7.0	2.7.1	`lib/xalan.jar`, `lib/xml-apis.jar`, `lib/serializer.jar` - Bitte beachten Sie: Wenn Sie J2SE 1.4.2 JRE oder J2SE 5.0 JRE verwenden, müssen Sie diese Bibliothek der Java VM als endorsed bekanntgeben. Sie können dies tun, indem Sie entweder + Bitte beachten Sie: Sie müssen diese Bibliothek gegebenenfalls der Java VM als endorsed bekanntgeben. Sie können dies tun, indem Sie entweder die Bibliothek in das (ggf. vorher anzulegende) Verzeichnis `$JAVA_HOME/jre/lib/endorsed/` kopieren; oder die System Property `java.endorsed.dirs` verwenden, und als Wert den Pfad zu jenem Verzeichnis angeben, in dem Sie die Bibliothek vorhalten (also z.B. `java.endorsed.dirs=c:/mylibdir`). @@ -455,49 +450,46 @@ INFO \| 01 21:25:26,540 \| Thread-3 \| TID=1049225059594-100 NID=<null>	`lib/commons-logging-1.0.4.jar`
Log4j	1.2.8	`lib/log4j-1.2.8.jar`	1.2.14	`lib/log4j-1.2.14.jar`
Commons-Discovery	0.2	`lib/commons-discovery-0.2.jar`
Postgres JDBC2	7.3	`lib/postgresql-7.2.jar` - Bitte beachten Sie: Wenn Sie keine Datenbank für MOA SP/SS verwenden (vergleiche 2.2.2), benötigen Sie diese Bibliothek nicht.
Axis	1.4	`lib/axis-1.4.jar, lib/axis-jaxrpc-1.4.jar, lib/axis-saaj-1.4.jar, lib/axis-wsdl4j-1.5.1.jar`	Axis	1.0_IAIK/1.4	`lib/axis-1.0_iaik.jar, lib/axis-jaxrpc-1.4.jar, lib/axis-saaj-1.4.jar, lib/axis-wsdl4j-1.5.1.jar`

3.1.4 Logging

Die MOA SP/SS Klassenbibliothek verwendet Jakarta Log4j für die Ausgabe von Log-Meldungen am Bildschirm bzw. in Log-Dateien. Die im Abschnitt 2.1.3 gemachten Aussagen lassen sich großteils auf den Einsatz der MOA SP/SS Klassenbibliothek übertragen.

3.2 Erweiterungsmöglichkeiten

Die im Abschnitt 2.2 angeführten Erweiterungsmöglichkeiten für die MOA SP/SS Webservices gelten in analoger Weise auch für die Klassenbibliothek.

Die MOA SP/SS Klassenbibliothek verwendet Log4j für die Ausgabe von Log-Meldungen am Bildschirm bzw. in Log-Dateien. Die im Abschnitt 2.1.3 gemachten Aussagen lassen sich großteils auf den Einsatz der MOA SP/SS Klassenbibliothek übertragen.

3.2 Erweiterungsmöglichkeiten

Die im Abschnitt 2.2 angeführten Erweiterungsmöglichkeiten für die MOA SP/SS Webservices gelten in analoger Weise auch für die Klassenbibliothek.

A Referenzierte Software

Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:

TODO Update Versions

Name	Beschreibung
Apache Tomcat 4.1.x	Servlet-Container des Apache Jakarta Projekts in der Version 4.1.x
J2SE 1.4.x SDK/JRE	Java 2 Standard Edition in der Version 1.4.x (Software Development Kit bzw. Java Runtime Environment)	Apache Tomcat	Apache Tomcat Servlet-Container
J2SE 5.0 SDK/JRE	Java 2 Standard Edition in der Version 5.0 (Software Development Kit bzw. Java Runtime Environment)	Java SE	Java Standard Edition (Software Development Kit bzw. Java Runtime Environment)
Jakarta Log4J	Logging Framework des Apache Jakarta Projekts	Log4J	Logging Framework

Date: Wed, 24 Apr 2013 16:46:35 +0200 Subject: Update Dokumentation --- spss/handbook/handbook/config/config.html | 105 ++++++++++++++++++++------- spss/handbook/handbook/install/install.html | 20 +++--- spss/handbook/handbook/usage/usage.html | 107 ++++++++++++++-------------- 3 files changed, 142 insertions(+), 90 deletions(-) (limited to 'spss/handbook') diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html index 2421deb1b..6809c143d 100644 --- a/spss/handbook/handbook/config/config.html +++ b/spss/handbook/handbook/config/config.html @@ -46,8 +46,13 @@

Allgemeines Parameter
1. Hardwarebasiertes Kryptographiemodul
2. Auflösen externer URIs
+
Auflösen externer URIs +
1. Blacklisting
2. Whitelisting
+

Parameter für MOA SS

Schlüsselspeicher
1. Parameter für XML-Signaturen
2. Profil für Transformationen
3. Profil für Signaturumgebung
4. XAdES Version
Parameter für MOA SP

1 Übersicht

Dieses Handbuch beschreibt detailliert die Konfigurationsmöglichkeiten für MOA SP/SS. Wenn nicht anders angegeben, beziehen sich die Erläuterungen sowohl auf die Konfiguration des Webservices als auch auf die Konfiguration von MOA SP/SS für den Einsatz als Klassenbibliothek.

1.1 Allgemeines

1.1.1 Namenskonventionen

Folgende Namenraum-Präfixe werden in diesem Handbuch zur Kennzeichnung der Namenräume - von XML-Elementen verwendet:

TODO Weitere Namespaces? Aktuell?

+ von XML-Elementen verwendet:

@@ -130,7 +135,7 @@ - + @@ -213,8 +218,14 @@

Präfix	`http://www.w3.org/2000/09/xmldsig#`
moa	`moa`	`http://reference.e-government.gv.at/namespace/moa/20020822#`

2.1.2 Auflösen externer URIs

TODO Update Whitelisting

2.1.2 Auflösen externer URIs

Standardmäßig ist das Auflösen von externen URIs (inkl. localhost) deaktiviert (d.h. keines der nachfolgenden Konfigurationselement cfg:PermitExternalUris bzw. cfg:ForbidExternalUris existiert). Es gibt jedoch zwei Möglichkeiten das Auflösen zu aktivieren bzw. zu

Blacklisting: Hierbei wird das Auflösen von externen URIs erlaubt. Es kann jedoch durch die Angaben einer Blacklist der Zugriff auf bestimmte URIs eingeschränkt werden.
Whitelisting: Hierbei ist das Auflösen von externen URIs weiterhin verboten. Es kann jedoch durch die Angabe einer Whitelist der Zugriff auf bestimmte URIs gestattet werden.

Diese beiden Möglichkeiten stehen wahlweise zur Verfügung, d.h. es kann entweder Blacklisting oder Whitelisting konfiguriert werden.

2.1.2.1 Blacklisting

@@ -226,7 +237,7 @@ -

Name

Erläuterung

Mit diesem Element wird MOA SP bzw. SS mitgeteilt ob das Auflösen externer URIs (inkl. localhost) erlaubt ist. Fehlt dieses Element, so ist das Auflösen externer URIs deaktiviert. Ist dieses Element vorhanden, so ist das Auflösen aller externer URIs aktiviert. Durch einen Blacklist-Mechanismus kann jedoch eingeschränkt werden, dass bestimmte URIs, die sich auf dieser Blacklist befinden, nicht aufgelöst werden. Diese Blacklist kann in dem folgenden Kindelement angegeben werden:

Mit diesem Element wird MOA SP bzw. SS mitgeteilt, dass das Auflösen externer URIs (inkl. localhost) erlaubt ist. Ist dieses Element vorhanden, so ist das Auflösen aller externer URIs aktiviert. Durch einen Blacklist-Mechanismus kann jedoch eingeschränkt werden, dass bestimmte URIs, die sich auf dieser Blacklist befinden, nicht aufgelöst werden. Diese Blacklist kann in dem folgenden Kindelement angegeben werden:

Element cfg:BlackListUri: Dieses optionale und unbegrenzten Element gibt einen Blacklist-Eintrag an und besteht aus folgenden zwei weiteren Kindelementen:

@@ -245,6 +256,28 @@

2.1.2.2 Whitelisting

+ + + + + + + + + + + + + +

Name cfg:Common/cfg:ForbidExternalUris

Gebrauch Null mal bis einmal

Erläuterung

Mit diesem Element wird MOA SP bzw. SS mitgeteilt, dass das Auflösen externer URIs (inkl. localhost) zwar verboten ist, aber durch eine Whitelist entsprechende Ausnahmen angeben werden können. D.h. URIs, die sich auf dieser Whitelist befinden werden aufgelöst. Diese Whitelist kann in dem folgenden Kindelement angegeben werden:

Element cfg:WhiteListUri: Dieses optionale und unbegrenzten Element gibt einen Whitelist-Eintrag an und besteht aus folgenden zwei weiteren Kindelementen:

Element cfg:IP: Dieses Element vom Type xs:string gibt eine IP-Adresse (z.B.: 127.0.0.1) oder einen IP-Adress-Bereich (z.B.: 192.168) an. Bei Angabe einer IP-Adresse werden nur URIs mit exakt dieser IP-Adresse aufgelöst. Bei Angabe eines IP-Adress-Bereichs werden sämtliche URIs, die mit diesem IP-Bereich beginnen aufgelöst (z.B.: alle IPs im Bereich 192.168.0.0 bis 192.168.255.255)
Element cfg:Port: Dieses optionale Element vom Typ xs:int legt eine bestimmte Portnummer fest. Ist eine Portnummer angegeben werden alle URIs mit obiger IP-Adresse und dieser Portnummer aufgelöst. Ist Portnummer angegeben, sind alle Portnummern offen.

2.2 Parameter für MOA SS

2.2.1 Schlüsselspeicher

2.2.1.1 Hardware-Schlüsselspeicher

@@ -327,17 +360,16 @@ Erläuterung -

TODO Update DigestMethod

Mit diesem Element wird in MOA SS eine Schlüsselgruppe definiert. Eine Schlüsselgruppe +

Sinn der Zusammenfassung von mehreren privaten Schlüsseln zu einer Schlüsselgruppe ist +

Sinn der Zusammenfassung von mehreren privaten Schlüsseln zu einer Schlüsselgruppe ist es, dass MOA SS selbst entscheidet, welcher konkrete Schlüssel aus der Schlüsselgruppe zur Erstellung der Signatur verwendet wird. Durch die somit mögliche Parallelisierung (mehrere private Schlüssel werden parallel für Anfragen, die auf die gleiche Schlüsselgruppe - referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern.

+ referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern.

Das Element cfg:SignatureCreation/cfg:KeyGroup hat folgenden Element-Inhalt:

Element cfg:Id: Dieses obligatorische Element vom Typ xs:token enthält @@ -370,10 +402,11 @@

Element cfg:DigestMethodAlgorithm: Dieses optionale Element spezifiert einen Digest-Algorithmus, der für das Erstellen von XML-Signaturen mittels dieser Schlüsselgruppe verwendet werden soll. Der Default-Wert bzw. ein allfällig in Abschnitt "Parameter für XML-Signaturen" definierter Wert, werden dadurch für diese Schlüsselgruppe überschrieben. Mögliche Werte sind dem Element cfg:SignatureCreation/cfg:XMLDSig/cfg:DigestMethodAlgorithm ebenfalls in Abschnitt "Parameter für XML-Signaturen" zu entnehmen.

Um auf einfache Weise für alle in Ihren Schlüsselspeichern enthaltenen privaten Schlüssel die jeweiligen Werte für dsig:X509IssuerName und dsig:X509SerialNumber zu - erhalten, gehen Sie am besten wie folgt vor:

Erfassen Sie in der zentralen Konfigurationsdatei alle Ihre Schlüsselspeicher mit Hilfe der Konfigurationselemente cfg:SignatureCreation/cfg:KeyModules/cfg:HardwareKeyModule bzw. cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule.

Als Inhalt des Elements kann der Kanonisierungs-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:

TODO: Kanonisierungs-Algorithmen entsprechend Kommissionsentscheidung?

http://www.w3.org/TR/2001/REC-xml-c14n-20010315 
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments 
http://www.w3.org/2001/10/xml-exc-c14n# 
http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:

TODO Update Beschreibung hinsichtlich XAdES 1.4.2

http://www.w3.org/2000/09/xmldsig#sha1
-

Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:

TODO Default-wert wenn XAdES 1.4.2?

http://www.w3.org/2000/09/xmldsig#sha1

Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.

http://www.w3.org/2000/09/xmldsig#sha1
+http://www.w3.org/2000/09/xmldsig#sha256
http://www.w3.org/2000/09/xmldsig#sha384
http://www.w3.org/2000/09/xmldsig#sha512

XAdES-Version

Für XAdES Version 1.1.1:

http://www.w3.org/2000/09/xmldsig#sha1

Für XAdES Version 1.4.2:

http://www.w3.org/2000/09/xmldsig#sha256

Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.

2.2.5 Profil für Transformationen

cfg:CreateSignatureEnvironmentProfile weist folgende obligatorische Kindelemene +

cfg:CreateSignatureEnvironmentProfile weist folgende obligatorische Kindelemente auf:

Element Id: Dieses Element vom Typ xs:token enthält @@ -566,7 +601,25 @@ IssuerDN (RFC2253) :

TODO XAdES 1.4.2 Möglichkeit

2.2.7 XAdES Version

Name cfg:SignatureCreation/cfg:XAdES

Gebrauch Null mal bis einmal

Erläuterung

MOA SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur (das Attribut SecurityLayerConformity im CreateXMLSignatureRequest ist auf false gesetzt) oder einer XAdES-Signatur (SecurityLayerConformity=true) gemäß der Security-Layer Spezifikation V1.1. Dieses Element gibt nun an welche XAdES-Version in diesem Fall eingesetzt werden soll. Bei Nichtvorhandensein des Elements wird die bisherige Standardversion XAdES 1.1.1 verwendet. Im folgenden Kindelement kann jedoch eine andere XAdES-Version konfiguriert werden. cfg:XAdES weist daher folgendes obligatorische Kindelement + auf:

Element Version: Dieses Element vom Typ xs:token gibt die zu verwendende XAdES-Version an. Derzeit kann nur die Version 1.4.2 angegeben werden.

2.3 Parameter für MOA SP

2.3.1 diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html index 7c78969c3..57da2b55c 100644 --- a/spss/handbook/handbook/install/install.html +++ b/spss/handbook/handbook/install/install.html @@ -21,14 +21,14 @@

Inhalt

-
Übersicht
+
Übersicht

Webservice

Basisinstallation

Einführung
Einführung

Installation

Vorbereitung
Referenzierte Software

1 Übersicht

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 Installation der beiden Module als Webservice oder als Klassenbibliothek, sowie die Einrichtung der Systemumgebung.

2 Webservice

Dieser Abschnitt beschreibt die Installation von MOA SP/SS als Webservice. Im ersten Unterkapitel wird eine minimale Basisinstallation beschrieben. Das zweite Unterkapitel zeigt eine Reihe von optionalen Erweiterungsmöglichkeiten auf.

2.1 Basisinstallation

2.1.1 Einführung

Die Mindestanforderungen für die Basisinstallation sind:

2.1.2.2 Konfiguration von Apache Tomcat

Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert.

2.1.2.2.1 Konfiguration des HTTP Connectors

TODO: server.xml auf 7 umstellen

Die Datei $MOA_SPSS_INST/tomcat/server.xml enthält eine minimale Tomcat-Konfiguration für Apache Tomcat 7, die ausschließlich den Connector für HTTP auf Port 8080 freischaltet. Durch Kopieren dieser Datei nach $CATALINA_HOME/conf/server.xml kann Tomcat mit dieser Konfiguration gestartet werden. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.

2.1.2.2.2 Konfiguration des HTTPS Connectors

Die Tomcat Default-Konfiguration schaltet ausschließlich den Connector für HTTP auf Port 8080 frei. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.

2.1.2.2.2 Konfiguration des HTTPS Connectors

Nutzt ein Kunde MOA SP, ist es für ihn wichtig, die Identität des Webservice eindeutig feststellen zu können, denn er vertraut dem Webservice ja die Prüfung einer elektronischen Signatur an.

2.2.1.1.1 Konfiguration von mod_jk im MS IIS

Für die Kommunikation des MS IIS mit dem im Tomcat eingerichteten MOA SP/SS Webservice wird das ISAPI-Modul von mod_jk im MS IIS installiert und konfiguriert. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk IIS HowTo. Beispiele für workers.properties und uriworkermap.properties Dateien liegen im Verzeichnis $MOA_SPSS_INST/tomcat bei.

2.2.1.1.2 Konfiguration von Tomcat

TODO: Update server.mod_jk.xml

Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels mod_jk weiterleitet werden, muss in $CATALINA_HOME/conf/server.xml der AJP 1.3 Connector aktiviert werden. Im Gegenzug können die Konnektoren für HTTP und HTTPS deaktiviert werden. Das geschieht am einfachsten durch Ein- bzw. Auskommentieren der entsprechenden Connector Konfigurations-Elemente in dieser Datei. Die Datei $MOA_SPSS_INST/tomcat/server.mod_jk.xml enthält eine Konfiguration, die ausschließlich den Port für den AJP 1.3 Connector offen lässt.

Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels mod_jk weiterleitet werden, muss in $CATALINA_HOME/conf/server.xml der AJP Connector aktiviert werden. Im Gegenzug können die Konnektoren für HTTP und HTTPS deaktiviert werden. Das geschieht am einfachsten durch Ein- bzw. Auskommentieren der entsprechenden Connector Konfigurations-Elemente in dieser Datei.

2.2.1.1.3 Konfiguration von SSL

Die Dokumentation zum Einrichten von SSL auf dem MS IIS steht nach Installation des IIS unter http://localhost/iisHelp/ oder aber auch auf den Webseiten von Mircrosoft zur Verfügung.

2.2.1.2 Apache

Den MOA SP/SS Webservices kann ein Apache Webserver vorgeschaltet sein. Das Prinzip funktioniert wie bei MS IIS, auch hier wird mod_jk für die Kommunikation zwischen Webserver und Tomcat eingesetzt. Die angeführten Konfigurationsschritte gehen von einer Standard-Installation des Apache Webservers aus.

2.2.1.2.1 Konfiguration von mod_jk im Apache

Um das MOA-SPSS Webservice hinter einem Apache Webserver zu betreiben, ist die Konfiguration des Apache-Moduls mod_jk erforderlich. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk Apache HowTo. Ein Beispiel für eine workers.properties Datei liegt im Verzeichnis $MOA_SPSS_INST/tomcat bei.

Verwendung des Webservices

XML-Requests

Erstellung einer XML-Signatur
1. Erstellung einer CMS bzw. CAdES-Signatur
2. Erstellung einer XML bzw. XAdES-Signatur +
  +

Prüfung einer CMS-Signatur

Prüfung einer CMS bzw. CAdES-Signatur +
1. Einfaches Beispiel
2. Erweitertes Beispiel

Prüfung einer XML-Signatur

Prüfung einer XML bzw. XAdES-Signatur +

Einfaches Beispiel
Erweitertes Beispiel
Prüfung eines XMLDSIG-Manifests

2.1 XML-Requests

TODO Erstellung einer CMS/CAdES Signatur

2.1.1 Erstellung einer XML-Signatur

2.1.1.1 Einfaches Beispiel

2.1.1 Erstellung einer CMS bzw. CAdES-Signatur

2.1.1.1 Einfaches Beispiel

TODO

2.1.1.1 Erweitertes Beispiel

TODO

2.1.2 Erstellung einer XML bzw. XAdES-Signatur

MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.1. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele).

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 Konfiguration der XAdES Version).

2.1.2.1 Einfaches Beispiel

Request

CreateXMLSignatureRequest.Simple.xml ist ein einfacher XML-Request zur Erzeugung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert:

  <KeyIdentifier>KG_allgemein</KeyIdentifier>

KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen.

  <SingleSignatureInfo SecurityLayerConformity="false">

Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.1 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.

    <DataObjectInfo Structure="enveloping">
+   Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.1  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).
+    <DataObjectInfo Structure="enveloping">
       <DataObject>
         <XMLContent>Diese Daten werden signiert.<XMLContent>
       </DataObject>
-   
+ 
    Für jedes Daten-Objekt, das in die XML-Signatur als dsig:Reference aufgenommen werden soll, muss ein DataObjectInfo Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten in die Signatur in ein dsig:Object Element integriert werden sollen (Structure="enveloping"), oder über einen URL referenziert werden sollen (Structure="detached"). 
    Im Fall von Structure="enveloping" muss im nachfolgenden DataObject Element entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit in einem der Elemente Base64Content (enthält Daten in Base64 kodierter Form) oder XMLContent (enthält Daten als beliebiges XML-Fragment) oder LocRefContent (enthält eine URL, von der SS die Daten beziehen soll; in diesem Fall also gleichwertig wie ein gesetztes Attribut Reference) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig einem der Elemente Base64Content oder XMLContent oder LocRefContent ist nicht erlaubt.
   Im Fall von Structure="detached" muss das Attribut Reference im nachfolgenden DataObject Element gesetzt sein. Es enthält jene URL, die  zur Referenzierung der Daten als Wert von dsig:Reference/@URI in die XML-Signatur aufgenommen wird. Die Angabe eines der Element Base64Content oder XMLContent oder LocRefContent ist optional. Unterbleibt die Angabe, bezieht SS die Daten von der URL im Attribut Reference. Wird eines der Elemente verwendet, bezieht SS die Daten durch Analyse des angegebenen Elements (siehe obiger Absatz). 
@@ -122,7 +137,7 @@
     </dsig:Signature>
  </SignatureEnvironment>
</CreateXMLSignatureResponse>

CreateXMLSignatureResponse enthält je erzeugter Signatur ein Element SignatureEnvironment (in diesem Fall genau ein Element). SignatureEnvironment enthält die von SS erzeugte XML-Signatur, die im obigen Request spezifiziert wurde. Man erkennt, dass die XML-Signatur genau ein Daten-Objekt unterzeichnet (ein dsig:Reference Element ist enthalten). Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping), und zwar in einem dsig:Object Element.

2.1.1.2 Angabe der zu signierenden Daten

2.1.2.2 Angabe der zu signierenden Daten

Request

Dieses Beispiel stellt die vielfältigen Möglichkeiten vor, wie MOA SS mitgeteilt werden kann, welche Daten signiert (wenn keine Transformationen angegeben werden) bzw. als Eingangsdaten für die Berechnung der Transformationen verwendet werden sollen (wenn Transformationen angegeben werden).

Mit CreateXMLSignatureRequest.Refs.xml sollen insgesamt neun Datenobjekte signiert werden:

Das fünfte dsig:Object enthält das dsig:Manifest, das von MOA SS auf Grund des ersten bzw. fünften DataObjectInfo des Requests erstellt wurde. Darin enthalten sind die zum ersten und fünten DataObjectInfo korrespondierenden dsig:Reference Elemente. Die Daten für die erste im dsig:Manifest enthaltene dsig:Reference wurden aus dem Base64Content Element des ersten DataObjectInfo entnommen, jene für die zweite dsig:Reference aus dem Base64Content Element des fünften DataObjectInfo. Der Wert des URI Attributs der zweiten dsig:Reference wurde aus dem DataObject/@Reference des fünften DataObjectInfo übernommen.

2.1.1.3 Transformationen

2.1.2.3 Transformationen

Request

Dieses Beispiel (CreateXMLSignatureRequest.Transforms.xml) stellt die wichtigsten Transformationen vor, die von MOA SS bei der Erstellung einer Signatur verwendet werden können. Eine Transformation bzw. eine Kette mehrerer hintereinandergeschalteter Transformationen werden auf die Referenz-Eingangsdaten (also jene Daten, die in DataObjectInfo/DataObject angegeben werden) angewendet; das Ergebnis fließt dann in die Hashwert-Berechnung ein.

<CreateXMLSignatureRequest
@@ -536,7 +551,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
         </dsig:Reference>

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

2.1.2.4 Ergänzungsobjekte

Request

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.

@@ -602,8 +617,8 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 Auch für das Auflösen eines Verweises in einer DTD kann in analoger Weise von Ergänzungsobjekten Gebrauch gemacht werden. 
 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.3 Prüfung einer CMS bzw. CAdES-Signatur
+2.1.3.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.
 @@ -650,7 +665,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
   </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 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
+2.1.3.2 Erweitertes Beispiel
 Request
 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. 
 @@ -672,8 +687,8 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
 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
+2.1.4 Prüfen einer XML-Signatur
+2.1.4.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.
 @@ -748,7 +763,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
   </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 
+2.1.4.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.
 @@ -816,7 +831,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife
 </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 
+2.1.4.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  XML-Signatur vorhandenden Manifests nach XMLDSig. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
 @@ -892,7 +907,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife
 </VerifyXMLSignatureResponse>
 

 Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).
-2.3.1.4 Ergänzungsobjekte 
+2.1.4.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 enthaltenden 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.
 @@ -960,7 +975,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 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 
+2.1.4.5 Signatur-Manifest des Security-Layers 
 Request
 Dieses Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.SigManifest.xml) demonstriert die Überprüfung des Zusammenhangs zwischen den Referenz-Eingangsdaten und den Hash-Eingangsdaten für die dsig:Reference-Elemente einer XML-Signatur. Mit Hilfe dieser Prüfung kann eine Anwendung feststellen, ob bei der Erstellung einer XML-Signatur jene Transformationen bzw. auch jene inkludierten Stylesheets (vgl. Implizite Transformationsparameter) einer XSLT-Transformation angewendet wurden, welche die Anwendung vorgegeben hat. Bei erfolgreicher Prüfung dieses Zusammenhangs kann die Anwendung die Referenz-Eingangsdaten einer dsig:Reference als gesichert ansehen, obwohl eigentlich die Hash-Eingangsdaten durch die Signatur gesichert sind. Dies ist jenen Fällen sinnvoll, in denen die Anwendung grundsätzlich mit XML-Daten arbeitet, diese Daten jedoch für das Signieren durch eine Person in ein für diese Person verständliches Format wie z.B. HTML umgewandelt werden sollen.
 @@ -1139,28 +1154,23 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 2.2.2 Gemeinsamkeiten
 Dieser Abschnitt beschreibt die Gemeinsamkeiten aller drei Varianten des Webservice-Clients. 
 Zunächst einmal benötigen alle drei Varianten die folgenden Java-Bibliotheken, die im Ordner clients/webservice/lib/ dieses Handbuchs bereits enthalten sind:
-TODO Update Versions
-TODO kein lib Verzeichnis
 
-    
-      
-      
+    
+      
+      
+    
-      
+      
-      
-    
-    
-      
-      
+      
   
     
       Java-Bibliothek
       Bemerkung
J2SE  J2SE 1.3.1 SDK oder J2SE 1.4.2 SDK oder J2SE 5.0 SDK. 
     
Java SE Java Standard Edition (Software Development Kit bzw. Java Runtime Environment) 
     
       Apache Xerces XML-Parser, Version 2.0.2 oder höher; nicht nötig wenn JDSE 1.4.2 oder höher verwendet wird. XML-Parser, Version 2.0.2 oder höher
     
     
       AXIS Framework Webservice-Framework, Version 1.1.
JSSE Java Secure Socket Extension, Version 1.0.3 oder höher; nur notwendig für die Varianten HTTPServerAuth und HTTPClientAuth. Webservice-Framework, ab Version 1.1.
     
   
 
@@ -1178,13 +1188,13 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
   Der zweite Kommandozeilenparameter enthält Pfad und Dateiname einer Java-Properties-Datei, die die weiteren Konfigurationsparameter für den Webservice-Client enthält. Ein relativer Pfad wird als relativ zum Arbeitsverzeichnis der Java Virtual Machine interpretiert. Genaue Infos zu den möglichen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation der jeweiligen Variante des Webservice-Clients. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.

Java-Bibliothek	Bemerkung
J2SE	J2SE 1.3.1 SDK oder J2SE 1.4.2 SDK oder J2SE 5.0 SDK.
Java SE	Java Standard Edition (Software Development Kit bzw. Java Runtime Environment)
Apache Xerces	XML-Parser, Version 2.0.2 oder höher; nicht nötig wenn JDSE 1.4.2 oder höher verwendet wird.	XML-Parser, Version 2.0.2 oder höher
AXIS Framework	Webservice-Framework, Version 1.1.
JSSE	Java Secure Socket Extension, Version 1.0.3 oder höher; nur notwendig für die Varianten `HTTPServerAuth` und `HTTPClientAuth`.	Webservice-Framework, ab Version 1.1.


 2.2.3 Besonderheiten von HTTPSServerAuth.java
-Diese Variante des Webservice-Clients verwendet JSSE, um im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server-Authentifizierung zum MOA SP/SS Server aufzubauen. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.
-Die Konfiguration von JSSE (Speicher für die vertrauenswürdigen Serverzertifikate, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSServerAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.
-Falls Sie Probleme beim SSL-Verbindungsaufbau zwischen Webservice-Client und MOA SP/SS Webservice haben, empfiehlt sich die Aktivierung des JSSE Loggings. Das Setzen der dafür notwendigen Java System Property ist im Quellcode von HTTPSServerAuth.java bereits enthalten, jedoch auskommentiert. Suchen Sie einfach nach dem String javax.net.debug, um zur entsprechenden Stelle im Quellcode zu gelangen. 
+Diese Variante des Webservice-Clients baut im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server-Authentifizierung zum MOA SP/SS Server auf. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.
+Die entsprechende Konfiguration (Speicher für die vertrauenswürdigen Serverzertifikate, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSServerAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.
+Falls Sie Probleme beim SSL-Verbindungsaufbau zwischen Webservice-Client und MOA SP/SS Webservice haben, empfiehlt sich die Aktivierung des SSL Loggings. Das Setzen der dafür notwendigen Java System Property ist im Quellcode von HTTPSServerAuth.java bereits enthalten, jedoch auskommentiert. Suchen Sie einfach nach dem String javax.net.debug, um zur entsprechenden Stelle im Quellcode zu gelangen. 
 2.2.4 Besonderheiten von HTTPSClientAuth.java 
-Diese Variante des Webservice-Clients verwendet JSSE, um im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server- und Client-Authentifizierung zum MOA SP/SS Server aufzubauen. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.
-Die gegenüber Abschnitt 2.2.3 zusätzlich notwendige Konfiguration von JSSE (Speicher für das SSL-Client-Zertifikat sowie den dazugehörigen privaten Schlüssel, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSClientAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.
-Beachten Sie bitte auch den Hinweis zum JSSE Logging aus Abschnitt 2.2.3.
+Diese Variante des Webservice-Clients baut im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server- und Client-Authentifizierung zum MOA SP/SS Server auf. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.
+Die gegenüber Abschnitt 2.2.3 zusätzlich notwendige Konfiguration (Speicher für das SSL-Client-Zertifikat sowie den dazugehörigen privaten Schlüssel, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSClientAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.
+Beachten Sie bitte auch den Hinweis zum SSL Logging aus Abschnitt 2.2.3.
 3 Verwendung der Klassenbibliothek
 Neben dem Betrieb von MOA SP/SS als Webservice ist als Alternative auch die Verwendung von MOA SP/SS als Klassenbibliothek möglich, also die direkte Einbindung in ein Java-Programm unter Verwendung des Application Programmers Interface (API) von MOA SP/SS. 
 3.1 Vorbereitung
@@ -1205,7 +1215,6 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
 
A Referenzierte Software
 Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:
-TODO Update Versions
 
@@ -1217,21 +1226,13 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
       
-      
+      
-      
-      
-    
-    
-      
-      
-    
-    
-      
-      
-    
+    
+    
+  
   
     XML-Parser aus dem Apache Project
     
     Apache Axis Apache Axis
       Webservice-Framework  aus dem Apache Project
     
     J2SE 1.4.2 SDK/JRE Java 2 Standard Edition in der Version 1.4.2 (Software Development Kit bzw. Java Runtime Environment) 
J2SE 5.0 SDK/JRE Java 2 Standard Edition in der Version 5.0 (Software Development Kit bzw. Java Runtime Environment) 
JSSE Java Secure Socket Extension 
Java SE Java Standard Edition (Software Development Kit bzw. Java Runtime Environment) 
   
 
  
-- 
cgit v1.2.3


From a544afcf4ad581ab7b76e85dc597ccf5643cd55a Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Mon, 6 May 2013 21:43:00 +0200
Subject: - Update MOA-SS Interface (CreateCMSignatureRequest) - Whitelisting
 in MOA-SPSS

---
 spss/handbook/clients/api/.classpath               |  82 ++--
 .../api/.settings/org.eclipse.jdt.core.prefs       |  12 +-
 spss/handbook/clients/referencedData/.classpath    |  10 +-
 .../.settings/org.eclipse.jdt.core.prefs           |  12 +-
 .../.settings/org.eclipse.wst.common.component     |   5 +-
 .../org.eclipse.wst.common.project.facet.core.xml  |   4 +-
 spss/handbook/clients/webservice/.classpath        |   8 +-
 .../.settings/org.eclipse.jdt.core.prefs           |  12 +-
 ...rifyXMLSignatureRequest.FileURIs.DataObject.xml |   2 +-
 ...SignatureRequest.FileURIs.ServerSupplements.xml |   2 +-
 ...ifyXMLSignatureRequest.FileURIs.Supplements.xml |   2 +-
 ...AIK-Test-Root-CA_20080114-20180114.SerNo.01.der | Bin 0 -> 880 bytes
 spss/handbook/handbook/intro/intro.html            |   8 +-
 spss/handbook/handbook/spec/MOA-SPSS-1.3.wsdl      | 105 -----
 spss/handbook/handbook/spec/MOA-SPSS-1.3.xsd       | 469 --------------------
 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.wsdl    | 128 ++++++
 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd     | 474 +++++++++++++++++++++
 spss/handbook/handbook/usage/usage.html            |  23 +-
 18 files changed, 700 insertions(+), 658 deletions(-)
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/test/IAIK-Test-Root-CA_20080114-20180114.SerNo.01.der
 delete mode 100644 spss/handbook/handbook/spec/MOA-SPSS-1.3.wsdl
 delete mode 100644 spss/handbook/handbook/spec/MOA-SPSS-1.3.xsd
 create mode 100644 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.wsdl
 create mode 100644 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd

(limited to 'spss/handbook')

diff --git a/spss/handbook/clients/api/.classpath b/spss/handbook/clients/api/.classpath
index cb29bfb96..95a3df914 100644
--- a/spss/handbook/clients/api/.classpath
+++ b/spss/handbook/clients/api/.classpath
@@ -1,41 +1,45 @@
 
 
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
\ No newline at end of file
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+		
+			
+		
+	
+	
+
diff --git a/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs b/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs
index 48249af31..c788ee346 100644
--- a/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs
+++ b/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs
@@ -1,6 +1,8 @@
-#Thu Dec 27 15:45:23 CET 2012
-org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
-org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 eclipse.preferences.version=1
-org.eclipse.jdt.core.compiler.source=1.5
-org.eclipse.jdt.core.compiler.compliance=1.5
+org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
+org.eclipse.jdt.core.compiler.compliance=1.7
+org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
+org.eclipse.jdt.core.compiler.source=1.7
diff --git a/spss/handbook/clients/referencedData/.classpath b/spss/handbook/clients/referencedData/.classpath
index 0173dfd90..d888b90e9 100644
--- a/spss/handbook/clients/referencedData/.classpath
+++ b/spss/handbook/clients/referencedData/.classpath
@@ -1,5 +1,9 @@
 
 
-  
-  
-
\ No newline at end of file
+	
+		
+			
+		
+	
+	
+
diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs b/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs
index 86859a78d..c788ee346 100644
--- a/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs
+++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs
@@ -1,6 +1,8 @@
-#Thu Dec 27 15:45:22 CET 2012
-org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
-org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 eclipse.preferences.version=1
-org.eclipse.jdt.core.compiler.source=1.5
-org.eclipse.jdt.core.compiler.compliance=1.5
+org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
+org.eclipse.jdt.core.compiler.compliance=1.7
+org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
+org.eclipse.jdt.core.compiler.source=1.7
diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component
index 0929e364c..2063ba643 100644
--- a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component
+++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component
@@ -1,8 +1,7 @@
-
-
+
   
     
     
     
   
-
\ No newline at end of file
+
diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml
index 564572b10..47b82b84e 100644
--- a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml
+++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml
@@ -3,5 +3,5 @@
   
   
   
-  
-
\ No newline at end of file
+  
+
diff --git a/spss/handbook/clients/webservice/.classpath b/spss/handbook/clients/webservice/.classpath
index d687b9b02..b75cb2821 100644
--- a/spss/handbook/clients/webservice/.classpath
+++ b/spss/handbook/clients/webservice/.classpath
@@ -12,15 +12,15 @@
 			
 		
 	
-	
+	
 		
 			
+			
 		
 	
-	
+	
 		
-			
-			
+			
 		
 	
 	
diff --git a/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs b/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs
index 48249af31..c788ee346 100644
--- a/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs
+++ b/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs
@@ -1,6 +1,8 @@
-#Thu Dec 27 15:45:23 CET 2012
-org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
-org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 eclipse.preferences.version=1
-org.eclipse.jdt.core.compiler.source=1.5
-org.eclipse.jdt.core.compiler.compliance=1.5
+org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
+org.eclipse.jdt.core.compiler.compliance=1.7
+org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
+org.eclipse.jdt.core.compiler.source=1.7
diff --git a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.DataObject.xml b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.DataObject.xml
index 5b4b61938..26fe42d8f 100644
--- a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.DataObject.xml
+++ b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.DataObject.xml
@@ -3,7 +3,7 @@
 	xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
 	xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-	xsi:schemaLocation="http://reference.e-government.gv.at/namespace/moa/20020822# file:D:/_java/moa-idspss/trunk/common/src/main/resources/resources/schemas/MOA-SPSS-1.3.xsd
+	xsi:schemaLocation="http://reference.e-government.gv.at/namespace/moa/20020822# file:D:/_java/moa-idspss/trunk/common/src/main/resources/resources/schemas/MOA-SPSS-1.5.2.xsd
 	                http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd">
 	
 		
diff --git a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.ServerSupplements.xml b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.ServerSupplements.xml
index 4b9fa43fe..417c29b3a 100644
--- a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.ServerSupplements.xml
+++ b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.ServerSupplements.xml
@@ -3,7 +3,7 @@
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-  xsi:schemaLocation="http://reference.e-government.gv.at/namespace/moa/20020822# file:D:/_java/moa-idspss/trunk/common/src/main/resources/resources/schemas/MOA-SPSS-1.3.xsd
+  xsi:schemaLocation="http://reference.e-government.gv.at/namespace/moa/20020822# file:D:/_java/moa-idspss/trunk/common/src/main/resources/resources/schemas/MOA-SPSS-1.5.2.xsd
                   http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd">
   
     
diff --git a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.Supplements.xml b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.Supplements.xml
index 27929cefd..ab8c1efd1 100644
--- a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.Supplements.xml
+++ b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.FileURIs.Supplements.xml
@@ -3,7 +3,7 @@
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-  xsi:schemaLocation="http://reference.e-government.gv.at/namespace/moa/20020822# file:D:/_java/moa-idspss/trunk/common/src/main/resources/resources/schemas/MOA-SPSS-1.3.xsd
+  xsi:schemaLocation="http://reference.e-government.gv.at/namespace/moa/20020822# file:D:/_java/moa-idspss/trunk/common/src/main/resources/resources/schemas/MOA-SPSS-1.5.2.xsd
                   http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd">
 	
 		
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/test/IAIK-Test-Root-CA_20080114-20180114.SerNo.01.der b/spss/handbook/conf/moa-spss/trustProfiles/test/IAIK-Test-Root-CA_20080114-20180114.SerNo.01.der
new file mode 100644
index 000000000..38c2de589
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/test/IAIK-Test-Root-CA_20080114-20180114.SerNo.01.der differ
diff --git a/spss/handbook/handbook/intro/intro.html b/spss/handbook/handbook/intro/intro.html
index a01a825b2..af479d2c5 100644
--- a/spss/handbook/handbook/intro/intro.html
+++ b/spss/handbook/handbook/intro/intro.html
@@ -32,14 +32,14 @@
   1 Allgemeines
    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.
   TODO: CAdES auf SL1.2x aufbauend - wie siehts mir Rest aus?
-  Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V1.3) detailliert beschrieben. Da diese Spezifikation auf der  Schnittstellenspezifikation des Security-Layers (V 1.1) aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. 
+  Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V2.0) detailliert beschrieben. Da diese Spezifikation auf der  Schnittstellenspezifikation des Security-Layers (V 1.2x) TODO aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. 
 2 Modul Serversignatur (SS) 
-   Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die  Schnittstellenspezifikation des Security-Layers (V 1.1). 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.
+   Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die  Schnittstellenspezifikation des Security-Layers (V 1.2x TODO). 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.
       Der Zugriff auf einzelne Signaturschlüssel in MOA SS kann basierend auf dem für TLS-Client-Authentisierung verwendeten Zertifikat eingeschränkt werden. 
       Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen. 
   3 Modul Signaturprüfung (SP) 
-   Das Modul Signaturprüfung (SP) dient zum Überprüfen von XML-Signaturen und CMS-Signaturen. 
-  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 Schnittstellenspezifikation des Security-Layers (V 1.1) entsprechen (vgl. Signaturmanifest). 
+   Das Modul Signaturprüfung (SP) dient zum Überprüfen von XML-Signaturen und CMS-Signaturen sowie den fortgeschrittenen Signaturen XAdES (TODO Link + Versionen) und CAdES (TODO Link + Versionen).
+  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 Schnittstellenspezifikation des Security-Layers (V 1.2x TODO) entsprechen (vgl. Signaturmanifest). 
       Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen.
 
 
diff --git a/spss/handbook/handbook/spec/MOA-SPSS-1.3.wsdl b/spss/handbook/handbook/spec/MOA-SPSS-1.3.wsdl
deleted file mode 100644
index 8ae1c1ff4..000000000
--- a/spss/handbook/handbook/spec/MOA-SPSS-1.3.wsdl
+++ /dev/null
@@ -1,105 +0,0 @@
-
-
-
-  
-  
-    
-  
-  
-    
-  
-  
-    
-  
-  
-    
-  
-  
-    
-  
-  
-    
-  
-  
-    
-  
-  
-    
-      
-      
-      
-    
-  
-  
-    
-      
-      
-      
-    
-    
-      
-      
-      
-    
-  
-  
-    
-    
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-    
-  
-  
-    
-    
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-    
-    
-      
-      
-        
-      
-      
-        
-      
-      
-        
-      
-    
-  
-  
-    
-      
-      
-    
-  
-  
-    
-      
-      
-    
-  
-
diff --git a/spss/handbook/handbook/spec/MOA-SPSS-1.3.xsd b/spss/handbook/handbook/spec/MOA-SPSS-1.3.xsd
deleted file mode 100644
index 756b51279..000000000
--- a/spss/handbook/handbook/spec/MOA-SPSS-1.3.xsd
+++ /dev/null
@@ -1,469 +0,0 @@
-
-
-
-  
-  
-  
-  
-  
-    
-      
-        
-      
-    
-  
-  
-    
-      
-      
-        
-          Ermöglichung der Stapelsignatur durch wiederholte Angabe dieses Elements
-        
-        
-          
-            
-              
-                
-                  
-                    
-                  
-                
-              
-            
-            
-              
-                
-                  
-                  
-                    
-                      Auswahl: Entweder explizite Angabe des Signaturorts sowie ggf. sinnvoller Supplements im Zshg. mit der Signaturumgebung, oder Verweis auf ein benanntes Profil
-                    
-                    
-                    
-                  
-                
-              
-            
-          
-          
-        
-      
-    
-  
-  
-  
-    
-      
-        Kardinalität 1..oo erlaubt die Antwort auf eine Stapelsignatur-Anfrage
-      
-      
-        
-          Resultat, falls die Signaturerstellung erfolgreich war
-        
-        
-          
-            
-          
-        
-      
-      
-    
-  
-  
-  
-  
-  
-    
-      
-        
-          
-        
-      
-    
-  
-  
-    
-      
-      
-      
-      
-        
-          mit diesem Profil wird eine Menge von vertrauenswürdigen Wurzelzertifikaten spezifiziert
-        
-      
-    
-  
-  
-  
-  
-    
-      
-        
-          only ds:X509Data and RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any;publicAuthority is included as X509Data/any
-        
-      
-      
-      
-    
-  
-  
-  
-  
-  
-    
-      
-      
-        
-          
-            
-            
-          
-        
-      
-      
-        
-        
-      
-      
-        
-          
-            
-              
-                Pro dsig:Reference-Element in der zu überprüfenden XML-Signatur muss hier ein ReferenceInfo-Element erscheinen. Die Reihenfolge der einzelnen ReferenceInfo Elemente entspricht jener der dsig:Reference Elemente in der XML-Signatur.
-              
-            
-          
-          
-        
-      
-      
-      
-        
-          mit diesem Profil wird eine Menge von vertrauenswürdigen Wurzelzertifikaten spezifiziert
-        
-      
-    
-  
-  
-  
-  
-    
-      
-        
-          only ds:X509Data and ds:RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any; PublicAuthority is included as X509Data/any
-        
-      
-      
-      
-      
-      
-      
-      
-    
-  
-  
-    
-  
-  
-    
-      
-        
-          
-            
-              
-              
-            
-          
-        
-        
-      
-    
-  
-  
-    
-      
-      
-      
-    
-  
-  
-    
-      
-        
-          
-        
-      
-    
-  
-  
-    
-      
-        
-          
-            
-          
-        
-      
-      
-        
-          Auswahl: Entweder explizite Angabe EINER Transformationskette inklusive ggf. sinnvoller Supplements oder Verweis auf ein benanntes Profil
-        
-        
-        
-      
-    
-    
-      
-        
-          
-          
-        
-      
-    
-  
-  
-    
-      
-      
-    
-  
-  
-    
-      
-      
-    
-  
-  
-    
-      
-      
-    
-  
-  
-    
-      
-        
-          
-        
-      
-    
-  
-  
-    
-      
-      
-    
-  
-  
-    
-      
-        
-          
-          
-        
-      
-    
-  
-  
-    
-      
-        
-          
-          
-        
-      
-    
-  
-  
-    
-      
-        
-          
-          
-        
-      
-    
-  
-  
-    
-      
-        
-          
-          
-          
-        
-      
-    
-  
-  
-  
-    
-      Resultat, falls die Signaturerstellung gescheitert ist
-    
-  
-  
-    
-      
-      
-    
-  
-  
-  
-    
-  
-  
-    
-      
-      
-    
-  
-  
-    
-  
-  
-    
-      
-    
-  
-  
-    
-      
-        
-      
-    
-  
-  
-    
-      
-      
-      
-    
-  
-  
-    
-      
-        
-          
-          
-        
-      
-    
-  
-  
-    
-      
-        
-      
-    
-  
-  
-    
-      
-        
-          
-          
-          
-        
-        
-      
-    
-  
-  
-    
-      
-        Ein oder mehrere Transformationswege können von der Applikation an MOA mitgeteilt werden. Die zu prüfende Signatur hat zumindest einem dieser Transformationswege zu entsprechen. Die Angabe kann explizit oder als Profilbezeichner erfolgen.
-      
-      
-      
-        
-          Profilbezeichner für einen Transformationsweg
-        
-      
-    
-  
-  
-  
-  
-    
-      
-    
-  
-  
-    
-      
-        
-      
-    
-  
-  
-    
-      
-    
-  
-  
-    
-      
-        
-      
-    
-  
-  
-    
-      
-        Die Angabe des Transformationsparameters (explizit oder als Hashwert) kann unterlassen werden, wenn die Applikation von der Unveränderlichkeit des Inhalts der in "Transformationsparamter", Attribut "URI" angegebenen URI ausgehen kann.
-      
-      
-        
-          Der Transformationsparameter explizit angegeben.
-        
-      
-      
-        
-          Der Hashwert des Transformationsparameters.
-        
-        
-          
-            
-            
-          
-        
-      
-    
-    
-  
-  
-    
-      
-        
-        
-      
-    
-  
-  
-    
-      Explizite Angabe des Transformationswegs
-    
-    
-      
-        
-        
-          
-            Alle impliziten Transformationsparameter, die zum Durchlaufen der oben angeführten Transformationskette bekannt sein müssen, müssen hier angeführt werden. Das Attribut "URI" bezeichnet den Transformationsparameter in exakt jener Weise, wie er in der zu überprüfenden Signatur gebraucht wird.
-          
-        
-      
-    
-  
-  
-  
-  
-    
-      
-        
-        
-      
-    
-  
-
diff --git a/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.wsdl b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.wsdl
new file mode 100644
index 000000000..135f26f68
--- /dev/null
+++ b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.wsdl
@@ -0,0 +1,128 @@
+
+
+
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+	
+	
+		
+			
+			
+			
+		
+		
+			
+			
+			
+		
+	
+	
+		
+			
+			
+			
+		
+		
+			
+			
+			
+		
+	
+	
+		
+		
+			
+			
+				
+			
+			
+				
+			
+			
+				
+			
+		
+		
+			
+			
+				
+			
+			
+				
+			
+			
+				
+			
+		
+	
+	
+		
+		
+			
+			
+				
+			
+			
+				
+			
+			
+				
+			
+		
+		
+			
+			
+				
+			
+			
+				
+			
+			
+				
+			
+		
+	
+	
+		
+			
+		
+	
+	
+		
+			
+		
+	
+
diff --git a/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd
new file mode 100644
index 000000000..137ad6deb
--- /dev/null
+++ b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd
@@ -0,0 +1,474 @@
+
+
+
+	
+	
+	
+	
+	
+		
+	
+	
+	
+	
+		
+			
+				
+			
+		
+	
+	
+		
+			
+			
+				
+					Ermöglichung der Stapelsignatur durch wiederholte Angabe dieses Elements
+				
+				
+					
+						
+							
+								
+									
+										
+									
+								
+							
+						
+						
+							
+								
+									
+									
+										
+											Auswahl: Entweder explizite Angabe des Signaturorts sowie ggf. sinnvoller Supplements im Zshg. mit der Signaturumgebung, oder Verweis auf ein benanntes Profil
+										
+										
+										
+									
+								
+							
+						
+					
+					
+				
+			
+		
+	
+	
+	
+		
+			
+				Kardinalität 1..oo erlaubt die Antwort auf eine Stapelsignatur-Anfrage
+			
+			
+				
+					Resultat, falls die Signaturerstellung erfolgreich war
+				
+				
+					
+						
+					
+				
+			
+			
+		
+	
+	
+	
+	
+	
+		
+			
+				
+					
+				
+			
+		
+	
+	
+		
+			
+			
+			
+			
+				
+					mit diesem Profil wird eine Menge von vertrauenswürdigen Wurzelzertifikaten spezifiziert
+				
+			
+		
+	
+	
+	
+	
+		
+			
+				
+					only ds:X509Data and RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any;publicAuthority is included as X509Data/any
+				
+			
+			
+			
+		
+	
+	
+	
+	
+	
+		
+			
+			
+				
+					
+						
+						
+					
+				
+			
+			
+				
+				
+			
+			
+				
+					
+						
+							
+								Pro dsig:Reference-Element in der zu überprüfenden XML-Signatur muss hier ein ReferenceInfo-Element erscheinen. Die Reihenfolge der einzelnen ReferenceInfo Elemente entspricht jener der dsig:Reference Elemente in der XML-Signatur.
+							
+						
+					
+					
+				
+			
+			
+			
+				
+					mit diesem Profil wird eine Menge von vertrauenswürdigen Wurzelzertifikaten spezifiziert
+				
+			
+		
+	
+	
+	
+	
+		
+			
+				
+					only ds:X509Data and ds:RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any; PublicAuthority is included as X509Data/any
+				
+			
+			
+			
+			
+			
+			
+			
+		
+	
+	
+		
+	
+	
+		
+			
+				
+					
+						
+							
+							
+						
+					
+				
+				
+			
+		
+	
+	
+		
+			
+			
+			
+		
+	
+	
+		
+			
+				
+					
+				
+			
+		
+	
+	
+		
+			
+				
+					
+						
+					
+				
+			
+			
+				
+					Auswahl: Entweder explizite Angabe EINER Transformationskette inklusive ggf. sinnvoller Supplements oder Verweis auf ein benanntes Profil
+				
+				
+				
+			
+		
+		
+			
+				
+					
+					
+				
+			
+		
+	
+	
+		
+			
+			
+		
+	
+	
+		
+			
+			
+		
+	
+	
+		
+			
+			
+		
+	
+	
+		
+			
+				
+					
+				
+			
+		
+	
+	
+		
+			
+			
+		
+	
+	
+		
+			
+				
+					
+					
+				
+			
+		
+	
+	
+		
+			
+				
+					
+					
+				
+			
+		
+	
+	
+		
+			
+				
+					
+					
+				
+			
+		
+	
+	
+		
+			
+				
+					
+					
+					
+				
+			
+		
+	
+	
+	
+		
+			Resultat, falls die Signaturerstellung gescheitert ist
+		
+	
+	
+		
+			
+			
+		
+	
+	
+	
+		
+	
+	
+		
+			
+			
+		
+	
+	
+		
+	
+	
+		
+			
+		
+	
+	
+		
+			
+				
+			
+		
+	
+	
+		
+			
+			
+			
+		
+	
+	
+		
+			
+				
+					
+					
+				
+			
+		
+	
+	
+		
+			
+				
+			
+		
+	
+	
+		
+			
+				
+					
+					
+					
+				
+				
+			
+		
+	
+	
+		
+			
+				Ein oder mehrere Transformationswege können von der Applikation an MOA mitgeteilt werden. Die zu prüfende Signatur hat zumindest einem dieser Transformationswege zu entsprechen. Die Angabe kann explizit oder als Profilbezeichner erfolgen.
+			
+			
+			
+				
+					Profilbezeichner für einen Transformationsweg
+				
+			
+		
+	
+	
+	
+	
+		
+			
+		
+	
+	
+		
+			
+				
+			
+		
+	
+	
+		
+			
+		
+	
+	
+		
+			
+				
+			
+		
+	
+	
+		
+			
+				Die Angabe des Transformationsparameters (explizit oder als Hashwert) kann unterlassen werden, wenn die Applikation von der Unveränderlichkeit des Inhalts der in "Transformationsparamter", Attribut "URI" angegebenen URI ausgehen kann.
+			
+			
+				
+					Der Transformationsparameter explizit angegeben.
+				
+			
+			
+				
+					Der Hashwert des Transformationsparameters.
+				
+				
+					
+						
+						
+					
+				
+			
+		
+		
+	
+	
+		
+			
+				
+				
+			
+		
+	
+	
+		
+			Explizite Angabe des Transformationswegs
+		
+		
+			
+				
+				
+					
+						Alle impliziten Transformationsparameter, die zum Durchlaufen der oben angeführten Transformationskette bekannt sein müssen, müssen hier angeführt werden. Das Attribut "URI" bezeichnet den Transformationsparameter in exakt jener Weise, wie er in der zu überprüfenden Signatur gebraucht wird.
+					
+				
+			
+		
+	
+	
+	
+	
+		
+			
+				
+				
+			
+		
+	
+
diff --git a/spss/handbook/handbook/usage/usage.html b/spss/handbook/handbook/usage/usage.html
index bafb6da29..4d14ab917 100644
--- a/spss/handbook/handbook/usage/usage.html
+++ b/spss/handbook/handbook/usage/usage.html
@@ -85,7 +85,8 @@
   2 Verwendung des Webservices 
   Dieser Abschnitt beschreibt die Verwendung der Module SP und SS über die Webservice-Schnittstelle. Im ersten Unterabschnitt werden typische XML-Requests zur Signaturerstellung mittels SS bzw. zur Signaturprüfung mittels SP vorgestellt, wie sie an das Webservice gesendet werden können. Der zweite Unterabschnitt stellt beispielhafte Implementierungen eines Webservice-Clients in Java vor, mit dem die Requests aus dem ersten Unterabschnitt an das Webservice gesendet werden können.
   2.1 XML-Requests 
-  Dieser Abschnitt stellt typische XML-Requests für die Erstellung einer XML-Signatur mittels SS bzw. zur Prüfung einer CMS- bzw. XML-Signatur mittels SP vor. Zu jedem Request wird jeweils auch eine typische Response des Services besprochen. 
+  TODO: Auch plain CMS unterstützt?
+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. 
   Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf localhost, z.B. http://localhost:8080/referencedData/Text.txt. 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 localhost:8080 betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation referencedData.war in das Verzeichnis webapps Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen. 
   2.1.1 Erstellung einer CMS bzw. CAdES-Signatur
   2.1.1.1 Einfaches Beispiel
@@ -95,7 +96,7 @@
   
  TODO
 2.1.2 Erstellung einer XML bzw. XAdES-Signatur
-MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.1. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
+MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
 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 Konfiguration der XAdES Version).
 2.1.2.1 Einfaches Beispiel
   Request
@@ -103,7 +104,7 @@
     <KeyIdentifier>KG_allgemein</KeyIdentifier> 
   KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
     <SingleSignatureInfo SecurityLayerConformity="false">
-   Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.1  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).
+   Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
     <DataObjectInfo Structure="enveloping">
       <DataObject>
         <XMLContent>Diese Daten werden signiert.<XMLContent>
@@ -652,19 +653,19 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
 
 Die Response enthält zunächst in SignerInfo/dsig:X509Data Informationen über den Signator, die aus dem in der CMS-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 immer vorhanden und enthält das Signatorzertifikat in base64 kodierter Form. 
-Optional vorhanden ist das inhaltslose Element QualifiedCertificate, und zwar dann, wenn es sich beim Signatorzertifikat um ein qualifiziertes Zertifikat handelt. Ebenfalls optional vorhanden ist schließlich - in diesem Beispiel nicht ersichtlich - 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.
+Optional vorhanden ist das inhaltslose Element QualifiedCertificate, und zwar dann, wenn es sich beim Signatorzertifikat um ein qualifiziertes Zertifikat handelt. Ebenfalls optional vorhanden ist schließlich - in diesem Beispiel nicht ersichtlich - 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.
+ 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.2x TODO.
    <CertificateCheck>
     <Code>1</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 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.
+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.2x TODO.
 2.1.3.2 Erweitertes Beispiel
 Request
 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. 
@@ -750,19 +751,19 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
 
 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.
+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.
+ 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.2x TODO.
    <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.
+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.2x TODO.
 2.1.4.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.
@@ -898,7 +899,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife
   </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 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.2x TODO.
 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>
@@ -1130,7 +1131,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
     <Code>0</Code>
   </SignatureManifestCheck>
 
-Das Element SignatureManifestCheck enhält das Resultat der Prüfung des Zusammenhangs  zwischen Referenz-Eingangsdaten und Hash-Eingangsdaten. Der Kode 0 im konkreten Beispiel bedeutet, dass alle Referenzen  die in der Anfrage zur Überprüfung der XML-Signatur gemachten Einschränkungen bezüglich der erlaubten Transformationskette(n) einhalten, sowie dass die Anforderungen  hinsichtlich des Signaturmanifests werden eingehalten. Für eine Übersicht der möglichen Kodes siehe die Spezifikation zu MOA SP/SS, Abschnitt 5.1.3.1.4.
+Das Element SignatureManifestCheck enhält das Resultat der Prüfung des Zusammenhangs  zwischen Referenz-Eingangsdaten und Hash-Eingangsdaten. Der Kode 0 im konkreten Beispiel bedeutet, dass alle Referenzen  die in der Anfrage zur Überprüfung der XML-Signatur gemachten Einschränkungen bezüglich der erlaubten Transformationskette(n) einhalten, sowie dass die Anforderungen  hinsichtlich des Signaturmanifests werden eingehalten. Für eine Übersicht der möglichen Kodes siehe die Spezifikation zu MOA SP/SS (Link TODO), Abschnitt 5.1.3.1.4.
    <CertificateCheck>
     <Code>0</Code>
-- 
cgit v1.2.3


From 5a676cfedb379eb73e0b86ba158214902da14bd3 Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Tue, 7 May 2013 10:24:47 +0200
Subject: Update documentation (Usage for CreateCMSSignatureRequest)

---
 ...reateCMSSignatureRequest.Base64Content.resp.xml | 44 ++++++++++++++
 .../CreateCMSSignatureRequest.Base64Content.xml    | 17 ++++++
 .../CreateCMSSignatureRequest.Reference.resp.xml   | 38 ++++++++++++
 .../CreateCMSSignatureRequest.Reference.xml        | 14 +++++
 .../CreateXMLSignatureRequest.Simple.response.xml  | 24 --------
 ...ateXMLSignatureRequest.Supplements.response.xml |  2 -
 ...ifyXMLSignatureRequest.Supplements.response.xml | 23 --------
 spss/handbook/handbook/usage/usage.html            | 69 ++++++++++++++++++----
 8 files changed, 170 insertions(+), 61 deletions(-)
 create mode 100644 spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml
 create mode 100644 spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.xml
 create mode 100644 spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.resp.xml
 create mode 100644 spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.xml
 delete mode 100644 spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.response.xml
 delete mode 100644 spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.response.xml
 delete mode 100644 spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.response.xml

(limited to 'spss/handbook')

diff --git a/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml
new file mode 100644
index 000000000..a99e97d0c
--- /dev/null
+++ b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml
@@ -0,0 +1,44 @@
+
+
+	MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgMwgAYJKoZIhvcNAQcB
+oIAkgAQdRGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4AAAAAAACgggQvMIIE
+KzCCA5SgAwIBAgIGY6tXffAmMA0GCSqGSIb3DQEBBQUAMEAxIjAgBgNVBAMTGUlB
+SUsgVGVzdCBJbnRlcm1lZGlhdGUgQ0ExDTALBgNVBAoTBElBSUsxCzAJBgNVBAYT
+AkFUMB4XDTEzMDQxNjE0MzMyNFoXDTIzMDQxNjE0MzMyNFowfjELMAkGA1UEBhMC
+QVQxDTALBgNVBAcTBEdyYXoxJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBU
+ZWNobm9sb2d5MQ0wCwYDVQQLEwRFR0laMSkwJwYDVQQDEyBUZXN0IFNpZ25hdHVy
+ZGllbnN0IGFsbGVyIEt1bmRlbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
+ggEBAN1oJenNIuGzCiny3kibTm1pYPfuCqbE+6x+skNXj+TRY0vsR+Skj5P1/sNl
+iFF0qVPrtH+VGvhzLBhb98uPEkxQ1xpl+AJ0YJin0XMW1+PMCGOuQ+A/mfsx9gZC
+lAMPffgCOBgEuAuugfl7NfW1+4wK8cy4OKUAl6/UuTKWhlZyh0HIsAVmvHquPsOa
+Fy607KI0JAK8QXogHu4nNXSRCuwf3YMM/lR1ky0Q90IBk4uBKE+2pPiIQAej6kiP
+a2HcbKNT9UCtmcUOtmaNPHhlGvjAAe6LBj7MfHjfHsvn3ub07w4hDG3NauaEiDcu
+cwjtOg9Bl6F8EcIzB8cmo25ZkrkCAwEAAaOCAWwwggFoMA4GA1UdDwEB/wQEAwIG
+wDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT5IDty8bqV51kzZB7+jExO+YOLUTBQ
+BgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28v
+Y3Jscy9JQUlLVGVzdF9JbnRlcm1lZGlhdGVDQS5jcmwwgaoGCCsGAQUFBwEBBIGd
+MIGaMEoGCCsGAQUFBzABhj5odHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28v
+T0NTUD9jYT1JQUlLVGVzdF9JbnRlcm1lZGlhdGVDQTBMBggrBgEFBQcwAoZAaHR0
+cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0lBSUtUZXN0X0ludGVy
+bWVkaWF0ZUNBLmNlcjAJBgNVHREEAjAAMB8GA1UdIwQYMBaAFGiiXhHa3i+Aa0RE
+v436ZTaBJKdvMA0GCSqGSIb3DQEBBQUAA4GBAGzwtp4nq0IxjnK5D86/9Gg6NRN2
+K39wN8/Zd6Uo8OnwmpYxEdfLsnDhp+H1IcqRFroqDRDmtoRXRqIW0VKJno70CzuW
++3ZFsSopH51BbHSxIvXAbxfOPX1PZQ1fXGTo5gWaJ62Xeu6zi+YtSxQHNMHqUxO/
+llGVtT8VDtNGS0wGMYICuTCCArUCAQEwSjBAMSIwIAYDVQQDExlJQUlLIFRlc3Qg
+SW50ZXJtZWRpYXRlIENBMQ0wCwYDVQQKEwRJQUlLMQswCQYDVQQGEwJBVAIGY6tX
+ffAmMAsGCWCGSAFlAwQCA6CCAUQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
+BgkqhkiG9w0BCQUxDxcNMTMwNTA2MjAwNTQ2WjBPBgkqhkiG9w0BCQQxQgRAds70
+61RkR9wybcxKrtd9Uc/S/DNyxhvXPzr5A8IphKGDTe4lHXiky2xwjYEcSE7Mx3Jm
+8Lo5d9iFu45Dq9nx0DCBuAYLKoZIhvcNAQkQAi8xgagwgaUwgaIwgZ8wCwYJYIZI
+AWUDBAIDBEBxEElsIgrSD8KgnZk88uomiqWEEvWoMufQe68l7z1/qYX39aLlD2Sh
+pHolkI+EM5JuuWM678CAJdkOTvxUvKm8ME4wRKRCMEAxIjAgBgNVBAMTGUlBSUsg
+VGVzdCBJbnRlcm1lZGlhdGUgQ0ExDTALBgNVBAoTBElBSUsxCzAJBgNVBAYTAkFU
+AgZjq1d98CYwCwYJKoZIhvcNAQEBBIIBACRh+vEXSpupLSJY56WNzVTaPLq4EINO
+ovsOFaigYtFy9VOVVijg0ycMJqEeIl+lxJvmr9z30w9g4STa0EGoFxt2rXCyYtFt
+W+A70MPZ++PXlKAtBtXoMR2hVZ5XYk8yI42NBlN0XWOTgDZgTXlj4M4YYZHUPCLr
+NhwT2hLZ6WsQWhZpVF6d8GnhqPPgUnSibbDkjHHQMJZh/y5j+1M8IrSosPainrkI
+8yxyZOmbfoWVUXKRxFgfZ7YpWShbDgZ3JasyIXihOPXF7n2jlFxFACYiNrD93D4k
+p5j58Cfjvd0gm5QIDPvx1Z4rQ3oVOrzsjV+2e82hbqmhkzenp92gh6wAAAAAAAA=
+
+
+
diff --git a/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.xml b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.xml
new file mode 100644
index 000000000..28b67f94c
--- /dev/null
+++ b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.xml
@@ -0,0 +1,17 @@
+
+
+	KG_allgemein
+	
+		
+			
+				
+                	text/plain
+                
+                
+                	RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=
+                				
+						
+		
+	
+
+
diff --git a/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.resp.xml b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.resp.xml
new file mode 100644
index 000000000..c81e98fee
--- /dev/null
+++ b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.resp.xml
@@ -0,0 +1,38 @@
+
+
+	MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgMwgAYJKoZIhvcNAQcB
+AACgggQvMIIEKzCCA5SgAwIBAgIGY6tXffAmMA0GCSqGSIb3DQEBBQUAMEAxIjAg
+BgNVBAMTGUlBSUsgVGVzdCBJbnRlcm1lZGlhdGUgQ0ExDTALBgNVBAoTBElBSUsx
+CzAJBgNVBAYTAkFUMB4XDTEzMDQxNjE0MzMyNFoXDTIzMDQxNjE0MzMyNFowfjEL
+MAkGA1UEBhMCQVQxDTALBgNVBAcTBEdyYXoxJjAkBgNVBAoTHUdyYXogVW5pdmVy
+c2l0eSBvZiBUZWNobm9sb2d5MQ0wCwYDVQQLEwRFR0laMSkwJwYDVQQDEyBUZXN0
+IFNpZ25hdHVyZGllbnN0IGFsbGVyIEt1bmRlbjCCASIwDQYJKoZIhvcNAQEBBQAD
+ggEPADCCAQoCggEBAN1oJenNIuGzCiny3kibTm1pYPfuCqbE+6x+skNXj+TRY0vs
+R+Skj5P1/sNliFF0qVPrtH+VGvhzLBhb98uPEkxQ1xpl+AJ0YJin0XMW1+PMCGOu
+Q+A/mfsx9gZClAMPffgCOBgEuAuugfl7NfW1+4wK8cy4OKUAl6/UuTKWhlZyh0HI
+sAVmvHquPsOaFy607KI0JAK8QXogHu4nNXSRCuwf3YMM/lR1ky0Q90IBk4uBKE+2
+pPiIQAej6kiPa2HcbKNT9UCtmcUOtmaNPHhlGvjAAe6LBj7MfHjfHsvn3ub07w4h
+DG3NauaEiDcucwjtOg9Bl6F8EcIzB8cmo25ZkrkCAwEAAaOCAWwwggFoMA4GA1Ud
+DwEB/wQEAwIGwDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT5IDty8bqV51kzZB7+
+jExO+YOLUTBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vY2EuaWFpay50dWdyYXou
+YXQvY2Fwc28vY3Jscy9JQUlLVGVzdF9JbnRlcm1lZGlhdGVDQS5jcmwwgaoGCCsG
+AQUFBwEBBIGdMIGaMEoGCCsGAQUFBzABhj5odHRwOi8vY2EuaWFpay50dWdyYXou
+YXQvY2Fwc28vT0NTUD9jYT1JQUlLVGVzdF9JbnRlcm1lZGlhdGVDQTBMBggrBgEF
+BQcwAoZAaHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0lBSUtU
+ZXN0X0ludGVybWVkaWF0ZUNBLmNlcjAJBgNVHREEAjAAMB8GA1UdIwQYMBaAFGii
+XhHa3i+Aa0REv436ZTaBJKdvMA0GCSqGSIb3DQEBBQUAA4GBAGzwtp4nq0IxjnK5
+D86/9Gg6NRN2K39wN8/Zd6Uo8OnwmpYxEdfLsnDhp+H1IcqRFroqDRDmtoRXRqIW
+0VKJno70CzuW+3ZFsSopH51BbHSxIvXAbxfOPX1PZQ1fXGTo5gWaJ62Xeu6zi+Yt
+SxQHNMHqUxO/llGVtT8VDtNGS0wGMYIB/TCCAfkCAQEwSjBAMSIwIAYDVQQDExlJ
+QUlLIFRlc3QgSW50ZXJtZWRpYXRlIENBMQ0wCwYDVQQKEwRJQUlLMQswCQYDVQQG
+EwJBVAIGY6tXffAmMAsGCWCGSAFlAwQCA6CBiTAYBgkqhkiG9w0BCQMxCwYJKoZI
+hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA1MDYyMDE3NThaME8GCSqGSIb3DQEJ
+BDFCBEB2zvTrVGRH3DJtzEqu131Rz9L8M3LGG9c/OvkDwimEoYNN7iUdeKTLbHCN
+gRxITszHcmbwujl32IW7jkOr2fHQMAsGCSqGSIb3DQEBAQSCAQARQoV2xP8NRZpi
+PXk8554tQQ1EiT0EDbgbxtpPMlkTz4WODxcY+qpKC3ZM6uaOnTPfCwya/xucFC/u
+A2rvuvyuaoDDAPmvdmsFtNX0ymO3THECe95iJ3pd92m2DjfyEPS2S7hRkoSaMzqd
+BBLjwSGm8ZaM8J1Pd4hC6pKEdgMFB3VOgZFHOZd2fG60olI3wcYVvu1Rwkab5R9/
+kTsMHqDjLz0reHRK5G4RUAZ7NSZ+h7HWuaoTviaWPM37iUw4ipko5+vR6m3kxbUv
+p2mVhbGtiVjV6lwOfCA5kuFFjeaLrxLwv5JeVQItzw4E3DMEB2+csSA/qTH/xly4
+SwxhbA9pAAAAAAAA
+
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.xml b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.xml
new file mode 100644
index 000000000..976ea7a6a
--- /dev/null
+++ b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Reference.xml
@@ -0,0 +1,14 @@
+
+
+	KG_allgemein
+	
+		
+			
+				
+                	text/plain
+                
+                
+						
+		
+	
+
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.response.xml b/spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.response.xml
deleted file mode 100644
index cb966151b..000000000
--- a/spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.response.xml
+++ /dev/null
@@ -1,24 +0,0 @@
-
-tLODyeiWFbAkQKwhrR23jtcgu4k=2tI1Wv/LsUKr0hcsWSYXSHne7kbCBXGFrIiI/1WfAH2ba8vT5kVfJn4NOBOBatLAMIIELjCCAxagAwIBAgIBEzANBgkqhkiG9w0BAQUFADBEMQswCQYDVQQGEwJBVDEQ
-MA4GA1UEChMHVFUgR3JhejENMAsGA1UECxMERUdJWjEUMBIGA1UEAxMLTU9BIFRl
-c3QgQ0EwHhcNMDcwODIzMTM1ODU0WhcNMTIwODIzMTM1ODU0WjBpMQswCQYDVQQG
-EwJBVDEQMA4GA1UEChMHVFUgR1JBWjENMAsGA1UECxMERUdJWjE5MDcGA1UEAxMw
-VGVzdCBTaWduYXR1cmRpZW5zdCBhbGxlciBLdW5kZW46IEVDRFNBIChQMTkydjEp
-MIHzMIG8BgcqhkjOPQIBMIGwAgEBMCQGByqGSM49AQECGQD/////////////////
-///+//////////8wNAQY/////////////////////v/////////8BBhkIQUZ5ZyA
-5w+n6atyJDBJ/rje7MFGubEEMQQYjagOsDCQ9ny/IOtDoYgA9P8K/YL/EBIHGSuV
-/8jaeGMQEe1rJM3Vc/l3oR55SBECGQD///////////////+Z3vg2FGvJsbTSKDEC
-AQEDMgAExf78b6N6BUhK+FHmunDUCQefSxpQmC6m4yq/+pqdDMJalTWATFhQwZqE
-qSMXJ2Tqo4IBNDCCATAwDgYDVR0PAQH/BAQDAgbAMAwGA1UdEwEB/wQCMAAwHQYD
-VR0OBBYEFBrwapQSMwabwPPOijtgOu3iNlt3MHAGA1UdIARpMGcwZQYMKwYBBAGV
-EgECewEBMFUwUwYIKwYBBQUHAgIwRxpFVGhpcyBjZXJ0aWZpY2F0ZSBvbmx5IG1h
-eSBiZSB1c2VkIGZvciBkZW1vbnN0cmF0aW9uIGFuZCB0ZXN0IHB1cnBvc2VzMEYG
-A1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9tb2EtaWRzcHNzLmVnb3ZsYWJzLmd2LmF0
-L2NybHMvbW9hLXRlc3QtY2EuY3JsMBYGByooAAoBAQEECxMJRUdJWi1UZXN0MB8G
-A1UdIwQYMBaAFFKXvB3Ugd6H51ClcBGdjhYJNiRSMA0GCSqGSIb3DQEBBQUAA4IB
-AQB60RLi9zIwF/Rmy/Wo0yf1/ZktElIt91vfBsXlpgLJ4Q6ol/4hTjMJ4FIa8GOl
-0b9dIkEe+WGq77JFJVgltsRoJfQBSvnK9jdLfB5YJD0ETDnMdckBV+RsxkEtl5Lr
-IrT6vExyJUAWz15XJiHgkYZncJCBTy1oh8f3V8cR1VZYwO4QBRDwRdVdZsaL5PME
-vvLrcAMJhF5fS4AiqMex2Eh2kav5t6/I5bmB4CKEe+0+dPO8DGl7areEfzQEPd8p
-jkkX5PnxriQvZfgVzwrdXGDqMTnBNaRtCGMiQU/0kp21a6BVtT4am27yr9p3ddhl
-z7sJ4Z6ys1bwB0on/O65tdn7Diese Daten werden signiert.
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.response.xml b/spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.response.xml
deleted file mode 100644
index ac5d0a52f..000000000
--- a/spss/handbook/clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.response.xml
+++ /dev/null
@@ -1,2 +0,0 @@
-
-2237Fehler beim Auflösen der internen Referenz (URI=Para2)
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.response.xml b/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.response.xml
deleted file mode 100644
index 2fab33b20..000000000
--- a/spss/handbook/clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.response.xml
+++ /dev/null
@@ -1,23 +0,0 @@
-
-CN=Test: Signaturdienst aller Kunden: ECDSA (P192v1),OU=Technik und Standards,O=Stabsstelle IKT-Strategie des Bundes,C=ATCN=Test CA - Signaturdienste,OU=Technik und Standards,O=Stabstelle IKT-Strategie des Bundes,C=AT9MIID+DCCA2WgAwIBAgIBCTAJBgUrDgMCHQUAMH8xCzAJBgNVBAYTAkFUMSwwKgYD
-VQQKEyNTdGFic3RlbGxlIElLVC1TdHJhdGVnaWUgZGVzIEJ1bmRlczEeMBwGA1UE
-CxMVVGVjaG5payB1bmQgU3RhbmRhcmRzMSIwIAYDVQQDExlUZXN0IENBIC0gU2ln
-bmF0dXJkaWVuc3RlMB4XDTA0MDgwNDA4MjM0OFoXDTA3MDgwNDA4MjM0OFowgZgx
-CzAJBgNVBAYTAkFUMS0wKwYDVQQKEyRTdGFic3N0ZWxsZSBJS1QtU3RyYXRlZ2ll
-IGRlcyBCdW5kZXMxHjAcBgNVBAsTFVRlY2huaWsgdW5kIFN0YW5kYXJkczE6MDgG
-A1UEAxMxVGVzdDogU2lnbmF0dXJkaWVuc3QgYWxsZXIgS3VuZGVuOiBFQ0RTQSAo
-UDE5MnYxKTCB8zCBvAYHKoZIzj0CATCBsAIBATAkBgcqhkjOPQEBAhkA////////
-/////////////v//////////MDQEGP////////////////////7//////////AQY
-ZCEFGeWcgOcPp+mrciQwSf643uzBRrmxBDEEGI2oDrAwkPZ8vyDrQ6GIAPT/Cv2C
-/xASBxkrlf/I2nhjEBHtayTN1XP5d6EeeUgRAhkA////////////////md74NhRr
-ybG00igxAgEBAzIABNHWY9lQOE1zgmpcpjTg2WIg6qgEsGhpXELPinJoMPDVheTv
-2BZPG42YJsNfvWgC06OCARwwggEYMA4GA1UdDwEB/wQEAwIGwDAMBgNVHRMBAf8E
-AjAAMB0GA1UdDgQWBBRHH5EXnrWosCmIa+JyEM5seMxFVzBdBgNVHSAEVjBUMFIG
-DCsGAQQBlRIBAgMBATBCMEAGCCsGAQUFBwICMDQaMkRpZXNlcyBaZXJ0aWZpa2F0
-IGlzdCBudXIgZvxyIFRlc3R6d2Vja2UgZ2VlaWduZXQuMEMGA1UdHwQ8MDowOKA2
-oDSGMmh0dHA6Ly9sYWJzLmNpby5ndi5hdC90ZW1wL2NybHMvc2lnbmF0dXJkaWVu
-c3QuY3JsMBQGByooAAoBAQEECQwHQktBLUlLVDAfBgNVHSMEGDAWgBRAl0P5fWaw
-vf59+uxGcYY9wffZPTAJBgUrDgMCHQUAA4GBAIMKUsnajgfBtpHeDdMdQMLA8fdt
-lluezDOM78WYYSFURP04QZk5iHkShzptgZCF5Y/T4an3dC3SnytL67LJvEoKUyja
-iTMLo7650xRTvAjTaMJ+nly/wTRYJKplOLXKWj3WwfObMHXdsDE8NJmpJSRE7Sw7
-+tj+UiTiNNSaXirqBKA-IKT00
\ No newline at end of file
diff --git a/spss/handbook/handbook/usage/usage.html b/spss/handbook/handbook/usage/usage.html
index 4d14ab917..6fcccc612 100644
--- a/spss/handbook/handbook/usage/usage.html
+++ b/spss/handbook/handbook/usage/usage.html
@@ -29,8 +29,8 @@
         XML-Requests          
             Erstellung einer CMS bzw. CAdES-Signatur
               
-                Einfaches Beispiel
-                Erweitertes Beispiel
+                Beispiel (Base64-codiertes Datenobjekt)
+                Beispiel (Datenobjekt als Referenz)
               
             Erstellung einer XML bzw. XAdES-Signatur              
               
@@ -85,18 +85,64 @@
   2 Verwendung des Webservices 
   Dieser Abschnitt beschreibt die Verwendung der Module SP und SS über die Webservice-Schnittstelle. Im ersten Unterabschnitt werden typische XML-Requests zur Signaturerstellung mittels SS bzw. zur Signaturprüfung mittels SP vorgestellt, wie sie an das Webservice gesendet werden können. Der zweite Unterabschnitt stellt beispielhafte Implementierungen eines Webservice-Clients in Java vor, mit dem die Requests aus dem ersten Unterabschnitt an das Webservice gesendet werden können.
   2.1 XML-Requests 
-  TODO: Auch plain CMS unterstützt?
-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. 
-  Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf localhost, z.B. http://localhost:8080/referencedData/Text.txt. 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 localhost:8080 betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation referencedData.war in das Verzeichnis webapps Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen. 
+  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. 
+Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf localhost, z.B. http://localhost:8080/referencedData/Text.txt. 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 localhost:8080 betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation referencedData.war in das Verzeichnis webapps Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen. 
   2.1.1 Erstellung einer CMS bzw. CAdES-Signatur
-  2.1.1.1 Einfaches Beispiel
-  TODO
-  
-  2.1.1.1 Erweitertes Beispiel
+  MOA-SS ermöglicht die Erstellung einer herkömmlichen CMS-Signatur und einer CAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x TODO. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme CAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele).
+2.1.1.1 Beispiel (Base64-codiertes Datenobjekt)
+Request
+  CreateCMSSignatureRequest.Base64Content.xml ist ein einfacher XML-Request zur Erzeugung einer CAdES-Signatur. Sein Aufbau wird nachfolgend analysiert:
+    <KeyIdentifier>KG_allgemein</KeyIdentifier> 
+  KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
+    <SingleSignatureInfo SecurityLayerConformity="true">
+   Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
+    <DataObjectInfo Structure="enveloping">
+	     <DataObject>
+		    <MetaInfo>
+             <MimeType>text/plain</MimeType>
+          </MetaInfo>
+          <Content>
+         	   <Base64Content>RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</Base64Content>
+          </Content>			
+       </DataObject>		
+	  </DataObjectInfo>
+
+Das zu signierende Daten-Objekt muss in einem  DataObjectInfo Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten in die Signatur integriert werden sollen (Structure="enveloping") oder nicht (Structure="detached"). 
+ Im nachfolgenden DataObject Element muss entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit im Element Base64Content (enthält Daten in Base64 kodierter Form) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig im Element Base64Content ist nicht erlaubt. Zusätzlich muss im Element MimeType (unter dem Element MetaInfo) der MIME-Type der zu signierenden Daten spezifiziert werden.
+  Im konkreten Beispiel sollen die Daten in die Signatur integriert werden (Structure="enveloping"). Die Daten werden in diesem Beispiel mittels Base64Content angegeben. Der MIME-Type wird mit text/plain angegeben.
+Response
+TODO: Neue Signatur erzeugen (da CAdES - d.h. noch auf neues iaik-moa warten)
+  CreateCMSSignatureRequest.Base64Content.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.  
+  <CreateCMSSignatureResponse
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	<CMSSignature>MIAGCSqGSI...p92gh6wAAAAAAAA=</CMSSignature>
</CreateCMSSignatureResponse>
+CreateCMSSignatureResponse enthält je erzeugter Signatur ein Element CMSSignature (in diesem Fall genau ein Element). CMSSignature enthält die von SS erzeugte CAdES-Signatur (da SecurityLayerConformity="true" im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping). 
+2.1.1.2 Beispiel (Datenobjekt als Referenz)
   
- TODO
+Request
+CreateCMSSignatureRequest.Reference.xml ist ein einfacher XML-Request zur Erzeugung einer CMS-Signatur. Sein Aufbau wird nachfolgend analysiert:
+  <KeyIdentifier>KG_allgemein</KeyIdentifier> 
+KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
+  <SingleSignatureInfo SecurityLayerConformity="false">
+ Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
+    <DataObjectInfo Structure="detached">
+	     <DataObject>
+		    <MetaInfo>
+             <MimeType>text/plain</MimeType>
+          </MetaInfo>
+          <Content Reference="http://localhost:8080/moa-spss-handbook-referencedData/Text.txt"/>         	   
+       </DataObject>		
+	  </DataObjectInfo>
+
+Das zu signierende Daten-Objekt muss in einem DataObjectInfo Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten in die Signatur integriert werden sollen (Structure="enveloping") oder nicht (Structure="detached"). 
+ Im nachfolgenden DataObject Element muss entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit im Element Base64Content (enthält Daten in Base64 kodierter Form) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig im Element Base64Content ist nicht erlaubt. Zusätzlich muss im Element MimeType (unter dem Element MetaInfo) der MIME-Type der zu signierenden Daten spezifiziert werden.
+Im konkreten Beispiel sollen die Daten nicht in die Signatur integriert werden (Structure="detached"). Die Daten werden in diesem Beispiel mittels der Attributs Refernce angegeben und SS muss es von dieser URL laden. Der MIME-Type wird mit text/plain angegeben.
+Response
+CreateCMSSignatureRequest.Reference.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. 
+<CreateCMSSignatureResponse
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	<CMSSignature>MIAGCSqGSI...SwxhbA9pAAAAAAAA</CMSSignature>
</CreateCMSSignatureResponse>
+CreateCMSSignatureResponse enthält je erzeugter Signatur ein Element CMSSignature (in diesem Fall genau ein Element). CMSSignature enthält die von SS erzeugte CMS-Signatur (da SecurityLayerConformity="false" im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur nicht enthalten (detached).
 2.1.2 Erstellung einer XML bzw. XAdES-Signatur
-MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
+MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x TODO. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
 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 Konfiguration der XAdES Version).
 2.1.2.1 Einfaches Beispiel
   Request
@@ -1236,6 +1282,5 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
   
   
 
- 
 
 
-- 
cgit v1.2.3


From 1d918b4e05d06ed39f6215fd70ce375a38a300b8 Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Thu, 16 May 2013 09:35:16 +0200
Subject: New design MOA-ID and MOA-SPSS documentation

---
 spss/handbook/handbook/common/LogoEGIZ.png         | Bin 0 -> 77395 bytes
 .../handbook/common/LogoMoa4c.3148x3545.jpg        | Bin 1584855 -> 0 bytes
 spss/handbook/handbook/common/LogoMoa4c.jpg        | Bin 45624 -> 0 bytes
 spss/handbook/handbook/common/LogoMoaBw.jpg        | Bin 41375 -> 0 bytes
 spss/handbook/handbook/common/MOA.css              | 317 +++++++++++++
 spss/handbook/handbook/config/config.html          |  50 +-
 spss/handbook/handbook/faq/faq.html                |  11 +-
 spss/handbook/handbook/index.html                  |   7 +-
 spss/handbook/handbook/install/install.html        |   9 +-
 spss/handbook/handbook/intro/intro.html            |   9 +-
 spss/handbook/handbook/usage/usage.html            | 511 ++++++++++-----------
 11 files changed, 612 insertions(+), 302 deletions(-)
 create mode 100644 spss/handbook/handbook/common/LogoEGIZ.png
 delete mode 100644 spss/handbook/handbook/common/LogoMoa4c.3148x3545.jpg
 delete mode 100644 spss/handbook/handbook/common/LogoMoa4c.jpg
 delete mode 100644 spss/handbook/handbook/common/LogoMoaBw.jpg

(limited to 'spss/handbook')

diff --git a/spss/handbook/handbook/common/LogoEGIZ.png b/spss/handbook/handbook/common/LogoEGIZ.png
new file mode 100644
index 000000000..39f05d131
Binary files /dev/null and b/spss/handbook/handbook/common/LogoEGIZ.png differ
diff --git a/spss/handbook/handbook/common/LogoMoa4c.3148x3545.jpg b/spss/handbook/handbook/common/LogoMoa4c.3148x3545.jpg
deleted file mode 100644
index a5ba135ef..000000000
Binary files a/spss/handbook/handbook/common/LogoMoa4c.3148x3545.jpg and /dev/null differ
diff --git a/spss/handbook/handbook/common/LogoMoa4c.jpg b/spss/handbook/handbook/common/LogoMoa4c.jpg
deleted file mode 100644
index a1102090b..000000000
Binary files a/spss/handbook/handbook/common/LogoMoa4c.jpg and /dev/null differ
diff --git a/spss/handbook/handbook/common/LogoMoaBw.jpg b/spss/handbook/handbook/common/LogoMoaBw.jpg
deleted file mode 100644
index 5a31e3e15..000000000
Binary files a/spss/handbook/handbook/common/LogoMoaBw.jpg and /dev/null differ
diff --git a/spss/handbook/handbook/common/MOA.css b/spss/handbook/handbook/common/MOA.css
index 81e0a3f8d..85ed13693 100644
--- a/spss/handbook/handbook/common/MOA.css
+++ b/spss/handbook/handbook/common/MOA.css
@@ -1,4 +1,320 @@
 body
+{ 
+  font-family: "Times New Roman", Times, serif;
+  font-size: medium;
+  font-weight: normal;
+  margin-left: 2.5em;
+  margin-right: 2.5em;
+  background-color: white;
+  text: #000000;
+  link: #990000;
+  vlink: #666666; 
+  alink: #cc9966;
+}
+
+
+
+p
+{ 
+  margin-top: 0pt;
+  margin-bottom: 0.5em;
+  text-align: justify
+}
+
+pre 
+{ 
+  font-family: "Courier New", monospace;
+  font-size: 90%;
+  background-color: #cccccc;
+  color: #000000;
+  margin-left:1.5%;
+  margin-right:1.5%;
+  margin-top: 1em;
+  margin-bottom: 1em;
+  border: #008000 none;
+}
+
+hr 
+{
+  color: #000080;
+  background-color: #000080;
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+}
+
+table.fixedWidth
+{
+  width: 97%;
+  margin-left:1.5%;
+  margin-right:1.5%;
+  margin-top: 1em;
+  margin-bottom: 1em;
+}
+
+
+table.varWidth
+{
+  margin-left:1.5%;
+  margin-top: 1em;
+  margin-bottom: 1em;
+}
+
+th
+{
+  text-align: left;
+}
+
+h1
+{ 
+  color: #000000; 
+  text-align: left;
+  font-size: 167%;
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  background-color:#999;
+}
+
+h2
+{ 
+  color: #000000;
+  font-size: 150%;
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  background-color:#999;
+}
+
+h3
+{ 
+  color: #000000;
+  font-size: 133%; 
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  background-color:#999;
+}
+
+h4
+{
+  color: #000000;
+  font-size: 116%;
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  background-color:#999;
+}
+
+h5
+{ 
+  color: #000000;
+  font-size: 100%;
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  background-color:#999;
+}
+
+h6
+{ 
+  color: #000000;
+  font-size: 83%;
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  background-color:#999;
+}
+
+code
+{
+  font-family: "Courier New", Courier, monospace;
+  font-size: 90%;
+  color: #000000
+}
+
+dd
+{
+  margin-top: 0.8em;
+  margin-bottom: 0.8em;
+  text-align: justify
+
+}
+
+dt 
+{
+  margin-top: 0.8em;
+  font-family: Arial, Helvetica, sans-serif;
+  color: #000080
+}
+
+ol
+{
+  margin-top: 0.5em;
+  margin-bottom: 0.5em
+}
+
+ol.alpha
+{
+  list-style-type: lower-alpha
+}
+
+li
+{
+  margin-top: 0.25em;
+  margin-bottom: 0.25em;
+  text-align: justify
+}
+
+a:hover
+{
+  color: #990000
+}
+
+
+.title
+{
+  text-align: left;
+  font-size: 200%;
+  color: #000000;
+  font-family: Arial, Helvetica, sans-serif;
+  margin-top: 0.4em;
+  margin-bottom: 0.4em;
+  background-color:#999;
+}
+
+.subtitle 
+{  
+  text-align: left;
+  font-size: 133%;
+  color: #000000;
+  font-family: Arial, Helvetica, sans-serif;
+  margin-top: 0.4em;
+  margin-bottom: 0.4em
+}
+
+.glossaryTerm 
+{  
+  font-style: italic;
+  color: #006699
+}
+
+.example
+{ 
+  font-family: "Courier New", monospace;
+  background-color: #CCFFFF;
+  color: #000000;
+  margin: 0pt 0pt;
+  border: #008000 none
+}
+
+.schema
+{ 
+  font-family: "Courier New", monospace;
+  background-color: #FFFFCC;
+  color: #000000;
+  margin: 0pt 0pt;
+  border: #008000 none
+}
+
+.documentinfo
+{
+  font-family: Arial, Helvetica, sans-serif;
+  font-size: 100%;
+}
+
+.ol-contents
+{
+  font-size: 100%;
+  margin-top: 0.0em;
+  margin-bottom: 0.0em;
+}
+
+.li-contents
+{
+  font-size: 100%;
+  margin-top: 0.0em;
+  margin-bottom: 0.0em;
+}
+
+.logoTitle 
+{ 
+  text-align: center;
+  font-size: 200%;
+  color: #000080;
+  font-family: Arial, Helvetica, sans-serif;
+}
+
+.logoTable 
+{ 
+  margin-bottom: 0px;
+  margin-left: 0px
+}
+
+.superscript
+{ 
+  vertical-align: super;
+  font-size: 66%;
+}
+
+.term
+{ 
+  font-style: italic; 
+}
+
+.comment
+{
+  color: #000000;
+  background: #ffff00;
+  font-style: italic
+}
+
+.addedErrata12
+{  
+  color: #FF0000; 
+  background-color: #FFEEEE;
+  text-decoration: underline
+}
+
+.deletedErrata12
+{
+  color: #999999;
+  background-color: #EEEEEE;
+  text-decoration: line-through
+}
+
+.added12
+{  
+  color: #FF0000; 
+  text-decoration: underline
+; background-color: #F8F0FF
+}
+
+.deleted12
+{
+  color: #999999;
+  text-decoration: line-through
+; background-color: #f8f0ff
+}
+
+.rfc2119Keyword 
+{ 
+  font-variant: small-caps;
+  font-style: normal;
+}
+
+.remark {  font-style: italic}
+
+li.faq
+{
+  margin-top: 1.5em;
+  margin-bottom: 1.5em;
+}
+
+.faq-question
+{ 
+  color: #000080;
+  font-size: 100%;
+  font-family: Arial, Helvetica, sans-serif;
+  font-weight: normal;
+  margin-bottom: 0.4em;
+}
+
+
+/*body
 { 
   font-family: "Times New Roman", Times, serif;
   font-size: medium;
@@ -298,3 +614,4 @@ li.faq
   font-weight: normal;
   margin-bottom: 0.4em;
 }
+*/
\ No newline at end of file
diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html
index 6809c143d..d1c7d5636 100644
--- a/spss/handbook/handbook/config/config.html
+++ b/spss/handbook/handbook/config/config.html
@@ -5,41 +5,40 @@
   MOA SS und SP - Konfiguration
   
 
- 
+ 
   
-      
-      
-      
+       
+      
+      
     Open Source

-      für das E-Government Dokumentation 
     
   
    
-  MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.5 
+  MOA: Serversignatur (SS) und Signaturprüfung (SP) 
   Konfiguration 
   
   Inhalt
   
     
-      Übersicht
+      Übersicht
       
-        Allgemeines
+        
Allgemeines
           
-            Namenskonventionen
+            Namenskonventionen
           
         
-        Zentrale Konfigurationsdatei
+        
Zentrale Konfigurationsdatei
           
-            Aktualisierung auf das Format von MOA SP/SS 1.3
+            Aktualisierung auf das Format von MOA SP/SS 1.3
           
         
-        Bekanntmachung der Konfigurationsdatei
+        
Bekanntmachung der Konfigurationsdatei
           
           
-            Aktualisierung der Konfiguration im laufenden Betrieb
+            Aktualisierung der Konfiguration im laufenden Betrieb
           
         
-		Konfiguration des Loggings
+		Konfiguration des Loggings
       
     
   Konfigurationsparameter
@@ -115,10 +114,10 @@
   
   
 
-  1 Übersicht 
+  1 Übersicht 
   Dieses Handbuch beschreibt detailliert die Konfigurationsmöglichkeiten für MOA SP/SS. Wenn nicht anders angegeben, beziehen sich die Erläuterungen sowohl auf die Konfiguration des Webservices als auch auf die Konfiguration von MOA SP/SS für den Einsatz als Klassenbibliothek.
-  1.1 Allgemeines
-  1.1.1 Namenskonventionen 
+  1.1 Allgemeines
+  1.1.1 Namenskonventionen 
   Folgende Namenraum-Präfixe werden in diesem Handbuch zur Kennzeichnung der Namenräume
     von XML-Elementen verwendet:  
   
@@ -143,9 +142,9 @@
       http://www.w3.org/2001/XMLSchema
     
   
-  1.2 Zentrale Konfigurationsdatei
+  1.2 Zentrale Konfigurationsdatei
   Die Konfiguration von MOA SP/SS erfolgt zentral über eine einzige Konfigurationsdatei. Das Format der Konfigurationsdatei ist XML und muss dem Schema MOA-SPSS-config-1.5.2.xsd entsprechen. Abschnitt 2 erläutert die Konfigurationsmöglichkeiten im Einzelnen.
-  1.2.1
+  
1.2.1
     Aktualisierung auf das Format von MOA SP/SS 1.3
   Mit dem Wechsel auf  Version 1.3 verwendet MOA SP/SS ein neues, übersichtlicheres Format für die
     XML-Konfigurationsdatei.    
@@ -159,19 +158,18 @@
   an, der zweite Parameter Pfad und Dateiname für die zu erzeugende Konfigurationsdatei im neuen Format (Hinweis:
     Die Beispielpfade beziehen sich auf Windows-Betriebssysteme; für Unix-Betriebssysteme wählen Sie bitte sinngemäße
     Pfade.). 
-  1.3 Bekanntmachung der Konfigurationsdatei
+  1.3 Bekanntmachung der Konfigurationsdatei
   Die zentrale Konfigurationsdatei von MOA SP/SS wird der Java Virtual Machine, in der MOA SP/SS läuft, durch eine System Property  mitgeteilt (wird beim Starten der Java Virtual Machine in der Form -D<name>=<wert> gemacht). Der Name der System Property lautet moa.spss.server.configuration; als Wert der System Property ist der Pfad sowie der Name der Konfigurationsdatei im Dateisystem anzugeben, z.B.
   moa.spss.server.configuration=C:/Programme/apache/tomcat-4.1.30/conf/moa-spss/moa-spss.config.xml 
 
 Weitere Informationen zum Bekanntmachen der zentralen Konfigurationsdatei für MOA SP/SS erhalten Sie in Abschnitt 2.1.2.3 des Installationshandbuchs.
-1.3.1
+
1.3.1
   Aktualisierung der Konfiguration im laufenden Betrieb
 Wird MOA SP/SS als Webservice eingesetzt, kann durch Aufrufen einer speziellen URL des Webservice ein erneutes Einlesen der Konfigurationsdatei erzwungen werden. Damit ist es möglich, Änderungen an der Konfigurationsdatei vorzunehmen, und diese Änderungen ohne Neustart des zu Grunde liegenden Servlet Containers in den Betrieb zu übernehmen.
 Weitere Informationen zum erneuten Einlesen der Konfigurationsdatei im Webservice-Betrieb erhalten Sie in Abschnitt 2.1.2.5 des Installationshandbuchs.
-1.4 Konfiguration des Loggings
-  MOA SP/SS verwendet als Framework für Logging-Information die Open Source Software log4j. Die Konfiguration der Logging-Information erfolgt  nicht direkt durch MOA SP/SS, sondern über eine eigene Konfigurationsdatei, die der Java Virtual Machine durch eine System Property   mitgeteilt wird. Der Name der System Property   lautet log4j.configuration; als Wert der System Property   ist eine URL anzugeben, die auf die log4j-Konfigurationsdatei verweist, z.B.
-  
-  
log4j.configuration=file:/C:/Programme/apache/tomcat-4.1.30/conf/moa-spss/log4j.properties
+1.4 Konfiguration des Loggings
+  MOA SP/SS verwendet als Framework für Logging-Information die Open Source Software log4j. Die Konfiguration der Logging-Information erfolgt  nicht direkt durch MOA SP/SS, sondern über eine eigene Konfigurationsdatei, die der Java Virtual Machine durch eine System Property   mitgeteilt wird. Der Name der System Property   lautet log4j.configuration; als Wert der System Property   ist eine URL anzugeben, die auf die log4j-Konfigurationsdatei verweist, z.B.  
+log4j.configuration=file:/C:/Programme/apache/tomcat-4.1.30/conf/moa-spss/log4j.properties
   Weitere Informationen zur Konfiguration des Loggings erhalten Sie in Abschnitt 2.1.3 des Installationshandbuchs.
 
   2 Konfigurationsparameter
@@ -219,7 +217,7 @@
   
   
   2.1.2 Auflösen externer URIs
-  Standardmäßig ist das Auflösen von externen URIs (inkl. localhost) deaktiviert (d.h. keines der nachfolgenden Konfigurationselement cfg:PermitExternalUris bzw. cfg:ForbidExternalUris existiert). Es gibt jedoch zwei Möglichkeiten das Auflösen zu aktivieren bzw. zu 
+  Standardmäßig ist das Auflösen von externen URIs (inkl. localhost) deaktiviert (d.h. keines der nachfolgenden Konfigurationselement cfg:PermitExternalUris bzw. cfg:ForbidExternalUris existiert). Es gibt jedoch zwei Möglichkeiten das Auflösen zu aktivieren: 
   
     Blacklisting: Hierbei wird das Auflösen von externen URIs erlaubt. Es kann jedoch durch die Angaben einer Blacklist der Zugriff auf bestimmte URIs eingeschränkt werden.
     Whitelisting: Hierbei ist das Auflösen von externen URIs weiterhin verboten. Es kann jedoch durch die Angabe einer Whitelist der Zugriff auf bestimmte URIs gestattet werden.
diff --git a/spss/handbook/handbook/faq/faq.html b/spss/handbook/handbook/faq/faq.html
index 00e005a02..4e9ff77a3 100644
--- a/spss/handbook/handbook/faq/faq.html
+++ b/spss/handbook/handbook/faq/faq.html
@@ -5,17 +5,16 @@
   MOA SS und SP - FAQ
   
 
- 
+ 
   
-      
-      
-      
+     
+      
+      
     Open Source

-      für das E-Government Dokumentation 
     
   
    
-  MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.5
+  MOA: Serversignatur (SS) und Signaturprüfung (SP)
   FAQ 
   
   Inhalt
diff --git a/spss/handbook/handbook/index.html b/spss/handbook/handbook/index.html
index 8146ea7c0..2dbc921bd 100644
--- a/spss/handbook/handbook/index.html
+++ b/spss/handbook/handbook/index.html
@@ -5,13 +5,12 @@
   MOA SS und SP - Übersicht
   
 
- 
+ 
   
-      
-      
+      
+      
     
       Open Source

-      für das E-Government Dokumentation 
     
   
    
diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html
index 57da2b55c..61785870d 100644
--- a/spss/handbook/handbook/install/install.html
+++ b/spss/handbook/handbook/install/install.html
@@ -5,17 +5,16 @@
   MOA SS und SP - Installation
   
 
-
+< 
   
-      
-      
+      
+      
     
       Open Source

-      für das E-Government Dokumentation 
     
   
    
-  MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.5 
+  MOA: Serversignatur (SS) und Signaturprüfung (SP) 
   Installation 
   
   Inhalt
diff --git a/spss/handbook/handbook/intro/intro.html b/spss/handbook/handbook/intro/intro.html
index af479d2c5..5d6dec136 100644
--- a/spss/handbook/handbook/intro/intro.html
+++ b/spss/handbook/handbook/intro/intro.html
@@ -5,17 +5,16 @@
   MOA SS und SP - Einführung
   
 
- 
+ 
   
-      
-      
+      
+      
     
       Open Source

-      für das E-Government Dokumentation 
     
   
    
-  MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.5 
+  MOA: Serversignatur (SS) und Signaturprüfung (SP) 
   Einführung 
   
   Inhalt
diff --git a/spss/handbook/handbook/usage/usage.html b/spss/handbook/handbook/usage/usage.html
index 6fcccc612..b6f97b79d 100644
--- a/spss/handbook/handbook/usage/usage.html
+++ b/spss/handbook/handbook/usage/usage.html
@@ -5,17 +5,16 @@
   MOA SS und SP - Anwendung
   
 
-
+ 
   
-      
-      
-      
+     
+      
+      
     Open Source

-      für das E-Government Dokumentation 
     
   
   
-  MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.5
+  MOA: Serversignatur (SS) und Signaturprüfung (SP)
   Anwendung
   
   Inhalt
@@ -96,16 +95,16 @@
   KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
     <SingleSignatureInfo SecurityLayerConformity="true">
    Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
-    <DataObjectInfo Structure="enveloping">
-	     <DataObject>
-		    <MetaInfo>
-             <MimeType>text/plain</MimeType>
-          </MetaInfo>
-          <Content>
-         	   <Base64Content>RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</Base64Content>
-          </Content>			
-       </DataObject>		
-	  </DataObjectInfo>
+  <DataObjectInfo Structure="enveloping">
+	  <DataObject>
+	    <MetaInfo>
+        <MimeType>text/plain</MimeType>
+      </MetaInfo>
+      <Content>
+        <Base64Content>RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</Base64Content>
+      </Content>			
+    </DataObject>		
+	</DataObjectInfo>
 
 Das zu signierende Daten-Objekt muss in einem  DataObjectInfo Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten in die Signatur integriert werden sollen (Structure="enveloping") oder nicht (Structure="detached"). 
  Im nachfolgenden DataObject Element muss entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit im Element Base64Content (enthält Daten in Base64 kodierter Form) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig im Element Base64Content ist nicht erlaubt. Zusätzlich muss im Element MimeType (unter dem Element MetaInfo) der MIME-Type der zu signierenden Daten spezifiziert werden.
@@ -113,8 +112,8 @@
 Response
 TODO: Neue Signatur erzeugen (da CAdES - d.h. noch auf neues iaik-moa warten)
   CreateCMSSignatureRequest.Base64Content.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.  
-  <CreateCMSSignatureResponse
-  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	<CMSSignature>MIAGCSqGSI...p92gh6wAAAAAAAA=</CMSSignature>
</CreateCMSSignatureResponse>
+    <CreateCMSSignatureResponse
+    xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	  <CMSSignature>MIAGCSqGSI...p92gh6wAAAAAAAA=</CMSSignature>
  </CreateCMSSignatureResponse>
 CreateCMSSignatureResponse enthält je erzeugter Signatur ein Element CMSSignature (in diesem Fall genau ein Element). CMSSignature enthält die von SS erzeugte CAdES-Signatur (da SecurityLayerConformity="true" im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping). 
 2.1.1.2 Beispiel (Datenobjekt als Referenz)
   
@@ -124,22 +123,22 @@
 KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
   <SingleSignatureInfo SecurityLayerConformity="false">
  Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
-    <DataObjectInfo Structure="detached">
-	     <DataObject>
-		    <MetaInfo>
-             <MimeType>text/plain</MimeType>
-          </MetaInfo>
-          <Content Reference="http://localhost:8080/moa-spss-handbook-referencedData/Text.txt"/>         	   
-       </DataObject>		
-	  </DataObjectInfo>
+  <DataObjectInfo Structure="detached">
+	  <DataObject>
+	    <MetaInfo>
+        <MimeType>text/plain</MimeType>
+      </MetaInfo>
+      <Content Reference="http://localhost:8080/moa-spss-handbook-referencedData/Text.txt"/>         	   
+    </DataObject>		
+	</DataObjectInfo>
 
 Das zu signierende Daten-Objekt muss in einem DataObjectInfo Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten in die Signatur integriert werden sollen (Structure="enveloping") oder nicht (Structure="detached"). 
  Im nachfolgenden DataObject Element muss entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit im Element Base64Content (enthält Daten in Base64 kodierter Form) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig im Element Base64Content ist nicht erlaubt. Zusätzlich muss im Element MimeType (unter dem Element MetaInfo) der MIME-Type der zu signierenden Daten spezifiziert werden.
 Im konkreten Beispiel sollen die Daten nicht in die Signatur integriert werden (Structure="detached"). Die Daten werden in diesem Beispiel mittels der Attributs Refernce angegeben und SS muss es von dieser URL laden. Der MIME-Type wird mit text/plain angegeben.
 Response
 CreateCMSSignatureRequest.Reference.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. 
-<CreateCMSSignatureResponse
-  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	<CMSSignature>MIAGCSqGSI...SwxhbA9pAAAAAAAA</CMSSignature>
</CreateCMSSignatureResponse>
+  <CreateCMSSignatureResponse
+    xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	  <CMSSignature>MIAGCSqGSI...SwxhbA9pAAAAAAAA</CMSSignature>
  </CreateCMSSignatureResponse>
 CreateCMSSignatureResponse enthält je erzeugter Signatur ein Element CMSSignature (in diesem Fall genau ein Element). CMSSignature enthält die von SS erzeugte CMS-Signatur (da SecurityLayerConformity="false" im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur nicht enthalten (detached).
 2.1.2 Erstellung einer XML bzw. XAdES-Signatur
 MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x TODO. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
@@ -151,216 +150,216 @@
   KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
     <SingleSignatureInfo SecurityLayerConformity="false">
    Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
-    <DataObjectInfo Structure="enveloping">
-      <DataObject>
-        <XMLContent>Diese Daten werden signiert.<XMLContent>
-      </DataObject>
+  <DataObjectInfo Structure="enveloping">
+    <DataObject>
+      <XMLContent>Diese Daten werden signiert.<XMLContent>
+    </DataObject>
  
    Für jedes Daten-Objekt, das in die XML-Signatur als dsig:Reference aufgenommen werden soll, muss ein DataObjectInfo Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten in die Signatur in ein dsig:Object Element integriert werden sollen (Structure="enveloping"), oder über einen URL referenziert werden sollen (Structure="detached"). 
    Im Fall von Structure="enveloping" muss im nachfolgenden DataObject Element entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit in einem der Elemente Base64Content (enthält Daten in Base64 kodierter Form) oder XMLContent (enthält Daten als beliebiges XML-Fragment) oder LocRefContent (enthält eine URL, von der SS die Daten beziehen soll; in diesem Fall also gleichwertig wie ein gesetztes Attribut Reference) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig einem der Elemente Base64Content oder XMLContent oder LocRefContent ist nicht erlaubt.
   Im Fall von Structure="detached" muss das Attribut Reference im nachfolgenden DataObject Element gesetzt sein. Es enthält jene URL, die  zur Referenzierung der Daten als Wert von dsig:Reference/@URI in die XML-Signatur aufgenommen wird. Die Angabe eines der Element Base64Content oder XMLContent oder LocRefContent ist optional. Unterbleibt die Angabe, bezieht SS die Daten von der URL im Attribut Reference. Wird eines der Elemente verwendet, bezieht SS die Daten durch Analyse des angegebenen Elements (siehe obiger Absatz). 
   Im konkreten Beispiel sollen die Daten in ein dsig:Object Element integriert werden (Structure="enveloping"). Die Daten werden mittels XMLContent als XML-Fragment (ein einfacher Textknoten) angegeben.
   
-  
    <CreateTransformsInfoProfile>
      <CreateTransformsInfo>
-        <FinalDataMetaInfo>
-          <MimeType>text/plain<MimeType>
-        </FinalDataMetaInfo>
-      </CreateTransformsInfo>
-    </CreateTransformsInfoProfile>
+    <CreateTransformsInfoProfile>
    <CreateTransformsInfo>
+      <FinalDataMetaInfo>
+        <MimeType>text/plain<MimeType>
+      </FinalDataMetaInfo>
+    </CreateTransformsInfo>
+  </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  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>
-        ...
-        <dsig:Reference Id="reference-1-1" URI="#xpointer(id(&apos;signed-data-1-1-1&apos;)/node())">
+  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>
           ...
-        </dsig:Reference>
+          <dsig:Reference Id="reference-1-1" URI="#xpointer(id(&apos;signed-data-1-1-1&apos;)/node())">
+          ...
+          </dsig:Reference>
+          ...
+        </dsig:SignedInfo>
         ...
-    </dsig:SignedInfo>
-    ...
-    <dsig:Object Id="signed-data-1-1-1">Diese Daten werden signiert.</dsig:Object>
-    </dsig:Signature>
  </SignatureEnvironment>
</CreateXMLSignatureResponse>
-  
+        <dsig:Object Id="signed-data-1-1-1">Diese Daten werden signiert.</dsig:Object>
+      </dsig:Signature>
    </SignatureEnvironment>
  </CreateXMLSignatureResponse>
+
   CreateXMLSignatureResponse enthält je erzeugter Signatur ein Element SignatureEnvironment (in diesem Fall genau ein Element). SignatureEnvironment enthält die von SS erzeugte XML-Signatur, die im obigen Request spezifiziert wurde. Man erkennt, dass die XML-Signatur genau ein Daten-Objekt unterzeichnet (ein dsig:Reference Element ist enthalten). Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping), und zwar in einem dsig:Object Element. 
   2.1.2.2 Angabe der zu signierenden Daten 
   Request
   Dieses Beispiel stellt die vielfältigen Möglichkeiten vor, wie MOA SS mitgeteilt werden kann, welche Daten signiert (wenn keine Transformationen angegeben werden) bzw. als Eingangsdaten für die Berechnung der Transformationen verwendet werden sollen (wenn Transformationen angegeben werden).
   Mit CreateXMLSignatureRequest.Refs.xml sollen insgesamt neun Datenobjekte signiert werden:
-  <CreateXMLSignatureRequest
-  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
-  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
  <KeyIdentifier>KG_allgemein</KeyIdentifier>
  <SingleSignatureInfo SecurityLayerConformity="false">
+    <CreateXMLSignatureRequest
+    xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
+    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
    <KeyIdentifier>KG_allgemein</KeyIdentifier>
    <SingleSignatureInfo SecurityLayerConformity="false">
   Die Signatur soll mit dem Schlüssel KG_allgemein erstellt werden; jene Elemente, die speziell für eine Security-Layer V1.1 konforme Signatur notwendig sind (vergleiche Einfaches Beispiel), brauchen nicht erstellt zu werden (SecurityLayerConformity="false").
-      <DataObjectInfo Structure="enveloping" ChildOfManifest="true">
-      <DataObject>
-        <Base64Content>RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</Base64Content>
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>text/plain</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+    <DataObjectInfo Structure="enveloping" ChildOfManifest="true">
+    <DataObject>
+      <Base64Content>RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</Base64Content>
+    </DataObject>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>text/plain</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
   Die Daten sollen in der Enveloping Form in die Signatur integriert werden, d. h. die Daten werden in einem dsig:Object als Teil der XML-Struktur der Signatur aufgenommen (Structure="enveloping"). Weiters sollen die Daten nicht über über eine dsig:Reference in dsig:SignedInfo, sondern über eine dsig:Reference in einem eigenen dsig:Manifest aufgenommen werden (ChildOfManifest="true").
   Die Daten selbst werden explizit in base64 kodierter Form als Inhalt des Elements Base64Content angegeben. Das Attribut DataObject/@Reference darf nicht angegeben werden, da die Daten in der Enveloping Form integriert werden sollen, und Base64Content verwendet wird.
   Es werden - wie in allen übrigen Fällen dieses Beispiels - keine Transformationen angegeben. Der Mime-Type der zu signierenden Daten wird als text/plain angegeben, da der Inhalt von Base64Content die base64-Kodierung des Texts Diese Daten waren base64 kodiert. ist. 
   -    <DataObjectInfo Structure="enveloping" ChildOfManifest="false">
-      <DataObject>
-        <XMLContent><doc:XMLDocument xmlns:doc="urn:document">
-  <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>
-</doc:XMLDocument></XMLContent>
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>application/xml</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="enveloping" ChildOfManifest="false">
+    <DataObject>
+      <XMLContent><doc:XMLDocument xmlns:doc="urn:document">
+        <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>
+      </doc:XMLDocument></XMLContent>
+    </DataObject>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>application/xml</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
   Die Daten sollen in der Enveloping Form in die Signatur integriert werden, d. h. die Daten werden in einem dsig:Object als Teil der XML-Struktur der Signatur aufgenommen (Structure="enveloping"). Diesmal sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false").
   Die Daten selbst werden explizit als XML-Fragment als Inhalt des Elements XMLContent angegeben. Das Attribut DataObject/@Reference darf nicht angegeben werden, da die Daten in der Enveloping Form integriert werden sollen, und XMLContent verwendet wird.
   Der Mime-Type der zu signierenden Daten wird als application/xml angegeben.
 -    <DataObjectInfo Structure="enveloping" ChildOfManifest="false">
-      <DataObject Reference="http://localhost:8080/referencedData/Text.txt"/>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>text/plain</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="enveloping" ChildOfManifest="false">
+    <DataObject Reference="http://localhost:8080/referencedData/Text.txt"/>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>text/plain</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Die Daten sollen in der Enveloping Form in die Signatur integriert werden, d. h. die Daten werden in einem dsig:Object als Teil der XML-Struktur der Signatur aufgenommen (Structure="enveloping"). Wiederum sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false").
 
 Die Daten werden diesmal nicht explizit angegeben, sondern mittels der URL in DataObject/@Reference referenziert. MOA SS versucht diese URL aufzulösen, um zu den zu signierenden Daten zu gelangen. Base64Content oder XMLContent oder LocRefContent dürfen nicht verwendet werden,  da die Daten in der Enveloping Form integriert werden sollen, und bereits DataObject/@Reference eingesetzt wird. 
 Der Mime-Type der zu signierenden Daten wird als text/plain angegeben.
 -    <DataObjectInfo Structure="enveloping" ChildOfManifest="false">
-      <DataObject>
-        <LocRefContent>http://localhost:8080/referencedData/Text.txt</LocRefContent>
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>text/plain</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="enveloping" ChildOfManifest="false">
+    <DataObject>
+      <LocRefContent>http://localhost:8080/referencedData/Text.txt</LocRefContent>
+    </DataObject>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>text/plain</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Die Daten sollen wiederum in der Enveloping Form in die Signatur integriert werden, d. h. die Daten werden in einem dsig:Object als Teil der XML-Struktur der Signatur aufgenommen (Structure="enveloping"). Wiederum sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false"). 
 Die Daten werden wie im vorhergehenden Fall nicht explizit angegeben, sondern referenziert. Diesmal wird die URL jedoch nicht DataObject/@Reference verwendet, sondern als Textinhalt des Elements LocRefContent (LocRef steht für Location Reference). DataObject/@Reference darf in diesem Fall nicht verwendet werden. Diese Methode ist semantisch völlig ident mit dem vorhergehenden Fall. 
 Der Mime-Type der zu signierenden Daten wird als text/plain angegeben.
 -    <DataObjectInfo Structure="detached" ChildOfManifest="true">
-      <DataObject Reference="http://localhost:8080/referencedData/Text.b64">
-        <Base64Content>RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</Base64Content>
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>text/plain</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="detached" ChildOfManifest="true">
+    <DataObject Reference="http://localhost:8080/referencedData/Text.b64">
+      <Base64Content>RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</Base64Content>
+    </DataObject>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>text/plain</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Die Daten sollen diesmal in der Detached Form in die Signatur aufgenommen werden, d. h. die Daten werden nicht direkt in die Signaturstruktur integriert, sondern lediglich mittels URI im Attribut URI der anzufertigenden dsig:Reference referenziert (Structure="detached"). Die Daten sollen indirekt über eine dsig:Reference eines dsig:Manifests aufgenommen werden  (ChildOfManifest="true"). 
 Die URI in DataObject/@Reference enthält dabei die URI, die zur Referenzierung in dsig:Reference/@URI aufgenommen werden soll. Die Daten selbst hingegen werden im diesem Beispiel explizit in base64 kodierter Form als Inhalt des Elements Base64Content angegeben. MOA SS löst also keine URL zur Erlangung der Daten auf, sondern verwendet den Inhalt von Base64Content. 
 Der Mime-Type der zu signierenden Daten wird als text/plain angegeben.
 -    <DataObjectInfo Structure="detached" ChildOfManifest="false">
-      <DataObject Reference="NichtAufloesbareReferenz1">
-        <XMLContent><doc:XMLDocument xmlns:doc="urn:document">
-  <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>
-</doc:XMLDocument></XMLContent>
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>application/xml</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="detached" ChildOfManifest="false">
+    <DataObject Reference="NichtAufloesbareReferenz1">
+      <XMLContent><doc:XMLDocument xmlns:doc="urn:document">
+        <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>
+        </doc:XMLDocument>
+      </XMLContent>
+    </DataObject>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>application/xml</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Die Daten sollen auch diesmal in der Detached Form in die Signatur aufgenommen werden, d. h. die Daten werden nicht direkt in die Signaturstruktur integriert, sondern lediglich mittels URI im Attribut URI der anzufertigenden dsig:Reference referenziert (Structure="detached"). Diesmal sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false").
 
 Die URI in DataObject/@Reference enthält dabei die URI, die zur Referenzierung in dsig:Reference/@URI aufgenommen werden soll. Die Daten selbst hingegen werden im diesem Beispiel explizit als XML-Fragment in XMLContent angegeben. MOA SS löst auch hier keine URL zur Erlangung der Daten auf, sondern verwendet den Inhalt von XMLContent. Zur Verdeutlichung dieses Umstandes wurde die URI in DataObject/@Reference auf einen Wert gesetzt, der von MOA SS ganz sicher nicht aufgelöst werden kann (NichtAufloesbareReferenz1). 
 Der Mime-Type der zu signierenden Daten wird als application/xml angegeben.
 -    <DataObjectInfo Structure="detached" ChildOfManifest="false">
-      <DataObject Reference="http://localhost:8080/referencedData/Text.txt">
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>text/plain</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="detached" ChildOfManifest="false">
+    <DataObject Reference="http://localhost:8080/referencedData/Text.txt">
+    </DataObject>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <FinalDataMetaInfo>
+          <MimeType>text/plain</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Wiederum sollen die Daten in der Detached Form in die Signatur aufgenommen werden (Structure="detached"). Wie zuvor sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false"). 
 Die URI in DataObject/@Reference enthält dabei die URI, die zur Referenzierung in dsig:Reference/@URI aufgenommen werden soll. Nachdem eine explizite Angabe der Daten mittels Base64Content, XMLContent oder LocRefContent unterbleibt, wird MOA SS versuchen, die URI in  dsig:Reference/@URI als URL aufzulösen, um so zu den zu signierenden Daten zu gelangen. 
 Der Mime-Type der zu signierenden Daten wird als text/plain angegeben.
 -    <DataObjectInfo Structure="detached" ChildOfManifest="false">
-      <DataObject Reference="NichtAufloesbareReferenz2">
-        <LocRefContent>http://localhost:8080/referencedData/Text.txt</LocRefContent>
-      </DataObject>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <FinalDataMetaInfo>
-            <MimeType>text/plain</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="detached" ChildOfManifest="false">
+    <DataObject Reference="NichtAufloesbareReferenz2">
+      <LocRefContent>http://localhost:8080/referencedData/Text.txt</LocRefContent>
+    </DataObject>
+   <CreateTransformsInfoProfile>
+     <CreateTransformsInfo>
+       <FinalDataMetaInfo>
+         <MimeType>text/plain</MimeType>
+       </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Wiederum sollen die Daten in der Detached Form in die Signatur aufgenommen werden (Structure="detached"). Wie zuvor sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false").
 Die URI in DataObject/@Reference enthält dabei die URI, die zur Referenzierung in dsig:Reference/@URI aufgenommen werden soll. Den Hinweis, wie MOA SS zu den zu signierenden Daten gelangen soll, ist jedoch in LocRefContent enthalten. MOA SS wird also versuchen, die dort enthaltene URL aufzulösen, um zu den zu signierenden Daten zu gelangen. Zur Verdeutlichung dieses Umstandes wurde die URI in DataObject/@Reference auf einen Wert gesetzt, der von MOA SS ganz sicher nicht aufgelöst werden kann (NichtAufloesbareReferenz2). Diese Art der Datenangabe kann eingesetzt werden, wenn die Daten zum Zeitpunkt der Signaturerstellung von einem anderen Ort bezogen werden müssen, als später dann bei der Signaturprüfung.
 Der Mime-Type der zu signierenden Daten wird als text/plain angegeben.
 -    <DataObjectInfo Structure="detached" ChildOfManifest="false">
-      <DataObject Reference=""/>
-      <CreateTransformsInfoProfile>
-        <CreateTransformsInfo>
-          <dsig:Transforms>
-            <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
-          </dsig:Transforms>
-          <FinalDataMetaInfo>
-            <MimeType>application/xml</MimeType>
-          </FinalDataMetaInfo>
-        </CreateTransformsInfo>
-      </CreateTransformsInfoProfile>
-    </DataObjectInfo>
+  <DataObjectInfo Structure="detached" ChildOfManifest="false">
+    <DataObject Reference=""/>
+    <CreateTransformsInfoProfile>
+      <CreateTransformsInfo>
+        <dsig:Transforms>
+          <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
+        </dsig:Transforms>
+        <FinalDataMetaInfo>
+          <MimeType>application/xml</MimeType>
+        </FinalDataMetaInfo>
+      </CreateTransformsInfo>
+    </CreateTransformsInfoProfile>
+  </DataObjectInfo>
 
 Im letzten Fall schließlich sollen wiederum Daten in der Detached Form in die Signatur aufgenommen werden (Structure="detached"). Wie zuvor sollen die Daten direkt über eine dsig:Reference in dsig:SignedInfo aufgenommen werden (ChildOfManifest="false").
 Die Referenz auf die zu signierenden Daten ist wiederum in DataObject/@Reference enthalten; sie verweist diesmal jedoch nicht auf ein externes Dokument, sondern auf das gesamte (XML-)Dokument, in das die zu erstellende Signatur integriert werden soll, und zwar, indem DataObject/@Reference den leeren String ("") enthält. Nachdem dadurch zwangsläufig auch die Signatur in den zu signierenden Daten enthalten wäre, wird die Signatur durch die Angabe einer Enveloped Signature Transform aus den zu signierenden Daten herausgenommen, bevor darüber der Hashwert berechnet wird (dsig:Transform).
 Offen bleibt die Frage, wie MOA SS nun weiß, in welches (XML-)Dokument es die die Signatur integrieren soll. Siehe dazu die Erläuterungen zum nächsten Ausschnitts des Requests. 
 Der Mime-Type der zu signierenden Daten wird als application/xml angegeben.
 -    <CreateSignatureInfo>
-      <CreateSignatureEnvironment>
-        <LocRefContent>http://localhost:8080/referencedData/XMLDocument.xml</LocRefContent>
-      </CreateSignatureEnvironment>
-      <CreateSignatureEnvironmentProfile>
-        <CreateSignatureLocation Index="4" xmlns:doc="urn:document">/doc:XMLDocument</CreateSignatureLocation>
-      </CreateSignatureEnvironmentProfile>
-    </CreateSignatureInfo>
+  <CreateSignatureInfo>
+    <CreateSignatureEnvironment>
+      <LocRefContent>http://localhost:8080/referencedData/XMLDocument.xml</LocRefContent>
+    </CreateSignatureEnvironment>
+    <CreateSignatureEnvironmentProfile>
+      <CreateSignatureLocation Index="4" xmlns:doc="urn:document">/doc:XMLDocument</CreateSignatureLocation>
+    </CreateSignatureEnvironmentProfile>
+  </CreateSignatureInfo>
 
 Das Element CreateSignatureInfo ist grundsätzlich optional, und muss nur angegeben werden, wenn die zu erstellende Signatur von MOA SS in ein bestehendes XML-Dokument integriert werden soll (was in diesem Beispiel ja der Fall ist).
 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.
@@ -368,118 +367,118 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 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  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>
-    <doc:XMLDocument xmlns:doc="urn:document">
-      <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:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
-          <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
+  <CreateXMLSignatureResponse
+    xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
+    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+    <SignatureEnvironment>
+      <doc:XMLDocument xmlns:doc="urn:document">
+        <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:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
+            <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
 
 Die Antwort enthält in SignatureEnvironment das Ergebnis der Signaturerstellung. Nachdem die Signatur in ein bestehendes XML-Dokument integriert werden sollte, enthält SignatureEnvironment das Dokument-Element dieses XML-Dokuments (doc:XMLDocument). Man erkennt auch gut, dass die XML-Signatur als fünfter Kindknoten (Offset 4) von doc:XMLDocument eingefügt wurde.
 -          <dsig:Reference Id="reference-1-2" URI="#xpointer(id('signed-data-1-2-1')/node())">
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>A8ml6/aZKCmj1hONwvLItIwGHoc=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-2" URI="#xpointer(id('signed-data-1-2-1')/node())">
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>A8ml6/aZKCmj1hONwvLItIwGHoc=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des zweiten DataObjectInfo Elements im Request erstellt. Man erkennt gut den Verweis in dsig:Reference/@URI auf das dsig:Object, das die signierten Daten enthält (der XPointer verweist auf sämtliche Kindknoten jenes Elements, das ein ID-Attribut mit dem Wert signed-data-1-2-1 aufweist, des ersten vorkommenden dsig:Objects der Signatur). 
 -          <dsig:Reference Id="reference-1-3" URI="#xpointer(id('signed-data-1-3-1')/node())">
-            <dsig:Transforms>
-              <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
-            </dsig:Transforms>
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-3" URI="#xpointer(id('signed-data-1-3-1')/node())">
+              <dsig:Transforms>
+                <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
+              </dsig:Transforms>
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des dritten DataObjectInfo Elements im Request erstellt. Die Text-Daten wurden von der angegebenen URL (http://localhost:8080/referencedData/Text.txt) aufgelöst und in das dsig:Object mit dem ID-Attribut signed-data-1-3-1 gesteckt. Um Probleme mit nicht in XML darstellbare Zeichen zu vermeiden, wurde der Text nicht direkt signiert, sondern in base64 kodierter Form in das dsig:Object integriert, und eine Transformation zur base64 Dekodierung spezifiziert. 
 -          <dsig:Reference Id="reference-1-4" URI="#xpointer(id('signed-data-1-4-1')/node())">
-            <dsig:Transforms>
-              <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
-            </dsig:Transforms>
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-4" URI="#xpointer(id('signed-data-1-4-1')/node())">
+              <dsig:Transforms>
+                <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
+              </dsig:Transforms>
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des vierten DataObjectInfo Elements im Request erstellt. Wie schon bei der Beschreibung des Requests angeführt, ist die erstellte dsig:Reference semantisch genau gleich wie die vorhergehende. 
 -          <dsig:Reference Id="reference-1-6" URI="NichtAufloesbareReferenz1">
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>2b83+NbXDFijHzz+sH0T7fM36sA=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-6" URI="NichtAufloesbareReferenz1">
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>2b83+NbXDFijHzz+sH0T7fM36sA=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des sechsten DataObjectInfo Elements im Request erstellt. Die zu signierenden Daten wurden aus dem XMLContent des Requests entnommen, als Wert von dsig:Reference/@URI wurde der Wert von DataObjectInfo/@Reference übernommen. 
 -          <dsig:Reference Id="reference-1-7" URI="http://localhost:8080/referencedData/Text.txt">
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-7" URI="http://localhost:8080/referencedData/Text.txt">
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des siebenten DataObjectInfo Elements im Request erstellt. Um zu den zu signierenden Daten zu gelangen, wurde von MOA SS die URL in DataObjectInfo/@Reference aufgelöst. Gleichermaßen wurde die URL in dsig:Reference/@URI übernommen. 
 -          <dsig:Reference Id="reference-1-8" URI="NichtAufloesbareReferenz2">
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-8" URI="NichtAufloesbareReferenz2">
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>0P878Dsmtxv5goj+6KgNmj6S/EE=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des achten DataObjectInfo Elements im Request erstellt. Um zu den zu signierenden Daten zu gelangen, wurde von MOA SS die URL in LocRefContent aufgelöst. In dsig:Reference/@URI wurde der Wert aus DataObjectInfo/@Reference übernommen.
 -          <dsig:Reference Id="reference-1-9" URI="">
-            <dsig:Transforms>
-              <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
-            </dsig:Transforms>
-            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-            <dsig:DigestValue>2b83+NbXDFijHzz+sH0T7fM36sA=</dsig:DigestValue>
-          </dsig:Reference>
+            <dsig:Reference Id="reference-1-9" URI="">
+              <dsig:Transforms>
+                <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
+              </dsig:Transforms>
+              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+              <dsig:DigestValue>2b83+NbXDFijHzz+sH0T7fM36sA=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference wurde auf Grund des neunten DataObjectInfo Elements im Request erstellt. Als zu signierende Daten wurde das XML-Dokument ausgewählt, in das die XML-Signatur integriert werden solle. Vor der Berechnung des Hashwerts wurde eine Enveloped Signature Transformation zwischengeschaltet, welche die XML-Struktur der Signatur selbst aus den Hash-Eingangsdaten herausschneidet. 
 -          <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>mNsxUkFoF46XZVBivBo4aasFCTQ=</dsig:DigestValue>
-          </dsig:Reference>
+            <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>mNsxUkFoF46XZVBivBo4aasFCTQ=</dsig:DigestValue>
+            </dsig:Reference>
 
 Diese dsig:Reference verweist auf das dsig:Manifest weiter unten in der XML-Struktur der Signatur. Das dsig:Manifest wurde angelegt, weil bei zwei DataObjectInfos im Request das Attribut ChildOfManifest auf den Wert true gesetzt wurde.
 -        </dsig:SignedInfo>
-        <dsig:SignatureValue>...</dsig:SignatureValue>
-        <dsig:KeyInfo>...</dsig:KeyInfo>
-        <dsig:Object Id="signed-data-1-2-1">
-          <doc:XMLDocument xmlns:doc="urn:document">
-            <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>
-          </doc:XMLDocument>
-        </dsig:Object>
-        <dsig:Object Id="signed-data-1-3-1">RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</dsig:Object>
-        <dsig:Object Id="signed-data-1-4-1">RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</dsig:Object>
-        <dsig:Object Id="signed-data-1-1-1">RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</dsig:Object>
+          </dsig:SignedInfo>
+          <dsig:SignatureValue>...</dsig:SignatureValue>
+          <dsig:KeyInfo>...</dsig:KeyInfo>
+          <dsig:Object Id="signed-data-1-2-1">
+            <doc:XMLDocument xmlns:doc="urn:document">
+              <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>
+            </doc:XMLDocument>
+          </dsig:Object>
+          <dsig:Object Id="signed-data-1-3-1">RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</dsig:Object>
+          <dsig:Object Id="signed-data-1-4-1">RGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4=</dsig:Object>
+          <dsig:Object Id="signed-data-1-1-1">RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</dsig:Object>
 
 SignatureValue und KeyInfo werden an dieser Stelle nicht näher betrachtet.
 Das erste dsig:Object enthält die Daten aus dem zweiten DataObjectInfo; das zweite dsig:Object jene aus dem dritten DataObjectInfo; das dritte dsig:Object jene aus dem vierten DataObjectInfo; das vierte dsig:Object schließlich jene aus dem ersten DataObjectInfo.
 -        <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:Transforms>
-                <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
-              </dsig:Transforms>
-              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-              <dsig:DigestValue>a53jOsL7KbyltpByAK87FoMZphI=</dsig:DigestValue>
-            </dsig:Reference>
-            <dsig:Reference Id="reference-1-5" URI="http://localhost:8080/referencedData/Text.b64">
-              <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
-              <dsig:DigestValue>a53jOsL7KbyltpByAK87FoMZphI=</dsig:DigestValue>
-            </dsig:Reference>
-          </dsig:Manifest>
-        </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:Transforms>
+                  <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
+                </dsig:Transforms>
+                <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+                <dsig:DigestValue>a53jOsL7KbyltpByAK87FoMZphI=</dsig:DigestValue>
+              </dsig:Reference>
+              <dsig:Reference Id="reference-1-5" URI="http://localhost:8080/referencedData/Text.b64">
+                <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
+                <dsig:DigestValue>a53jOsL7KbyltpByAK87FoMZphI=</dsig:DigestValue>
+              </dsig:Reference>
+            </dsig:Manifest>
+          </dsig:Object>
 
 Das fünfte dsig:Object enthält das dsig:Manifest, das von MOA SS auf Grund des ersten bzw. fünften DataObjectInfo des Requests erstellt wurde. Darin enthalten sind die zum ersten und fünten DataObjectInfo korrespondierenden dsig:Reference Elemente. Die Daten für die erste im dsig:Manifest enthaltene dsig:Reference wurden aus dem Base64Content Element des ersten DataObjectInfo entnommen, jene für die zweite dsig:Reference aus dem Base64Content Element des fünften DataObjectInfo. Der Wert des URI Attributs der zweiten dsig:Reference wurde aus dem DataObject/@Reference des fünften DataObjectInfo übernommen. 
 2.1.2.3 Transformationen
-- 
cgit v1.2.3


From 4072ea9de2646cd16475ec1e9bf7d345e5a618c1 Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Thu, 16 May 2013 11:42:43 +0200
Subject: Minor updates documentation

---
 ...reateCMSSignatureRequest.Base64Content.resp.xml |  34 +++++++++++----------
 spss/handbook/handbook/config/config.html          |   9 +++---
 spss/handbook/handbook/install/install.html        |   8 ++---
 spss/handbook/handbook/intro/intro.html            |   3 +-
 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.pdf     | Bin 0 -> 288688 bytes
 spss/handbook/handbook/usage/usage.html            |   5 ++-
 6 files changed, 28 insertions(+), 31 deletions(-)
 create mode 100644 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.pdf

(limited to 'spss/handbook')

diff --git a/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml
index a99e97d0c..45b06e48f 100644
--- a/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml
+++ b/spss/handbook/clients/webservice/resources/requests/CreateCMSSignatureRequest.Base64Content.resp.xml
@@ -1,6 +1,6 @@
 
 
-	MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgMwgAYJKoZIhvcNAQcB
+         MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgMwgAYJKoZIhvcNAQcB
 oIAkgAQdRGllc2UgRGF0ZW4gc2luZCByZWluZXIgVGV4dC4AAAAAAACgggQvMIIE
 KzCCA5SgAwIBAgIGY6tXffAmMA0GCSqGSIb3DQEBBQUAMEAxIjAgBgNVBAMTGUlB
 SUsgVGVzdCBJbnRlcm1lZGlhdGUgQ0ExDTALBgNVBAoTBElBSUsxCzAJBgNVBAYT
@@ -24,21 +24,23 @@ bWVkaWF0ZUNBLmNlcjAJBgNVHREEAjAAMB8GA1UdIwQYMBaAFGiiXhHa3i+Aa0RE
 v436ZTaBJKdvMA0GCSqGSIb3DQEBBQUAA4GBAGzwtp4nq0IxjnK5D86/9Gg6NRN2
 K39wN8/Zd6Uo8OnwmpYxEdfLsnDhp+H1IcqRFroqDRDmtoRXRqIW0VKJno70CzuW
 +3ZFsSopH51BbHSxIvXAbxfOPX1PZQ1fXGTo5gWaJ62Xeu6zi+YtSxQHNMHqUxO/
-llGVtT8VDtNGS0wGMYICuTCCArUCAQEwSjBAMSIwIAYDVQQDExlJQUlLIFRlc3Qg
+llGVtT8VDtNGS0wGMYIC0TCCAs0CAQEwSjBAMSIwIAYDVQQDExlJQUlLIFRlc3Qg
 SW50ZXJtZWRpYXRlIENBMQ0wCwYDVQQKEwRJQUlLMQswCQYDVQQGEwJBVAIGY6tX
-ffAmMAsGCWCGSAFlAwQCA6CCAUQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
-BgkqhkiG9w0BCQUxDxcNMTMwNTA2MjAwNTQ2WjBPBgkqhkiG9w0BCQQxQgRAds70
-61RkR9wybcxKrtd9Uc/S/DNyxhvXPzr5A8IphKGDTe4lHXiky2xwjYEcSE7Mx3Jm
-8Lo5d9iFu45Dq9nx0DCBuAYLKoZIhvcNAQkQAi8xgagwgaUwgaIwgZ8wCwYJYIZI
-AWUDBAIDBEBxEElsIgrSD8KgnZk88uomiqWEEvWoMufQe68l7z1/qYX39aLlD2Sh
-pHolkI+EM5JuuWM678CAJdkOTvxUvKm8ME4wRKRCMEAxIjAgBgNVBAMTGUlBSUsg
-VGVzdCBJbnRlcm1lZGlhdGUgQ0ExDTALBgNVBAoTBElBSUsxCzAJBgNVBAYTAkFU
-AgZjq1d98CYwCwYJKoZIhvcNAQEBBIIBACRh+vEXSpupLSJY56WNzVTaPLq4EINO
-ovsOFaigYtFy9VOVVijg0ycMJqEeIl+lxJvmr9z30w9g4STa0EGoFxt2rXCyYtFt
-W+A70MPZ++PXlKAtBtXoMR2hVZ5XYk8yI42NBlN0XWOTgDZgTXlj4M4YYZHUPCLr
-NhwT2hLZ6WsQWhZpVF6d8GnhqPPgUnSibbDkjHHQMJZh/y5j+1M8IrSosPainrkI
-8yxyZOmbfoWVUXKRxFgfZ7YpWShbDgZ3JasyIXihOPXF7n2jlFxFACYiNrD93D4k
-p5j58Cfjvd0gm5QIDPvx1Z4rQ3oVOrzsjV+2e82hbqmhkzenp92gh6wAAAAAAAA=
-
+ffAmMAsGCWCGSAFlAwQCA6CCAVwwFgYGBACNRQIBMQwMCnRleHQvcGxhaW4wGAYJ
+KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE2MDkz
+MzUxWjBPBgkqhkiG9w0BCQQxQgRAds7061RkR9wybcxKrtd9Uc/S/DNyxhvXPzr5
+A8IphKGDTe4lHXiky2xwjYEcSE7Mx3Jm8Lo5d9iFu45Dq9nx0DCBuAYLKoZIhvcN
+AQkQAi8xgagwgaUwgaIwgZ8wCwYJYIZIAWUDBAIDBEBxEElsIgrSD8KgnZk88uom
+iqWEEvWoMufQe68l7z1/qYX39aLlD2ShpHolkI+EM5JuuWM678CAJdkOTvxUvKm8
+ME4wRKRCMEAxIjAgBgNVBAMTGUlBSUsgVGVzdCBJbnRlcm1lZGlhdGUgQ0ExDTAL
+BgNVBAoTBElBSUsxCzAJBgNVBAYTAkFUAgZjq1d98CYwCwYJKoZIhvcNAQEBBIIB
+AN0fuQCwuCxNQOGtR+Jv6lk/1QQkkxD7YUvbjGbJoaX+qpYmRFyw5dLo1y+1p4fR
+Sxyy0Zn2Yo8dD+5q/4LFtC4O1sz6qGZtmDMizwOuRcDQ0sn+nBQcDDWw81QKWqha
+g7VWOotssgq9Rt//YswBh/mx5B7yEx7RXdzvK9knPncyXnM5Yef7yrhJ65txJMSA
+hWUqikMC6NUn8N+ZCYyFlqyCWmbwpvBqXXb5OLt5Ke/lqKKG7iQrVwfTPBy0A7SA
+ZnOHW9RnKfC9lXfT0Qf9jVCsXaTznlLQS5FzUVQNmEJzWF7WAwYzVhRgmxWhbnp+
+V8aqyuBfKTs4gm0sQIxXoToAAAAAAAA=
+      
+
 
 
diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html
index d1c7d5636..b0247180c 100644
--- a/spss/handbook/handbook/config/config.html
+++ b/spss/handbook/handbook/config/config.html
@@ -497,10 +497,9 @@ IssuerDN (RFC2253) :
     
     
       Erläuterung
-      TODO: Kanonisierungs-Algorithmen entsprechend Kommissionsentscheidung?
-        Als Inhalt des Elements  kann der Kanonisierungs-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:
-        
-        
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments 
http://www.w3.org/2001/10/xml-exc-c14n# 
http://www.w3.org/2001/10/xml-exc-c14n#WithComments  
+      Als Inhalt des Elements  kann der Kanonisierungs-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:
+
+
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments 
http://www.w3.org/2001/10/xml-exc-c14n# 
http://www.w3.org/2001/10/xml-exc-c14n#WithComments  
         
        Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:
       http://www.w3.org/TR/2001/REC-xml-c14n-20010315  
	  Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.
     
@@ -1181,7 +1180,7 @@ Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall.
     
   
   3 Beispielkonfigurationen
-  TODO Update Konfigurations (Simple, Expert)
+  
 3.1 Minimale Konfiguration für MOA SS
   Nachfolgend finden Sie eine zentrale Konfigurationsdatei mit den minimal notwendigen Einträgen für
     den alleinigen Betrieb von MOA SS. Darin sind als Kinder des Wurzelelements cfg:MOAConfiguration    folgende
diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html
index 61785870d..382f9633f 100644
--- a/spss/handbook/handbook/install/install.html
+++ b/spss/handbook/handbook/install/install.html
@@ -397,9 +397,8 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null>
 
3.1.3 Verwendung
    Um die MOA SP/SS Klassenbibliothek in einer Applikation verwenden zu können, müssen die mit MOA SP/SS ausgelieferten Bibliotheken in den Java Klassenpfad der Applikation eingebunden werden. 
   Die nachfolgende Tabelle listet diese Klassenbibliotheken auf; die Einträge in der Spalte Dateien sind relativ zum Verzeichnis $MOA_SPSS_INST zu interpretieren.
-  TODO Update Versions
 
-
+  
@@ -408,9 +407,8 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null>
 
-
-
+
diff --git a/spss/handbook/handbook/intro/intro.html b/spss/handbook/handbook/intro/intro.html
index 5d6dec136..077a1dabe 100644
--- a/spss/handbook/handbook/intro/intro.html
+++ b/spss/handbook/handbook/intro/intro.html
@@ -30,8 +30,7 @@
 
1 Allgemeines
 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.
-  TODO: CAdES auf SL1.2x aufbauend - wie siehts mir Rest aus?
-  Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V2.0) detailliert beschrieben. Da diese Spezifikation auf der  Schnittstellenspezifikation des Security-Layers (V 1.2x) TODO aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. 
+  Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V1.5.2) detailliert beschrieben. Da diese Spezifikation auf der  Schnittstellenspezifikation des Security-Layers (V 1.2x) TODO aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. 
2 Modul Serversignatur (SS) 
 Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die  Schnittstellenspezifikation des Security-Layers (V 1.2x TODO). 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.
    Der Zugriff auf einzelne Signaturschlüssel in MOA SS kann basierend auf dem für TLS-Client-Authentisierung verwendeten Zertifikat eingeschränkt werden. 
diff --git a/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.pdf b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.pdf
new file mode 100644
index 000000000..61e727eb3
Binary files /dev/null and b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.pdf differ
diff --git a/spss/handbook/handbook/usage/usage.html b/spss/handbook/handbook/usage/usage.html
index b6f97b79d..8bd1cdc46 100644
--- a/spss/handbook/handbook/usage/usage.html
+++ b/spss/handbook/handbook/usage/usage.html
@@ -110,8 +110,7 @@
  Im nachfolgenden DataObject Element muss entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit im Element Base64Content (enthält Daten in Base64 kodierter Form) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig im Element Base64Content ist nicht erlaubt. Zusätzlich muss im Element MimeType (unter dem Element MetaInfo) der MIME-Type der zu signierenden Daten spezifiziert werden.
Im konkreten Beispiel sollen die Daten in die Signatur integriert werden (Structure="enveloping"). Die Daten werden in diesem Beispiel mittels Base64Content angegeben. Der MIME-Type wird mit text/plain angegeben.
Response
-TODO: Neue Signatur erzeugen (da CAdES - d.h. noch auf neues iaik-moa warten)
-  CreateCMSSignatureRequest.Base64Content.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.  
+CreateCMSSignatureRequest.Base64Content.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.  
  <CreateCMSSignatureResponse
     xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	  <CMSSignature>MIAGCSqGSI...p92gh6wAAAAAAAA=</CMSSignature>
  </CreateCMSSignatureResponse>
CreateCMSSignatureResponse enthält je erzeugter Signatur ein Element CMSSignature (in diesem Fall genau ein Element). CMSSignature enthält die von SS erzeugte CAdES-Signatur (da SecurityLayerConformity="true" im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping). 
@@ -1176,7 +1175,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
     <Code>0</Code>
   </SignatureManifestCheck>
 
-Das Element SignatureManifestCheck enhält das Resultat der Prüfung des Zusammenhangs  zwischen Referenz-Eingangsdaten und Hash-Eingangsdaten. Der Kode 0 im konkreten Beispiel bedeutet, dass alle Referenzen  die in der Anfrage zur Überprüfung der XML-Signatur gemachten Einschränkungen bezüglich der erlaubten Transformationskette(n) einhalten, sowie dass die Anforderungen  hinsichtlich des Signaturmanifests werden eingehalten. Für eine Übersicht der möglichen Kodes siehe die Spezifikation zu MOA SP/SS (Link TODO), Abschnitt 5.1.3.1.4.
+Das Element SignatureManifestCheck enhält das Resultat der Prüfung des Zusammenhangs  zwischen Referenz-Eingangsdaten und Hash-Eingangsdaten. Der Kode 0 im konkreten Beispiel bedeutet, dass alle Referenzen  die in der Anfrage zur Überprüfung der XML-Signatur gemachten Einschränkungen bezüglich der erlaubten Transformationskette(n) einhalten, sowie dass die Anforderungen  hinsichtlich des Signaturmanifests werden eingehalten. Für eine Übersicht der möglichen Kodes siehe die Spezifikation zu MOA SP/SS, Abschnitt 5.1.3.1.4.
   <CertificateCheck>
     <Code>0</Code>
-- 
cgit v1.2.3


From a52d3300d20837b12b45a0d4fb2b0ee520f6e641 Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Wed, 14 Aug 2013 16:36:40 +0200
Subject: 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

---
 spss/handbook/clients/api/.classpath               | 84 +++++++++++-----------
 .../api/.settings/org.eclipse.jdt.core.prefs       | 11 +--
 spss/handbook/clients/referencedData/.classpath    | 10 +--
 .../.settings/org.eclipse.jdt.core.prefs           | 11 +--
 .../.settings/org.eclipse.wst.common.component     |  5 +-
 .../org.eclipse.wst.common.project.facet.core.xml  |  4 +-
 spss/handbook/clients/webservice/.classpath        | 66 ++++++++++-------
 spss/handbook/clients/webservice/.project          | 74 +++++++++----------
 .../.settings/org.eclipse.jdt.core.prefs           | 11 +--
 spss/handbook/handbook/config/config.html          |  1 -
 spss/handbook/handbook/install/install.html        |  5 +-
 spss/handbook/handbook/intro/intro.html            |  8 +--
 spss/handbook/handbook/usage/usage.html            | 37 +++++++---
 13 files changed, 173 insertions(+), 154 deletions(-)

(limited to 'spss/handbook')

diff --git a/spss/handbook/clients/api/.classpath b/spss/handbook/clients/api/.classpath
index 95a3df914..ea8736aef 100644
--- a/spss/handbook/clients/api/.classpath
+++ b/spss/handbook/clients/api/.classpath
@@ -1,45 +1,43 @@
 
 
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-	
-		
-			
-		
-	
-	
-
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
\ No newline at end of file
diff --git a/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs b/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs
index c788ee346..5bdae7434 100644
--- a/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs
+++ b/spss/handbook/clients/api/.settings/org.eclipse.jdt.core.prefs
@@ -1,8 +1,9 @@
+#Mon Aug 05 10:52:31 CEST 2013
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 eclipse.preferences.version=1
 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
-org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
-org.eclipse.jdt.core.compiler.compliance=1.7
+org.eclipse.jdt.core.compiler.source=1.5
 org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
-org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
-org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
-org.eclipse.jdt.core.compiler.source=1.7
+org.eclipse.jdt.core.compiler.compliance=1.5
diff --git a/spss/handbook/clients/referencedData/.classpath b/spss/handbook/clients/referencedData/.classpath
index d888b90e9..0173dfd90 100644
--- a/spss/handbook/clients/referencedData/.classpath
+++ b/spss/handbook/clients/referencedData/.classpath
@@ -1,9 +1,5 @@
 
 
-	
-		
-			
-		
-	
-	
-
+  
+  
+
\ No newline at end of file
diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs b/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs
index c788ee346..5bdae7434 100644
--- a/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs
+++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.jdt.core.prefs
@@ -1,8 +1,9 @@
+#Mon Aug 05 10:52:31 CEST 2013
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 eclipse.preferences.version=1
 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
-org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
-org.eclipse.jdt.core.compiler.compliance=1.7
+org.eclipse.jdt.core.compiler.source=1.5
 org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
-org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
-org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
-org.eclipse.jdt.core.compiler.source=1.7
+org.eclipse.jdt.core.compiler.compliance=1.5
diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component
index 2063ba643..0929e364c 100644
--- a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component
+++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.component
@@ -1,7 +1,8 @@
-
+
+
   
     
     
     
   
-
+
\ No newline at end of file
diff --git a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml
index 47b82b84e..564572b10 100644
--- a/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml
+++ b/spss/handbook/clients/referencedData/.settings/org.eclipse.wst.common.project.facet.core.xml
@@ -3,5 +3,5 @@
   
   
   
-  
-
+  
+
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/.classpath b/spss/handbook/clients/webservice/.classpath
index b75cb2821..ea8736aef 100644
--- a/spss/handbook/clients/webservice/.classpath
+++ b/spss/handbook/clients/webservice/.classpath
@@ -1,27 +1,43 @@
 
 
-	
-		
-			
-			
-		
-	
-	
-		
-			
-			
-		
-	
-	
-		
-			
-			
-		
-	
-	
-		
-			
-		
-	
-	
-
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/.project b/spss/handbook/clients/webservice/.project
index cddae3823..d23223048 100644
--- a/spss/handbook/clients/webservice/.project
+++ b/spss/handbook/clients/webservice/.project
@@ -1,44 +1,34 @@
 
 
-	moa-spss-handbook-webserviceClient
-	NO_M2ECLIPSE_SUPPORT: Project files created with the maven-eclipse-plugin are not supported in M2Eclipse.
-	
-		moa-common
-		moa-spss-lib
-	
-	
-		
-			org.eclipse.jdt.core.javabuilder
-			
-			
-		
-		
-			org.eclipse.wst.common.project.facet.core.builder
-			
-			
-		
-		
-			org.eclipse.wst.validation.validationbuilder
-			
-			
-		
-		
-			org.maven.ide.eclipse.maven2Builder
-			
-			
-		
-		
-			org.eclipse.m2e.core.maven2Builder
-			
-			
-		
-	
-	
-		org.eclipse.m2e.core.maven2Nature
-		org.maven.ide.eclipse.maven2Nature
-		org.eclipse.wst.common.project.facet.core.nature
-		org.eclipse.jdt.core.javanature
-		org.eclipse.wst.common.modulecore.ModuleCoreNature
-		org.eclipse.jem.workbench.JavaEMFNature
-	
-
+  moa-spss-handbook-webserviceClient
+  NO_M2ECLIPSE_SUPPORT: Project files created with the maven-eclipse-plugin are not supported in M2Eclipse.
+  
+    moa-common
+    moa-spss-lib
+  
+  
+    
+      org.eclipse.jdt.core.javabuilder
+    
+    
+      org.eclipse.wst.common.project.facet.core.builder
+    
+    
+      org.eclipse.wst.validation.validationbuilder
+    
+    
+      org.maven.ide.eclipse.maven2Builder
+    
+    
+      org.eclipse.m2e.core.maven2Builder
+    
+  
+  
+    org.eclipse.m2e.core.maven2Nature
+    org.maven.ide.eclipse.maven2Nature
+    org.eclipse.wst.common.project.facet.core.nature
+    org.eclipse.jdt.core.javanature
+    org.eclipse.wst.common.modulecore.ModuleCoreNature
+    org.eclipse.jem.workbench.JavaEMFNature
+  
+
\ No newline at end of file
diff --git a/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs b/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs
index c788ee346..5bdae7434 100644
--- a/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs
+++ b/spss/handbook/clients/webservice/.settings/org.eclipse.jdt.core.prefs
@@ -1,8 +1,9 @@
+#Mon Aug 05 10:52:31 CEST 2013
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
 eclipse.preferences.version=1
 org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
-org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
-org.eclipse.jdt.core.compiler.compliance=1.7
+org.eclipse.jdt.core.compiler.source=1.5
 org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
-org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
-org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning
-org.eclipse.jdt.core.compiler.source=1.7
+org.eclipse.jdt.core.compiler.compliance=1.5
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.
 3.4 Typische Konfiguration für MOA SP/SS
   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 Anwenderhandbuchs notwendig ist.
   Typische Konfiguration für MOA SP/SS  
-    
 
 
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 @@
   
   Wir empfehlen jedoch jeweils aktuelle Version zu verwenden:
   
-    Java SE 6 Update 41 bzw. Java SE Update SE 6 Update 21
+    Java SE 6 (neuestes Update) bzw. Java SE Update SE 7 (neuestes Update)
     Apache Tomcat 6.0.36 bzw. Apache Tomcat 7.0.39
 
   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.
@@ -377,7 +377,7 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null>
 
   Wir empfehlen jedoch jeweils aktuelle Version zu verwenden:
   
-    Java SE 6 Update 41 bzw. Java SE Update SE 6 Update 21
+    Java SE 6 (neuestes Update) bzw. Java SE Update SE 7 (neuestes Update)
   
 3.1.2 Vorbereitung 
 Die folgenden Schritte dienen der Vorbereitung der Installation.
@@ -487,5 +487,6 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null>
     

 Klassenbibliothek Version Dateien
 
 
moa-spss.jar, moa-common.jar
 

 MOA IAIK 1.33.1
-  TODO: Update Version (auf 1.5 laut Harald)  lib/iaik_moa-1.33.1.jar,
+ 1.5  lib/iaik_moa-1.5.jar,
       lib/iaik_cms-4.1.jar, lib/iaik_ixsil-1.2.2.5.jar
   
 
   
   
 
   
   
   
 
   
 
 Logging Framework 
   
 
+
 
 
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 @@
 
   1 Allgemeines
    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.
-  Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V1.5.2) detailliert beschrieben. Da diese Spezifikation auf der  Schnittstellenspezifikation des Security-Layers (V 1.2x) TODO aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. 
+  Die Funktionalität und der Aufbau der Schnittstelle zu den beiden Modulen ist in der Spezifikation MOA SP/SS (V1.5.2) detailliert beschrieben. Da diese Spezifikation auf der  @TODO (Update auf neue abgestimmte Spezifikation) Schnittstellenspezifikation des Security-Layers (V 1.2x) aufbaut, ist deren Kenntnis zum Verstehen der Schnittstellen zu SS und SP erforderlich. 
 2 Modul Serversignatur (SS) 
-   Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die  Schnittstellenspezifikation des Security-Layers (V 1.2x TODO). 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.
+   Das Modul Serversignatur (SS) dient zum Erstellen von XML-Signaturen in Anlehnung an die  @TODO (Update auf neue abgestimmte Spezifikation) Schnittstellenspezifikation des Security-Layers (V 1.2x TODO). 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.
       Der Zugriff auf einzelne Signaturschlüssel in MOA SS kann basierend auf dem für TLS-Client-Authentisierung verwendeten Zertifikat eingeschränkt werden. 
       Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen. 
   3 Modul Signaturprüfung (SP) 
-   Das Modul Signaturprüfung (SP) dient zum Überprüfen von XML-Signaturen und CMS-Signaturen sowie den fortgeschrittenen Signaturen XAdES (TODO Link + Versionen) und CAdES (TODO Link + Versionen).
-  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 Schnittstellenspezifikation des Security-Layers (V 1.2x TODO) entsprechen (vgl. Signaturmanifest). 
+   Das Modul Signaturprüfung (SP) dient zum Überprüfen von XML-Signaturen und CMS-Signaturen sowie den fortgeschrittenen Signaturen XAdES (@TODO Link + Versionen basierend auf Update SL) und CAdES (@TODO Link + Versionen basierend auf Update SL).
+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 @TODO (Update auf neue abgestimmte Spezifikation) Schnittstellenspezifikation des Security-Layers (V 1.2x) entsprechen (vgl. Signaturmanifest). 
       Anwendungen können das Modul entweder als Web-Service oder über ein Java-API ansprechen.
 
 
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 @@
   
   
     Referenzierte Software
+    Referenzierte Spezifikation
   
+
 
   1 Übersicht
      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.
@@ -87,14 +89,14 @@
   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. 
 Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf localhost, z.B. http://localhost:8080/referencedData/Text.txt. 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 localhost:8080 betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation referencedData.war in das Verzeichnis webapps Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen. 
   2.1.1 Erstellung einer CMS bzw. CAdES-Signatur
-  MOA-SS ermöglicht die Erstellung einer herkömmlichen CMS-Signatur und einer CAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x TODO. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme CAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele).
+  MOA-SS ermöglicht die Erstellung einer herkömmlichen CMS-Signatur und einer CAdES-Signatur gemäß der  Security-Layer Spezifikation. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme CAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele).
 2.1.1.1 Beispiel (Base64-codiertes Datenobjekt)
 Request
   CreateCMSSignatureRequest.Base64Content.xml ist ein einfacher XML-Request zur Erzeugung einer CAdES-Signatur. Sein Aufbau wird nachfolgend analysiert:
     <KeyIdentifier>KG_allgemein</KeyIdentifier> 
   KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
     <SingleSignatureInfo SecurityLayerConformity="true">
-   Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
+   Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß  Security-Layer Spezifikation 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).
   <DataObjectInfo Structure="enveloping">
 	  <DataObject>
 	    <MetaInfo>
@@ -121,7 +123,7 @@
   <KeyIdentifier>KG_allgemein</KeyIdentifier> 
 KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
   <SingleSignatureInfo SecurityLayerConformity="false">
- Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
+ Für jedes SingleSignatureInfoElement wird eine eigene CMS/CAdES-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine CAdES-Signatur gemäß  Security-Layer Spezifikation 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).
   <DataObjectInfo Structure="detached">
 	  <DataObject>
 	    <MetaInfo>
@@ -140,7 +142,7 @@
     xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
	  <CMSSignature>MIAGCSqGSI...SwxhbA9pAAAAAAAA</CMSSignature>
  </CreateCMSSignatureResponse>
 CreateCMSSignatureResponse enthält je erzeugter Signatur ein Element CMSSignature (in diesem Fall genau ein Element). CMSSignature enthält die von SS erzeugte CMS-Signatur (da SecurityLayerConformity="false" im Request angegeben wurde) als Base64-codierten Wert. Das unterzeichnete Datenobjekt ist in der Signaturstruktur nicht enthalten (detached).
 2.1.2 Erstellung einer XML bzw. XAdES-Signatur
-MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.2x TODO. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
+MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der  Security-Layer Spezifikation. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele). 
 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 Konfiguration der XAdES Version).
 2.1.2.1 Einfaches Beispiel
   Request
@@ -148,7 +150,7 @@
     <KeyIdentifier>KG_allgemein</KeyIdentifier> 
   KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. 
     <SingleSignatureInfo SecurityLayerConformity="false">
-   Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.2x TODO  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).
+   Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß  Security-Layer Spezifikation 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).
   <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>
 
- 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.2x TODO.
+ 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 Spezifikation.
    <CertificateCheck>
     <Code>1</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 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.2x TODO.
+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 Spezifikation.
 2.1.3.2 Erweitertes Beispiel
 Request
 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. 
@@ -801,13 +803,13 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
     <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.2x TODO.
+ 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 Spezifikation.
    <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.2x TODO.
+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 Spezifikation.
 2.1.4.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.
@@ -943,7 +945,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife
   </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.2x TODO.
+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 Spezifikation.
 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>
@@ -1184,7 +1186,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
 Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).
  
-TODO Beispiel-Request mit TSL-Prüfung
+@TODO Beispiel-Request mit TSL-Prüfung
 2.2 Webservice-Clients
 Abschnitt 2.1 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.
 2.2.1 Übersicht
@@ -1280,5 +1282,18 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
   
   
 
+B Referenzierte Spezifikation
+
+  
+    
+      
+      
+    
+        	
+      
+      
+    
+  
+Spezifikation Link
Security Layer Spezifikation V x.x @TODO Version einfügen @TODO Link
 
 
-- 
cgit v1.2.3


From 5b697c424d24a7523dccd210454d029368e34898 Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Wed, 21 Aug 2013 13:12:26 +0200
Subject: Update QC/SSCD check WSDL location updated

---
 spss/handbook/clients/api/.classpath               |  82 ++++++++--------
 .../handbook/config/MOA-SPSS-config-1.5.2.xsd      |  61 +++++++++---
 spss/handbook/handbook/config/config.html          |   6 +-
 spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd     | 104 +++++++++++++++++++--
 4 files changed, 188 insertions(+), 65 deletions(-)

(limited to 'spss/handbook')

diff --git a/spss/handbook/clients/api/.classpath b/spss/handbook/clients/api/.classpath
index ea8736aef..53806d1e8 100644
--- a/spss/handbook/clients/api/.classpath
+++ b/spss/handbook/clients/api/.classpath
@@ -1,43 +1,43 @@
 
 
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
\ No newline at end of file
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+	
+
diff --git a/spss/handbook/handbook/config/MOA-SPSS-config-1.5.2.xsd b/spss/handbook/handbook/config/MOA-SPSS-config-1.5.2.xsd
index 669ebe53f..91d281171 100644
--- a/spss/handbook/handbook/config/MOA-SPSS-config-1.5.2.xsd
+++ b/spss/handbook/handbook/config/MOA-SPSS-config-1.5.2.xsd
@@ -19,20 +19,36 @@
 									
 								
 							
-							
-								
-									
-										
-											
-												
-													
-													
-												
-											
-										
-									
-								
-							
+							
+								
+									
+										
+											
+												
+													
+														
+														
+													
+												
+											
+										
+									
+								
+								
+									
+										
+											
+												
+													
+														
+														
+													
+												
+											
+										
+									
+								
+							
 						
 					
 				
@@ -78,6 +94,7 @@
 												
 											
 										
+										
 									
 								
 							
@@ -99,6 +116,19 @@
 							
 							
 							
+							
+								
+									
+										
+											
+												
+													
+												
+											
+										
+									
+								
+							
 						
 					
 				
@@ -147,7 +177,7 @@
 															
 														
 													
-													
+													
 														
 															
 																
@@ -283,6 +313,7 @@
 										
 											
 												
+													
 													
 														
 															
diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html
index 96270bde1..f44bd7dc0 100644
--- a/spss/handbook/handbook/config/config.html
+++ b/spss/handbook/handbook/config/config.html
@@ -1071,7 +1071,10 @@ Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall.
       Das Element cfg:TSLConfiguration legt die TSL Konfiguration fest, wenn Vertrauensprofile mit TSL Unterstützung konfiguriert sind. Das Element weist folgende Kind-Elemente auf:
         

         
-            Element cfg:UpdateSchedule: Dieses Element legt fest wann und in welchem Intervall die EU-TSL erneut eingelesen werden soll. Das Element cfg:UpdateSchedule besteht dabei aus folgenden Kind-Elementen:
+            Element cfg:EUTSLUrl: Dieses optionale Element legt die URL zur EU-TSL fest.

+            
+            Hinweis: Wird kein cfg:EUTSLUrl Element angegeben so wird defaultmäßig https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml als EU-TSL URL herangezogen.
+            Element cfg:UpdateSchedule: Dieses optionale Element legt fest wann und in welchem Intervall die EU-TSL erneut eingelesen werden soll. Das Element cfg:UpdateSchedule besteht dabei aus folgenden Kind-Elementen:
             
             Element cfg:StartTime: Legt eine Startzeit im Format hh:mm:ss fest. 
             Element cfg:Period: Legt das Intervall (in Millisekunden) fest, in welchem die EU-TSL erneut eingelesen werden soll
@@ -1085,7 +1088,6 @@ Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall.
           Wichtig: Das angegebene Verzeichnis muss jedenfalls die Unterverzeichnis
           "trust" aus der Beispiel-Konfiguration beinhalten. In dessen Unterverzeichnis "eu" müssen jene vertrauenswürdigen Zertifikate angegeben werden, mit denen die EU-TSL signiert ist.
         
-      Wichtig: Beim Tomcat-Start muss zusätzlich noch ein so genannten Hashcache Verzeichnis angegeben werden. Dies erfolgt mit dem Parameter iaik.xml.crypto.tsl.BinaryHashCache.DIR (siehe auch Starten und Stoppen von Tomcat). 
       Hinweis: Um die TSL Überprüfung zu aktivieren muss auch (zumindest) ein Vertrauensprofil mit TSL Überprüfung konfiguriert werden (siehe Vertrauensprofil)
     
     
diff --git a/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd
index 137ad6deb..144918778 100644
--- a/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd
+++ b/spss/handbook/handbook/spec/MOA-SPSS-1.5.2.xsd
@@ -1,15 +1,56 @@
 
 
 
 	
 	
 	
 	
-	
-		
-	
+	
+		
+			
+				
+			
+		
+	
+	
+		
+			
+			
+				
+					Ermöglichung der Stapelsignatur durch wiederholte Angabe dieses Elements
+				
+				
+					
+						
+							
+								
+									
+								
+							
+						
+					
+					
+				
+			
+		
+	
+	
+	
+	
+		
+			
+				Kardinalität 1..oo erlaubt die Antwort auf eine Stapelsignatur-Anfrage
+			
+			
+				
+					Resultat, falls die Signaturerstellung erfolgreich war
+				
+			
+			
+		
+	
 	
 	
 	
@@ -106,7 +147,7 @@
 		
 			
 				
-					only ds:X509Data and RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any;publicAuthority is included as X509Data/any
+					only ds:X509Data and RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any;publicAuthority is included as X509Data/any; SecureSignatureCreationDevice is included as X509Data/any, IssuingCountry is included as X509Data/any
 				
 			
 			
@@ -157,7 +198,7 @@
 		
 			
 				
-					only ds:X509Data and ds:RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any; PublicAuthority is included as X509Data/any
+					only ds:X509Data and ds:RetrievalMethod is supported; QualifiedCertificate is included as X509Data/any; PublicAuthority is included as X509Data/any; SecureSignatureCreationDevice is included as X509Data/any, IssuingCountry is included as X509Data/any
 				
 			
 			
@@ -228,6 +269,25 @@
 			
 		
 	
+	
+		
+			
+				
+					
+						
+					
+				
+			
+		
+		
+			
+				
+					
+					
+				
+			
+		
+	
 	
 		
 			
@@ -246,6 +306,12 @@
 			
 		
 	
+	
+		
+			
+			
+		
+	
 	
 		
 			
@@ -388,7 +454,31 @@
 			
 		
 	
-	
+	
+		
+			
+				
+					
+						
+						
+					
+				
+			
+		
+	
+	
+		
+			
+				
+					
+						
+						
+					
+				
+			
+		
+	
+	
 	
 	
 		
-- 
cgit v1.2.3


From 69f2dfdf3e0b5d976df3cdece6a8ead4848d746a Mon Sep 17 00:00:00 2001
From: Klaus Stranacher 
Date: Wed, 21 Aug 2013 19:02:57 +0200
Subject: Update standard configuration Update truststores and certstore Update
 wsdl location

---
 .../341F53B3B17518213B1856BFAB3CEFBE948AFC0D       | Bin 0 -> 1070 bytes
 .../3A24040C01D5C9A4980575BFF99A25E534A056CB       | Bin 0 -> 1070 bytes
 .../08BBE8E906397158FA4BF4058BBBDB5EA11BAE82       | Bin 0 -> 979 bytes
 .../04CF0318BA0B54DD76E1DE143445210BDD32E299       | Bin 0 -> 865 bytes
 .../266FCA0265A576548425BDAE15448665EE8BB889       | Bin 0 -> 1076 bytes
 .../8944AF64790FA467C02424CB22523A068C3B72DB       | Bin 0 -> 1073 bytes
 .../36B41A8B411985ED1032DBD85A154207164A9B85       | Bin 0 -> 1069 bytes
 spss/handbook/conf/moa-spss/sp.minimum.config.xml  |  32 +++++++++++++----
 .../conf/moa-spss/sp.minimum_with_tsl.config.xml   |  39 +++++++++++++++------
 spss/handbook/conf/moa-spss/spss.config.xml        |  32 +++++++++++++----
 spss/handbook/conf/moa-spss/ss.minimum.config.xml  |  18 +++++++---
 ...rust-nQual-01.20041201-20141201.SerNo01c85e.cer | Bin 0 -> 865 bytes
 ...Trust-nQual-04.20130708-20230701.SerNof28a2.cer | Bin 0 -> 979 bytes
 ...rust-nQual-01.20041201-20141201.SerNo01c85e.cer | Bin 0 -> 865 bytes
 ...Trust-nQual-04.20130708-20230701.SerNof28a2.cer | Bin 0 -> 979 bytes
 ...4.20130708-20230701.SerNo\342\200\216f28c4.cer" | Bin 0 -> 1073 bytes
 ...Premium-Sig-04.20130702-20230701.SerNof1d50.cer | Bin 0 -> 1070 bytes
 ...4.20130705-20230701.SerNo\342\200\216f24d6.cer" | Bin 0 -> 1070 bytes
 ...4.2010821-20230821.SerNo.\342\200\216f76bd.cer" | Bin 0 -> 1069 bytes
 ...Premium-Sig-04.20130702-20230701.SerNof1d50.cer | Bin 0 -> 1070 bytes
 ...4.20130705-20230701.SerNo\342\200\216f24d6.cer" | Bin 0 -> 1070 bytes
 ...mium-mobile-04.20130702-20180701.SerNof1d4f.cer | Bin 0 -> 1076 bytes
 22 files changed, 94 insertions(+), 27 deletions(-)
 create mode 100644 spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/341F53B3B17518213B1856BFAB3CEFBE948AFC0D
 create mode 100644 spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/3A24040C01D5C9A4980575BFF99A25E534A056CB
 create mode 100644 spss/handbook/conf/moa-spss/certstore/349CA7B279F4EF3C085B1E8D08AA5DE3EC586188/08BBE8E906397158FA4BF4058BBBDB5EA11BAE82
 create mode 100644 spss/handbook/conf/moa-spss/certstore/3B2F8C424AA88CA305C519FDEFCF29DDB7E96AE2/04CF0318BA0B54DD76E1DE143445210BDD32E299
 create mode 100644 spss/handbook/conf/moa-spss/certstore/A7437C35301BDB5349F320B62231615028F397F8/266FCA0265A576548425BDAE15448665EE8BB889
 create mode 100644 spss/handbook/conf/moa-spss/certstore/B1A1ACC805C656EF257C5115509B977964591D7E/8944AF64790FA467C02424CB22523A068C3B72DB
 create mode 100644 spss/handbook/conf/moa-spss/certstore/B293710691F553804016FCEC3428ABA1CB11ADF7/36B41A8B411985ED1032DBD85A154207164A9B85
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer
 create mode 100644 "spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Enc-04.20130708-20230701.SerNo\342\200\216f28c4.cer"
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer
 create mode 100644 "spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer"
 create mode 100644 "spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-corporate-04.2010821-20230821.SerNo.\342\200\216f76bd.cer"
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer
 create mode 100644 "spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer"
 create mode 100644 spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-premium-mobile-04.20130702-20180701.SerNof1d4f.cer

(limited to 'spss/handbook')

diff --git a/spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/341F53B3B17518213B1856BFAB3CEFBE948AFC0D b/spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/341F53B3B17518213B1856BFAB3CEFBE948AFC0D
new file mode 100644
index 000000000..3250c6adc
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/341F53B3B17518213B1856BFAB3CEFBE948AFC0D differ
diff --git a/spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/3A24040C01D5C9A4980575BFF99A25E534A056CB b/spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/3A24040C01D5C9A4980575BFF99A25E534A056CB
new file mode 100644
index 000000000..3848a2b82
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/0BF5B0C4B029051D91A83EE9CCD0266A52D867A6/3A24040C01D5C9A4980575BFF99A25E534A056CB differ
diff --git a/spss/handbook/conf/moa-spss/certstore/349CA7B279F4EF3C085B1E8D08AA5DE3EC586188/08BBE8E906397158FA4BF4058BBBDB5EA11BAE82 b/spss/handbook/conf/moa-spss/certstore/349CA7B279F4EF3C085B1E8D08AA5DE3EC586188/08BBE8E906397158FA4BF4058BBBDB5EA11BAE82
new file mode 100644
index 000000000..167c36411
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/349CA7B279F4EF3C085B1E8D08AA5DE3EC586188/08BBE8E906397158FA4BF4058BBBDB5EA11BAE82 differ
diff --git a/spss/handbook/conf/moa-spss/certstore/3B2F8C424AA88CA305C519FDEFCF29DDB7E96AE2/04CF0318BA0B54DD76E1DE143445210BDD32E299 b/spss/handbook/conf/moa-spss/certstore/3B2F8C424AA88CA305C519FDEFCF29DDB7E96AE2/04CF0318BA0B54DD76E1DE143445210BDD32E299
new file mode 100644
index 000000000..8d33015f9
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/3B2F8C424AA88CA305C519FDEFCF29DDB7E96AE2/04CF0318BA0B54DD76E1DE143445210BDD32E299 differ
diff --git a/spss/handbook/conf/moa-spss/certstore/A7437C35301BDB5349F320B62231615028F397F8/266FCA0265A576548425BDAE15448665EE8BB889 b/spss/handbook/conf/moa-spss/certstore/A7437C35301BDB5349F320B62231615028F397F8/266FCA0265A576548425BDAE15448665EE8BB889
new file mode 100644
index 000000000..3754de603
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/A7437C35301BDB5349F320B62231615028F397F8/266FCA0265A576548425BDAE15448665EE8BB889 differ
diff --git a/spss/handbook/conf/moa-spss/certstore/B1A1ACC805C656EF257C5115509B977964591D7E/8944AF64790FA467C02424CB22523A068C3B72DB b/spss/handbook/conf/moa-spss/certstore/B1A1ACC805C656EF257C5115509B977964591D7E/8944AF64790FA467C02424CB22523A068C3B72DB
new file mode 100644
index 000000000..a95605e5a
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/B1A1ACC805C656EF257C5115509B977964591D7E/8944AF64790FA467C02424CB22523A068C3B72DB differ
diff --git a/spss/handbook/conf/moa-spss/certstore/B293710691F553804016FCEC3428ABA1CB11ADF7/36B41A8B411985ED1032DBD85A154207164A9B85 b/spss/handbook/conf/moa-spss/certstore/B293710691F553804016FCEC3428ABA1CB11ADF7/36B41A8B411985ED1032DBD85A154207164A9B85
new file mode 100644
index 000000000..a365a465b
Binary files /dev/null and b/spss/handbook/conf/moa-spss/certstore/B293710691F553804016FCEC3428ABA1CB11ADF7/36B41A8B411985ED1032DBD85A154207164A9B85 differ
diff --git a/spss/handbook/conf/moa-spss/sp.minimum.config.xml b/spss/handbook/conf/moa-spss/sp.minimum.config.xml
index af7077e79..96f0cf4d5 100644
--- a/spss/handbook/conf/moa-spss/sp.minimum.config.xml
+++ b/spss/handbook/conf/moa-spss/sp.minimum.config.xml
@@ -3,18 +3,26 @@
 
 
 
-
+
+
+
 
-
+		-->
+
+
+
 	
 		
 			
@@ -65,22 +73,34 @@
 						CN=A-Trust-Qual-03,OU=A-Trust-Qual-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
+					
+						CN=A-Trust-Qual-04,OU=A-Trust-Qual-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						CN=a-sign-Premium-Sig-01,OU=a-sign-Premium-Sig-01,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
 					
-						CN=a-sign-Premium-Sig-02,OU=a-sign-Premium-Sig-02,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT													          
+						CN=a-sign-Premium-Sig-02,OU=a-sign-Premium-Sig-02,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
 					
 						CN=a-sign-Premium-Sig-03,OU=a-sign-Premium-Sig-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
+					
+						CN=a-sign-Premium-Sig-04,OU=a-sign-Premium-Sig-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						CN=a-sign-premium-mobile-03,OU=a-sign-premium-mobile-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 															
+					
+						CN=a-sign-premium-mobile-04,OU=a-sign-premium-mobile-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						E=a-cert@a-cert.at,CN=A-CERT GOVERNMENT,O=ARGE DATEN - Österreichische Gesellschaft für Datenschutz,L=Wien,S=Wien,C=AT
 						12775
diff --git a/spss/handbook/conf/moa-spss/sp.minimum_with_tsl.config.xml b/spss/handbook/conf/moa-spss/sp.minimum_with_tsl.config.xml
index 255360088..79345890a 100644
--- a/spss/handbook/conf/moa-spss/sp.minimum_with_tsl.config.xml
+++ b/spss/handbook/conf/moa-spss/sp.minimum_with_tsl.config.xml
@@ -3,18 +3,26 @@
 
 
 
-
+
+
+
 
-
+		-->
+
+
+
 	
 		
 			
@@ -35,7 +43,7 @@
 					trustProfiles/test
 				
 				
-					TestTSL
+					Test-TSLProfil
 					trustProfiles/testTSL
 					
 					
@@ -75,31 +83,42 @@
 						CN=A-Trust-Qual-03,OU=A-Trust-Qual-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
+					
+						CN=A-Trust-Qual-04,OU=A-Trust-Qual-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						CN=a-sign-Premium-Sig-01,OU=a-sign-Premium-Sig-01,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
 					
-						CN=a-sign-Premium-Sig-02,OU=a-sign-Premium-Sig-02,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT													          
+						CN=a-sign-Premium-Sig-02,OU=a-sign-Premium-Sig-02,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
 					
 						CN=a-sign-Premium-Sig-03,OU=a-sign-Premium-Sig-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
+					
+						CN=a-sign-Premium-Sig-04,OU=a-sign-Premium-Sig-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						CN=a-sign-premium-mobile-03,OU=a-sign-premium-mobile-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 															
+					
+						CN=a-sign-premium-mobile-04,OU=a-sign-premium-mobile-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						E=a-cert@a-cert.at,CN=A-CERT GOVERNMENT,O=ARGE DATEN - Österreichische Gesellschaft für Datenschutz,L=Wien,S=Wien,C=AT
 						12775
 					
 				
 			
-			
-			
-			
+			
+			
 			
 				
 					02:00:00
diff --git a/spss/handbook/conf/moa-spss/spss.config.xml b/spss/handbook/conf/moa-spss/spss.config.xml
index f12748f68..6fbd1bcee 100644
--- a/spss/handbook/conf/moa-spss/spss.config.xml
+++ b/spss/handbook/conf/moa-spss/spss.config.xml
@@ -3,18 +3,26 @@
 
 
 
-
+
+
+
 
-
+		-->
+
+
+
 	
 		
 			
@@ -170,22 +178,34 @@
 						CN=A-Trust-Qual-03,OU=A-Trust-Qual-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
+					
+						CN=A-Trust-Qual-04,OU=A-Trust-Qual-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						CN=a-sign-Premium-Sig-01,OU=a-sign-Premium-Sig-01,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
 					
-						CN=a-sign-Premium-Sig-02,OU=a-sign-Premium-Sig-02,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT													          
+						CN=a-sign-Premium-Sig-02,OU=a-sign-Premium-Sig-02,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
 					
 						CN=a-sign-Premium-Sig-03,OU=a-sign-Premium-Sig-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 					
+					
+						CN=a-sign-Premium-Sig-04,OU=a-sign-Premium-Sig-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						CN=a-sign-premium-mobile-03,OU=a-sign-premium-mobile-03,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
 						12775
 															
+					
+						CN=a-sign-premium-mobile-04,OU=a-sign-premium-mobile-04,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT
+						12775
+					
 					
 						E=a-cert@a-cert.at,CN=A-CERT GOVERNMENT,O=ARGE DATEN - Österreichische Gesellschaft für Datenschutz,L=Wien,S=Wien,C=AT
 						12775
diff --git a/spss/handbook/conf/moa-spss/ss.minimum.config.xml b/spss/handbook/conf/moa-spss/ss.minimum.config.xml
index 4f39f8517..f85bd1c6b 100644
--- a/spss/handbook/conf/moa-spss/ss.minimum.config.xml
+++ b/spss/handbook/conf/moa-spss/ss.minimum.config.xml
@@ -3,18 +3,26 @@
 
 
 
-
+
+
+
 
-
+		-->
+
+
+
 	
 		
 			
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer
new file mode 100644
index 000000000..8d33015f9
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer differ
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer
new file mode 100644
index 000000000..167c36411
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature+Test/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer differ
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer
new file mode 100644
index 000000000..8d33015f9
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-01.20041201-20141201.SerNo01c85e.cer differ
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer
new file mode 100644
index 000000000..167c36411
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/certifiedSignature/A-Trust-nQual-04.20130708-20230701.SerNof28a2.cer differ
diff --git "a/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Enc-04.20130708-20230701.SerNo\342\200\216f28c4.cer" "b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Enc-04.20130708-20230701.SerNo\342\200\216f28c4.cer"
new file mode 100644
index 000000000..a95605e5a
Binary files /dev/null and "b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Enc-04.20130708-20230701.SerNo\342\200\216f28c4.cer" differ
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer
new file mode 100644
index 000000000..3250c6adc
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer differ
diff --git "a/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer" "b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer"
new file mode 100644
index 000000000..3848a2b82
Binary files /dev/null and "b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer" differ
diff --git "a/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-corporate-04.2010821-20230821.SerNo.\342\200\216f76bd.cer" "b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-corporate-04.2010821-20230821.SerNo.\342\200\216f76bd.cer"
new file mode 100644
index 000000000..a365a465b
Binary files /dev/null and "b/spss/handbook/conf/moa-spss/trustProfiles/officialSignature/a-sign-corporate-04.2010821-20230821.SerNo.\342\200\216f76bd.cer" differ
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer b/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer
new file mode 100644
index 000000000..3250c6adc
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130702-20230701.SerNof1d50.cer differ
diff --git "a/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer" "b/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer"
new file mode 100644
index 000000000..3848a2b82
Binary files /dev/null and "b/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-Premium-Sig-04.20130705-20230701.SerNo\342\200\216f24d6.cer" differ
diff --git a/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-premium-mobile-04.20130702-20180701.SerNof1d4f.cer b/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-premium-mobile-04.20130702-20180701.SerNof1d4f.cer
new file mode 100644
index 000000000..3754de603
Binary files /dev/null and b/spss/handbook/conf/moa-spss/trustProfiles/secureSignature-qual-only/a-sign-premium-mobile-04.20130702-20180701.SerNof1d4f.cer differ
-- 
cgit v1.2.3

XML-Parser aus dem Apache Project
Apache Axis	Apache Axis	Webservice-Framework aus dem Apache Project
J2SE 1.4.2 SDK/JRE	Java 2 Standard Edition in der Version 1.4.2 (Software Development Kit bzw. Java Runtime Environment)
J2SE 5.0 SDK/JRE	Java 2 Standard Edition in der Version 5.0 (Software Development Kit bzw. Java Runtime Environment)
JSSE	Java Secure Socket Extension
Java SE	Java Standard Edition (Software Development Kit bzw. Java Runtime Environment)

1.1.1 Namenskonventionen

2.1.2 Auflösen externer URIs

2.2.5 Profil für Transformationen

2.3 - Parameter für MOA SP

2.3.1 Zertifikatsvalidierung

2.3.1.1 @@ -1124,7 +1130,8 @@ Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall.

3 Beispielkonfigurationen

3.1 Minimale Konfiguration für MOA SS

3.1 Minimale Konfiguration für MOA SS

2.1.1 Einführung

2.1.2 Installation

2.1.2 Installation

2.1.2.1 Vorbereitung

2.1.2.2 Konfiguration von Apache Tomcat

2.1.2.2.1 Konfiguration des HTTP Connectors

2.1.2.2 Konfiguration von Apache Tomcat

2.1.2.2.1 Konfiguration des HTTP Connectors

2.1.2.2.2 Konfiguration des HTTPS Connectors

2.2 Erweiterungsmöglichkeiten

2.2.1 Vorgeschalteter Webserver

2.2.1 Vorgeschalteter Webserver

2.2.1.1 Microsoft Internet Information Server (MS IIS)

2.2.1.1.1 Konfiguration von Jakarta mod_jk im MS IIS

3.1.1 Einführung

3.1.3 Verwendung

3.1.3 Verwendung

A Referenzierte Software

1 Allgemeines

2 Modul Serversignatur (SS)

2 Modul Serversignatur (SS)

2.1 XML-Requests

2.1.1 Erstellung einer XML-Signatur

2.1.1 Erstellung einer XML-Signatur

2.1.1.1 Einfaches Beispiel

Request

2.2 Webservice-Clients

2.2.1 Übersicht

2.2.2 Gemeinsamkeiten

A Referenzierte Software

2.1 Basisinstallation

2.1.1 Einführung

2.1.2 Installation

2.1.2.1 Vorbereitung

2.1.2.1 Vorbereitung

2.1.2.2 Konfiguration von Apache Tomcat

2.1.2.2.1 Konfiguration des HTTP Connectors

2.1.2.2.2 Konfiguration des HTTPS Connectors

2.1.2.2.3 Einrichten des MOA SP/SS Administrators

2.1.2.4 Starten und Stoppen von Tomcat

2.1.2.4.1 Unter Windows

2.1.2.4.2 Unter Unix

2.1.3 Logging

2.2 Erweiterungsmöglichkeiten

2.2 Erweiterungsmöglichkeiten

2.2.1 Vorgeschalteter Webserver

2.2.1.1 Microsoft Internet Information Server (MS IIS)

2.2.1.1.1 Konfiguration von Jakarta mod_jk im MS IIS

2.2.1.1.2 Konfiguration von Tomcat

2.2.1.1.3 Konfiguration von SSL

2.2.1 Vorgeschalteter Webserver

2.2.1.1 Microsoft Internet Information Server (MS IIS)

2.2.1.1.1 Konfiguration von mod_jk im MS IIS

2.2.1.1.2 Konfiguration von Tomcat

2.2.1.1.3 Konfiguration von SSL

2.2.1.2 Apache

2.2.1.2.1 Konfiguration von Jakarta mod_jk im Apache

2.2.1.2.1 Konfiguration von mod_jk im Apache

2.2.1.2.2 Konfiguration von Tomcat

2.2.1.2.2 Konfiguration von SSL mit mod_SSL

2.2.1.2.2 Konfiguration von Tomcat

2.2.1.2.2 Konfiguration von SSL mit mod_SSL

2.2.2 Datenbank

2.2.2 Datenbank

2.2.2.1 PostgreSQL

2.2.2.1.1 Anlegen eines Benutzers und einer Datenbank für MOA SP/SS

2.2.2.1 PostgreSQL

2.2.2.1.1 Anlegen eines Benutzers und einer Datenbank für MOA SP/SS

2.2.2.1.2 Archivierung von CRLs

2.2.2.1.2 Archivierung von CRLs

2.2.2.1.3 Logging