| Dokumentation |

MOA: Serversignatur (SS) und Signaturprüfung (SP)

Konfiguration

# Inhalt

1. Übersicht

   1. Allgemeines
      1. Namenskonventionen
   2. Zentrale Konfigurationsdatei
      1. Aktualisierung auf das Format von MOA SP/SS 1.3
   3. Bekanntmachung der Konfigurationsdatei
      1. Aktualisierung der Konfiguration im laufenden Betrieb
   4. Konfiguration des Loggings
2. Konfigurationsparameter
   1. Allgemeines Parameter
      1. Hardwarebasiertes Kryptographiemodul
      2. Auflösen externer URIs
         1. Blacklisting
         2. Whitelisting
   2. Parameter für MOA SS
      1. Schlüsselspeicher
         1. Hardware-Schlüsselspeicher
         2. Software-Schlüsselspeicher
      2. Schlüsselgruppe
      3. Zuordnung von Schlüsselgruppen zu einem Kunden
      4. Parameter für XML-Signaturen
      5. Profil für Transformationen
      6. Profil für Signaturumgebung
      7. XAdES Version
      8. Allgemeine Signaturparameter
   3. Parameter für MOA SP
      1. Zertifikatsvalidierung
         1. Konstruktion des Zertifikatspfads
            1. Cachen von Zertifikaten
            2. Auswertung der Zertifikatserweiterung Authority Information Access
            3. Lokalisierung des Zertifikatsspeichers
         2. Valdierung des Zertifikatspfads
            1. Gültigkeitsmodell für die Zertifikatskettenprüfung
            2. Vertrauensprofile
         3. Widerrufsprüfung
            1. Aktivieren der Widerrufsprüfung
            2. Maximales Alter der Widerrufsinformation
            3. Reihenfolge der Widerrufsdienste
            4. Archivierung von Widerrufsinformationen
            5. Manuelle Konfiguration von Verteilungspunkten für Widerrufsinformationen
            6. Validierung von short-term Zertifikaten
            7. TSL Konfiguration
      2. Profil für Transformationen
      3. Profil für Ergänzungsobjekte
      4. file-URIs
3. Beispielkonfigurationen
   1. Minimale Konfiguration für MOA SS
   2. Minimale Konfiguration für MOA SP
   3. Minimale Konfiguration für MOA SP mit TSL Unterstützung
   4. Typische Konfiguration für MOA SP/SS

# 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:

Präfix | Namenraum
--- | ---
`cfg` | `http://reference.e-government.gv.at/namespace/moaconfig/20021122#`
`dsig` | `http://www.w3.org/2000/09/xmldsig#`
`moa` | `http://reference.e-government.gv.at/namespace/moa/20020822#`
`xs` | `http://www.w3.org/2001/XMLSchema`

## 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-3.3.0.xsd entsprechen. Abschnitt 2 erläutert die Konfigurationsmöglichkeiten im Einzelnen.

### 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.

Wenn Sie von einer älteren Version von MOA SP/SS auf die Version 1.3 wechseln und Ihre bestehende Konfiguration beibehalten wollen, steht Ihnen ein einfaches Kommandozeilenwerkzeug zur Verfügung, mit dem Sie Ihre Konfigurationsdatei vom bisherigen auf das neue Format migrieren können.

Dieses Werkzeug können Sie durch Ausführen des Scripts `configtool` aus dem Verzeichnis `tools` im MOA-Installationsverzeichnis verwenden:

    configtool c:\pfad\zur\konfiguration\config.alt.xml c:\pfad\zur\konfiguration\config.neu.xml

Der erste Parameter für das Script gibt also Pfad und Dateiname der bestehenden, alten Konfigurationsdatei 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

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 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

Weitere Informationen zur Konfiguration des Loggings erhalten Sie in Abschnitt 2.1.3 des Installationshandbuchs.

# 2 Konfigurationsparameter

Nachfolgend werden die verfügbaren Konfigurationsparameter der zentralen Konfigurationsdatei im Detail erläutert. Die Reihenfolge der Abhandlung entspricht der Reihenfolge des vorgeschriebenen Auftretens in der Konfigurationsdatei. Für beispielhafte Konfigurationsdateien siehe Abschnitt 3.

Muss der Wert eines Konfigurationsparameters eine URL oder eine Pfadangabe sein, und wird als konkreter Wert eine relative URL bzw. ein relativer Pfad angegeben, so wird diese Angabe relativ zum Pfad jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist.

## 2.1 Allgemeine Parameter

### 2.1.1 Hardwarebasiertes Kryptographiemodul

Name | `cfg:Common/cfg:HardwareCryptoModule`
Gebrauch | Null mal bis unbeschränkt oft
Erläuterung | Mit diesem Element wird MOA SP bzw. SS die Verfügbarkeit eines Hardware-Kryptographiemoduls mitgeteilt. Wird ein solches Hardware-Kryptographiemodul konfiguriert, versucht MOA SP/SS das Hardware-Kryptographiemodul für die Verifikation des Signaturwerts (MOA SP) bzw. für die Berechnung von Hashwerten (MOA SP und MOA SS) anstatt des standardmäßig konfigurierten Software-Kryptographiemoduls zu verwenden. Werden mehrere Hardware-Kryptographiemodule konfiguriert, prüft MOA SP/SS entsprechend der Konfigurationsreihenfolge der Hardware-Kryptographiemodule, ob eines der Module die benötigte Funktion (Hashwertberechnung, Siganturprüfung) zur Verfügung stellt. Verwendet wird das erste Hardware-Kryptographiemodul, das ide benötigte Funktion zur Verfügung stellen kann. Das Element weist bis zu drei Kindelemente auf: Element `cfg:Name`: Dieses obligatorische Element vom Typ `xs:string` enthält den Dateinamen der DLL (Windows) oder der Shared-Library (Unix), welche die PKCS#11-Schnittstelle zum Hardware-Kryptographiemodul implementiert; der Wert enthält entweder einen Dateinamen mit absoluter Pfadangabe oder einen Dateinamen ohne Pfadangabe. Im letzteren Fall wird der Dateiname relativ zum Suchpfad des Betriebssystems interpretiert. Element `cfg:SlotId`: Dieses optionale Element vom Typ `xs:string` gibt des Slot der PKCS#11-Schnittstelle an, über den das Hardware-Kryptographiemodul von MOA SP/SS angesprochen werden soll. Fehlt dieses Attribut, wählt MOA SP/SS selbst einen Slot aus der Liste der verfügbaren Slots aus. Element `cfg:UserPIN`: Dieses obligatorische Element vom Typ `xs:string` enthält den PIN-Code zur Freischaltung der Kryptographiefunktionen über die PKCS#11-Schnittstelle des Hardware-Kryptographiemoduls.

### 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:

- 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

Name | `cfg:Common/cfg:PermitExternalUris`
Gebrauch | Null mal bis einmal
Erläuterung | 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: 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 nicht aufgelöst. Bei Angabe eines IP-Adress-Bereichs werden sämtliche URIs, die mit diesem IP-Bereich beginnen nicht 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 nicht aufgelöst. Ist keine Portnummer angegeben, sind alle Portnummern gesperrt. Empfehlung: Bei aktiviertem Auflösen von externen URIs sollten sowohl localhost als auch der gesamte Intranetbereich in die Blacklist eingetragen werden. Hierzu eine beispielhafte Blacklist: `<cfg:BlackListUri> <cfg:IP>192.168</cfg:IP> </cfg:BlackListUri> <cfg:BlackListUri> <cfg:IP>127.0.0.1</cfg:IP> </cfg:BlackListUri>`

#### 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

Name | `cfg:SignatureCreation/cfg:KeyModules/cfg:HardwareKeyModule`
Gebrauch | Null mal bis unbeschränkt oft; zumindest ein Hardware- (`cfg:HardwareKeyModule`) oder Software-Schlüsselspeicher (`cfg:SoftwareKeyModule`) muss jedoch vorhanden sein
Erläuterung | Mit diesem Element wird MOA SS die Verfügbarkeit eines Hardware-Schlüsselspeichers mitgeteilt. Das Element weist bis zu vier Kindelemente auf: Element `cfg:Id`: Dieses obligatorische Element vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Mit Hilfe dieses Identifikators wird im Konfigurationselement `cfg:SignatureCreation/cfg:KeyGroup` auf dieses Konfigurationselement referenziert. Element `cfg:Name`: Dieses obligatorische Element vom Typ `xs:string` enthält den Dateinamen der DLL (Windows) oder der Shared-Library (Unix), welche die PKCS#11-Schnittstelle zum Hardware-Schlüsselspeicher implementiert; der Wert enthält entweder einen Dateinamen mit absoluter Pfadangabe oder einen Dateinamen ohne Pfadangabe. Im letzteren Fall wird der Dateiname relativ zum Suchpfad des Betriebssystems interpretiert. Element `cfg:SlotId`: Dieses optionale Element vom Typ `xs:string` gibt des Slot der PKCS#11-Schnittstelle an, über den der Hardware-Schlüsselspeicher von MOA SS angesprochen werden soll. Fehlt dieses Attribut, wählt MOA SS selbst einen Slot aus der Liste der verfügbaren Slots aus. Element `cfg:UserPIN`: Dieses obligatorische Element vom Typ `xs:string` enthält den PIN-Code zur Freischaltung der Schlüsselverwendung über die PKCS#11-Schnittstelle des Hardware-Schlüsselspeichers.

#### 2.2.1.2 Software-Schlüsselspeicher

Name | `cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule`
Gebrauch | Null mal bis unbeschränkt oft; zumindest ein Hardware- (`cfg:HardwareKeyModule`) oder Software-Schlüsselspeicher (`cfg:SoftwareKeyModule`) muss jedoch vorhanden sein
Erläuterung | Mit diesem Element wird MOA SS die Verfügbarkeit eines Software-Schlüsselspeichers in Form einer PKCS#12-Datei mitgeteilt. Das Element weist drei obligatorische Kindelemente auf: Element `cfg:Id`: Dieses Element vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Mit Hilfe dieses Identifikators wird im Konfigurationselement `cfg:SignatureCreation/cfg:KeyGroup` auf dieses Konfigurationselement referenziert. Element `cfg:Filename`: Dieses Element vom Typ `xs:string` enthält den Dateinamen der PKCS#12-Datei, die den Software-Schlüsselspeicher repräsentiert. Der Wert enthält einen Dateinamen mit absoluter oder relativer Pfadangabe. Eine relative Pfadangabe wird von MOA SS relativ zum Pfad jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Element `cfg:Password`: Dieses Element vom Typ `xs:string` enthält das Passwort zum Entschlüsseln der Inhalte der PKCS#12-Datei.

### 2.2.2 Schlüsselgruppe

Name | `cfg:SignatureCreation/cfg:KeyGroup`
Gebrauch | einmal bis unbeschränkt oft
2. Erläuterung | 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 im Request zur Signaturerstellung angesprochen. 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. Das Element `cfg:SignatureCreation/cfg:KeyGroup` hat folgenden Element-Inhalt: Element `cfg:Id`: Dieses obligatorische Element vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Mit Hilfe dieses Identifikators wird im Konfigurationselement `cfg:SignatureCreation/cfg:KeyGroupMapping` auf dieses Konfigurationselement referenziert. Weiters wird dieser Identifikator im Request zur Erstellung der Signatur verwendet, um die zu verwendende Schlüsselgruppe anzugeben. Element `cfg:Key`: Dieses Element muss zumindest einmal vorkommen. Jedes Element beschreibt einen der privaten Schlüssel, aus denen sich die Schlüsselgruppe zusammensetzt. Das Element hat folgenden Element-Inhalt: Element `cfg:KeyModuleId`: Dieses Element kommt genau einmal vor. Mit ihm wird auf einen der konfigurierten Hardware- oder Software-Schlüsselspeicher referenziert. Sein Textinhalt vom Typ `xs:token` enthält den Identifikator des Hardware- oder Software-Schlüsselspeichers, so wie er in `cfg:SignatureCreation/cfg:KeyModules/cfg:HardwareKeyModule/cfg:Id` bzw. `cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule/cfg:Id` festgelegt wurde. Element `cfg:KeyCertIssuerSerial`: Dieses Element kommt ebenfalls genau einmal vor. Mit ihm wird ein privater Schlüssel innerhalb des mit `cfg:KeyModuleId` ausgewählten Schlüsselspeichers ausgewählt (sowohl Hardware- als auch Softwareschlüsselspeicher können ja prinzipiell mehr als nur einen einzigen privaten Schlüssel verwalten). Das Element hat folgenden Element-Inhalt: Element `dsig:X509IssuerName`: Dieses Element kommt genau einmal vor. Sein Textinhalt vom Typ `xs:string` enthält den Namen des Ausstellers des Zertifikats für den ausgewählten privaten Schlüssel. Element `dsig:X509SerialNumber`: Dieses Element kommt genau einmal vor. Sein Textinhalt vom Typ `xs:integer` enthält die Seriennummer des Zertifikats für den ausgewählten privaten Schlüssel. 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. Attribut `cfg:RSASSA-PSS`: Dieses Attribut ermöglicht die Deaktivierung von RSASSA-PSS Algorithmen bei Verwendung von RSA Schlüsselmaterial. Falls nicht vorhanden wird der Defaultwert aus `cfg:SignatureCreation/cfg:Signing` verwendet. 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 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`. Starten Sie nun - mit bewusst fehlenden `cfg:SignatureCreation/cfg:KeyGroup` Elementen - den MOA SP/SS Server. Stellen Sie dabei sicher, dass das Log-Level für den Logger `moa.spss.server` zumindest auf das Niveau `info` eingestellt ist (Informationen zur Konfiguration des Loggings von MOA SP/SS finden Sie in Abschnitt 2.1.3 des Installationshandbuchs). Im Log-File werden dann alle verfügbaren privaten Schlüssel an Hand der Werte `dsig:X509IssuerName` und `dsig:X509SerialNumber` aufgelistet. Vergleichen Sie den folgenden beispielhaften Auszug:
       INFO | 15 15:10:14,737 | moa.spss.server | TID=startup NID=node1 MSG=Key
         ID=SKM_Kunde1;CN=Test CA - Signaturdienste,OU=Technik und Standards,O=Stabstelle IKT-Strategie des Bundes,C=AT;7
       INFO | 15 15:10:14,737 | moa.spss.server | TID=startup NID=node1 MSG=Key
         ID=SKM_allgemein;CN=Test CA - Signaturdienste,OU=Technik und Standards,O=Stabstelle IKT-Strategie des Bundes,C=AT;9
       INFO | 15 15:10:14,737 | moa.spss.server | TID=startup NID=node1 MSG=Key
         ID=SKM_Kunde2;CN=Test CA - Signaturdienste,OU=Technik und Standards,O=Stabstelle IKT-Strategie des Bundes,C=AT;8
Der Wert der Eigenschaft `ID` des Logging-Eintrags gliedert sich in drei Teile: Der erste Teil enthält den Identifikator des Hardware- bzw. Softwareschlüsselspeichers, so wie er im entsprechenden Konfigurationselement `cfg:SignatureCreation/cfg:KeyModules/cfg:HardwareKeyModule` bzw. `cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule` erfasst wurde. Der zweite Teil enthält nach dem ersten Semikolon den Namen des Ausstellers des Zertifikats für den privaten Schlüssel, so wie er in `dsig:X509IssuerName` benötigt wird. Der dritte Teil enthält nach dem zweiten Semikolon die Seriennummer des Zertifikats für den privaten Schlüssel, so wie er in `dsig:X509SerialNumber` benötigt wird. Erfassen Sie nun mit Hilfe der neu gewonnenen Informationen die Schlüsselgruppen, die in MOA SS zur Verfügung stehen sollen. Wenn Ihnen für einen privaten Schlüssel, den Sie in eine Schlüsselgruppe aufnehmen wollen, das Zertifikat bekannt ist und es in Form einer DER-kodierten Datei vorliegt, können Sie alternativ das Script `certtool` aus dem Verzeichnis `tools` im MOA-Installationsverzeichnis verwenden, um zu den Werten für `dsig:X509IssuerName` und `dsig:X509SerialNumber` zu kommen:
    certtool -info <certfilename>
`<certfilename>` enthält den Namen der DER-kodierten Zertifikatsdatei, für die die beiden Werte `dsig:X509IssuerName` und `dsig:X509SerialNumber` geliefert werden sollen. Eine beispielhafte Ausgabe des Scripts sieht wie folgt aus:
    SubjectDN (RFC2253):
      CN=Test: Signaturdienst aller Kunden: ECDSA (P192v1),OU=Technik und Standards,O=Stabsstelle IKT-Strategie des Bundes,C=AT
    IssuerDN (RFC2253) :
      CN=Test CA - Signaturdienste,OU=Technik und Standards,O=Stabstelle IKT-Strategie des Bundes,C=AT
    Serial Number      :
      9
Die Werte für `IssuerDN (RFC2253)` sowie `Serial Number` entsprechen den Werten für `dsig:X509IssuerName` und `dsig:X509SerialNumber`.

### 2.2.3 Zuordnung von Schlüsselgruppen zu Kunden

Name | `cfg:SignatureCreation/cfg:KeyGroupMapping`
Gebrauch | einmal bis unbeschränkt oft
Erläuterung | Das Element `cfg:SignatureCreation/cfg:KeyGroupMapping` ordnet einem Kunden von MOA SS die ihm zur Verfügung stehenden Schlüsselgruppen zu, indem das den Kunden repräsentierende SSL-Clientzertifikat mit einer oder mehreren Schlüsselgruppen assoziiert wird. Das Element hat folgenden Element-Inhalt: Element `cfg:CustomerId`: Dieses Element bezeichnet auf eindeutige Weise das den Kunden repräsentierende SSL-Clientzertifikat. Der Aufbau des Elements enspricht dem Aufbau des Elements `cfg:KeyCertIssuerSerial` in Abschnitt 2.2.2. Um zu den Werten für Ausstellername und Seriennummer des SSL-Clientzertifikats zu kommen, können Sie auch hier das Script `certtool` (vergleiche Abschnitt 2.2.2) verwenden. Element `cfg:KeyGroupId`: Dieses Element vom Typ `xs:token` kommt so oft vor, wie Schlüsselgruppen einem bestimmten SSL-Clientzertifikat zugeordnet werden sollen, mindestens jedoch einmal. Sein Wert repräsentiert dem Identifikator der Schlüsselgruppe, so wie er in `cfg:SignatureCreation/cfg:KeyGroup/cfg:Id` festgelegt wurde. Bitte beachten Sie: Für maximal ein Konfigurationselement `cfg:SignatureCreation/cfg:KeyGroupMapping` kann `cfg:CustomerId` auch weggelassen werden. Die darin enthaltenen Schlüsselgruppen stehen dann allen Kunden von MOA SS gleichermaßen zur Verfügung.

### 2.2.4 Parameter für XML-Signaturen

Name | `cfg:SignatureCreation/cfg:XMLDSig/cfg:CanonicalizationAlgorithm`
Gebrauch | Null mal oder einmal
Erläuterung | 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.

Name | `cfg:SignatureCreation/cfg:XMLDSig/cfg:DigestMethodAlgorithm`
Gebrauch | Null mal oder einmal
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:
    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
Wird das Element nicht angegeben, wird - abhängig von der konfigurierten XAdES-Version (siehe XAdES-Version)- folgender Wert als Default-Wert verwendet: 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

Name | `cfg:SignatureCreation/cfg:CreateTransformsInfoProfile`
Gebrauch | Null mal bis unbeschränkt oft
Erläuterung | MOA SS erlaubt die Hinterlegung von vordefinierten Profilen für Transformationen, die im Rahmen einer XML-Signaturerstellung zur Anwendung kommen sollen. Im Request zur XML-Signaturerstellung reicht es dann aus, auf dieses Profil zu referenzieren, anstatt die gesamten Transformationen explizit anzugeben. `cfg:CreateTransformsInfoProfile` enthält für ein bestimmtes Datenobjekt für eine zu erstellende XML-Signatur die auf dieses Datenobjekt anzuwendenden Transformationen, sowie allenfalls für die Durchführung der Transformationen notwendige Ergänzungsobjekte (z.B. einen zu importierenden Stylesheet für eine XSL-Transformation). `cfg:CreateTransformsInfoProfile` weist folgende obligatorische Kindelemene auf: Element`Id`: Dieses Element`` vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Dieser Identifikator wird im Request zur Erstellung der XML-Signatur verwendet, um das hinterlegte Profil zu referenzieren (vergleiche Element `moa:CreateTransformsInfoProfileID`). Element`` `Location`: Dieses Element`` vom Typ `xs:anyURI` enthält den Namen der XML-Datei, die das hinterlegte Profil beinhaltet. Der Wert enthält eine relative oder absolute URI. Eine relative URI wird von MOA SS als File-URI relativ zum Lage jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Die XML-Datei muss als Wurzelelement das Element`moa:CreateTransformsInfoProfile` enthalten.

### 2.2.6 Profil für Signaturumgebung

Name | `cfg:SignatureCreation/cfg:CreateSignatureEnvironmentProfile`
Gebrauch | Null mal bis unbeschränkt oft
Erläuterung | MOA SS erlaubt die Hinterlegung von vordefinierten Profilen für die Signaturumgebung, die im Rahmen einer XML-Signaturerstellung zur Anwendung kommen soll. Im Request zur XML-Signaturerstellung reicht es dann aus, auf dieses Profil zu referenzieren, anstatt die Informationen zur Signaturumgebung explizit anzugeben. `cfg:CreateSignatureEnvironmentProfile` enthält für eine zu erstellende XML-Signatur, die in ein bereits bestehendes XML-Dokument integriert werden soll, die Stelle, an der die XML-Signatur eingefügt werden soll, sowie allenfalls für die Verarbeitung des bestehenden XML-Dokuments notwendige Ergänzungsobjekte (z.B. ein XML-Schema für das validierende Parsen des bestehenden XML-Dokuments). `cfg:``CreateSignatureEnvironmentProfile` weist folgende obligatorische Kindelemente auf: Element`Id`: Dieses Element`` vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Dieser Identifikator wird im Request zur Erstellung der XML-Signatur verwendet, um das hinterlegte Profil zu referenzieren (vergleiche Element `moa:``CreateSignatureEnvironmentProfileID`). Element`` `Location`: Dieses Element`` vom Typ `xs:anyURI` enthält den Namen der XML-Datei, die das hinterlegte Profil beinhaltet. Der Wert enthält eine relative oder absolute URI. Eine relative URI wird von MOA SS als File-URI relativ zum Lage jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Die XML-Datei muss als Wurzelelement das Element`moa:CreateSignatureEnvironmentProfile` enthalten.

### 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.2.8 Allgemeine Signaturparameter

Name | `cfg:SignatureCreation/cfg:Signing`
Gebrauch | Null mal bis einmal
Erläuterung | Dieses Element ermöglicht die Konfiguration allgemeiner Signaturparameter. Attribut `cfg:RSASSA-PSS`: Dieses Attribut ermöglicht die Deaktivierung von RSASSA-PSS Algorithmen bei Verwendung von RSA Schlüsselmaterial. Falls nicht vorhanden oder der `true` als Attributwert wird RSASSA-PSS verwendet.

## 2.3 Parameter für MOA SP

Name | `cfg:SignatureVerification/cfg:StrictSignatureValueParsing`
Gebrauch | Null mal bis einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an ob ECDSA Signaturwerte strikt gegen die ASN.1 Soezifikation validiert werden. Zulässige Werte sind true oder false. (Defaultwert: true)

### 2.3.1 Zertifikatsvalidierung

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:ConnectionTimeout`
Gebrauch | Null mal bis einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:string` gibt an, welcher Timeout in Sekunden bei URL Verbindungsaufbau gesetzt wird. Zulässige Werte sind beliebige positive Zahlen. (Defaultwert: 30 Sekunden)

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:ReadTimeout`
Gebrauch | Null mal bis einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:string` gibt an, welcher Timeout in Sekunden beim Empfangen von Daten über eine URL gesetzt wird. Zulässige Werte sind beliebige positive Zahlen. (Defaultwert: 30 Sekunden)

#### 2.3.1.1

##### 2.3.1.1.1 Cachen von Zertifikaten

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathConstruction/cfg:AutoAddCertificates`
Gebrauch | genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an, ob Zertifikate, die in einer zu prüfenden Signatur enthalten sind bzw. bei der Zertifikatspfaderstellung durch Auswertung der Zertifikatserweiterung Authority Information Access (siehe auch Parameter `cfg:UseAuthorityInfoAccess`) aus dem Internet geladen werden, automatisch in den lokalen Zertifikatsspeicher hinzugefügt werden sollen. Zulässige Werte für diesen Parameter sind `true` oder `false`.

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathConstruction/cfg:AutoAddEECertificates`
Gebrauch | optional, jedoch genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an, ob End-User Zertifikate, die in einer zu prüfenden Signatur enthalten sind bzw. bei der Zertifikatspfaderstellung durch Auswertung der Zertifikatserweiterung Authority Information Access (siehe auch Parameter `cfg:UseAuthorityInfoAccess`) aus dem Internet geladen werden, automatisch in den lokalen Zertifikatsspeicher hinzugefügt werden sollen. Zulässige Werte für diesen Parameter sind `true` oder `false`. Defaultwert: `false`

##### 2.3.1.1.2 Auswertung der Zertifikatserweiterung Authority Information Access

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathConstruction/cfg:UseAuthorityInfoAccess`
Gebrauch | genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an, ob die Zertifikatserweiterung Authority Information Access für die Zertifikatspfaderstellung verwendet werden soll. Wird der Wert auf `true` gesetzt, dann setzt MOA auch den Parameter `cfg:AutoAddCertificate` automatisch auf `true` und ignoriert den gegebenenfalls in der Konfigurationsdatei dafür gesetzten Wert. Zulässige Werte für diesen Parameter sind `true` oder `false`.

##### 2.3.1.1.3 Lokalisierung des Zertifikatsspeichers

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathConstruction/cfg:CertificateStore/cfg:DirectoryStore/cfg:Location`
Gebrauch | genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:token` gibt ein Verzeichnis im lokalen Dateisystem an, das von MOA als lokaler Zertifikatsspeicher verwendet werden soll. Zulässige Werte für diesen Parameter sind absolute oder relative Pfadangaben, wobei relative Pfadangaben als relativ zum Pfad jenes Verzeichnisses interpretiert werden, in dem die zentrale Konfigurationsdatei gespeichert ist. Beispiele für zulässige Werte lauten:
    C:/Programme/apache/tomcat-4.1.30/conf/moa-spss/certstore
    certstore

#### 2.3.1.2 Valdierung des Zertifikatspfads

##### 2.3.1.2.1 Gültigkeitsmodell für die Zertifikatskettenprüfung

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathValidation/cfg:ChainingMode`
Gebrauch | genau einmal
Erläuterung | Dieses Element legt fest, ob MOA SP für die Prüfung der Gültigkeit einer konstruierten Zertifikatskette das Kettenmodell aus ISIS-MTT oder das Schalenmodell aus dem PKIX RFC 3280 verwenden soll. Es hat folgende Kindelemente: `cfg:DefaultMode`: Dieses obligatorische Element gibt das Default-Modell für die Prüfung der Gültigkeit einer konstruierten Zertifikatskette an. Gültige Werte sind `chaining` (Kettenmodell) oder `pkix` (Schalenmodell). `cfg:TrustAnchor`: Dieses Element kann beliebig oft (auch gar nicht) verwendet werden, um für bestimmte Vertrauensanker (vergleiche nächsten Parameter `cfg:TrustProfile`) Ausnahmen vom Default-Modell vorzugeben. Das Element weist folgende Kindelemente auf: `cfg:Identification`: Dieses obligatorische Element identifiziert den Vertrauensanker, für den ein bestimmtes Modell konfiguriert werden soll. Es entspricht vom Aufbau jenem von `cfg:KeyCertIssuerSerial` in Abschnitt 2.2.2. Um zu den Werten für Ausstellername und Seriennummer des Vertrauensankers zu kommen, können Sie auch hier das Script `certtool` (vergleiche Abschnitt 2.2.2) verwenden. `cfg:Mode`: Dieses obligatorische Element vom Typ `xs:string` gibt jenes Modell an, das von MOA SP für die Prüfung von konstruierten Zertifikatsketten zu verwenden ist, die im mittels `cfg:Identification/dsig:X509IssuerName` und `cfg:Identification/dsig:X509SerialNumber` angegebenen Vertrauensanker münden. Gültige Werte sind `chaining` (Kettenmodell) oder `pkix` (Schalenmodell).

##### 2.3.1.2.2 Vertrauensprofile

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathValidation/cfg:TrustProfile`
Gebrauch | einmal bis unbeschränkt oft (zumindest ein Vertrauensprofil muss vorhanden sein)
Erläuterung | Das Element `cfg:``TrustProfile` wird dazu verwendet, um in MOA SP ein Vertrauensprofil für die Signaturprüfung einzurichten. Ein Vertrauensprofil besteht aus einer Menge von Vertrauensankern und einer optionalen Menge von explizit erlaubten Signatorzertifikaten. Ein Vertrauensanker ist ein CA-Zertifikat, das explizit als vertrauenswürdig eingestuft wird. MOA SP versucht bei der Konstruktion einer Zertifikatskette, einen Pfad vom Signatorzertifikat bis hin zu einem der konfigurierten Vertrauensanker zu finden. Gelingt dies, wird auch das Signatorzertifikat als vertrauenswürdig betrachtet, ansonsten nicht. Wird neben der Menge von Vertrauensankern auch noch eine Menge von explizit erlaubten Signatorzertifikaten angegeben, prüft MOA SP nicht nur, ob sich ein Pfad vom Signatorzertifikat zu einem konfigurierten Vertrauensanker konstruieren lässt, sondern darüber hinaus auch noch, ob das Signatorzertifikat aus der zu prüfenden Signatur in der Menge der explizit erlaubten Signatorzertifikate vorkommt. Explizit erlaubte Signatorzertifikate sollten Sie dann konfigurieren, wenn nicht allen von einer als Vertrauensanker konfigurierten CA ausgestellten Zertifikaten vertraut werden soll, sondern nur ganz bestimmten Zertifikaten dieser CA. In MOA SP können beliebig viele solcher Vertrauensprofile konfiguriert werden. Der Kunde von MOA SP gibt im Request zur Signaturprüfung an, gegen welches Vertrauensprofil MOA SP die Zertifikatsprüfung vornehmen soll. Das Element `cfg:``TrustProfile` weist folgende Kindelemente auf: `cfg:Id`: Dieses obligatorische Element vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Dieser Identifikator wird im Request zur Signaturprüfung verwendet, um das zu verwendende Vertrauensprofil auszuwählen. Element `cfg:TrustAnchorsLocation`: Dieses obligatorische Element vom Typ `xs:anyURI` enthält eine relative oder absolute URL, die ein Verzeichnis im lokalen Dateisystem referenziert. Eine relative URL wird relativ zum Pfad jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Eine absolute URL muss als Protokoll-Teil `file` verwenden. Das referenzierte Verzeichnis muss eine oder mehrere DER-kodierte Zertifikatsdateien beinhalten. Jede Zertifikatsdatei repräsentiert einen Vertrauensanker. Element `cfg:SignerCertsLocation`: Dieses optionale Element vom Typ `xs:anyURI` enthält eine relative oder absolute URL, die ein Verzeichnis im lokalen Dateisystem referenziert. Eine relative URL wird relativ zum Pfad jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Eine absolute URL muss als Protokoll-Teil `file` verwenden. Das referenzierte Verzeichnis muss eine oder mehrere DER-kodierte Zertifikatsdateien beinhalten. Jede Zertifikatsdatei repräsentiert ein explizit erlaubtes Signatorzertifikat. Element `cfg:EUTSL`: Dieses optionale Element aktiviert bei Vorhandensein die EU-TSL Unterstützung für dieses Vertrauensprofile. D.h. als Vertrauensanker werden jene CA-Zertifikate herangezogen, die zum gegenwärtigen Zeitpunkt auf der EU-TSL bzw. den entsprechenden TSLs der Mitgliedsstaaten stehen und den Anforderungen der nachstehenden Kind-Elemente entsprechen. Des Weiteren werden bei TSL-aktivierten Vertrauensprofilen, die Überprüfung auf qualifiziertes Zertifikat (QC-Überprüfung) und die Überprüfung auf sichere Signaturerstellungseinheit (SSCD-Überprüfung) über die EU-TSL durchgeführt. Mittels des Attributes `forceAvailability` (Defaultwert: true) kann definiert werden ob der TSL Client zur Verffügung stehen muss. Zusätzliche können optionale Kind-Element angegeben werden: `cfg:CountrySelection` Dieses Element definiert eine komma-separierte Liste an zweistelligen Länderkürzeln nach ISO 3166. Ist so eine Liste vorhanden, werden nur die Vertrauensanker der angegebenen Länder herangezogen. Defaultwert: alle Länder `cfg:AllowedTSPStatus` Dieses Element definiert eine komma-separierte Liste an ServiceLevel welche ein Zertififierungsdiensteanbieter für diesen Vertrauensanker erfüllen muss. Die Angabe erfolgt als 'ServiceLevel' URI Identifier entsprechend der aktuellen TSL Spezifikation. (z.B. http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted,http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/recognisedatnationallevel) Defaultwert: http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted,http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/recognisedatnationallevel, http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/accredited,http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/undersupervision `cfg:AllowedTSPServiceTypes` Dieses Element definiert eine komma-separierte Liste an ServiceTypen welche ein Zertififierungsdiensteanbieter für diesen Vertrauensanker erfüllen muss. Die Angabe erfolgt als Regex Patterns welche die 'ServiceType' URI Identifier entsprechend der aktuellen TSL Spezifikation abbilden. (z.B. http://uri\.etsi\.org/TrstSvc/Svctype/Certstatus/.*,.*) Defaultwert: alle ServiceTypen Wichtig: Es können zusätzlich manuelle Vertrauensanker via `cfg:TrustAnchorsLocation` konfiguriert werden. Hierbei ist jedoch, insbesondere beim Hinzufügen von Enduser-Zertifikaten als Vertrauensanker, zu beachten, dass eine QC- bzw. SSCD-Überprüfung gegebenenfalls nicht erfolgreich durchgeführt werden kann. Wichtig: Bei aktivierter TSL-Unterstützung muss einen entsprechende TSL Konfiguration angegeben werden (siehe TSL Konfiguration).

#### 2.3.1.3 Widerrufsprüfung

##### 2.3.1.3.1 Aktivieren der Widerrufsprüfung

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:EnableChecking`
Gebrauch | genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an, ob bei der Zertifikatsüberprüfung im Zuge einer Signaturprüfung auch der Zertifikatsstatus jedes einzelnen Zertifikats des gebildeten Zertifikatspfads überprüft werden soll. Bitte beachten Sie: Die Widerrufsprüfung ist ein sehr wichtiger Schritt der Zertifikatsüberprüfung und somit der Signaturprüfung. Eine Deaktivierung sollte nur in begründeten Ausnahmefällen in Erwägung gezogen werden, z.B. für Testsituationen. Zulässige Werte für diesen Parameter sind `true` oder `false`.

##### 2.3.1.3.2 Maximales Alter der Widerrufsinformation

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:MaxRevocationAge`
Gebrauch | genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:integer` gibt an, wie aktuell eine ggf. lokal gespeicherte Widerrufsinformation sein muss, damit sie von MOA SP als gültig angesehen wird. Ist die lokal gespeicherte Widerrufsinformation nicht aktuell genug, wird sie von MOA SP erneut aus dem Internet geladen. Dieser Parameter wird nur ausgewertet, wenn die Widerrufsprüfung aktiviert ist (siehe Parameter `cfg:EnableChecking`). Zulässige Werte für diesen Parameter sind ganze Zahlen: Ein beliebiger negativer Wert bedeutet, dass eine Widerrufsinformation jedes Mal, wenn sie benötigt wird, neu aus dem Internet geladen wird. Der Wert `0` bedeutet, dass eine Widerrufsinformation dann neu geladen wird, wenn das Datum im Feld `nextUpdate` der entsprechenden Widerrufsliste bereits überschritten ist. Ein positiver Wert gibt gibt die Zeitspanne in Millisekunden an, nach der eine ggf. vorhandene lokale Widerrufsinformation spätestens durch erneutes Laden aus dem Internet aktualisiert wird.

##### 2.3.1.3.3 Reihenfolge der Widerrufsdienste

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:ServiceOrder`
Gebrauch | Null mal oder einmal
Erläuterung | Dieses Element gibt an, in welcher Reihenfolge MOA SP die Widerrufsdienste für die Prüfung des Widerrufs für ein Zertifikat kontaktieren soll, wenn für das Zertifikat mehrere unterschiedliche Widerrufsdienste (CRL, OCSP) verfügbar sind. Das Element weist folgendes Kindelement auf: `cfg:Service`: Dieses Element vom Typ `xs:token` muss genau ein oder zwei mal vorkommen. Gütlige Werte für den Textinhalt des Elements sind `OCSP` und `CRL`. Damit kann entweder die Reihenfolge (CRL, OCSP) oder (OCSP, CRL) festgelegt werden. Wird nur ein Element angegeben, so wird auch nur der jeweilige Dienst verwendet. Wird das Element nicht angegeben, so lautet die von MOA SP dann verwendete Default-Reihenfolge (CRL, OCSP).

##### 2.3.1.3.4 Archivierung von Widerrufsinformationen

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:Archiving/cfg:EnableArchiving`
Gebrauch | genau einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an, ob mittlerweile ungültig gewordene (i.e. historische) CRL-Widerrufsinformationen von MOA SP archiviert werden soll. Wird dieser Parameter auf den Wert `true` gesetzt, muss auch der Parameter `cfg:Archive` (siehe unten) angegeben werden. Zulässige Werte für diesen Parameter sind `true` oder `false`.

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:Archiving/cfg:ArchiveDuration`
Gebrauch | Null mal oder einmal
Erläuterung | Dieses Element vom Typ `xs:nonNegativeInteger` gibt (in Tagen) an, wie lange Widerrufsinformationen von MOA SP archiviert werden müssen. Das Element wird von MOA SP nur dann ausgewertet, wenn der Konfigurationsparameter `cfg:EnableArchiving` auf true gesetzt ist. Wird das Element nicht angegeben, so verwendet MOA SP den Default-Wert von 365 Tagen.

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:Archiving/cfg:Archive`
Gebrauch | Null mal oder einmal
- - Erläuterung | Dieses Element gibt an, welches Archiv MOA SP zur Archivierung von mittlerweile ungültig gewordene (i.e. historische) CRL-Widerrufsinformationen verwenden soll, falls der Konfigurationsparameter `cfg:EnableArchiving` auf `true` gesetzt ist. Es muss angegeben werden, wenn der Konfigurationsparameter `cfg:EnableArchiving` auf true gesetzt ist. Das Element weist folgendes Kindelement auf: `cfg:DatabaseArchive`: Dieses obligatorische Element dient zur Angabe der notwendigen Informationen für die Benutzung eines datenbankbasierten CRL-Archivs durch MOA SP. Das Datenbankarchiv ist die einzige derzeit unterstützte Archivform. Das Element weist folgende Kindelemente auf: `cfg:JDBCURL`: Dieses obligatorische Element vom Typ `xs:anyURI` gibt die JDBC-URL zu jener Datenbank an, in der MOA historische Widerrufsinformationen archivieren soll. Der genaue Aufbau der JDBC-URL ist abhängig von der verwendeten Datenbank. Im Fall von PostgreSQL kann folgende URL verwendet werden:
        jdbc:postgresql://<host>/<moadb>?user=<moauser>&amp;password=<moapassword>
Die Platzhalter `<host>`, `<moadb>`, `<moauser>` und `<moapassword>` müssen dabei an die tatsächlich verwendete Datenbank angepasst werden. Bitte beachten Sie: Die Kodierung des Zeichens "&" als "&amp;" ist erforderlich, da es andernfalls zu einem Validierungsfehler beim Parsen der XML-Konfigurationsdatei durch MOA kommen würde. Bitte beachten Sie: MOA SP legt eigenständig eine passende Tabelle in der angegebenen Datenbank an und befüllt diese dann in weiterer Folge. Der in der JDBC-URL angegebene Benutzer muss mit den dazu passenden Rechten ausgestattet sein. `cfg:JDBCDriverClassName`: Dieses obligatorische Element vom Typ `xs:token` gibt den vollständig qualifizierten Java-Klassennamen des JDBC-Treibers an, der von MOA SP zur Ansprache der für die CRL-Archivierung zu verwendenden Datenbank benützt werden soll. Bitte beachten Sie: Informationen zum Anlegen einer Datenbank in postgreSQL finden Sie in Abschnitt 2.2.2.1 des Installationshandbuchs.

##### 2.3.1.3.5 Manuelle Konfiguration von Verteilungspunkten für Widerrufsinformationen

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:DistributionPoint`
Gebrauch | Null mal bis unbeschränkt oft
Erläuterung | Das Element `cfg:``CRLDistributionPoint` kann dazu verwendet werden, manuelle Verteilungspunkte für Widerrufsinformationen einer bestimmten CA zu konfigurieren. Dies macht für veraltete Zertifikate Sinn, die nicht den aktuellen Vorgaben aus dem PKIX RFC 3280 entsprechen und im Zertifikat selbst keine Zertifikatserweiterung mit einem solchen Verteilungspunkt enthalten. Weiters kann diese manuelle Konfiguration verwendet werden, wenn die in einem Zertifikat enthaltenen Verteilungspunkte für eine bestimmte CA durch einen manuellen Eintrag überschrieben werden soll (etwa weil die im Zertifikat enthaltenen Verteilungspunkte in Form von ldap-URLs angegeben sind, MOA SP aber der Zugriff auf ldap-URLs per Firewall-Einstellungen untersagt ist; dann könnte man stattdessen manuell eine (lokale) http-URL als Verteilungspunkt angeben, die von MOA SP dann aufgelöst werden kann). Das Element weist folgende Kind-Elemente auf: Element `cfg:CAIssuerDN`: Dieses Element enthält als Textinhalt vom Typ `xs:string` den Namen jener CA, die das Zertifikat ausgestellt hat, dessen Widerruf mit Hilfe des zu konfigurierenden Verteilungspunktes geprüft werden soll. Um zu diesem Wert zu kommen, können Sie auch hier das Script `certtool` (vergleiche Abschnitt 2.2.2) verwenden, in dem Sie es für das Zertifikat anwenden, dessen Widerruf mit Hilfe des zu konfigurierenden Verteilungspunktes geprüft werden soll. Element `cfg:CRLDP`: Dieses Element verweist auf einen Verteilungspunkt, an dem eine Widerrufsliste abgeholt werden kann. Es weist folgende Kind-Elemente auf: Element`cfg:Location`: Der Wert dieses obligatorischen Elements vom Typ`xs:anyURI` enthält die URL für den zu konfigurierenden Verteilungspunkt. Es werden die Protokolle HTTP, HTTPS und LDAP unterstützt. Element`cfg:ReasonCode`: Dieses Element vom Typ `xs:token` kann null mal bis unbeschränkt oft vorkommen und enthält jeweils einen laut PKIX RFC 3280 möglichen Grund eines Widerrufs, für welche die über den zu konfigurierenden Verteilungspunkt zu beziehende Widerrufsliste ausgestellt ist. Gültige Gründe sind `unused`, `keyCompromise`, `cACompromise`, `affiliationChanged`, `superseded`, `cessationOfOperation`, `certificateHold`, `privilegeWithdrawn` und `aACompromise`. Wird eine Widerrufsliste für mehrere Gründe ausgestellt, muss also das Element `cfg:ReasonCode` mehrmals angegeben werden. Wird das Element null mal angegeben, gilt der Verteilungspunkt für alle möglichen Widerrufsgründe. Element `cfg:OCSPDP`: Dieses Element verweist auf einen Verteilungspunkt, an dem die Widerrufsinformation von einem OCSP-Responder bezogen werden kann. Es weist folgendes Kind-Element auf: Element`cfg:Location`: Der Wert dieses obligatorischen Elements vom Typ`xs:anyURI` enthält die URL für den zu konfigurierenden Verteilungspunkt. Es werden die Protokolle HTTP, HTTPS und LDAP unterstützt. Hinweis: Die Elemente `cfg:CRLDP` bzw. `cfg:OSCPDP` können beliebig oft als Kinder von `cfg:CRLDistributionPoint` angegeben werden. Die Reihenfolge spielt dabei keine Rolle. Jedenfalls muss aber eines dieser beiden Elemente angegeben werden.

##### 2.3.1.3.6 Konfiguration CRL Retention Intervallen

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:CrlRetentionIntervals`
Gebrauch | Null oder einmal
Erläuterung | Das Element `cfg:``CrlRetentionIntervals` kann dazu verwendet werden, um Retention Intervalle für bestimmte CAs zu konfigurieren. Gemäß RFC 5280 muss ein widerrufenes Zertifikat solange auf Widerrufslisten aufscheinen, bis das Zertifikat abgelaufen ist und noch eine CRL-Periode darüber hinaus. Auf allen weiteren CRLs muss das Zertifikat nicht mehr geführt werden. Daraus folgt, dass MOA SP für abgelaufene Zertifikate in der Regel keine CRL-Statusabfrage durchführen kann, da nicht sichergestellt ist, dass eine aktuell geladene Widerrufssliste für derartige Zertifikate noch adeqaute Widerrufsinformationen enthält. Garantiert eine CA jedoch, dass widerrufene Zertifikate noch über deren Ablauf hinaus auf der Widerrufsliste geführt werden, so kann für diese CA ein Retention Intervall definiert werden. Das `cfg:``CrlRetentionIntervals` Element weist folgendes Kind-Element auf: Element `cfg:CA`: Dieses Element legt ein Retention Intervall für eine CA fest und kann beliebig oft vorkommen. Es weist folgende Kind-Elemente auf: Element `cfg:X509IssuerName`: Dieses Element vom Typ `xs:string` muss einmal vorkommen und definiert die entsprechende CA über einen RFC2253 String. Das (im folgenden Element) festgelegte Intervall wird für alle Widerrufslisten, die von dieser CA ausgestellt werden, verwendet. Element `cfg:Interval`: Dieses Element vom Typ `xs:integer` muss einmal vorkommen und enthält das Retention Intervall. Es gibt den Zeitraum in Tagen an, über den widerrufene Zertifikate über deren Ablauf hinaus auf Widerrufslisten geführt werden. Wird der Wert auf -1 gesetzt, dann bedeutet das ein unendlich langes Intervall. In diesem Fall wird ein widerrufenes Zertifikat niemals von den Widerrufslisten entfernt.

##### 2.3.1.3.7 Validierung von Short-Term Zertifikaten

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking/cfg:ShortTermedCertificates`
Gebrauch | Null oder einmal
Erläuterung | Das Element `cfg:``ShortTermedCertificates` kann dazu verwendet werden, um die Validierung von short-term Zertifikaten zu konfigurieren. Das `cfg:``ShortTermedCertificates` Element weist folgendes Kind-Element auf: Element `cfg:CA`: Dieses Element legt ein Gültigkeitsintervall für eine CA fest und kann beliebig oft vorkommen. Es weist folgende Kind-Elemente auf: Element `cfg:X509IssuerName`: Dieses Element vom Typ `xs:string` muss einmal vorkommen und definiert die entsprechende CA über einen RFC2253 String. Die (im folgenden Element) festgelegte ValidityPeriod wird für alle Widerrufsprfüfungen, ffür Zertifikate die von dieser CA ausgestellt wurden, verwendet. Element `cfg:ValidityPeriod`: Dieses Element vom Typ `xs:integer` muss einmal vorkommen und enthält das Gültigkeitsintervall in Minuten für welches keine Widerrufsprüfung durchgeführt wird. Ist der Zertifikatsgültigkeitszeitraum länger als der hier eingestellt Wert wird eine reguläre Widerrufsprüfung durchgeführt. Wird der Wert auf 0 gesetzt, wird die short-term Eigenschaft für diese CA ignoriert. Attribut `cfg:defaultValidityPeriod`: Dieses Attribut definiert eine Default ValidityPeriod (siehe Element `cfg:ValidityPeriod`) für alle CA Zertifikate. Ist dieses Attribut nicht gesetzt wird der Defaultwert 0 verwendet wodurch die spezielle Behandlung von short-term Zertifikaten, sofern nicht spezifisch konfiguriert, deaktiviert ist. Attribut `cfg:checkETSIValidityAssuredExtension`: Dieses Attribut aktiviert/deaktiviert (`true/false`) die Auswertung der X509 Extension "ETSI EN 319 412-1 - Validity Assured - Short Term" zur Prüfung von short-term Zertifikaten. Ist dieses Attribut nicht gesetzt wird der Defaultwert `true` verwendet.

##### 2.3.1.3.7 TSL Konfiguration

Name | `cfg:SignatureVerification/cfg:CertificateValidation/cfg:TSLConfiguration`
Gebrauch | Null oder einmal
Erläuterung | 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: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 Hinweis: Wird kein `cfg:UpdateSchedule` Element angegeben so wird defaultmäßig `02:00.00` als Startzeit und `86400000` Millisekunden (=1 Tag) als Intervall herangezogen Hinweis: Der Import der Zertifikate von der EU-TSL benötigt (je nach Verbindung) ca. 90-180 Sekunden. Als Startzeit sollte daher eine Zeit gewählt werden, zu der die Auslastung gering ist. Element `cfg:WorkingDirectory`: Diese Element gibt einen Pfad zum Arbeitsverzeichnis (inkl. Lese- und Schreibrechte) für die TSL an. Enthält dieses Element eine relative Pfadangabe, so wird dieser relativ zum Verzeichnis in dem sich die MOA-SPSS Konfigurationsdatei befindet interpretiert. Hinweis: Wird kein `cfg:WorkingDirectory` Element angegeben so wird defaultmäßig `tslworking` als Arbeitsverzeichnis herangezogen. 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. Element `cfg:Evaluation`: Diese Element hat zwei Kind Elemente Element `cfg:QCQualifier`: Diese Element gibt eine Komma-sparierte Liste an ServiceType Identifier an welche als QC interpretiert werden und das entsprechende QC Flag in der MOA-SP Response setzen. Element `cfg:SSCDQualifiern`: Diese Element gibt eine Komma-sparierte Liste an Additional-Qualifiern Extentsions an welche als SSCD interpretiert werden und das entsprechende SSCD Flag in der MOA-SP Response setzen Element `cfg:ServiceTypesForDocumentSigning`: Dieses Element definiert eine komma-separierte Liste von ServiceType-Identifier, deren Zertifikate für Dokumentensignaturen verwendet werden dürfen. Wenn ein TSP mehrere ServiceTypes unter demselben CA-Zertifikat anbietet, bestimmt diese Konfiguration den ffür Dokumentensignaturen zu verwendenden ServiceType. Defaultwert: `http://uri.etsi.org/TrstSvc/Svctype/CA/QC,http://uri.etsi.org/TrstSvc/Svctype/CA/PKC`

Hinweis: Um die TSL Überprüfung zu aktivieren muss auch (zumindest) ein Vertrauensprofil mit TSL Überprüfung konfiguriert werden (siehe Vertrauensprofil)

### 2.3.2 Profil für Transformationen

Name | `cfg:SignatureVerification/cfg:VerifyTransformsInfoProfile`
Gebrauch | Null mal bis unbeschränkt oft
Erläuterung | MOA SP erlaubt die Hinterlegung eines vordefinierten Profils für eine erlaubte Transformationsfolge, deren Einhaltung im Rahmen einer XML-Signaturprüfung kontrolliert wird. Im Request zur XML-Signaturprüfung reicht es dann aus, auf dieses Profil zu referenzieren, anstatt die gesamten Transformationen explizit anzugeben. `cfg:VerifyTransformsInfoProfile` enthält für ein bestimmtes Datenobjekt für eine zu prüfende XML-Signatur eine für dieses Datenobjekt erlaubte Transformationsfolge, bestehend aus den anzuwendenden Transformationen, sowie allenfalls für die Durchführung der Transformationen erlaubte implizite Transformationsparameter (z.B. einen zu importierenden Stylesheet für eine XSL-Transformation). `cfg:``VerifyTransformsInfoProfile` weist folgende obligatorische Kindelemene auf: Element`Id`: Dieses Element`` vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Dieser Identifikator wird im Request zur Prüfung der XML-Signatur verwendet, um das hinterlegte Profil zu referenzieren (vergleiche Element `moa:``VerifyTransformsInfoProfileID`). Element`` `Location`: Dieses Element`` vom Typ `xs:anyURI` enthält den Namen der XML-Datei, die das hinterlegte Profil beinhaltet. Der Wert enthält eine relative oder absolute URI. Eine relative URI wird von MOA SP als File-URI relativ zum Lage jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Die XML-Datei muss als Wurzelelement das Element`moa:VerifyTransformsInfoProfile` enthalten.

### 2.3.3 Profil für Ergänzungsobjekte

Name | `cfg:SignatureVerification/cfg:SupplementProfile`
Gebrauch | Null mal bis unbeschränkt oft
Erläuterung | MOA SS erlaubt die Hinterlegung eines vordefinierten Profils für ein Ergänzungsobjekt, das im Rahmen einer XML-Signaturprüfung verwendet werden soll. Im Request zur XML-Signaturprüfung reicht es dann aus, auf dieses Profil zu referenzieren, anstatt die Informationen zur Signaturumgebung explizit anzugeben. `cfg:SupplementProfile` enthält für ein Datenobjekt in der zu prüfenden XML-Signatur ein allenfalls für die Durchführung der vorgegebenen Transformationen notwendiges Ergänzungsobjekt (z.B. einen zu importierenden Stylesheet für eine XSL-Transformation). `cfg:``SupplementProfile` weist folgende obligatorische Kindelemene auf: Element`Id`: Dieses Element`` vom Typ `xs:token` enthält einen frei wählbaren Identifikator für dieses Konfigurationselement, der innerhalb der XML-Konfigurationsdatei eindeutig sein muss. Dieser Identifikator wird im Request zur Prüfung der XML-Signatur verwendet, um das hinterlegte Profil zu referenzieren (vergleiche Element `moa:``SupplementProfileID`). Element`` `Location`: Dieses Element`` vom Typ `xs:anyURI` enthält den Namen der XML-Datei, die das hinterlegte Profil beinhaltet. Der Wert enthält eine relative oder absolute URI. Eine relative URI wird von MOA SP als File-URI relativ zum Lage jenes Verzeichnisses interpretiert, in dem die zentrale Konfigurationsdatei gespeichert ist. Die XML-Datei muss als Wurzelelement das Element`moa:SupplementProfile` enthalten.

### 2.3.4 file-URIs

Name | `cfg:SignatureVerification/cfg:PermitFileURIs`
Gebrauch | Null mal oder einmal
Erläuterung | Der Inhalt dieses Elements vom Typ `xs:boolean` gibt an, ob file-URIs innerhalb von MOA-SP zugelassen werden sollen. In MOA-SS werden file-URIs strikt verboten. Bitte beachten Sie: Das Erlauben von file-URIs birgt Sicherheitsrisikien. Eine Deaktivierung sollte nur in begründeten Ausnahmefällen in Erwägung gezogen werden. Bitte beachten Sie: Es werden keine file-URIs in Ergänzungsobjekten unterstützt. Zulässige Werte für diesen Parameter sind `true` oder `false`. Wird dieses Element nicht angegeben, so nimmt MOA den Wert `false` an.

# 3 Beispielkonfigurationen

## 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:

- Ein Software-Schlüsselspeicher (`cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule`);
- Eine Schlüsselgruppe (`cfg:SignatureCreation/``cfg:KeyGroup`);
- Eine Zuordnung dieser Schlüsselgruppe für einen bestimmten Kunden (`cfg:SignatureCreation/cfg:KeyGroupMapping`).

Minimale Konfiguration für MOA SS

## 3.2 Minimale Konfiguration für MOA SP

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

- Einstellungen betreffend die Konstruktion des Zertifikatspfades (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathConstruction`);
- Einstellungen betreffend die Validierung des Zertifikatspfades (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathValidation`), unter anderem ein Vertrauensprofil (`cfg:TrustProfile`);
- Einstellungen betreffend die Widerrufsprüfung von Zertifikaten des Zertifikatspfades (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking`) .

Minimale Konfiguration für MOA SP

## 3.3 Minimale Konfiguration für MOA SP mit TSL Unterstützung

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

- Einstellungen betreffend die Konstruktion des Zertifikatspfades (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathConstruction`);
- Einstellungen betreffend die Validierung des Zertifikatspfades (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:PathValidation`), unter anderem ein Vertrauensprofil mit TSL Unterstützung (`cfg:TrustProfile`);
- Einstellungen betreffend die Widerrufsprüfung von Zertifikaten des Zertifikatspfades (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:RevocationChecking`) .
- Einstellungen betreffend der TSL Konfiguration (`cfg:SignatureVerification/cfg:CertificateValidation/cfg:TSLConfiguration`) .

Minimale Konfiguration für MOA SP mit TSL Unterstützung

## 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