Benutzerhandbuch SLMBC

Benutzer- und Administrationshandbuch
AuthentiDate SLM Base

Component V3.0
AuthentiDate
SLM Base Component Benutzer- und Administrationshandbuch
V3.0
Produktversion 3.0
Dokumentversion 1.2.12
Erstellungsdatum 09. Januar 2008
© 2006, 2007 AuthentiDate Deutschland GmbH – Alle Rechte vorbehalten.

Der Name AuthentiDate ist eine eingetragene Marke der AuthentiDate International AG. Alle anderen in
diesem Dokument genannten Produkt- und Firmennamen sind möglicherweise Marken ihrer jeweiligen
Eigentümer.
AuthentiDate Deutschland GmbH ist ein Unternehmen der AuthentiDate Gruppe.
Weitergabe und Vervielfältigung nur mit ausdrücklicher Genehmigung

der AuthentiDate Deutschland GmbH.
AuthentiDate Deutschland GmbH, Großenbaumer Weg 6,

40472 Düsseldorf / Germany
Tel. ++49 (0)211 - 43 69 89 0
www.authentidate.de info@authentidate.de
Irrtümer und technische Änderungen vorbehalten. Im Zuge der Produktentwicklung behalten sich Authen-
tiDate Deutschland GmbH und AuthentiDate International AG das Recht vor Änderungen an Produkten
und Leistungen, auch ohne vorherige Benachrichtigung, vorzunehmen.
Seite 2 von 94
AuthentiDate
V3.0
Inhaltsverzeichnis
Abbildungsverzeichnis .............................................................................................................. 5
Tabellenverzeichnis ................................................................................................................... 6
1 Einleitung ............................................................................................................................ 8
1.1 Aufbau des Handbuchs ................................................................................................ 8
1.2 Einsatzbereich .............................................................................................................. 9
1.3 Prozessumgebung (stark/schwach).............................................................................. 9
1.4 Vorgangs-/Auftragssteuerung (Signaturerzeugung/Signaturprüfung) ........................ 11
1.5 Sichere Verzeichnisse ................................................................................................ 12
1.6 Authentisierung........................................................................................................... 12
2 Konfiguration von SLMBC............................................................................................... 14
2.1 Hauptkonfiguration ..................................................................................................... 14
2.1.1 Element <httpServer>......................................................................................... 15
2.1.2 Element <clientNetworkAccessParameter> ....................................................... 17
2.1.3 Element <logging>.............................................................................................. 20
2.1.4 Element <evgLogging>....................................................................................... 21
2.1.5 Element <weakProcessBoundEnvironment> ..................................................... 23
2.1.6 Element <knownAttributeOid> ............................................................................ 24
2.1.7 Element <authenticationPolicies>....................................................................... 24
2.1.8 Element <license> .............................................................................................. 25
2.1.9 Element <xmlProtocolHandlerPool>................................................................... 25
2.2 Nebenkonfiguration Chipkartenleser .......................................................................... 41
2.3 Nebenkonfiguration Benutzer ..................................................................................... 42
2.3.1 Hashwerte für Benutzerpasswörter .................................................................... 43
2.4 Nebenkonfiguration Gruppen ..................................................................................... 46
2.4.1 Hashwerte für Gruppenkonfigurationen.............................................................. 48
3 SLMBC-Schnittstelle ........................................................................................................ 51
3.1 Einsatzszenarien ........................................................................................................ 52
3.1.1 Vollständige SAK zur Signaturerstellung ............................................................ 52
3.1.2 Vollständige SAK zur Signaturprüfung ............................................................... 53
3.2 F1Sign – Signaturerstellung zu Hashwerten .............................................................. 54
3.2.1 F1Sign Anfragedokument ................................................................................... 55
3.2.2 F1Sign Antwortdokument ................................................................................... 57
3.2.3 F1Sign Fehlerdokument ..................................................................................... 57
3.3 F2Verify – Signaturprüfung zu Hashwerten................................................................ 58
3.3.1 F2Verify Anfragedokument ................................................................................. 58
3.3.2 F2Verify Antwortdokument ................................................................................. 59
3.3.3 F2Verify Fehlerdokument ................................................................................... 60
3.4 F3Lock – Anlegen eines Auftrags............................................................................... 61
3.4.1 F3Lock Anfragedokument................................................................................... 62
3.4.2 F3Lock Antwortdokument ................................................................................... 64
3.4.3 F3Lock Fehlerdokument ..................................................................................... 64
3.5 F4FetchTimeStamp – Anlegen eines Auftrags ........................................................... 65
3.5.1 F4FetchTimestamp Anfragedokument ............................................................... 66
3.5.2 F4FetchTimestamp Antwortdokument................................................................ 66
3.5.3 F4FetchTimestamp Fehlerdokument.................................................................. 66
3.6 F5SignFile – Ausführung eines Signierauftrags ......................................................... 67
3.6.1 F5SignFile Anfragedokument ............................................................................. 67
3.6.2 F5SignFile Antwortdokument.............................................................................. 68
3.6.3 F5SignFile Fehlerdokument................................................................................ 68
3.7 F6VerifyFile – Ausführung eines Verifikationsauftrags ............................................... 69
3.7.1 F6VerifyFile Anfragedokument ........................................................................... 69
Seite 3 von 94
AuthentiDate
V3.0
3.7.2 F6VerifyFile Antwortdokument............................................................................ 70

3.7.3 F6VerifyFile Fehlerdokument.............................................................................. 70
3.8 F7Unlock– Beenden eines Auftrags ........................................................................... 70
3.8.1 F7Unlock Anfragedokument ............................................................................... 72
3.8.2 F7Unlock Antwortdokument................................................................................ 72
3.8.3 F7Unlock Fehlerdokument.................................................................................. 73
3.9 F8Deactivate – Deaktivieren von Signaturkarten ....................................................... 73
3.9.1 F8Deactivate Anfragedokument ......................................................................... 74
3.9.2 F8Deactivate Antwortdokument.......................................................................... 74
3.9.3 F8Deactivate Fehlerdokument............................................................................ 74
3.10 F9List – Auflisten von Signaturkarten ......................................................................... 75
3.10.1 F9List Anfragedokument..................................................................................... 76
3.10.2 F9List Antwortdokument ..................................................................................... 76
3.10.3 F9List Fehlerdokument ....................................................................................... 77
3.11 F10GetStatus – Abfragen eines Auftragsstatus ......................................................... 77
3.11.1 F10GetStatus Anfragedokument ........................................................................ 78
3.11.2 F10GetStatus Antwortdokument......................................................................... 78
3.11.3 F10GetStatus Fehlerdokument........................................................................... 80
3.12 F12Freeze – Anhalten eines Auftrags ........................................................................ 80
3.12.1 F12Freeze Anfragedokument ............................................................................. 81
3.12.2 F12Freeze Antwortdokument ............................................................................. 81
3.12.3 F12Freeze Fehlerdokument ............................................................................... 81
3.13 F13Thaw – Fortsetzen eines Auftrags........................................................................ 82
3.13.1 F13Thaw Anfragedokument ............................................................................... 82
3.13.2 F13Thaw Antwortdokument................................................................................ 82
3.13.3 F13Thaw Fehlerdokument.................................................................................. 83
3.14 F14GetURL – Dateidownload vorbereiten.................................................................. 83
3.14.1 F14GetURL Anfragedokument ........................................................................... 84
3.14.2 F14GetURL Antwortdokument............................................................................ 84
3.14.3 F14GetURL Fehlerdokument.............................................................................. 85
3.15 Download – Download einzelner Dateien................................................................... 85
3.16 Prüftiefe ...................................................................................................................... 86
4 Protokoll- und Fehlermeldungen .................................................................................... 88
4.1 Einträge in die Protokolldatei ...................................................................................... 88
4.2 Fehlermeldungen beim Start von SLMBC .................................................................. 90
4.3 Fehlermeldungen der Schnittstelle von SLMBC ......................................................... 91
5 Literaturverzeichnis ......................................................................................................... 94
Seite 4 von 94
AuthentiDate
V3.0
Abbildungsverzeichnis
Abbildung 1: Steuerung eines Vorgangs.................................................................................... 11

Abbildung 2: Steuerung paralleler Vorgänge ............................................................................. 11
Abbildung 3: Benutzerkennwörter Startdialog ............................................................................ 44
Abbildung 4: Benutzerkennwörter Zufallszahlen ........................................................................ 44
Abbildung 5: Benutzerkennwörter Eingabe ................................................................................ 45
Abbildung 6: Benutzerkennwörter Hashwerte ............................................................................ 46
Abbildung 7: Gruppenkonfiguration............................................................................................ 47
Abbildung 8: Startdialog des Hilfsprogramms groupFP ............................................................ 49
Abbildung 9: Berechnung der Gruppen-Hashwerte ................................................................... 50
Abbildung 10: Prozessgrenzen bei der Signaturerstellung ........................................................ 52
Abbildung 11: Prozessgrenzen bei der Signaturprüfung............................................................ 53
Seite 5 von 94
AuthentiDate
V3.0
Tabellenverzeichnis
Tabelle 1: Parameter des XML-Elements <httpServer>............................................................. 17

Tabelle 2: Parameter des XML-Elements <authenticationConfigs>........................................... 18
Tabelle 3: Parameter des XML-Elements <proxyConfigs> ........................................................ 18
Tabelle 4: Parameter des XML-Elements <httpAccessConfigs> ............................................... 19
Tabelle 5: Parameter des XML-Elements <timestampClients>.................................................. 20
Tabelle 6: Parameter des XML-Elements <logging>.................................................................. 21
Tabelle 7: Parameter des XML-Elements <evgLogging>........................................................... 23
Tabelle 8: Parameter des XML-Elements <weakProcessBoundEnvironment> ......................... 23
Tabelle 9: Parameter des XML-Elements <knownAttributeOid>................................................ 24
Tabelle 10: Parameter des XML-Elements <authenticationPolicies> ........................................ 25
Tabelle 11: Parameter des XML-Elements <license> ................................................................ 25
Tabelle 12: Parameter des XML-Elements <xmlProtocolHandlerPool>..................................... 26
Tabelle 13: Parameter des XML-Elements <accessAA> ........................................................... 26
Tabelle 14: Parameter des XML-Elements <F1SignRequest> .................................................. 30
Tabelle 15: Parameter des XML-Elements <F2VerifyRequest> ................................................ 35
Tabelle 16: Parameter des XML-Elements <F3LockRequest> .................................................. 36
Tabelle 17: Parameter des XML-Elements <F5SignFileRequest>............................................. 37
Tabelle 18: Parameter des XML-Elements <F6VerifyFileRequest>........................................... 39
Tabelle 19: Parameter des XML-Elements <F9ListRequest> .................................................... 40
Tabelle 20: Nebenkonfiguration Chipkartenleser ....................................................................... 41
Tabelle 21: Nebenkonfiguration Benutzer .................................................................................. 43
Tabelle 22: F1Sign Anfragedokument........................................................................................ 56
Tabelle 23: F1Sign Antwortdokument ........................................................................................ 57
Tabelle 24: F1Sign Fehlerdokument .......................................................................................... 57
Tabelle 25: F2Verify Anfragedokument...................................................................................... 59
Tabelle 26: F2Verify Antwortdokument ...................................................................................... 60
Tabelle 27: F2Verify Fehlerdokument ........................................................................................ 60
Tabelle 28: F3Lock Anfragedokument ....................................................................................... 64
Tabelle 29: F3Lock Antwortdokument........................................................................................ 64
Tabelle 30: F3Lock Fehlerdokument.......................................................................................... 65
Tabelle 31: F4FetchTimestamp Anfragedokument .................................................................... 66
Tabelle 32: F4FetchTimestamp Antwortdokument..................................................................... 66
Tabelle 33: F4FetchTimestamp Fehlerdokument....................................................................... 67
Tabelle 34: F5SignFile Anfragedokument .................................................................................. 68
Tabelle 35: F5SignFile Antwortdokument .................................................................................. 68
Tabelle 36: F5SignFile Fehlerdokument .................................................................................... 68
Tabelle 37: F6VerifyFile Anfragedokument ................................................................................ 69
Tabelle 38: F6VerifyFile Antwortdokument ................................................................................ 70
Tabelle 39: F6VerifyFile Fehlerdokument .................................................................................. 70
Tabelle 40: F7Unlock Anfragedokument .................................................................................... 72
Tabelle 41: F7Unlock Antwortdokument .................................................................................... 73
Tabelle 42: F7Unlock Fehlerdokument ...................................................................................... 73
Tabelle 43: F8Deactivate Anfragedokument .............................................................................. 74
Tabelle 44: F8Deactivate Antwortdokument .............................................................................. 74
Tabelle 45: F8Deactivate Fehlerdokument ................................................................................ 74
Tabelle 46: F9List Anfragedokument ......................................................................................... 76
Tabelle 47: F9List Antwortdokument.......................................................................................... 77
Tabelle 48: F9List Fehlerdokument............................................................................................ 77
Tabelle 49: F10GetStatus Anfragedokument ............................................................................. 78
Seite 6 von 94
AuthentiDate
V3.0
Tabelle 50: F10GetStatus Antwortdokument ............................................................................. 78

Tabelle 51: F10GetStatus Jobstatus .......................................................................................... 80
Tabelle 52: F10GetStatus Fehlerdokument ............................................................................... 80
Tabelle 53: F12Freeze Anfragedokument.................................................................................. 81
Tabelle 54: F12Freeze Antwortdokument .................................................................................. 81
Tabelle 55: F12Freeze Fehlerdokument .................................................................................... 82
Tabelle 56: F13Thaw Anfragedokument .................................................................................... 82
Tabelle 57: F13Thaw Antwortdokument..................................................................................... 83
Tabelle 58: F13Thaw Fehlerdokument....................................................................................... 83
Tabelle 59: F14GetURL Anfragedokument ................................................................................ 84
Tabelle 60: F14GetURL Antwortdokument ................................................................................ 84
Tabelle 61: F14GetURL Fehlerdokument .................................................................................. 85
Tabelle 62: Fehlermeldungen in den Protokolldateien ............................................................... 90
Tabelle 63: Fehlermeldungen beim Start von SLMBC ............................................................... 91
Tabelle 64: Allgemeine Fehlermeldungen (XML-Schemata)...................................................... 92
Tabelle 65: Allgemeine Fehlermeldungen (Beschreibung) ........................................................ 93
Seite 7 von 94
AuthentiDate
V3.0
1 Einleitung
„AuthentiDate Signature Lifecycle Management Base Component“ (Kurzbezeichnung „SLMBC“)

ist eine Signaturanwendungskomponente (SAK) gemäß SigG / SigV, die der Erzeugung und
Prüfung qualifizierter elektronischer Signaturen dient.
SLMBC kann alternativ zur Verwendung als SAK auch als technische Komponente für Zertifizie-
rungsdiensteanbieter mit Bestätigung gemäß Deutschem Signaturgesetz zwecks Erzeugung
qualifizierter elektronischer Zeitstempel eingesetzt werden. Eine Verwendung als SAK schließt
jedoch vorgenannten Einsatz aus.
Nähere Informationen hierzu entnehmen Sie bitte dem "Benutzer- und Administrationshandbuch
SLMBC als technische Komponente für ZDAs zur Erzeugung von Zeitstempeln".
Das vorliegende Handbuch „AuthentiDate SLM Base Component“ wendet sich an zwei ver-
schiedene Gruppen:
• Administratoren und
• Softwareentwickler
Administratoren werden durch dieses Dokument in die Lage versetzt, SLMBC zu konfigurieren
und zu warten.
Softwareentwickler sind mit diesem Dokument in der Lage, aus ihren eigenen Applikationen
heraus SLMBC anzusprechen und dessen Feature zu nutzen.
Bitte beachten Sie: Bei der Integration des SLMBC als technische Komponente für Zertifizie-
rungsdienste oder als Signaturanwendungskomponente müssen alle in diesem Handbuch ent-
haltenen Hinweise, die für einen sicheren Betrieb des SLMBC notwendig sind, vom Hersteller
der Anwendung („Integrator“) an die Endbenutzer dieser Anwendung weitergegeben werden.
Zu diesem Zweck sind alle derartigen Hinweise besonders gekennzeichnet.
1.1 Aufbau des Handbuchs
Das vorliegende Handbuch “AuthentiDate SLM Base Component“ unterteilt sich in zwei Berei-
che: Die Administration von SLMBC bei Endanwendern und die Einbindung von SLMBC in Ap-
plikationen der jeweiligen Hersteller über die SLMBC-Schnittstelle.
Das Kapitel „Konfiguration von SLMBC“ behandelt den administrativen Bereich der SLMBC-
Dokumentation. Es beschreibt in allen Details die Konfigurationsdateien von SLMBC und wel-
che Parameter angepasst werden können.
Das Kapitel „SLMBC-Schnittstelle“ beschreibt die Möglichkeiten, um SLMBC durch Benutzer

(Software-Applikationen) mit Hilfe des HTTPS-Protokolls anzusprechen. Es beschreibt insbe-
sondere die Schnittstelle zur Integration von SLMBC in Drittapplikationen.
Das Kapitel „Protokoll- und Fehlermeldungen“ dokumentiert die Fehlernummern und -texte, die
bei der Kommunikation mit SLMBC auftreten können. Außerdem werden mögliche Protokollein-
träge erläutert.
Seite 8 von 94
AuthentiDate
V3.0
1.2 Einsatzbereich
Obwohl SLMBC auch in der Lage ist, auf Einzelplatz-PCs Signaturen durch manuelle Anforde-
rung zu erzeugen bzw. zu verarbeiten, ist es für den Bereich der hochvolumigen Erzeugung
bzw. Verarbeitung von qualifizierten Signaturen und Zeitstempeln zum Einsatz auf unterschied-
lichen Betriebssystemen (Windows, Linux) ausgelegt und dient der Optimierung und Automati-
sierung elektronischer Prozesse (Stapelsignaturen und Massensignaturen).
Einsatzszenarien sind zum Beispiel die Bestätigung des Medienbruchs im Scan-Capture-

Prozess, die Absicherung von elektronischen Rechnungen gemäß gesetzlicher Anforderungen
oder auch das automatisierte Nachsignieren zum Zwecke der Langzeitarchivierung elektronisch
signierter Daten.
Bei der Erstellung qualifizierter elektronischer Signaturen schützt SLMBC die zu signierenden
Daten aktiv während des gesamten Prozesses der Signaturerstellung. Dazu gehören das Anle-
gen des Auftrags, die optionale Anzeige der Daten und das Erzeugen von Signaturen.
Für die Erzeugung von Signaturen können mehrere sichere Chipkartenterminals – gegebenen-
falls gruppiert - gleichzeitig verwendet werden. Bei der Erzeugung von Signaturen können opti-
onal qualifizierte Zeitstempel zum Nachweis des Zeitpunktes der Erstellung eingeholt und in die
Signatur eingebettet werden.
Bei der Prüfung elektronischer Signaturen schützt SLMBC die zu prüfenden Daten zusammen
mit den Prüfergebnissen aktiv während des gesamten Prozesses der Signaturprüfung. Dazu
gehören das Anlegen des Auftrags, die optionale Anzeige der Daten und das Prüfen der Signa-
turen.
Die Prüfung erfolgt nach Anforderung durch den Prüfenden entweder teilweise oder vollständig
unter Beachtung hinreichend aktueller Auskünfte zuständiger Zertifizierungsdienste zu der Exis-
tenz und Sperrung von Zertifikaten. Diese Auskünfte holt SLMBC bei Bedarf vom jeweiligen
Zertifizierungsdienst ein. In die zu prüfenden Signaturen eingebettete qualifizierte Zeitstempel
werden auf gleichem Wege überprüft.
Diese Prüfung findet in unterschiedlichen Prüftiefen, maximal bis zur Erlangung von nicht zu-
rückweisbaren Prüfergebnissen statt. Die Prüfergebnisse können dann ebenfalls mit den elek-
tronischen Dokumenten und Signaturen archiviert werden.
Hierbei ist es wichtig die Begriffe Anforderung und Erstellung von Zeitstempeln zu differenzie-
ren. Beim Einsatz von SLMBC bei einem Endkunden werden von SLMBC die Zeitstempel aus-
schließlich angefordert. Erstellt werden Zeitstempel bei (angezeigten oder akkreditierten) Zerti-
fizierungsdiensten in einer sicheren Server-Umgebung („Trust-Center“).
Nachfolgend werden die beiden Einsatzgebiete für den Einsatz als vollständige Signatur-
anwendungskomponente erläutert.
1.3 Prozessumgebung (stark/schwach)
Im Gegensatz zu anderen Signaturanwendungskomponenten kann SLMBC nicht nur an Ar-

beitsplätzen für Anwender konfiguriert werden, sondern spielt seine Stärken besonders im Ein-
satz in Server-Umgebungen aus.
Seite 9 von 94
AuthentiDate
V3.0
Aus diesem Grund werden zwei Einsatz-Szenarien definiert.
• Als schwach prozessgebundener Einsatz wird bezeichnet, wenn SLMBC auf einem
Arbeitsplatzsystem installiert ist, an dem ein Signaturkarteninhaber („Anwender“)
SLMBC die zu signierenden bzw. prüfenden Daten interaktiv zuführt. Die Zuführung ge-
schieht zwar immer über die Software-Applikation, die SLMBC dazu beauftragt, diese
wird aber durch den Anwender bedient.
• Als stark prozessgebundener Einsatz wird ein abgeschlossener Betrieb bezeichnet,

bei dem die zu signierenden bzw. zu prüfenden Daten SLMBC vollautomatisch ohne ei-
ne Interaktion mit dem Signaturkarteninhaber („Anwender“) zugeführt werden. Die Zu-
führung geschieht zwar auch hier immer über die Software-Applikation, die SLMBC dazu
beauftragt, diese wird aber durch automatisierte Prozesse gesteuert.
Durch eine einfache Einstellung in der Hauptkonfigurationsdatei wird SLMBC mitgeteilt, in wel-
chem Einsatzumfeld gearbeitet wird. Für diese beiden Einsatzfelder erzwingt SLMBC unter-
schiedliche Abläufe der Vorgangsverarbeitung und unterstützt unterschiedliche Arten der Akti-
vierung und Deaktivierung von Signaturkarten.
Im stark prozessgebundenen Einsatz erlaubt SLMBC die Verwendung derselben Gruppe von
Signaturkarten durch mehrere Vorgänge gleichzeitig. Des Weiteren kann der Signaturkarten-
inhaber beim Starten des Dienstes einmalig durch Eingabe seiner PINs die Signaturkarten in-
nerhalb der Gruppe aktivieren und diese dann für einen längeren Zeitraum SLMBC zur Verfü-
gung stellen.
Voraussetzung für den stark prozessgebundenen Einsatz im Sinne des Signaturgesetzes ist die
Verwendung bestätigter Multisignatur-Signaturerstellungseinheiten (Multisignatur-SSEE); es
sind die Anforderungen der Multisignatur-SSEE zu erfüllen, d. h. sie dürfen ausschließlich in
besonders gesicherten Umgebungen, z. B. in einem Rechenzentrum, verwendet werden. Die
Anwendung (der Benutzer) muss dabei sicherstellen, dass die zu signierenden Daten plausibili-
siert werden und nur gleichartige Dokumente signiert werden.
Im schwach prozessgebundenen Einsatz hingegen nutzt ein Vorgang eine Gruppe exklusiv.
Nach Abschluss eines Vorgangs werden die Signaturkarten einer Gruppe automatisch deakti-
viert und müssen für die Bearbeitung des nächsten Vorgangs erneut aktiviert werden.
Mit der Aktivierung von Signaturkarten ist die Operation gemeint, mit der sich der Signaturkar-
teninhaber durch Eingabe seiner Identifikationsdaten gegenüber der Signaturkarte identifiziert
und diese daraufhin Signaturen erzeugen kann. Mit der Deaktivierung ist die Operation gemeint,
durch die die Signaturkarte dazu veranlasst wird, erst nach erneuter Authentifizierung des Be-
sitzers weitere Signaturen zu erzeugen.
Im schwach prozessgebundenen Einsatz können Multisignatur-SSEE eingesetzt werden, um

Stapelsignaturen zu erzeugen. Dabei wird die Multisignatur-SSEE für die Signaturerstellung
eines Stapels von Dateien aktiviert. Der Anwender kann und soll sich während des Signaturvor-
ganges davon überzeugen, welche Daten er signiert. Zur Erfüllung der Anforderungen im Sinne
des Signaturgesetzes muss die Anwendung in einem geschützten Einsatzbereich gemäß der
Empfehlung der Bundesnetzagentur betrieben werden, wie sie in der Regel in einem normalen
Büroumfeld vorliegt. Eine entsprechende Einsatzumgebung muss bei Einzelsignaturen mit Ein-
zelsignatur-SSEE vorliegen.
Seite 10 von 94
AuthentiDate
V3.0
1.4 Vorgangs-/Auftragssteuerung (Signaturerzeu-

gung/Signaturprüfung)
Der gesamte Prozess der Signaturverarbeitung (Erstellung und Prüfung von Signaturen und
Zeitstempeln) wird innerhalb von SLMBC durch eine Vorgangs- bzw. Auftragssteuerung umge-
setzt.
Diese Vorgangssteuerung wird intern für den Benutzer vollkommen transparent über eine so
genannte „Statemachine“ realisiert. Dies bedeutet, dass wie in einem Workflow-Prozess jeder
Auftrag, der an SLMBC übergeben wird, einen initialen Zustand hat und dann verschiedene
weitere Zustände durchläuft.
Erstellung Vorgang 1 f3Lock Datenübergabe f5SignFile f7Unlock Datenrückgabe Abschluss Vorgang 1
08:00 08:05
Schutz der Daten durch SLMBC
08:00 - 08:04
Abbildung 1: Steuerung eines Vorgangs
Den Zustand jedes Vorgangs kann der Benutzer jederzeit über SLMBC erfragen. Findet keine
Interaktion mit dem Benutzer statt, werden die Vorgänge vollkommen automatisiert verarbeitet
und wandern so von einem Zustand zum nächsten, bis sie verarbeitet wurden.
Die Vorgangssteuerung wurde für eine massenhafte und parallele Verarbeitung konzipiert. Das
bedeutet, dass der Benutzer SLMBC mehrere Aufträge gleichzeitig in Arbeit geben kann und
SLMBC jeden für sich sicher verarbeitet. Die Vorgänge werden dabei abhängig von der einge-
setzten Umgebung (Anzahl Chipkartenterminals, Prozessoren) in mehreren Prozessen (Mul-
tithreading) gleichzeitig verarbeitet.
09:00 09:15
Schutz der Daten durch SLMBC
09:02 - 09:12
Abbildung 2: Steuerung paralleler Vorgänge
Die Vorgangssteuerung verarbeitet und manipuliert für jeden Vorgang ein exklusiv zugeordne-
tes sicheres Verzeichnis (s. auch Kapitel 1.5 „Sichere Verzeichnisse“).
Seite 11 von 94
AuthentiDate
V3.0
Das sichere Verzeichnis enthält die vom Anwender übergebenen Daten. Während der aktiven
Erstellung bzw. Prüfung von Signaturen ist jeglicher Zugriff auf das sichere Verzeichnis aus-
schließlich SLMBC möglich. Zur restlichen Laufzeit eines Vorganges ist dem Benutzer (Soft-
ware-Applikation) und Anwendern der lesende Zugriff erlaubt, wohingegen nur SLMBC schrei-
ben und manipulieren darf.
1.5 Sichere Verzeichnisse
Zwischen der Betrachtung eines Dokuments, der sicheren Eingabe der PIN am Kartenlesegerät
und der Signaturerstellung vergeht oftmals nur ein kurzer Zeitraum, der aber theoretisch aus
der Sicht eines Angreifers ausreicht, um Dokumente zu fälschen oder weitere Dokumente un-
entdeckt einem vorhandenen Stapel hinzuzufügen.
Um diese Art der Angriffsversuche zu unterbinden, übernimmt SLMBC aktiv den Schutz der zu
verarbeitenden Daten. Dabei unterstützt SLMBC die Absicherung von Benutzerdaten, Doku-
menten und eben auch Verzeichnissen.
Wird SLMBC zur Erstellung oder Prüfung von Signaturen betrieben, nimmt es die zu signieren-
den Dokumente in Form von Dateien entgegen. Die Dokumente werden in ein sicheres Ver-
zeichnis verschoben und verbleiben dort solange, bis ein Benutzer (Software-Applikation) ihre
Freigabe anfordert. Dies kann entweder nach der Erstellung bzw. Prüfung der Signaturen oder
aber auch vorzeitig geschehen.
SLMBC garantiert, dass entweder alle Signaturen erstellt bzw. geprüft werden oder der Prozess
keine Signaturen bzw. Prüfergebnisse erhält. Das heißt, für den Benutzer (Software-
Applikation) ist die Signaturerstellung und -prüfung für eine Menge von Dokumenten transakti-
onsorientiert.
1.6 Authentisierung
Bei jedem Aufruf einer Funktion von SLMBC identifiziert und authentifiziert SLMBC den aufru-
fenden Benutzer (Software-Applikation) anhand einer Benutzerkennung und eines Passwortes.
Dies dient dazu, die Berechtigung des Benutzers zum Aufruf der jeweiligen Funktion zu prüfen.
Verschiedene Benutzer können dabei dieselbe Benutzerkennung verwenden.
Für die Erstellung von Signaturen wird beim Aufruf der Funktion zur Erzeugung eines Signatur-
auftrages, beim Aufruf der Funktion zum Starten eines Signaturvorganges und beim Aufruf der
internen Funktion von SLMBC zur konkreten Erzeugung einer einzelnen Signatur eine weitere
Identifikation und Authentifizierung des Signaturkarteninhabers anhand einer Kennung und ei-
nes Passwortes durchgeführt. Sie dient SLMBC zum Zweck, die Berechtigung der Verwendung
einer konkreten Gruppe von Signaturerstellungseinheiten zu überprüfen.
Die Benutzerkennung zur Identifikation eines Benutzers (Software-Applikation) und die Benut-
zerkennung zur Identifikation eines Signaturkarteninhabers zu einer Gruppe von Signaturkarten
sind voneinander unabhängig.
Die Authentisierung des Besitzers einer Gruppe von Signaturkarten wird erst beim Aufruf der
internen Funktion von SLMBC zur Erzeugung einer einzelnen Signatur wirklich durchgeführt.
Die Funktionen zum Erzeugen eines Signaturauftrages und zum Starten der tatsächlichen Er-
stellung von Signaturen nehmen nur die Identifikation direkt beim Funktionsaufruf vor, während
Seite 12 von 94
AuthentiDate
V3.0
sich SLMBC das zugehörige Passwort nur für den späteren Aufruf der internen Funktion merkt.
So wäre beim Erzeugen des Signaturauftrages eigentlich keine Angabe des Passwortes not-
wendig. Tatsächlich wird es aber durch SLMBC zum Vergleich mit dem Passwort verwendet,
welches der Benutzer beim Aufruf der Funktion zum Starten der Erstellung von Signaturen er-
neut angibt. Auf diese Weise wird bei der Funktion zum Starten der Urheber des Auftrages si-
cher identifiziert.
Seite 13 von 94
AuthentiDate
V3.0
2 Konfiguration von SLMBC
Die Konfiguration von SLMBC geschieht ausschließlich über XML-Dateien. Es gibt eine Haupt-
konfigurationsdatei und mehrere Nebenkonfigurationsdateien.
Mit der Hauptkonfigurationsdatei, die beim Start von SLMBC als Parameter mit angegeben
wird, wird das gesamte Verhalten des Systems gesteuert.
Mit den Nebenkonfigurationsdateien werden die Chipkartenleser, die Signaturerstellungs-

einheiten („SmartCards“), die Benutzer und die Gruppen („Mandanten“) parametrisiert.
2.1 Hauptkonfiguration
Der Name der Konfigurationsdatei wird SLMBC beim Start als Parameter übergeben. Das For-
mat dieser Datei ist wie bei allen anderen Konfigurationsdateien XML. Das XML-Schema dieser
Datei wird in mehreren Schema-Dateien (mit der Endung .xsd) definiert, die in elektronischer
Form in dem von AuthentiDate ausgelieferten komprimierten Archiv unter dem Verzeichnis
\developer\xml-schemata enthalten sind. Dabei ist das Wurzelelement <slmbcServer> in der
Datei slmbcServer.xsd definiert. Alle weiteren Dateien werden von dort aus namentlich refe-
renziert. Der Inhalt der Schema-Dateien wird hier nicht wiedergegeben, weil dies den Rahmen
dieses Dokuments überschreiten würde.
Die Konfiguration lässt sich hierbei in zwei Arten einteilen, den allgemeinen Teil und die Konfi-
guration der einzelnen Funktionen F1 – F14. F11 steht nicht zur Verfügung.
Die nachfolgenden Darstellungen und Tabellen erklären die einzelnen XML-Tags, die durch
erfahrene Administratoren bzw. Entwickler angepasst werden können.
Hierbei werden die Konfigurationsoptionen durch eine Angabe in der dritten Spalte („Level“)
folgendermaßen klassifiziert:
(1) Änderungen durch den Anwender ggfs. erforderlich bzw. möglich,

(2) Änderungen nur nach Rücksprache mit dem AuthentiDate Service-Team,
(3) Änderungen dürfen ausschließlich durch das AuthentiDate Service-Team vorgenom-
men werden
Zuerst werden die Parameter des allgemeinen Teils beschrieben (2.1.1 bis 2.1.7) und anschlie-
ßend die Elemente zu den einzelnen Funktionen von SLMBC. Hierbei ist zwischen der Konfigu-
ration der Funktionen von SLMBC und dem Zugriff auf diese Funktionen über die Schnittstelle
von SLMBC zu unterschieden.
Mit der Konfiguration der Funktionen sind die Einstellungen und das Reaktionsverhalten von
SLMBC auf Anfragen durch den Benutzer (Software-Applikation) gemeint, während die Schnitt-
stelle von SLMBC die eigentlichen Anfragen an diese Funktionen beschreibt
(siehe Kapitel 3 „SLMBC-Schnittstelle“).
Da einige Konfigurationen komplexe XML-Subelemente beinhalten, die die Grenzen dieses

Handbuchs sprengen würden, verweisen wir hiermit auf die Schemata-Dateien, die mit ausge-
liefert werden. Die Dateien befinden sich dabei in dem Verzeichnis \slmbc\developer\xml-
Seite 14 von 94
AuthentiDate
V3.0
schemata\, wobei hier zwischen der administrativen Konfiguration und der Entwickler-
Schnittstelle unterschieden wird. Die Schemata des erstgenannten befinden sich in dem Unter-
verzeichnis \configuration\ und die des letzteren in dem Unterverzeichnis \interface\.
2.1.1 Element <httpServer>
Mit dem Element <httpServer> wird eingestellt, unter welcher Adresse (resp. unter welchen Ad-
ressen) und mit welchem Protokoll SLMBC angesprochen werden kann.
Im Element <listeners> kann zunächst eine beliebige Anzahl von Elementen <httpsListener>
aufgeführt werden. Mindestens ein direkt eingebettetes Element muss im umgebenden <liste-
ners> Element aufgeführt werden. Mit jedem <httpsListener> Element wird definiert, dass
SLMBC über eine bestimmte Adresse per HTTPS erreichbar ist.
Für die Konfiguration eines HTTPS-Ports steht das XML-Tag <httpsSignerInformation> samt
aller eingebetteten Tags zur Verfügung.
Im <baseSignerInformation> Element wird dann definiert, wo der private SSL-Schlüssel für das
HTTPS-Protokoll zu finden ist. Zum Betreiben von SLMBC wird eine PKCS#12-Datei benötigt,
welche den privaten Schlüssel für die SSL-Kommunikation und das zugehörige SSL-Zertifikat
unter einem bestimmten Eintrag enthält.
Eine PKCS#12-Datei mit SSL-Zertifikat kann entweder von einem entsprechenden Anbieter wie
Verisign oder TC Trustcenter erworben werden oder mit einem Tool wie OpenSSL erzeugt wer-
den. Die genaue Vorgehensweise hängt vom Einsatzzweck von SLMBC ab. Auf keinen Fall darf
die mitgelieferte PKCS#12-Datei im Produktivbetrieb genutzt werden.
Die Elemente <supportedCipherSuite> und <servlet> dürfen nicht geändert werden. Details, die
über die unten genannte Information hinausgehen, sind in den XML-Schemadateien zu finden.
01 <httpServer>
02 <listeners>
03 <httpsListener>
04 <hostname>localhost</hostname>
05 <port>443</port>
06 <minThreads>5</minThreads>
07 <maxThreads>10</maxThreads>
08 <maxIdleTimeMs>0</maxIdleTimeMs>
09 <httpsSignerInformation>
10 <baseSignerInformation>
11 <joinedSignerInformation>
12 <keyStoreJoinedSignerInformation>
13 <keyStore>
14 <keyStoreDef>
15 <keyStoreType>PKCS12</keyStoreType>
16 <keyStoreSource>
17 <uriStoredData>file:serverKey.p12</uriStoredData>
18 </keyStoreSource>
19 <password>pwdkey</password>
20 </keyStoreDef>
21 </keyStore>
22 <keyAlias>aliasKey</keyAlias>
23 <keyPassword>pwdkey</keyPassword>
24 </keyStoreJoinedSignerInformation>
Seite 15 von 94
AuthentiDate
V3.0
25 </joinedSignerInformation>
26 </baseSignerInformation>
27 </httpsSignerInformation>
28 <supportedCipherSuite>TLS_RSA_WITH_AES_256_CBC_SHA
29 </supportedCipherSuite>
30 <supportedCipherSuite>SSL_RSA_WITH_3DES_EDE_CBC_SHA
31 </supportedCipherSuite>
32 </httpsListener>
33 </listeners>
34
35 <servlet>
36 <name>Interface for sigAnf</name>
37 <httpContext>/xml</httpContext>
38 <servletClass>de.authentidate.module.
39 xmlproto.XmlServlet</servletClass>
40 </servlet>
41
42 <servlet>
43 <name>File download handler</name>
44 <httpContext>/slmbc-download/*</httpContext>
45 <servletClass>de.authentidate.sir.
46 orderbook.DownloadServlet</servletClass>
47 </servlet>
48
49 <useDefaultNotFoundHandler>true</useDefaultNotFoundHandler>
50 </httpServer>
Zeile XML-Tag Level Beschreibung

4 hostname 1 Benennt die IP-Adresse oder den DNS-Namen unter wel-
chem SLMBC ansprechbar sein soll. Die besondere Ad-
resse „localhost“ kann verwendet werden, damit SLMBC
nur lokal von Programmen auf dem Rechner selbst ange-
sprochen werden kann. Der besondere Wert „0.0.0.0“ kann
eingestellt werden, damit SLMBC unter allen IP-Adressen
erreichbar ist, die im Betriebssystem als lokale Netzwerk-
schnittstellen konfiguriert sind bzw. sein werden.
5 port 1 Benennt die Port-Nummer, unter der SLMBC per TCP
angesprochen werden können soll.
6 minThreads 2 Benennt die Anzahl der Threads, welche von SLMBC min-
destens bereitgehalten werden sollen, um Anfragen, die
über die genannte Netzwerkschnittstelle und Port-Nummer
an SLMBC gerichtet werden, zu bedienen. Die Anzahl der
Threads wird auch dann bereitgehalten, wenn aktuell keine
oder weniger Anfragen zu bearbeiten sind.
7 maxThreads 2 Benennt die Anzahl der Threads, die von SLMBC maximal
parallel betrieben werden sollen, um Anfragen, die über die
genannte Netzwerkschnittstelle und Port-Nummer an
SLMBC gerichtet werden, zu bedienen. Die Anzahl der
Threads wird wieder auf den Wert bis hin zum Wert von
<minThreads> verringert, sobald weniger gleichzeitige
Anfragen zu bearbeiten sind.
17 uriStoredData 1 Benennt den Namen einer Datei im Format PKCS#12,
welche den privaten Schlüssel für die SSL-Verbindungen
und das zugehörige Zertifikat des Servers enthält. Der
Dateiname kann mit absolutem oder relativem Pfad ange-
geben werden. Relative Pfade werden bezogen auf das
zum Zeitpunkt des Startens von SLMBC aktuelle Arbeits-
verzeichnis interpretiert.
19 password 1 Innerhalb des Elementes <keyStoreDef> ist das Element
Seite 16 von 94
AuthentiDate
V3.0

<password> auf den Wert zu setzen, mit dem die Ent-
schlüsselung der PKCS#12-Datei an sich vorgenommen
werden kann.
22 keyAlias 1 Der Wert des Elementes <keyPassword> ist so zu setzen,
dass damit der private SSL-Schlüssel entschlüsselt und
benutzt werden kann
23 keyPassword 1 Bezeichnet den Namen des Eintrages („friendly name“),
unter dem der private SSL-Schlüssel und das zugehörige
Zertifikat in die PKCS#12-Datei eingetragen wurde.
28, 30 supportedCipherSuite 3 Bestimmt die minimale Anforderung an die Verschlüs-
selungsalgorithmen für die SSL-Kommunikation.
37, 44 httpContext 2 Angabe einer relativen URL, unter der das Servlet ange-
sprochen werden kann.
Tabelle 1: Parameter des XML-Elements <httpServer>
2.1.2 Element <clientNetworkAccessParameter>
Mit dem Element <clientNetworkAccessParameter> werden Verbindungsparameter definiert,

die SLMBC benötigt, wenn um als Client-Applikation Verbindungen zu anderen Servern aufzu-
bauen, wie z. B. zu einem Zertifizierungsdiensteanbieter oder aber auch beim zweiteiligen Be-
trieb von SLMBC zum zweiten Teil von SLMBC, auf dem die Funktionen F1, F8, F9 und F2
ausgeführt werden.
Zu dem Element <clientNetworkAccessParameter> gehören die folgenden Unterelemente:
• authenticationConfigs – Einfache Konfiguration mit Benutzername und Passwort.
• proxyConfigs – Konfiguration eines Proxys für HTTP-Verbindungen. Java-Parameter

beim Aufruf der JVM sind wirkungslos.
• httpAccessConfigs – Vollständige Konfiguration der Zugangsdaten zu einer URL-

Verbindung, inklusive Beschreibung des Zugriffs, des Proxys bzw. der SSL-
Verbindungsparameter.
• httpClientsConfigurations – Beschreibung einer URL-Verbindung mit Referenzierung auf

die Konfiguration der Zugangsdaten.
• timestampClients – Vollständige Konfiguration des Zugangs zu einem Zeitstempel-

Trustcenter inklusive Beschreibung der Nutzerdaten und der Verbindungsdaten.
Die hier genannten Daten können beispielsweise bei der Konfiguration der Funktion F1 genutzt
werden. Falls die Signatur mit einem Zeitstempel abgesichert werden soll, wird bei der Konfigu-
ration der Funktion F1 nur eine Referenz auf den hier definierten Zeitstempelnutzer angegeben.
Bei der Konfiguration des Zeitstempelnutzers kann dann auf eine URL-Verbindung, diese wie-
derum auf einen Proxy und dieser daraufhin auf die erstgenannte Benutzer-zu-Passwort-
Konfiguration zurückgreifen.
Dies bietet den Vorteil, dass die Netzwerk-Zugangsdaten nur an einer Stelle geändert werden
müssen, da alle weiteren Eigenschaften diese referenzieren. Alle Subelemente der genannten
fünf Elemente können mehrfach vorkommen.
Seite 17 von 94
AuthentiDate
V3.0
01 <authenticationConfigs>
02 <httpAuthDef id="tsaAuth01">
03 <basicAuthDef>
04 <userName>streng</userName>
05 <password>geheim</password>
06 </basicAuthDef>
07 </httpAuthDef>
08 <httpAuthDef id="auth4InternalSlmbcCall">
09 <basicAuthDef>
10 <userName>admin</userName>
11 <password>pwadmin</password>
12 </basicAuthDef>
13 </httpAuthDef>
14 </authenticationConfigs>

2, 8 httpAuthDef 1 Legt die eindeutige ID des Elementes fest, auf das spä-
ter referenziert werden kann.
4, 10 userName 1 Beschreibt den Benutzernamen für einen späteren
Zugriff z. B. auf einen Zeitstempel-Account.
5, 11 password 1 Beschreibt das dazugehörige Passwort des Benutzers.
Tabelle 2: Parameter des XML-Elements <authenticationConfigs>
01 <proxyConfigs>
02 <proxyServerConfigDef id="ID000001">
03 <host>localhost</host>
04 <port>9090</port>
05 <httpAuth>
06 <httpAuthRef>
07 <httpAuthDefId>auth4proxy</httpAuthDefId>
08 </httpAuthRef>
09 </httpAuth>
10 </proxyServerConfigDef>
11 </proxyConfigs>

2 proxyServerConfigDef 1 Legt die eindeutige ID des Elementes fest, auf das später refe-
renziert werden kann.
3 host 1 Beschreibt die IP-Adresse des Proxy-Servers.
4 port 1 Beschreibt den Port des Proxy-Servers.
5 ... httpAuth 1 Dieses Element ist optional. Man kann entweder eine Referenz
auf ein <authenticationConfigs>-Element angeben, oder aber
es hier definieren. Das Element wird benötigt, falls der ange-
gebene Proxy eine Benutzerauthentifizierung vorgibt.
Tabelle 3: Parameter des XML-Elements <proxyConfigs>
01 <httpAccessConfigs>
02 <httpClientConfigDef id="defaultHttpAccessConfig"/>
03
04 <httpClientConfigDef id="internalSlmbcCallAccessConfig">
05 <authentication>
06 <httpAuthRef>
07 <httpAuthDefId>auth4InternalSlmbcCall</httpAuthDefId>
08 </httpAuthRef>
09 </authentication>
10 </httpClientConfigDef>
Seite 18 von 94
AuthentiDate
V3.0
11
12 <httpClientConfigDef id="tsaAccount01">
13 <authentication>
14 <httpAuthRef>
15 <httpAuthDefId>tsaAuth01</httpAuthDefId>
16 </httpAuthRef>
18
19 <proxyServerConfig>
20 <proxyServerConfigDef>
21 <host>localhost</host>
22 <port>8080</port>
23 <httpAuth>
24 <httpAuthRef>
25 <httpAuthDefId>proxytest</httpAuthDefId>
26 </httpAuthRef>
27 </httpAuth>
28 </proxyServerConfigDef>
29 </proxyServerConfig>
30
31 <sslOptions>
32 <trustedServerCert>
33 <encodedCertificate>
34 <certType>X.509</certType>
35 <securityProviderName>AuthentiDate</securityProviderName>
36 <certSource>
37 <hexEncodedData>308202…0b7a7f</hexEncodedData>
38 </certSource>
39 </encodedCertificate>
40 </trustedServerCert>
41 </sslOptions>
43 </httpAccessConfigs>

2, 4, 12 httpClientConfigDef 1 Legt die eindeutige ID des Elementes fest, auf das später
referenziert werden kann. Das erste Element wird z. B. als
leeres Element angegeben. Wenn alle weiteren Einstellungen
auf dieses Element referenzieren, kann man später nur an
dieser einen Stelle eine Änderung vornehmen, die dann von
allen Elementen genutzt wird.
5, 13 authentication 1 Dieses Element ist optional. Es referenziert oder definiert die
Benutzer-zu-Passwort-Daten.
19 proxyServerConfig 1 Dieses Element ist optional. Es definiert oder referenziert die
Daten, um eine Verbindung über einen Proxy herzustellen. In
diesem Beispiel wird ein komplettes Element für einen Proxy
definiert und nicht referenziert.
31 sslOptions 1 Dieses Element ist optional. Es definiert die SSL-
Zugangsdaten (Zertifikate), die bei einer verschlüsselten Ver-
bindung benötigt werden.
Tabelle 4: Parameter des XML-Elements <httpAccessConfigs>
01 <timestampClients>
02 <timestampClientDef id="tsa01">
03 <url>http://www.authentidate.de</url>
04 <config>
05 <httpClientConfigRef>
06 <httpClientConfigDefId>tsaAccount01</httpClientConfigDefId>
07 </httpClientConfigRef>
Seite 19 von 94
AuthentiDate
V3.0
08 </config>
09 <defaultTimeStampFormatOidOrName>RFC3161
10 </defaultTimeStampFormatOidOrName>
11 </timestampClientDef>
12 </timestampClients>

2 timestampClientDef 1 Legt die eindeutige ID des Elementes fest, auf das später refe-
renziert werden kann.
3 url 1 Dieses Element bestimmt die URL, unter der der Zeitstempel-
Server zu erreichen ist.
4 ... config 1 Dieses Element ist optional. Es definiert oder referenziert die
Zugangsdaten über das <httpClientConfigs>-Element. In diesem
Beispiel wird auf ein vorher definiertes Element referenziert.
Tabelle 5: Parameter des XML-Elements <timestampClients>
2.1.3 Element <logging>
Mit dem Element <logging> wird eingestellt, in welcher Detailtiefe und wohin Logdaten zu
schreiben sind.
Die für den Produktionsbetrieb empfohlene Einstellung ist INFO. In diesem Detailgrad werden
nicht zu viele Ressourcen für die Aufzeichnung von Ereignissen verwendet, es werden aber
dennoch der Beginn und das Ende eines Vorganges, das explizite (also nicht implizit durch
Vorgänge vorgenommene) Aktivieren und Deaktivieren von Signierkarten sowie das Einstecken
und Herausnehmen von Signierkarten aus dem Chipkartenlesegerät protokolliert.
01 <logging>
02 <logSinks>
03 <logLevel>DEBUG</logLevel>
04 <logSink>
05 <logFile>
06 <fileName>log/signer.log</fileName>
07 <maxFileSize>10485760</maxFileSize>
08 <oldLogsToKeep>30</oldLogsToKeep>
09 </logFile>
10 </logSink>
11 </logSinks>
12 </logging>

3 logLevel 1 Stellt den Detailgrad für alle Empfänger von Ereignismeldungen ein.
Unterstützte Werte sind in der folgenden Tabelle erklärt.
• ALL - Alle Ereignismeldungen werden weitergereicht.
• DEBUG - Die Meldung der nachfolgend genannten Detail-
grade und Meldungen zur Fehlerfindung innerhalb SLMBC
werden zur Aufzeichnung an die Empfänger weitergereicht.
• INFO - Meldungen der nachfolgend genannten Detailgrade
und Meldungen mit nennenswerten, aber normalem Informa-
tionsgehalt werden zur Aufzeichnung an die Empfänger wei-
tergereicht.
• WARN - Meldungen der nachfolgend genannten Detailgrade
und Meldungen, die vor nicht unbedingt fehlerhaften aber po-
Seite 20 von 94
AuthentiDate
V3.0

tentiell fehlerhaften Ereignissen warnen, werden zur Auf-
zeichnung an die Empfänger weitergereicht.
• ERROR - Meldungen der nachfolgend genannten Detailgra-
de und Fehlermeldungen werden zur Aufzeichnung an die
Empfänger weitergereicht.
• FATAL - Nur Meldungen über Ereignisse, die die Funktion
SLMBC (nahezu) unmöglich machen, werden zur Aufzeich-
nung an die Empfänger weitergereicht.
• OFF - Keine Meldung wird an die Empfänger weitergereicht.
6 fileName 1 Benennt die Datei, in der die Ereignismeldungen eingetragen werden
sollen. Dies sollte ein absoluter Pfad sein. Er wird sonst relativ zu
dem Verzeichnis interpretiert, in dem der Signierdienst gestartet wur-
de.
7 maxFileSize 1 Stellt die maximale Größe der Logdatei ein. Nach der hier angege-
benen Anzahl von Bytes wird die Datei geschlossen und umbenannt.
8 oldLogsToKeep 1 Stellt die Anzahl der alten Logdateien ein, die gespeichert werden
sollen. Wenn eine Logdatei ihre maximale Größe erreicht, wird sie
geschlossen und in der Weise umbenannt, dass ihr neuer Name dem
alten Namen mit der neuen Dateiendung „.1“ darstellt. Die alten Log-
dateien werden so umbenannt, dass die hinten angehangene Num-
mer jeweils um Eins erhöht wird. Durch dieses Element wird einge-
stellt, wie viele dieser alten Logdateien insgesamt vorhanden sein
sollen. Negative Werte sind nicht erlaubt.
Tabelle 6: Parameter des XML-Elements <logging>
2.1.4 Element <evgLogging>
Mit dem Element <evgLogging> wird das Logging für den gemäß Signaturgesetz benötigten
Betrieb konfiguriert. Dazu gehören z. B. die Neukonfiguration der Gruppen, das Erzeugen eines
neuen Auftrages oder der Zugriff auf die Signaturkarte. Das Protokoll wird dabei in einer eige-
nen Datei abgelegt.
Bitte beachten Sie: Die für den Produktionsbetrieb empfohlene Einstellung ist EVG_2. Die Ein-
stellung EVG_NONE darf nicht verwendet werden, falls der EVG in einem signaturgesetzkon-
formen Umfeld eingesetzt werden soll.
01 <evgLogging>
02 <secureLog>
03 <secureLoggingDef id="sl001">
04 <iSAMFileSecureLoggingAppenderDef>
05 <storageFolder>log</storageFolder>
06 <createIndex>true</createIndex>
07 <syncAfterEachLogWrite>true</syncAfterEachLogWrite>
08 <linkFiles>true</linkFiles>
09 <filePrefix>
10 <openLog>ol</openLog>
11 <timestampedLog>tl</timestampedLog>
12 </filePrefix>
13 <fileSuffix>
14 <dataFile>.log</dataFile>
15 <indexFile>.idx</indexFile>
16 <timestampFile>.tsr</timestampFile>
17 </fileSuffix>
18 <period4OpenLog>
19 <metronomeFactoryName>
Seite 21 von 94
AuthentiDate
V3.0
20 general metronome factory

21 </metronomeFactoryName>
22 <threadName>SecureABC</threadName>
23 <periodMillis>60000</periodMillis>
24 </period4OpenLog>
25 <openLogFileSize>10485760</openLogFileSize>
26 <timestamp>
27 <source>
28 <rfc3161HttpProxy>
29 <standardRfc3161HttpProxy>
30 <url>https://hera.authentidate.de/rfc3161</url>
31 <config>
32 <httpClientConfigRef>
33 <httpClientConfigDefId>tsaAccount01</httpClientConfigDefId>
34 </httpClientConfigRef>
35 </config>
36 <hackCMSVersion>false</hackCMSVersion>
37 </standardRfc3161HttpProxy>
38 </rfc3161HttpProxy>
39 </source>
40 <digestAlgorithmNameOrOID>SHA-1</digestAlgorithmNameOrOID>
41 <requestRetryLimit>3</requestRetryLimit>
42 </timestamp>
43 <secureLogConfig>
44 <logSinks>
45 <customLogSinksType>
46 <logLevel>EVG_1</logLevel>
47 <logSink>
48 <logFile>
49 <fileName>evg.log</fileName>
50 </logFile>
51 </logSink>
52 </customLogSinksType>
53 </logSinks>
54 </secureLogConfig>
55 </iSAMFileSecureLoggingAppenderDef>
56 </secureLoggingDef>
57 </secureLog>
58 </evgLogging>

5 storageFolder 1 Verzeichnis unterhalb des Serververzeichnisses, das die EVG-
Protokolldateien enthalten soll.
6 createIndex 2 Eine Indexdatei zur Protokolldatei wird erzeugt. Dies beschleunigt
eine eventuelle spätere Auswertung.
7 syncAfter- 2 Sorgt dafür, dass die Protokolldatei nach jedem Schreibvorgang
EachLogWrite tatsächlich auf die Festplatte geschrieben wird und nicht im Cache
bleibt.
8 linkFiles 2 Verbindet mehrere Protokolldateien miteinander, indem die vorher-
gehende Protokolldatei zeitgestempelt wird und der Zeitstempel in
die neue Protokolldatei eingetragen wird.
10 openLog 1 Präfix einer aktuellen EVG-Protokolldatei.
11 timestamped- 1 Präfix einer zeitgestempelten EVG-Protokolldatei.
Log
14 dataFile 1 Dateinamensanhang der EVG-Protokolldatei.
15 indexFile 1 Dateinamensanhang einer Indexdatei.
16 timestampFile 1 Dateinamensanhang einer zeitgestempelten EVG-Protokolldatei.
23 periodMillis 2 Zeitdauer in Millisekunden, nach der die Protokolldatei rolliert wird.
25 openLogFileSi- 1 Maximale Dateigröße einer EVG-Protokolldatei.
Seite 22 von 94
AuthentiDate
V3.0

ze
26- 1 Zeitstempeldienst, bei dem die Zeitstempel für die EVG-
39 Protokolldateien eingeholt werden.
40 digestAlgo- 1 Hashalgorithmus für die Zeitstempel der EVG-Protokolldateien.
rithmNameO-
rOID
41 requestRetry- 1 Anzahl der Versuche, den Zeitstempeldienst zu erreichen. Kann der
Limit Dienst nicht erreicht werden, wird der SLMBC-Dienst abgebrochen.
46 logLevel 1 Stellt den Detailgrad für alle Empfänger von Ereignismeldungen ein.
Unterstützte Werte sind in der folgenden Tabelle erklärt.
• EVG_ALL - Alle Ereignismeldungen werden weitergereicht.
• EVG_1 - Die Meldung der nachfolgend genannten Detail-
grade und Meldungen zur Fehlerfindung innerhalb SLMBC
werden zur Aufzeichnung an die Empfänger weitergereicht.
• EVG_2 - Meldungen der nachfolgend genannten Detailgrade
und Meldungen mit nennenswerten, aber normalem Informa-
tionsgehalt werden zur Aufzeichnung an die Empfänger wei-
tergereicht.
• EVG_3 - Meldungen der nachfolgend genannten Detailgrade
und Meldungen, die vor nicht unbedingt fehlerhaften aber
potentiell fehlerhaften Ereignissen warnen, werden zur Auf-
zeichnung an die Empfänger weitergereicht.
• (ERROR) - Meldungen der nachfolgend genannten Detail-
grade und Fehlermeldungen werden zur Aufzeichnung an
die Empfänger weitergereicht.
• (FATAL) - Nur Meldungen über Ereignisse, die die Funktion
SLMBC (nahezu) unmöglich machen, werden zur Aufzeich-
nung an die Empfänger weitergereicht.
• EVG_NONE - Keine Meldung wird an die Empfänger weiter-
gereicht.
49 fileName 1 Benennt die Datei, in der die Ereignismeldungen eingetragen werden
sollen.
Tabelle 7: Parameter des XML-Elements <evgLogging>
2.1.5 Element <weakProcessBoundEnvironment>
Mit dem Element <weakProcessBoundEnvironment> wird die Art der Prozessbindung konfigu-
riert (siehe Kapitel 3.1.1.3 „Funktion F1Sign“).
01 <weakProcessBoundEnvironment>true</weakProcessBoundEnvironment>

1 weakProcessBoundEnvironment 1 Durch den Parameterwert „true“ wird die schwache
Prozessbindung, durch den Parameterwert „false“ wird
die starke Prozessbindung aktiviert.
Tabelle 8: Parameter des XML-Elements <weakProcessBoundEnvironment>
Seite 23 von 94
AuthentiDate
V3.0
2.1.6 Element <knownAttributeOid>
Mit dem Elementen <knownAttributeOid> werden die OIDs (Object Identifier) definiert, mit de-
nen die Eigenschaften der Attribute eines Zertifikates beschrieben werden. Dieses Element
kann mehrfach vorkommen.
01 <knownAttributeOid>
02 <oid>0.2.262.1.10.7.52</oid>
03 <name>LiabilityText</name>
04 <restriction>true</restriction>
05 </knownAttributeOid>

2 oid 2 Benennt die OID, den Schlüssel des Attributstyps.
3 name 2 Bezeichnet den Attributtyp.
4 restriction 2 Bestimmt, ob das Attribut beschränkender oder erweiternder Art ist.
Tabelle 9: Parameter des XML-Elements <knownAttributeOid>
2.1.7 Element <authenticationPolicies>
Mit dem Element <authenticationPolicies> werden einerseits die maximalen Wiederholungsver-

suche zur Authentisierung und Autorisierung festgelegt, andererseits die Anforderungen an die
Passworte für die Benutzerauthentifikation. Letzteres betrifft sowohl die HTTP-Authentifikation,
als auch die Benutzerauthentifikation für die Funktionen F1 und F2.
01 <authenticationPolicies>
02 <maxTryLimit>
03 <maxTryLimitForAuthentication>3</maxTryLimitForAuthentication>
04 <maxTryLimitForInformation>5</maxTryLimitForInformation>
05 <maxTryLimitForAuthorization>3</maxTryLimitForAuthorization>
06 </maxTryLimit>
07 <passwordPolicy>
08 <requiredPasswordLength>10</requiredPasswordLength>
09 <requiredDigitNumbers>3</requiredDigitNumbers>
10 <requiredSpecialChars>2</requiredSpecialChars>
11 <requiredUniqueChars>5</requiredUniqueChars>
12 </passwordPolicy>
13 </authenticationPolicies>

3 maxTryLimitFo- 2 Bei entsprechend häufiger Anzahl fehlerhafter Authentifikations-
rAuthentication versuche des Benutzers lässt SLMBC keine weitere Anmeldung
des Benutzers zu.
4 maxTryLimitFo- 2 Bei entsprechend häufiger Anzahl fehlerhafter Autorisierungsver-
rInformation suche des Benutzers für die Funktion F9 lässt SLMBC keine wei-
tere Anmeldung des Benutzers zu.
5 maxTryLimitFo- 2 Bei entsprechend häufiger Anzahl fehlerhafter Autorisierungsver-
rAuthorization suche des Benutzers lässt SLMBC keine weitere Anmeldung des
Benutzers zu. Dies ist der Fall, wenn der Benutzer zwar bekannt
ist, aber für die gewählte Funktion nicht zugelassen ist.
8 requiredPass- 2 Länge der Passworte für die HTTP-Authentifikation und die Be-
wordLength nutzerauthentifikation für F1 und F2.
9 requiredDigit- 2 Anzahl der Ziffern im Passwort.
Numbers
Seite 24 von 94
AuthentiDate
V3.0

10 requiredSpecial- 2 Anzahl der Sonderzeichen im Passwort.
Chars
11 requiredUnique- 2 Anzahl der Buchstaben im Passwort.
Chars
Tabelle 10: Parameter des XML-Elements <authenticationPolicies>
2.1.8 Element <license>
Mit dem Element <license> wird der Pfad zu den zum Betrieb des SLMBC erforderlichen Li-
zenzdateien festgelegt.
01 <license>
02 <licenseFile>config/license.xml</licenseFile>
03 <counterFile>config/counter.xml</counterFile>
04 </license>

2 licenseFile 1 Gibt den Dateinamen der Lizenzdatei an. Diese Datei wird nur lesend
benutzt.
3 counterFile 1 Gibt den Dateinamen der Zähldatei an. Diese Datei wird lesend und
schreibend benutzt.
Tabelle 11: Parameter des XML-Elements <license>
2.1.9 Element <xmlProtocolHandlerPool>
Das Element <xmlProtocolHandlerPool> besteht aus den Einstellungen für die Anzahl der vor-
gefertigten XML-Parserobjekte, den Zugangsüberprüfungen der einzelnen Funktionen (Element
<accessAA>) und den <implementationMap>-Elementen, die die einzelnen Funktionen darstel-
len. Details, die über die unten genannte Information hinausgehen, sind in den XML-Schema-
dateien zu finden; die Elemente dürfen nicht verändert werden.
01 <xmlProtocolHandlerPool>
02 <numHandlers>10</numHandlers>
03 <xmlConverterPool>
04 <numberOfInstances>10</numberOfInstances>
05 <namespacePrefixMapperClassName>
06 de.authentidate.sir.NamespacePrefixMapperImpl
07 </namespacePrefixMapperClassName>
08 <contextName>
09 de.authentidate.xml.ns.datastruct.slmbc.functions</contextName>
10 </xmlConverterPool>
11 <xmlProtocolHandler>
12 <maxRequestSize>102400</maxRequestSize>
13 ...

2 numHandlers 3 Bestimmt die Anzahl der nach außen sichtbaren Schnittstellen-
Threads.
4 numberOfInstances 3 Bestimmt die Anzahl der XML-Parserobjekte. Sollte immer grö-
ßer oder gleich der Anzahl der Schnittstellen (Zeile 2) sein.
12 maxRequestSize 3 Benennt die maximale Größe der Anfrage in Bytes für den Zugriff
Seite 25 von 94
AuthentiDate
V3.0

auf die SLMBC-Schnittstelle.
Tabelle 12: Parameter des XML-Elements <xmlProtocolHandlerPool>
Das Element <xmlProtocolHandlerPool> ist hier noch nicht beendet, sondern wird in den nächs-
ten Abschnitten weiter beschrieben.
2.1.9.1 Element <accessAA>
Das Element <accessAA> steuert die Zugriffskontrolle der Benutzer auf die einzelnen Funktio-
nen der SLMBC-Schnittstelle.
Die hier konfigurierten User (Benutzer) erhalten Zugriff auf die konfigurierten Funktionen der
SLMBC-Schnittstelle. Bei einem Aufruf der Schnittstelle wird der Benutzer (Software-
Applikation) gegenüber SLMBC mittels Basic Authentication des HTTP-Requests authentifiziert.
Dabei werden der übergebene Benutzername und sein Passwort mit den hier konfigurierten
Werten verglichen. Nur bei Identität beider Werte führt SLMBC die Funktion im Namen des Be-
nutzers aus (siehe Kapitel 2.3 „Nebenkonfiguration Benutzer“). Das Kennwort wird während der
Kommunikation durch das SSL-Protokoll geschützt.
01 <accessAA>
02 <userAAServiceDef id="accessUaa">
03 <memoryUserAAService>
04 <userAAData>
05 <userId>User01</userId>
06 <secretFingerprint>
07 <hashAlgo>SHA-1</hashAlgo>
08 <hashValue>vQaWv3QA0oXH/t3wYlmYynqPDe8=</hashValue>
09 </secretFingerprint>
10
11 <authorization>
12 <thing>F1</thing>
13 <limit> - </limit>
14 </authorization>
15
16 <authorization>
17 <thing>F2</thing>
18 <limit> - </limit>
19 </authorization>
20 ...

05 userId 1 Benutzername im HTTP-Request Objekt
07 hashAlgo 1 Name des verwendeten Hash-Algorithmus
08 hashValue 1 Hashwert des Passwortes
12 thing 1 Kurzbezeichnung der Funktion
Tabelle 13: Parameter des XML-Elements <accessAA>
Seite 26 von 94
AuthentiDate
V3.0
2.1.9.2 Element <implementationMap> F1SignRequest
Das Element <implementationMap> beinhaltet das Element <signingRequestHandlerConfig>,

mit der die Funktion F1SignReqest konfiguriert wird.
01 <signingRequestHandlerConfig>
02 <maxSignRetries>2</maxSignRetries>
03 <retryTimeoutMillis>7000</retryTimeoutMillis>
04 <activationMode>onRequest</activationMode>
05 <supportedSignAlgo>SHA1withRSA</supportedSignAlgo>
06 <supportedSignAlgo>RIPEMD160withRSA</supportedSignAlgo>
07 <signServiceTemplateFileName>
08 signServiceTemplate.xml</signServiceTemplateFileName>
09
10 <signingOpLimitations>
11 <activationPeriod>0</activationPeriod>
12 <signatureOpLimitDuringActivationPeriod>
13 0</signatureOpLimitDuringActivationPeriod>
14 </signingOpLimitations>
15
16 <timestampAccess>
17 <contentTimestampSource includeTimestampAsDefault="false">
18 <timestampAccount>
19 <timestampAccountRef>
20 <timestampAccountDefId>tsa01</timestampAccountDefId>
21 </timestampAccountRef>
22 </timestampAccount>
23 <preferredDigestAlgorithm>
24 <digestAlgorithmNameOrOid>SHA-1</digestAlgorithmNameOrOid>
25 </preferredDigestAlgorithm>
27 </contentTimestampSource>
28 <signatureTimestampSource includeTimestampAsDefault="false">
29 <timestampAccount>
30 <timestampAccountRef>
31 <timestampAccountDefId>tsa02</timestampAccountDefId>
32 </timestampAccountRef>
33 </timestampAccount>
34 <preferredDigestAlgorithm>
35 <digestAlgorithmNameOrOid>SHA-1</digestAlgorithmNameOrOid>
36 </preferredDigestAlgorithm>
38 </signatureTimestampSource>
39 </timestampAccess>
40
41 <dynamicConfig>
42 <content>
43 <uriStoredData>file:config/token.xml</uriStoredData>
44 </content>
45 <confirmationSubDir>confirmed</confirmationSubDir>
46 <certPathCertsSubDir>ca-and-root-certs</certPathCertsSubDir>
47 <userAFileName>user.xml</userAFileName>
48 <reconfigPeriod>
50 general metronome factory</metronomeFactoryName>
51 <threadName>ConfigWatchdog</threadName>
53 </reconfigPeriod>
54 <tokenJobWorkerPeriod>
Seite 27 von 94
AuthentiDate
V3.0
56 general metronome factory</metronomeFactoryName>
57 <threadName>TokenJobManager/Worker</threadName>
59 </tokenJobWorkerPeriod>
60 <terminalInitMessage>Geraet gefunden</terminalInitMessage>
61 </dynamicConfig>
62
63 <commonGroupConfig>
64 <unmappedSignerFoundMessage>
65 : Signaturkarte ist keiner Gruppe zugeordnet
66 </unmappedSignerFoundMessage>
67 <groupIdDigestAlgo>
68 <algorithmName>SHA-1</algorithmName>
69 <requestedSecurityProvider>BC</requestedSecurityProvider>
70 </groupIdDigestAlgo>
71 </commonGroupConfig>
72
73 <ocfConfig>
74 <property>
75 <key>OpenCard.services</key>
76 <value>de.telesec.opencard.tcos20.
77 service.TCOS2CardServiceFactory</value>
78 </property>
79 <property>
80 <key>KOBIL.baudrate</key>
81 <value>57600</value>
82 </property>
83 <property>
84 <key>OpenCard.trace</key>
85 <value>opencard:5 de:5 com:5</value>
86 </property>
87 <property>
88 <key>OpenCard.trace.eventsOnly</key>
89 <value>true</value>
90 </property>
91 </ocfConfig>
92 </signingRequestHandlerConfig>

2 maxSignRetries 1 Mit der Einstellung wird die Anzahl der Versuche bestimmt,
falls bei der Signaturerstellung ein temporärer Fehler auf-
trat.
3 retryTimeoutMillis 1 Mit der Einstellung wird die Zeitspanne zwischen zwei Ver-
suchen in Millisekunden angegeben.
4 activationMode 1 Mit der Einstellung wird bestimmt, wann die PIN-Eingabe
für eine Signaturkarte abgefragt wird.
Bei der Einstellung „onRequest“ wird die PIN-Eingabe nach
jeder Auftragserstellung aktiviert.
Bei der Einstellung „immediately“ wird die PIN-Eingabe
direkt nach der Erkennung einer Karte im Kartenleser akti-
viert. Dies kann nur bei der starken Prozessbindung genutzt
werden.
5 supportedSignAlgo 1 Mit der Einstellung werden die von SLMBC unterstützten
Signatur-Algorithmen angeben, entweder als OID oder als
Java-Name des Algorithmus. Zu beachten ist, dass nur
Algorithmen angegeben werden sollten, die auch von Sig-
naturkarten verwendet werden können.
Seite 28 von 94
AuthentiDate
V3.0

Bitte beachten Sie: Bei der Integration des SLMBC als
technische Komponente für Zertifizierungsdienste müssen
diese Hinweise vom Hersteller der Anwendung („Integra-
tor“) an die Endbenutzer dieser Anwendung weitergegeben
werden.
11 activationPeriod 2 Mit der Einstellung wird die Zeit pro Kartenaktivierung ein-
gestellt. D.h. nach Aktivierung einer Signaturkarte bleibt
diese maximal n Sekunden frei geschaltet.
12 signatureOpLimitDuring 2 Mit der Einstellung wird die Anzahl der Signaturen pro Kar-
ActivationPeriod tenaktivierung eingestellt. D.h. nach Aktivierung einer Sig-
naturkarte bleibt diese maximal n Signaturen lang frei ge-
schaltet.
17 contentTimestamp 1 Wird diese Einstellung auf „true“ gesetzt, so wird der zu
Source signierende Inhalt mit einem Zeitstempel versehen und als
signiertes Attribut in die Signatur eingebettet.
20 timestampAccount 1 Dies ist eine Referenz auf ein Zeitstempel-Element (siehe
DefId Kapitel 2.1.2 „Element <clientNetworkAccessParameter>“),
das für die Zeitstempelanfrage genutzt werden soll.
24 digestAlgorithmName 1 Mit der Einstellung wird der Algorithmus für die Zeitstem-
OrOid pelanfrage festgelegt.
26 requestRetryLimit 1 Mit der Einstellung wird die Anzahl der Wiederholungen für
die Zeitstempelanfrage eingestellt.
28 signatureTimestamp 1 Wird diese Einstellung auf „true“ gesetzt, wird der signierte
Source Inhalt mit einem Zeitstempel versehen und als unsigniertes
Attribut in die Signatur eingebettet.
31 timestampAccount 1 Dies ist eine Referenz auf ein Zeitstempel-Element (siehe
DefId Kapitel 2.1.2 „Element <clientNetworkAccessParameter>“),
das für die Zeitstempelanfrage genutzt werden soll.
35 digestAlgorithmName 1 Mit der Einstellung wird der Algorithmus für die Zeitstem-
OrOid pelanfrage festgelegt.
37 requestRetryLimit 1 Mit der Einstellung wird die Anzahl der Wiederholungen für
die Zeitstempelanfrage eingestellt.
43 uriStoredData 3 Mit der Einstellung wird die Nebenkonfigurationsdatei für
die Kartenleser angegeben. Im selben Verzeichnis müssen
sich auch die Konfigurationen für die Gruppen befinden.
45 confirmationSubDir 3 Mit der Einstellung wird das Unterverzeichnis benannt, in
das Änderungen der Nebenkonfigurationsdateien protokol-
liert werden.
46 certPathCertsSubDir 3 Mit der Einstellung wird das Unterverzeichnis pro Gruppe
benannt, in dem die CA- und Root-Zertifikate der jeweiligen
Gruppe abgelegt werden.
47 userAFileName 3 Mit der Einstellung wird die Nebenkonfigurationsdatei pro
Gruppe benannt, in der die Benutzer definiert werden, die
auf diese Gruppe zugreifen können.
52 periodMillis 2 Mit der Einstellung wird die Zeitspanne in Millisekunden
angegeben, nach der die Konfigurationsdatei neu eingele-
sen wird.
60 terminalInitMessage 1 Mit der Einstellung wird der Text angegeben, der nach der
Erkennung eines Kartenlesers auf dessen Display ausge-
geben wird.
64 unmappedSignerFound 1 Mit der Einstellung wird der Text angegeben, der auf dem
Message Display des Kartenlesers ausgegeben wird, falls eine einge-
legt Signaturkarte keiner Gruppe zugeordnet werden kann.
68 algorithmName 2 Mit der Einstellung wird der Name des Algorithmus be-
stimmt, der zur Bildung des Gruppen-Hashwertes genom-
men wird.
Seite 29 von 94
AuthentiDate
V3.0

69 requestedSecurity 3 Mit der Einstellung wird der Security Provider für den o. g.
Provider Algorithmus bestimmt.
73 … ocfConfig 3 Mit diesen Einstellungen werden die OCF-Daten (Open
Card Framework) konfiguriert.
Tabelle 14: Parameter des XML-Elements <F1SignRequest>
2.1.9.3 Element <implementationMap> F2VerifyRequest
Das Element <implementationMap> beinhaltet das Element <validatorConfig>, mit der die
Funktion F2VerifyRequest konfiguriert werden kann.
01 <validatorConfig>
02 <certPathValidator>
03 <caches>
04 <persistentCacheDir>/persistentCache</persistentCacheDir>
05 <validatedCertPathCache>
06 <cacheUnits>30</cacheUnits>
07 <toleranceUnits>5</toleranceUnits>
08 <validationModel>chain</validationModel>
09 <garbageCollectionPeriod>600000</garbageCollectionPeriod>
10 </validatedCertPathCache>
11 </caches>
12
13 <trustAnchors>
14 <trustAnchor>
15 <certFile>trustAnchorCerts/RegTP/4R-CA.pem</certFile>
16 <qualified>true</qualified>
17 <public>true</public>
18 </trustAnchor>
19 <trustAnchor>
20 <certFile>trustAnchorCerts/RegTP/5R-CA.pem</certFile>
21 <qualified>true</qualified>
22 <public>true</public>
23 </trustAnchor>
24 </trustAnchors>
25
26 <certSelectors>
27 <certSelector>
28 <name>von RegTP ausgestellte Zertifikate</name>
29 <issuerStartsWith>O=Bundesnetzagentur,C=DE</issuerStartsWith>
30 </certSelector>
31 <certSelector>
32 <name>von TeleSec ausgestellte Zertifikate</name>
33 <issuerStartsWith>O=Deutsche Telekom AG,C=DE</issuerStartsWith>
34 </certSelector>
35 </certSelectors>
36
37 <certStatusSources>
38 <certStatusSource>
39 <resourceName>ALTE anonymous PKD der RegTP</resourceName>
40 <active>true</active>
41 <certStatusResourceReference>
42 <aPkdFile>
43 <url>file:persistentCache/anonymous PKD der
44 RegTP/aPkdFile.ttp</url>
Seite 30 von 94
AuthentiDate
V3.0
45 <cachePersistently>false</cachePersistently>
46 <downloadPeriod>86700</downloadPeriod>
47 </aPkdFile>
48 </certStatusResourceReference>
49 <certSelectorRef>von RegTP ausgestellte
50 Zertifikate</certSelectorRef>
51 <issuerStartsWith>O=Regulierungsbeh\C3\B6rde f\C3\BCr
52 Telekommunikation und Post,C=DE</issuerStartsWith>
53 </certStatusSource>
54
55 <certStatusSource>
56 <resourceName>OCSP Server der Bundesnetzagentur</resourceName>
57 <active>true</active>
58 <certStatusResourceReference>
59 <ocspResponder>
60 <url>http://ocsp.nrca-ds.de:8080/ocsp-ocspresponder</url>
61 <substituteThisUpdateByProducedAt>true
62 </substituteThisUpdateByProducedAt>
63 <unknownInfoAction>RegTP</unknownInfoAction>
64 </ocspResponder>
65 </certStatusResourceReference>
66 <certSelectorRef>von RegTP
67 ausgestellte Zertifikate</certSelectorRef>
68 <issuerStartsWith>O=Bundesnetzagentur,C=DE</issuerStartsWith>
69 </certStatusSource>
70 </certStatusSources>
71
72 <validationModel>chain</validationModel>
73 </certPathValidator>
74
75 <algorithmAssessor>
76 <memoryAlgorithmAssessor>
77 <warningPeriodMillis>31536000000</warningPeriodMillis>
78 <algorithmExpiration>
79 <oid>1.2.840.113549.1.1.5</oid>
80 <paramSpec>1024</paramSpec>
81 <outdatedNotBefore>2008-12-31T23:00:00Z</outdatedNotBefore>
82 </algorithmExpiration>
83 </memoryAlgorithmAssessor>
84 </algorithmAssessor>
85
86 </validatorConfig>

4 persistentCacheDir 3 Bezeichnet ein Verzeichnis im Dateisystem des Rech-
ners, in dem SLMBC selbständig Unterverzeichnisse
und darin Dateien anlegt, um die Ergebnisdateien aus
Abfragen bestimmter Typen von Verzeichnisdiensten
eines oder mehrerer Zertifizierungsdiensteanbieter ab-
zulegen und für den weiteren Gebrauch auch nach ei-
nem Neustart von SLMBC zur Verfügung zu haben.
Benutzt wird dieses Verzeichnis nur für Dateien vom
Typ CRL, PKD und aPKD. Diese Dateien können mitun-
ter mehrere 100 Kilobyte groß sein, und es kann lange
dauern, sie von dem Zertifizierungsdiensteanbieter her-
unter zu laden (Das TrustCenter der BNetzA zum Bei-
spiel scheint nur mit einer geringen Bandbreite an das
Internet angeschlossen zu sein).
Das Element kann weggelassen werden, womit der
Seite 31 von 94
AuthentiDate
V3.0

persistente Cache für diese besonderen Dateitypen
abgeschaltet wird und der Signierdienst sie nicht im
Dateisystem des Rechners ablegt.
Werden Verzeichnisdienste benutzt, bei denen diese
Typen von Dateien herunter geladen werden müssen,
ist dringend angeraten, dieses Verzeichnis anzugeben.
Ansonsten erfordert jeder Neustart des Signierdienstes
ein erneutes Herunterladen der Dateien, und es kann
gegebenenfalls Minuten dauern, bis manche Signaturen
erfolgreich verifiziert werden können.
6 cacheUnits 1 Bezeichnet innerhalb einer Cache-Konfiguration (z. B.
innerhalb des <validatedCertPathCache>-Elements) die
Anzahl der Informationseinheiten, welche in diesem
Cache gehalten werden können. Dabei handelt es sich
nicht um eine fixe, exakte Zahl, sondern einen Wert der
um den Wert von <toleranceUnits> überschritten wer-
den kann. Welchen Hauptspeicherbedarf eine Informa-
tionseinheit hat, ergibt sich aus dem Zweck, für den der
Ergebnispuffer verwendet werden soll.
7 toleranceUnits 1 Gibt innerhalb einer Cache-Konfiguration neben der
Angabe der <cacheUnits> an, um wie viele Informati-
onseinheiten die mit <cacheUnits> bezeichnete Kapazi-
tät des Zwischenpuffers überschritten werden darf,
wenn es der Effizienzsteigerung des Algorithmus zum
Aussortieren älterer Werte aus dem Zwischenpuffer (per
garbage collection) dient.
8 validationModel 3 Bestimmt innerhalb eines <validatedCertPathCache>-
Elements, für welches Validierungsmodell in diesem
Cache Pfade abgelegt werden.
Erlaubt sind die Werte „shell“ für das Schalenmodell
nach PKIX und „chain“ für das Kettenmodell nach deut-
schem Signaturgesetz.
9 garbageCollectionPeriod 2 Nennt innerhalb eines <validatedCertpathCache>-
Elements, in welchen Zeitabständen auf dem Cache
eine Sammlung und Entfernung von überzähligen Ele-
menten durchgeführt werden soll. Der Zeitabstand wird
als ganze Dezimalzahl in Millisekunden angegeben.
Dieser Wert muss positiv sein. Nach Ablauf der hier
genannten Zeit wird der Inhalt des Caches auf die im
Element <cacheUnits> genannten Anzahl von Einheiten
gekürzt, wenn er zum Zeitpunkt des Beginns dieser
Überprüfung mehr Einheiten enthält als die Summe der
Werte der Elemente <cacheUnits> und <tolerance-
Units> angibt.
13 trustAnchors 3 Enthält eine Liste von vertrauenswürdigen Zertifikaten.
Dieses Element ist optional, solange SLMBC nicht zum
Prüfen benutzt wird. Ohne dieses Element stehen die
Routinen zum prüfen nicht zur Verfügung. Es muss in
dieser Liste mindestens ein „trustAnchor“-Element ent-
halten sein.
14, 19 trustAnchor 3 Beschreibt ein Zertifikat, das am Ende einer Zertifikats-
kette zu einer zu prüfenden Signatur stehen darf. Nur
Signaturen, deren Zertifikatspfade an diesen konfigu-
rierten Zertifikaten enden, können erfolgreich geprüft
werden. Hierbei muss es sich um „Root-Zertifikate“
handeln (d. h. selbst signierte, selbst ausgestellte Zerti-
fikate eines Zertifizierungsdiensteanbieters). Für
Deutschland stellt die Bundesnetzagentur (BNetzA),
Seite 32 von 94
AuthentiDate
V3.0

ehemals Regulierungsbehörde für Telekommunikation
und Post (RegTP), alleinig die Root-Zertifikate aus,
welche zu Zertifikatspfaden für qualifizierte Signaturen
gehören (siehe http://www.nrca-ds.de). Allerdings er-
laubt es der Signierdienst nicht nur qualifizierte, sondern
auch lediglich fortgeschrittene Signaturen zu prüfen, so
dass neben den Root-Zertifikaten der BNetzA auch
andere Root-Zertifikate („Wurzelzertifikate“) konfiguriert
sein können.
15, 20 certFile 3 Benennt den Namen einer Datei, in der ein Zertifikat
enthalten ist. Diese Datei darf entweder das Zertifikat
binär oder im PEM-Format enthalten. Auch das von der
T-TeleSec erzeugte Format mit der Dateiendung „dat“
wird akzeptiert. Die Datei muss jedoch immer ein
Schlüsselzertifikat enthalten, welches mit seinem eige-
nen öffentlichen Schlüssel verifiziert werden kann. Die-
se Datei ist auf dem Rechner besonders vor schreiben-
den Zugriffen oder Ersetzung durch Unbefugte zu
schützen.
16, 21 qualified 3 Enthält ein Kennzeichen, das besagt, ob alle Zertifikats-
pfade, die bei dem zugehörigen Wurzelzertifikat enden,
ausschließlich qualifizierte Zertifikate enthalten. Nur
zwei Werte sind erlaubt, „true“ und „false“. Nur der Wert
„true“ besagt, dass dies der Fall ist.
17, 22 public 3 Enthält einen Wahrheitswert „true“ oder „false“, der aus-
sagt, ob das Zertifikat des Elements <trustAnchor>, in
dem er sich befindet, öffentlich verfügbar ist. Ein Wur-
zelzertifikat ist in diesem Sinne öffentlich verfügbar,
wenn jeder es erhalten kann und nicht nur eine einge-
schränkte Personengruppe. Wurzelzertifikate sollten
aus Gründen der Sicherheit prinzipiell veröffentlicht
werden.
28 certSelectors 3 Enthält eine Liste von Elementen, von denen jedes eine
Zuordnung zwischen einer Zertifikatsquelle (Verzeich-
nisdienst eines Zertifizierungsdiensteanbieters) oder
einer Statusquelle zu Zertifikaten (Auskunftsdienst eines
Zertifizierungsdiensteanbieters, z. B. OCSP) zu einer
Menge von Zertifikaten vornimmt. Diese Liste von Zu-
ordnungen ist notwendig, wenn auch Zertifikate verifi-
ziert werden sollen, die nicht in sich selbst die Informa-
tion bereitstellen, wo ihre Statusinformationen verfügbar
sind.
Sie ist auch notwendig, wenn Signaturen verifiziert wer-
den sollen, die keine Zertifikate enthalten. (Bei manchen
Massensignaturen, v. a. bei solchen, die alle vom sel-
ben Unterzeichner oder einer Gruppe von Unterzeich-
nern erstellt wurden und an derselben Stelle gespei-
chert werden, sind in die Signaturcontainer selbst keine
Zertifikate beigelegt, um somit Speicherplatz zu spa-
ren.) Erst über solche Zuordnungen lassen sich die zur
Prüfung notwendigen Zertifikate effizient beim Ver-
zeichnisdienst von Zertifizierungsdiensteanbietern er-
fragen.
Dieses Element ist optional. Wird es nicht in der Konfi-
guration aufgeführt, können nur Signaturen verifiziert
werden, die entweder alle dafür notwendigen Zertifikate
enthalten (oder denen diese beim Aufruf der Prüfungs-
routine beigelegt werden) und denen auch die notwen-
Seite 33 von 94
AuthentiDate
V3.0

dige Validierungsinformationen in anderen Parametern
beim Aufruf der Prüfungsroutine beigefügt werden oder
zu denen die Zertifikate die entsprechenden Angaben
enthalten, wie der Verzeichnisdienst und der Auskunfts-
dienst des Zertifizierungsdiensteanbieters verwendet
werden kann.
29, 33 certSelector 3 Stellt eine Zuordnung zwischen einem Verzeichnis-
dienst bzw. einem Auskunftsdienst eines Zertifizie-
rungsdiensteanbieters und einer Menge von Zertifikaten
her. Die Menge von Zertifikaten wird dabei aus der
Menge aller denkbaren Zertifikate gebildet, bei denen
der Name des Ausstellers in einer bestimmten Form
beginnt (bzw. endet).
Eine Zuordnung kann für die Elemente innerhalb des
Elements <certificateSources> für <certStatusSource>-
Elemente erfolgen, wobei diese jeweils dieses Zuord-
nungselementes anhand des Namenselementes refe-
renzieren (siehe <certSelectorRef>).
Zuordnungen müssen auch für nicht mehr aktive Ver-
zeichnis- bzw. Auskunftsdienste eingestellt bleiben,
wenn diese von dem Zertifizierungsdiensteanbieter
abgestellt wurden aber im Nachhinein Signaturen mit
zugehörigen Zertifikatspfaden mit Hilfe von archivierten
Validierungsnachweisen verifiziert werden sollen. Denn
dann wird die Zuordnung der archivierten Validierung-
sinformationen zu den Zertifikaten auf Basis dieser Zu-
ordnungsinformation beschleunigt oder erst möglich
gemacht.
30, 34 name 3 Benennt ein <certSelector>-Element, so dass es von
einem <certStatusSource>-Element oder / und einem in
<certificateSources> enthaltenen Element über diesen
Namen referenziert werden kann. Eine Einschränkung
des erlaubten Zeichensatzes für diese Zeichenkette
besteht nicht. Sie muss lediglich innerhalb des Elemen-
tes <certSelectors> eindeutig sein.
Das sollte sogar bezogen auf die gesamte Konfigurati-
onsdatei gelten (, muss aber nicht).
31, 35 issuerStartsWith 3 Das Element kann als Kindelement zweier verschiede-
ner Elemente vorkommen und hat dort jeweils die glei-
che Syntax, aber unterschiedliche Bedeutung.
Enthält den Anfang (oder das Ende) eines Namens.
Solche Namen werden sowohl binär als auch in Zei-
chenketten dargestellt. Beide Darstellungsformen ent-
halten eine speziell geordnete Sequenz von Namens-
bestandteilen.
Leider werden die Bestandteile bei binärer Darstellung
in genau entgegengesetzter Richtung geschrieben, in
der sie als Zeichenkette notiert werden.
Das erste Teil einer Darstellung als Zeichenkette be-
ginnt mit dem letzten Teil der binären Darstellung. Mit
der Namensgebung des Elementes <issuerStartsWith>
ist der Vergleich des Anfangs der Reihenfolge von Na-
menselementen nach binärer Darstellung des Ausstel-
lernamens gemeint, also der Vergleich des Endes zwei-
er textorienterter Darstellungen.) des Namens des Aus-
stellers von Zertifikaten bzw. des Namens des Ausstel-
lers von Statusinformationen zu Zertifikaten. Welche Art
von Aussteller bezeichnet ist, richtet sich danach, zu
Seite 34 von 94
AuthentiDate
V3.0

welchem Element dieses Element als Kindelement ein-
gesetzt wird. Als Kindelement zu dem Element <certSe-
lector> beschreibt es eine Menge von Zertifikaten, wäh-
rend es als Kindelement zu dem Element <certStatus-
Source> alle Statusinformationen beschreibt, deren
Ausstellername mit dem genannten Namen beginnt.
Die Darstellung des Ausstellernamens innerhalb dieses
Elementes muss nach den Regeln von RFC 2253 erfol-
gen. Sowohl Zertifikate als auch verwertbare Statusin-
formationen zu Zertifikaten sind elektronisch unter-
zeichnet und nennen zwecks Prüfung dieser Unter-
schrift den Namen des Ausstellers.
41 certStatusSources 3 Enthält eine Liste von Diensten, über die Statusinforma-
tionen zu Zertifikaten erfragt werden können. Solche
Statusinformation ist während einer vollen Prüfung einer
Signatur notwendig, um zu erfahren, ob ein Zertifikat zu
einem bestimmten Zeitpunkt nicht zurückgezogen war
bzw. ist.
Dieses Element kann weggelassen werden. Fehlt es, ist
eine vollständige Prüfung von Signaturen nur mit Hilfe
archivierter Validierungsinformationen möglich. Weil in
der Liste enthaltene Quellen inaktiv sein können (siehe
Element <active>), gilt diese Aussage auch, wenn das
Element vorhanden ist, aber alle enthaltenen Quellen
als passiv konfiguriert sind.
42 certStatusSource 3 Benennt eine Quelle mit Statusinformationen zu Zertifi-
katen.
Dieses Element kann mehrfach innerhalb des Elements
<certStatusSource> vorkommen und entweder eine
CRL, eine aPKD oder einen OCSP-Server beschreiben.
44 active 3 Mit dem Wert „true“ innerhalb dieses Feldes wird be-
sagt, ob die Quelle für Statusinformation aktiv benutzt
werden soll. Mit dem Wert „false“ wird diese Quelle
nicht zur Erfragung von Statusinformationen benutzt,
sondern nur um ehemals von ihr stammende, archivier-
te Validierungsinformationen nachträglich den damit zu
validierenden Zertifikaten zuzuordnen.
45 … certStatusResource 3 Kapselt die Konfigurationswerte, welche von der Art und
Reference / oder dem Kommunikationsprotokoll der Informations-
quelle abhängen und daher von Quelle zu Quelle unter-
schiedlich sein kann.
78 validationModel 3 Benennt das Model, mit welchem die Zertifikate einer
Zertifikatskette geprüft werden sollen.
Mögliche Werte sind „chain“ und „shell“, wobei „chain“
für das Kettenmodell nach SigG Verwendung findet.
81 … algorithmAssessor 3 Mit diesen Einstellungen werden die Gültigkeitszeiträu-
me für die hier konfigurierten Algorithmen angegeben.
Neben der Angabe des Typs des Algorithmus wird hier
ggf. die Schlüssellänge des Algorithmus angegeben. Je
nach Einsatzzweck von SLMBC sind diese Daten aus
dem Dokument der geeigneten Algorithmen der BNetzA
zu entnehmen.
Tabelle 15: Parameter des XML-Elements <F2VerifyRequest>
Seite 35 von 94
AuthentiDate
V3.0
2.1.9.4 Element <implementationMap> F3LockRequest
Das Element <implementationMap> beinhaltet das Element <orderBook>, mit der die Funktion
F3LockReqest konfiguriert werden kann.
01 <orderBook>
02 <baseDir>C:/secureDir</baseDir>
03 <baseHttpContext>http://localhost:9080/slmbc-download</baseHttpContext>
04 <helperProgramList>
05 <makeReadOnlyProgram>C:/secureDir/
06 helper-progs/takeOwnership.exe</makeReadOnlyProgram>
07 <checkAccessProgram>C:/secureDir/
08 helper-progs/checkAccess.exe</checkAccessProgram>
09 <makeNonAccessibleProgram>C:/secureDir/
10 helper-progs/revokeAccess.exe</makeNonAccessibleProgram>
11 <makeWorldAccessibleProgram>C:/secureDir/
12 helper-progs/makeWorldAccessible.exe</makeWorldAccessibleProgram>
13 <renameFileOrDirProgram>C:/secureDir/
14 helper-progs/renameFromTo.exe</renameFileOrDirProgram>
15 </helperProgramList>
16 </orderBook>

2 baseDir 1 Mit dem Element wird das Basis-Verzeichnis, auch
sicheres Verzeichnis genannt, eingestellt, in dem die
Aufträge für die Signaturverarbeitung zwischengespei-
chert werden.
3 baseHttpContext 2 Bestimmt den Bestandteil der Basis-URL, unter der
später die Dateien eines Auftrags herunter geladen
werden können.
5 makeReadOnlyProgram 3 Dieses Programm ändert die Verzeichnis- und Datei-
rechte aller Dateien eines Auftrages.
7 checkAccessProgram 3 Dieses Programm überprüft die Benutzerrechte von
Verzeichnissen oder Dateien.
9 makeNonAccessibleProgram 3 Dieses Programm entzieht allen Benutzern außer dem
SLMBC-Benutzer alle Rechte auf Verzeichnisse und
Dateien.
11 makeWorldAccessibleProgram 3 Dieses Programm gibt Verzeichnisse und Dateien für
alle Benutzer wieder frei.
13 renameFileOrDirProgram 3 Dieses Programm verschiebt ein Verzeichnis innerhalb
einer lokalen Partition.
Tabelle 16: Parameter des XML-Elements <F3LockRequest>
2.1.9.5 Element <implementationMap> F5SignFileRequest
Das Element <implementationMap> beinhaltet das Element <fileSignerConfig>, mit der die
Funktion F5SignFileReqest konfiguriert werden kann. Das Element beinhaltet die drei Elemente
<signatureModule>, <listModule> und <deactivateModule>. Da diese Module auf dem gleichen
XML-Schema aufbauen, wird an dieser Stelle die Konfiguration der drei Module nur einmal dar-
gestellt.
01 <fileSignerConfig>
02 <workingThreads>3</workingThreads>
03 <tickInterval>250</tickInterval>
Seite 36 von 94
AuthentiDate
V3.0
04
05 <signatureModule>
06 <httpClientDef>
07 <url>http://localhost:9080/xml</url>
08 <config>
09 <httpClientConfigDef>
10 <authentication>
11 <httpAuthDef>
12 <basicAuthDef>
15 </basicAuthDef>
16 </httpAuthDef>
19 </config>
20 </httpClientDef>
26 <contextName>
27 de.authentidate.xml.ns.datastruct.slmbc.functions
28 </contextName>
30 <nonceGenerator>
31 <randomNumberGenerator>
32 <secureRandomAlgorithm>SHA1PRNG</secureRandomAlgorithm>
33 <bytesForMantissa>16</bytesForMantissa>
34 </randomNumberGenerator>
35 </nonceGenerator>
36 </signatureModule>
37 </fileSignerConfig>

2 workingThreads 2 Bestimmt die Anzahl der Threads, die pro Auftrag Dateien
verarbeiten.
7 url 1 Benennt die URL unter der die entsprechende Funktion des
SLMBC erreicht werden kann (z. B. F1 und F2). In der Regel
wird SLMBC aber auf einem PC betrieben, so dass hier
localhost steht.
13 userName 1 Benennt den Benutzer, der die Funktion F5 gegenüber der
internen Funktion F1 authentifiziert (siehe Kapitel 2.1.9.1
„Element <accessAA>“).
14 password 1 Benennt das Passwort des Benutzers, der die Funktion F5
gegenüber der internen Funktion F1 authentifiziert (siehe
Kapitel 2.1.9.1 „Element <accessAA>“).
22 numberOfInstances 2 Bestimmt die Anzahl der XML-Parserobjekte. Diese sollte
immer größer oder gleich der Anzahl der Schnittstellen (Ab-
schnitt 2.1.9.1, Zeile 2) sein.
Tabelle 17: Parameter des XML-Elements <F5SignFileRequest>
Seite 37 von 94
AuthentiDate
V3.0
2.1.9.6 Element <implementationMap> F6VerifyFileRequest
Das Element <implementationMap> beinhaltet das Element <fileVerifierConfig>, mit der die
Funktion F6VerifyFileReqest konfiguriert werden kann.
01 <fileVerifierConfig>
02 <workingThreads>3</workingThreads>
03 <tickInterval>250</tickInterval>
04
05 <verificationModule>
06 <httpClientDef>
08 <config>
10 <authentication>
11 <httpAuthDef>
12 <basicAuthDef>
15 </basicAuthDef>
16 </httpAuthDef>
19 </config>
20 </httpClientDef>
26 <contextName>
28 </contextName>
30 <nonceGenerator>
36 </verificationModule>
37 </fileVerifierConfig>

2 workingThreads 3 Bestimmt die Anzahl der Threads, die pro Auftrag Dateien verar-
beiten.
7 url 1 Benennt die URL, unter der die entsprechende Funktion des
SLMBC erreicht werden kann (z. B. F1 oder F2). In der Regel
wird SLMBC aber auf einem PC betrieben, so dass hier „local-
host“ steht.
13 userName 1 Benennt den Benutzer, der die Funktion F6 gegenüber der inter-
nen Funktion F2 authentifiziert (siehe Kapitel 2.1.9.1 „Element
<accessAA>“).
14 password 1 Benennt das Passwort des Benutzers der die Funktion F6 ge-
genüber der internen Funktion F2 authentifiziert (siehe Kapitel
2.1.9.1 „Element <accessAA>“).
22 numberOfInstances 2 Bestimmt die Anzahl der XML-Parserobjekte. Diese sollte immer
größer oder gleich der Anzahl der Schnittstellen (Abschnitt
Seite 38 von 94
AuthentiDate
V3.0

2.1.9.1, Zeile 2) sein.
Tabelle 18: Parameter des XML-Elements <F6VerifyFileRequest>
2.1.9.7 Element <implementationMap> F7UnlockRequest
Das Element <implementationMap> für die Funktion F7UnlockReqest bietet keine Konfigurati-
onsmöglichkeiten.
2.1.9.8 Element <implementationMap> F8DeactivateRequest
Das Element <implementationMap> für die Funktion F8DeactivateRequest bietet keine Konfi-
gurationsmöglichkeiten.
2.1.9.9 Element <implementationMap> F9ListRequest
Das Element <implementationMap> beinhaltet das Element <listingRequestHandlerConfig>, mit

dem die Funktion F9ListRequest konfiguriert werden kann.
01 <listingRequestHandlerConfig>
02 <listProxy>
03 <listModule>
04 <httpClientDef>
06 <config>
08 <authentication>
09 <httpAuthDef>
10 <basicAuthDef>
13 </basicAuthDef>
14 </httpAuthDef>
17 </config>
18 </httpClientDef>
24 <contextName>
26 </contextName>
28 <nonceGenerator>
Seite 39 von 94
AuthentiDate
V3.0
34 </listModule>
35 <maxListRetries>3</maxListRetries>
36 <retryTimeoutMillis>10000</retryTimeoutMillis>
37 </listProxy>
38 </listingRequestHandlerConfig>

5 url 1 Benennt die URL, unter der die entsprechende Funktion des
SLMBC erreicht werden kann (z. B. F1 oder F2). In der Regel
wird SLMBC aber auf einem PC betrieben, so dass hier „local-
host“ steht.
11 userName 1 Benennt den Benutzer, der die Funktion F5 gegenüber der inter-
nen Funktion F1 authentifiziert (siehe Kapitel 2.1.9.1 „Element
<accessAA>“).
12 password 1 Benennt das Passwort des Benutzers, der die Funktion F5 ge-
genüber der internen Funktion F1 authentifiziert (siehe Kapitel
2.1.9.1 „Element <accessAA>“).
20 numberOfInstances 2 Bestimmt die Anzahl der XML-Parserobjekte. Diese sollte immer
größer oder gleich der Anzahl der Schnittstellen (Abschnitt
2.1.9.1, Zeile 2) sein.
35 maxListRetries 2 Mit der Einstellung wird die Anzahl der Versuche bestimmt, falls
bei Auflisten ein temporärer Fehler auftrat.
36 retryTimeoutMillis 2 Mit der Einstellung wird die Zeitspanne zwischen zwei Versuchen
in Millisekunden angegeben.
Tabelle 19: Parameter des XML-Elements <F9ListRequest>
2.1.9.10 Element <implementationMap> F10GetStatusRequest
Das Element <implementationMap> für die Funktion F10GetStatusRequest bietet keine Konfi-
2.1.9.11 Element <implementationMap> F12FreezeRequest
Das Element <implementationMap> für die Funktion F12FreezeRequest bietet keine Konfi-
2.1.9.12 Element <implementationMap> F13ThawRequest
Das Element <implementationMap> für die Funktion F13ThawRequest bietet keine Konfi-
2.1.9.13 Element <implementationMap> F14GetURLRequest
Das Element <implementationMap> für die Funktion F14GetURLRequest bietet keine Konfi-
Seite 40 von 94
AuthentiDate
V3.0
2.2 Nebenkonfiguration Chipkartenleser
Damit SLMBC die eindeutige Kontrolle über die angeschlossenen Chipkartenleser übernehmen
kann, müssen diese SLMBC bekannt gemacht werden. Dies geschieht über eine Nebenkonfigu-
rationsdatei, die in der Hauptkonfiguration über das XML-Tag <uriStoredData> im Element
<F1SignRequest> referenziert wird. Der voreingestellte Dateiname ist token.xml.
Alle unterstützen Kartenleser sind innerhalb dieser Datei beispielhaft exemplarisch definiert und
auskommentiert. Zur Integration eines dieser Kartenleser muss lediglich das Anfangszeichen
„“ des Kommentars passend entfernt (bzw. verschoben) werden.
01 <userWrittenTriggerId>1231456711</userWrittenTriggerId>
02
03 
04 

1 userWrit- 1 Wenn zur Laufzeit die Chipkarten- bzw. Gruppenkonfiguration geän-
ten TriggerId dert wird, kann durch simple Veränderung dieser ID SLMBC dazu
veranlasst werden, ohne Neustart die Konfiguration neu auszulesen
und intern neu aufzubauen.
5 ... terminal 1 Mit der Einstellung werden die einzelnen Chipkartenleser definiert.
(nur textuell)
6 config 1 Angabe des sog. OCF-Konfigurationsparameters für den jeweiligen
Chipkartenleser (Terminal). Bei einer Konfiguration sollten Sie immer
auf die von Authentidate vorgefertigten Templates – welche in der
Datei auskommentiert vorhanden sind – zurückgreifen und dort nur die
Schnittstellen-Nummerierung anpassen.
Die einzelnen Bestandteile dieses Parameters sind durch das „|“-
Zeichen getrennt und haben – wenn Sie von links nach rechts gelesen
werden – die folgende Bedeutung:
- Klassenname: Bezeichnung des Java-Klasse, welche zum Zugriff
auf den Chipkartenleser (Terminal) eines Typs verwendet wird.
Dieser Parameter darf nicht verändert werden, sondern muss aus
den Templates und Beispielen der Token-Dateien extrahiert wer-
den.
- CT-API-DLL: Bei Verwendung des CT-API Wrappers wird hier die
Treiber-DLL angegeben, welche verwendet wird um den Kartenle-
ser anzusprechen. Wenn die native OCF-Schnittstelle verwendet
wird, dann darf dieser Parameter nicht verwendet werden.
- Name: Name des OCF-Treibers. Dieser Parameter darf nicht ver-
ändert werden, sondern muss aus den Templates extrahiert wer-
den.
- Type: Typ des OCF-Treibers. Dieser Parameter darf nicht verän-
dert werden, sondern muss aus den Templates extrahiert werden.
- Adresse: Adresse (der Schnittstelle) des OCF-Treibers. Dieser
Wert muss vom Administrator für die jeweilige Schnittstelle ange-
passt werden.
Tabelle 20: Nebenkonfiguration Chipkartenleser
Seite 41 von 94
AuthentiDate
V3.0
2.3 Nebenkonfiguration Benutzer
Der Begriff „Benutzer“ bezieht sich aus Sicht von SLMBC auf die Software-Applikation, die
SLMBC anspricht und die Vorgangsverarbeitung aktiviert. Da SLMBC eine vollständige Signa-
turanwendungskomponente darstellt, ist jede Software, die mit SLMBC kommuniziert als Benut-
zer zu sehen.
Eine natürliche Person, die im Besitz einer Signaturkarte ist, und diese an einem Arbeitsplatz
über ein Chipkartenterminal SLMBC zur Verfügung stellt, ist aus Sicht von SLMBC der Signa-
turkarteninhaber („Anwender“).
SLMBC unterstützt obligatorisch zwei Authentifizierungen, die „Funktionen-Authentifizierung“

der SLMBC-Schnittstelle und die „Gruppen-Authentifizierung“ der Signaturkartengruppen.
Damit ein Benutzer die Funktionen von SLMBC aufrufen kann, wobei hier nicht zwischen exter-
nen (z. B. F3, F5, F6) und internen (z. B. F1, F2) Funktionen unterschieden wird, muss sich
dieser gegenüber der Funktion authentifizieren. Dies wird durch die Basic Authentication im
HTTP-Request realisiert. Beim Aufruf werden im HTTP-Request der Benutzer und das Pass-
wort mitgegeben. Da die Kommunikation über SSL stattfindet, ist die Authentifizierung ver-
schlüsselt. Eine Aufnahme der SSL-Kommunikation ohne Verwendung eines der angebotenen
Algorithmen ist nicht möglich. Die Benutzerdaten für die Funktionen-Authentifizierung werden in
der Hauptkonfigurationsdatei im XML-Tag <accessAA> definiert (siehe Kapitel 2.1.9.1 „Element
<accessAA>“). Dort werden der Benutzername und der Hashwert des Passwortes gespeichert,
damit das Passwort nicht im Klartext hinterlegt wird.
Damit ein Benutzer bei der Erstellung von Signaturen auf einzelne Gruppen von Signaturkarten
zugreifen kann, muss er sich gegenüber der Gruppe authentifizieren. Dies geschieht beim Auf-
ruf einer Funktion, in dem der Benutzername und das Passwort im XML-Anfragedokument mit-
gegeben und diese Werte gegen die Konfigurationsdatei geprüft werden – diese Authentifikati-
on hat nichts mit der Basic Authentication des HTTP-Requests zu tun. Die Benutzer, die die
einzelnen Gruppen ansprechen dürfen, werden für jede Gruppe einzeln in einer XML-Datei ab-
gelegt. Der Dateiname wird in der Hauptkonfigurationsdatei über das XML-Tag <userAFileNa-
me> im Element <F1SignRequest> referenziert. Der vorgegebene Dateiname ist hierbei u-
ser.xml. Diese Datei muss sich im Gruppenverzeichnis befinden. Die Gruppenverzeichnisse
sind Unterverzeichnisse des Verzeichnisses signer-groups.
Achtung: für den Betrieb von SLMBC im signaturgesetzkonformen Umfeld, darf das Benutzer-
passwort auf Clientseite nicht gespeichert werden. Es muss für jeden Auftrag von einem An-
wender eingegeben werden. Ferner ist sicherzustellen, dass nur solche Anwender Benutzer-
passworte eingeben, die auch für die Gruppen der Signaturkarten konfiguriert sind. Auf diese
Weise wird sichergestellt, dass nur Anwender Signaturaufträge erteilen, die auch selbst signa-
turberechtigt sind.
Da mehrere Benutzer für eine Gruppe konfiguriert werden können, kann das unten beschriebe-
ne XML-Tag <userId> mehrfach in der Benutzerdatei vorkommen.
01 <groupUserA>
02 <userId>
03 <name>dummy</name>
04 <passwordFingerprint>
05 <hashAlgo>SHA-1</hashAlgo>
06 <hashValue>cTwdkZIlFT0TSZgkyq/EArD/S8A=</hashValue>
07 </passwordFingerprint>
08 </userId>
09 </groupUserA>
Seite 42 von 94
AuthentiDate
V3.0

3 name 1 Mit der Einstellung wird der Benutzername für eine Gruppe bestimmt.
5 hashAlgo 1 Mit der Einstellung wird der Hash-Algorithmus für das Passwort des Be-
nutzers eingestellt.
6 hashValue 1 Mit der Einstellung wird der Hashwert des Benutzerpasswortes eingestellt
(siehe Kapitel 2.3.1 „Hashwerte für Benutzerpasswörter“).
Tabelle 21: Nebenkonfiguration Benutzer
Auch hier werden der Benutzername und der Hashwert des Passwortes gespeichert, damit das
Passwort nicht im Klartext hinterlegt wird.
2.3.1 Hashwerte für Benutzerpasswörter
Damit die einzelnen Passwörter für die Benutzer der Funktionen bzw. der Gruppen nicht im
Klartext in den Konfigurationsdateien abgelegt werden, werden die Passwörter dort in Form
ihrer Hashwerte gespeichert. Der Benutzer (Software-Applikation) gibt beim Funktionsaufruf
den Benutzer und das Passwort als Parameter mit (Basic Authentication für die Funktionen-
Authentifizierung bzw. das XML-Tag <requestorIdentifier> für die Gruppen-Authentifizierung der
Signaturkarten).
Die Kommunikation findet über SSL statt, so dass bei der Übertragung keine unverschlüsselten
Daten ausgelesen werden können. SLMBC berechnet intern den Hashwert des übergebenen
Passwortes und vergleicht diesen mit dem Wert aus der Konfigurationsdatei bzw. Benutzerda-
tei. Erst bei Gleichheit ist der Benutzer berechtigt, die Gruppe anzusprechen.
AuthentiDate bietet ein Hilfsprogramm zur sicheren Eingabe von Passwörtern und zur Erzeu-
gung von Hashwerten an. Dieses liegt in dem Verzeichnis \tools\PasswortFP\ unterhalb
des Installationsverzeichnisses als Java-Programm passwordFP.jar vor.
Das Programm wird durch den Aufruf java –jar passwordFP.jar gestartet und präsentiert
sich mit der folgenden Oberfläche.
Seite 43 von 94
AuthentiDate
V3.0
Abbildung 3: Benutzerkennwörter Startdialog
Durch Klick auf „Kennwort sicher eingeben“ wird ein Dialog gestartet, der durch die Bewegung
der Maus Zufallszahlen für die nächsten Berechnungen erzeugt. Wenn genug Zahlen berechnet
wurden (und nur dann), kann durch „Ok“ fortgefahren werden.
Abbildung 4: Benutzerkennwörter Zufallszahlen
Seite 44 von 94
AuthentiDate
V3.0
Der nächste Dialog erstellt durch zufällige Anordnung der Tasten eine virtuelle Tastatur auf dem
Bildschirm. Durch den Mausklick auf die einzelnen Buchstaben und Zeichen kann das Kennwort
eingegeben werden. Wenn es den Sicherheitsanforderungen genügt, kann der Dialog fortge-
setzt werden.
Abbildung 5: Benutzerkennwörter Eingabe
Nach Auswahl des Signaturalgorithmus wird das Ergebnis der Berechnungen angezeigt. In der
unteren Textbox wird dabei ein exemplarisches XML-Tag für die Benutzerdatei user.xml ange-
geben, der nach Angabe des Benutzernamens in dieser Form in die Benutzerdatei kopiert wer-
den kann.
In der mittleren Textbox wird der Hashwert des Passwortes in der Base64-Kodierung angezeigt,
der dann in das XML-Tag für die Authentifizierung der Funktionsaufrufe kopiert werden kann.
Es ist zu beachten, dass das Kennwort nicht zwischengespeichert und erst recht nicht ange-
zeigt wird. Nur so kann gewährleistet werden, dass kein Trojaner die Daten ausspähen und
weiterleiten kann.
Bitte beachten Sie: Bei der Integration von SLMBC in eine andere Anwendung muss dieser
Hinweis vom Hersteller der Anwendung („Integrator“) an die Endbenutzer dieser Anwendung
weitergegeben werden.
Seite 45 von 94
AuthentiDate
V3.0
Abbildung 6: Benutzerkennwörter Hashwerte
2.4 Nebenkonfiguration Gruppen
Die Signaturkarten werden über Chipkartenterminals angesprochen und sind in Gruppen orga-
nisiert. Jede Signaturkarte ist genau einer Gruppe zugeordnet.
Dadurch wird eine Mandantenfähigkeit erzeugt, mit der z. B. verschiedene Dokumenttypen ver-
schiedenen Mandanten zugeordnet werden können. Durch die Angabe der Gruppe beim Funk-
tionsaufruf an SLMBC, werden die einzelnen Signaturkarten für den Mandanten zur Signaturer-
stellung herangezogen.
Die Zuordnung der Signaturkarten zu Gruppen erfolgt durch das Anlegen von Unterverzeichnis-
sen in den Gruppenverzeichnissen, wie unten beschrieben. Dies kann zur Laufzeit geändert
werden. SLMBC erkennt die Änderung nach Veränderung des Triggerwertes <userWrittenTrig-
gerId> in der Nebenkonfiguration Chipkartenleser automatisch und übernimmt die neue Grup-
pierung nach einer Konsistenz- und Plausibilitätsprüfung (siehe Kapitel 2.2 „Nebenkonfiguration
Chipkartenleser“). Sind die neuen Angaben inkonsistent, wird dies in der Logdatei vermerkt.
SLMBC steht dann solange nicht zur Verfügung, bis die Gruppen wieder konsistent sind.
Die einzelnen Gruppenverzeichnisse müssen sich in dem gleichen Verzeichnis wie die oben
genannte „Nebenkonfiguration Chipkartenleser“ befinden. Das Verzeichnis wird als Konfigurati-
onsverzeichnis für Gruppen von Signaturerstellungseinheiten bezeichnet.
Zu jeder Gruppe enthält das Verzeichnis genau ein Unterverzeichnis, das nachfolgend als
Gruppenverzeichnis bezeichnet wird. Es existieren genau so viele Gruppen wie Unterverzeich-
nisse im Konfigurationsverzeichnis für Gruppen vorhanden sind.
Außer einer einzigen Datei enthält jedes Gruppenverzeichnis sonst ausschließlich weitere Un-
terverzeichnisse. Bei dieser Datei handelt es sich um die Benutzerzuordnung (siehe Kapitel 2.3
Seite 46 von 94
AuthentiDate
V3.0
„Nebenkonfiguration Benutzer“). Dies sind die Benutzer, denen die Gruppe zugeordnet ist. Ver-
schiedene Gruppen können demselben Benutzer zugeordnet sein.
Hauptkonfigurationsdatei
verweist auf
verweist auf
Konfigurationsverzeichnis
für Gruppen von
Signaturerstellungseinheiten Nebenkonfigurationsdatei
Ordner der Gruppe 1
Benutzerzuordnung
Ordner der Signaturerstellungseinheit A
Ordner der Signaturerstellungseinheit B
Ordner mit CA- und Root-Zertifikaten
Ordner der Gruppe 2
Benutzerzuordnung
Ordner der Signaturerstellungseinheit D
Ordner mit CA- und Root-Zertifikaten
Abbildung 7: Gruppenkonfiguration
Jedes Gruppenverzeichnis muss mindestens zwei Unterverzeichnisse haben.

Eines davon muss das Verzeichnis für Zertifikate übergeordneter Zertifizierungsdienste sein,
das in der Abbildung als „Ordner mit CA- und Root-Zertifikaten“ bezeichnet ist. Seine Bedeu-
tung wird später erklärt. Alle anderen Unterverzeichnisse beschreiben jeweils genau eine Sig-
naturerstellungseinheit und ordnen ihr Zertifikate zu. In der Abbildung sind diese als „Ordner der
Signaturerstellungseinheit n“ bezeichnet, wobei n als Platzhalter für „A“ bis „D“ steht. Jedes Un-
terverzeichnis enthält genau ein Zertifikat zum Signaturschlüssel der jeweiligen Signaturerstel-
lungseinheit als eigenständige Datei.
Neben der Datei mit dem Schlüsselzertifikat kann sich eine beliebige Menge weiterer Dateien
befinden. Jede der Dateien muss genau ein Attributzertifikat enthalten, das zum Schlüsselzerti-
fikat gehört. Eine Signaturerstellungseinheit wird anhand ihres Zertifikates zum Signaturschlüs-
sel eindeutig identifiziert. SLMBC setzt voraus, dass nicht zwei verschiedene Signaturerstel-
Seite 47 von 94
AuthentiDate
V3.0
lungseinheiten mit demselben Signaturschlüssel existieren. Er setzt weiterhin voraus, dass jede
Signaturerstellungseinheit das Zertifikat zum Signaturschlüssel enthält bzw. bereitstellt.
Wenn eine Signaturerstellungseinheit für SLMBC verfügbar wird, zum Beispiel weil sie in ein
von ihm verwaltetes Kartenlesegerät eingesteckt wird, erfragt SLMBC zuerst das Zertifikat zum
Signaturschlüssel von der Einheit. SLMBC stellt dann anhand der konfigurierten Schlüsselzerti-
fikate die Zuordnung der Einheit zu einer Gruppe und zu den Attributzertifikaten her. Dabei
muss dasselbe Schlüsselzertifikat in der Konfiguration auffindbar sein. Ist es nicht vorhanden,
wird die Einheit nicht verwendet. Ansonsten ordnet SLMBC die Einheit der Gruppe von Einhei-
ten zu, deren Schlüsselzertifikate in einem Unterverzeichnis desselben Gruppenverzeichnisses
vorhanden sind. Der Name des Gruppenverzeichnisses entspricht dem Namen der Gruppe, wie
er auch durch die Funktion F9 aufgelistet wird.
Verwendet SLMBC eine konkrete Signaturerstellungseinheit zur Erzeugung einer Signatur, so

bindet SLMBC das zugehörige Schlüsselzertifikat und alle konfigurierten zugehörigen Attribut-
zertifikate stets mittels derer Hashwerte in die Signatur ein. Des Weiteren legt SLMBC auf An-
forderung des Benutzers die Zertifikate dem erstellten bzw. modifizierten Signatur-Container
bei. Auf Anforderung des Benutzers legt er dem Signatur-Container auch die zugehörigen Zerti-
fikate übergeordneter Zertifizierungsdienste bei. Diese erhält er aus dem Unterverzeichnis mit
jenen Zertifikaten, das sich im zugeordneten Gruppenverzeichnis befindet.
Eine Beispielkonfiguration für Gruppen könnte folgendermaßen aussehen:
C:\
|- AD_SLMBC_3.0\
|
|- Server\
|
|- config\
|
|- groups\
|
|- token.xml
|- SIRA#1\
|
|- user.xml
|- A-017-3\
|
|- SW_USER-799765596.crt
|- SW_ATTR1-799765593.crt
|- ca-and-root-certs\
|
|- CA-13.cer
|- 6R.cer
2.4.1 Hashwerte für Gruppenkonfigurationen
Dem Signaturkarteninhaber wird vor der Erstellung eines Auftrags die Möglichkeit geboten, sich
alle zugeordneten Signaturerstellungseinheiten einer Signaturgruppe über die Funktion F9List
anzeigen zu lassen. Diese aufgelisteten Komponenten werden von SLMBC für jede Signatur-
gruppe jeweils zu einem eindeutigen Hashwert zusammengefasst, der ebenfalls über den Auf-
ruf von F9List an den Benutzer zurückgereicht wird. Bei der Auftragserstellung wird dieser
Hashwert – neben anderen Auftragsdaten – nun wieder an SLMBC übergeben, welches seiner-
seits die Übereinstimmung des Hashwerts mit dem der zu verwendenden Signaturgruppe er-
Seite 48 von 94
AuthentiDate
V3.0
neut überprüft. Hierdurch stellt SLMBC sicher, dass der Auftrag auch dann ausschließlich mit
der zuvor angezeigten Signaturgruppenkonfiguration ausgeführt wird, wenn zwischen Signatur-
gruppenanzeige und Auftragserstellung ein längerer Zeitraum liegt, in dem die Signaturgrup-
penkonfigurationen sich theoretisch hätte ändern können.
Zusätzlich bietet AuthentiDate ein Hilfsprogramm zur Berechnung von Gruppen-Hashwerten an.
Dieses liegt in dem Verzeichnis \Server\tools unterhalb des Installationsverzeichnisses als
Java-Programm groupFP.jar vor.
Das Hilfsprogramm wird durch den Aufruf java –jar groupFP.jar gestartet und präsentiert
sich mit der folgenden Oberfläche.
Abbildung 8: Startdialog des Hilfsprogramms groupFP
Nach Auswahl eines Gruppenverzeichnisses, hier z. B. SIRA#1, und des Hash-Algorithmus

werden die errechneten Daten angezeigt und können in dieser Form in die XML-Tags für die
Auftragserstellung kopiert werden (siehe Kapitel 3 „SLMBC-Schnittstelle“).
Seite 49 von 94
AuthentiDate
V3.0
Abbildung 9: Berechnung der Gruppen-Hashwerte
Seite 50 von 94
AuthentiDate
V3.0
3 SLMBC-Schnittstelle
Für die massenhafte Erzeugung bzw. Prüfung von Signaturen stellt SLMBC sowohl Schnittstel-
len über TCP als auch über das lokale Dateisystem bereit.
Über das lokale Dateisystem werden die zu signierenden bzw. prüfenden Daten vom Benutzer
(Software-Applikation) an SLMBC übergeben und die signierten Daten bzw. Prüfergebnisse
dem Benutzer von SLMBC zurückgereicht.
Aus Gründen der Sicherheit setzt und kontrolliert SLMBC die Zugriffsrechte auf diese Daten,
um während kritischer Phasen den Zugriff auf die zu verarbeitenden Daten einzuschränken.
SLMBC stellt somit sicher, dass genau die Daten signiert bzw. verifiziert werden, welche der
Benutzer zu diesem Zweck bestimmt hat.
Über das TCP-Protokoll wird dem Benutzer jedoch eine Steuerungsmöglichkeit für seinen Auf-
trag zur Erstellung bzw. Prüfung von Signaturen gegeben. Auch diese Steuerungsmöglichkeit
ist zur Sicherheit eingeschränkt. Sie funktioniert nach einem klar definierten Regelwerk. Diese
Steuerungsmöglichkeit wird durch einzelne Funktionen in Form von Funktionsaufrufen für den
Benutzer bereitgestellt.
Die Aufrufparameter, exakter der Funktionsname und die Parameter, sind vom Benutzer als
XML-Dokument zu formulieren und über die Transportschicht HTTPS an SLMBC zu übergeben.
Der Benutzer hat unabhängig von der aufgerufenen Funktion stets denselben URL zu verwen-
den. SLMBC erkennt die aufgerufene Funktion eindeutig anhand des Wurzelelementes des
übergebenen XML-Dokuments.
SLMBC antwortet ebenfalls mit einem XML-Dokument. In den XML-Antworten werden auch
Zeitwerte als Elemente eingebettet. Sie werden immer sekundengenau und bezogen auf die
Zeitzone UTC (Coordinated Universal Time) dargestellt. UTC wird als Nachfolger der GMT
(Greenwich Mean Time) verwendet. Diese Klärung ist leider notwendig, weil die Datentypen zu
Zeitwerten gemäß XML-Schema mehrdeutige Zeitwerte ohne Angabe einer Zeitzone erlauben.
Während bestimmter Phasen der Bearbeitung seines Auftrages zur Erstellung bzw. Prüfung von
Signaturen kann der Benutzer auch über das TCP-Protokoll lesend auf seine zu verarbeitenden
Daten zugreifen. Diese Schnittstellen werden in den folgenden Abschnitten einzeln erklärt.
Die Schnittstelle von SLMBC basiert, wie bereits erwähnt, auf dem Austausch von XML-
Dokumenten. Diese Dokumente stellen wohlgeformte Dokumente dar, die durch XML-Sche-
mata beschrieben werden. In den nachfolgenden Kapiteln werden die Dokumente im Detail be-
schrieben.
Da jedoch einige XML-Schemata sehr komplexe XML-Subelemente beinhalten, die die Grenzen
dieses Handbuchs sprengen würden, verweisen wir hiermit auf die Schemata-Dateien, die an
die Entwickler mit ausgeliefert werden. Die Dateien befinden sich in dem Verzeichnis
\slmbc\developer\xml-schema\, wobei hierbei zwischen der administrativen Konfiguration
und der Entwickler-Schnittstelle unterschieden wird. Die Schemata des erstgenannten befinden
sich in dem Unterverzeichnis \configuration\ und des letzteren in dem Unterverzeichnis
\interface\.
Die Beispieldokumente inklusive der Beispielprogramme, die verschiedene Auftragsarten um-

setzen, wie z. B. das Erstellen von Signaturen, befinden sich innerhalb des Verzeichnisses
\slmbc\developer.
Seite 51 von 94
AuthentiDate
V3.0
3.1 Einsatzszenarien
Wie bereits in Kapitel 1.2 „Einsatzbereich“ beschrieben, kann SLMBC als vollständige Signatur-
anwendungskomponente (SAK) zum Erstellen bzw. Prüfen von Signaturen betrieben werden.
Die nächsten Abschnitte beschreiben diese Szenarien detaillierter, bevor die einzelnen Funktio-
nen der Schnittstelle dargestellt werden.
3.1.1 Vollständige SAK zur Signaturerstellung
SLMBC kann beim Endkunden als vollständige Signaturanwendungskomponente (SAK) gemäß

SigG / SigV zur Erstellung qualifizierter elektronischer Signaturen betrieben werden.
SLMBC konfiguriert und steuert dabei die unten genannten Funktionen, welche auch in getrenn-
ten Prozessen auf unterschiedlichen Rechnern zur Verfügung gestellt werden können. In der
Regel wird SLMBC aber auf einem Rechner betrieben, so dass die optionale Prozessgrenze
entfällt.
SLMBC
Benutzer SLMBC
(Funktion F3Lock)
(Software-Applikation) (Funktion F1Sign)
(Funktion F5SignFile)
Prozessgrenze optionale
Prozessgrenze
Abbildung 10: Prozessgrenzen bei der Signaturerstellung
3.1.1.1 Funktion F3Lock
Die Funktion F3Lock übernimmt die Kontrolle der Vorgangssteuerung bei der Erzeugung von
Signaturen für Originaldateien (auch Parallelsignaturen) bzw. für Gegensignaturen bei bereits
signierten Dateien.
Hierzu legt F3Lock einen neuen Auftrag im Auftragsbuch an, übernimmt die vom Benutzer
(Software-Applikation) bereitgestellten Dateien und überführt diese nach Aufforderung in ein
sicheres Verzeichnis.
Dabei ist zu beachten, dass der Auftrag noch nicht ausgeführt, sondern nur angelegt wird.
Seite 52 von 94
AuthentiDate
V3.0
3.1.1.2 Funktion F5SignFile
Die Funktion F5SignFile startet dann den eigentlichen Auftrag, erstellt für die zu signierenden
Daten Hashwerte und übergibt diese Hashwerte zusammen mit Steuerungs- und Authentifizie-
rungsinformationen über sichere, definierte Schnittstellen an die interne Funktion F1Sign.
Die Funktion F1Sign erstellt die Signaturen und reicht die Daten an die Funktion F5SignFile
zurück, welche diese im Dateisystem ablegt. Auf Auforderung des Benutzers werden diese Sig-
naturen nach erfolgreicher, kompletter Bearbeitung des Auftrages wieder im Dateisystem frei-
gegeben.
3.1.1.3 Funktion F1Sign
Die Funktion F1Sign übernimmt die Erzeugung der Signaturen. Hierzu hat die Funktion F1Sign
eine Anzahl sicherer Signaturerstellungseinheiten unter ihrer Kontrolle. Diese Signaturerstel-
lungseinheiten können mit Hilfe von Konfigurationsdateien zu Gruppen zusammengefasst wer-
den, welche dann zu einer performanten Erstellung von Signaturen verwendet werden können.
Zusätzlich ist F1Sign in der Lage, Zeitstempel von externen Zeitstempelquellen abzufragen und
in die erzeugten Signaturen zu integrieren.
3.1.2 Vollständige SAK zur Signaturprüfung
SLMBC kann beim Endkunden als vollständige Signaturanwendungskomponente (SAK) gemäß

SigG / SigV zur Prüfung qualifizierter elektronischer Signaturen und qualifizierter elektronischer
Zeitstempel betrieben werden.
SLMBC konfiguriert und steuert dabei die unten genannten Funktionen, welche auch in getrenn-
ten Prozessen auf unterschiedlichen Rechnern zur Verfügung gestellt werden können. In der
Regel wird SLMBC aber auf einem Rechner betrieben, so dass die optionale Prozessgrenze
wegfällt.
SLMBC
Benutzer SLMBC
(Funktion F3Lock)
(Software-Applikation) (Funktion F2Verify)
(Funktion F6VerifyFile)
Prozessgrenze optionale
Prozessgrenze
Abbildung 11: Prozessgrenzen bei der Signaturprüfung
Seite 53 von 94
AuthentiDate
V3.0
3.1.2.1 Funktion F3Lock
Die Funktion F3Lock übernimmt die Kontrolle der Vorgangssteuerung bei der Prüfung von Sig-
naturen bzw. Zeitstempeln für Originaldateien bzw. für Gegensignaturen bei bereits signierten
Dateien.
Hierzu legt F3Lock einen neuen Auftrag im Auftragsbuch an, übernimmt die vom Benutzer
(Software-Applikation) bereitgestellten Dateien und Signaturen bzw. Zeitstempel und überführt
diese nach Aufforderung in ein sicheres Verzeichnis.
Dabei ist zu beachten, dass der Auftrag noch nicht ausgeführt, sondern nur angelegt wird.
3.1.2.2 Funktion F6VerifyFile
Die Funktion F6VerifyFile startet den eigentlichen Auftrag und überführt die Dateien und Signa-
turen bzw. Zeitstempel über sichere, definierte Schnittstellen an die interne Funktion F2Verify.
Die Funktion F2Verify überprüft die Signaturen, Zeitstempel und Unterzeichner und reicht die
Daten an die Funktion F6VerifyFile zurück, welche die Prüfergebnisse im Dateisystem ablegt.
Auf Anforderung des Benutzers werden diese Prüfergebnisse nach erfolgreicher, kompletter
Bearbeitung des Auftrages wieder im Dateisystem freigegeben.
3.1.2.3 Funktion F2Verify
Die Funktion F2Verify übernimmt die Überprüfung von Signaturen, Zeitstempeln und Zertifikats-
ketten. Um diese Aufgabe zu erfüllen, werden neben der Überprüfung der mathematischen Sig-
natur auch die Statusinformationsquellen der entsprechenden Zertifizierungsdiensteanbieter
abgefragt und die erhaltenen Informationen in die Prüfergebnisse integriert.
3.2 F1Sign – Signaturerstellung zu Hashwerten
Mit dem Aufruf der Funktion wird SLMBC veranlasst, eine Signatur mit Hilfe einer beliebigen
Signaturerstellungseinheit aus einer bestimmten Signaturgruppe zu erzeugen.
Unter dem Begriff „Signaturerstellung“ wird hier die sowohl die Erzeugung von Signaturen als
auch die Erzeugung von Parallelsignaturen und Gegensignaturen verstanden.
SLMBC benutzt diese Funktion selbst für die Erstellung einer Signatur zu einer Datei. Im Be-
trieb als vollständige Signaturanwendungskomponente stellt SLMBC die Funktion dem Benut-
zer nicht direkt zur Verfügung. Sie gehört deshalb eigentlich nicht zur externen Schnittstelle.
Dennoch ist sie hier beschrieben, da SLMBC in zwei Teilen betrieben werden kann, eventuell
sogar auf getrennten Rechnern (siehe Kapitel 3.1.1 „Vollständige SAK zur Signaturerstellung“).
Der Zweck dieser Funktion ist es, eine Signatur zu erstellen. Dazu müssen die zu signierenden
Daten mit den Funktionsparametern, also im XML-Dokument eingebettet, oder stellvertretend
durch einen Hashwert übergeben werden. In beiden Fällen wird in den Parametern der zu ver-
wendende Hash-Algorithmus durch den Aufrufenden der Funktion vorgegeben.
Seite 54 von 94
AuthentiDate
V3.0
Die Wirkung des Aufrufes dieser Funktion ist, dass SLMBC veranlasst wird, sofort eine der Sig-
naturerstellungseinheiten der benannten Gruppe zu verwenden und mit ihr eine Signatur zu
erzeugen.
Falls eine Aktivierung der Signaturerstellungseinheit vorher notwendig sein sollte, zeigt SLMBC
dies über die Anzeigen der jeweiligen Chipkarten-Terminals an. Die Aktivierung bleibt gegebe-
nenfalls für weitere Aufrufe dieser Funktion - abhängig von der konfigurierten Prozessbindung -
erhalten.
3.2.1 F1Sign Anfragedokument
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokuments, welches
vom Benutzer (Software-Applikation) an SLMBC gesendet wird.
Haupt-XML-Tag XML-Tag Beschreibung

f1SignRequest nonce Mit diesem Attribut des Tags f1SignRequest wird
dem Aufrufenden die Möglichkeit gegeben, einen
eindeutigen Wert mitzugeben, der in der Antwort
wiedergegeben wird. SLMBC beachtet diesen Wert
selber nicht, er dient nur dem Aufrufenden.
requestorIdentifier name Mit diesem Element wird der Benutzer der Gruppe
authentifiziert. Der Benutzer muss in der Datei „u-
ser.xml“ konfiguriert werden.
password Mit diesem Element wird das Passwort des Grup-
penbenutzers angegeben.
signatureAlgorithm Mit diesem Element wird der Signaturalgorithmus
benannt, mit dem eine Signatur erstellt wird.
Zu Beachten ist, dass erstens die Signaturkarte die-
sen Algorithmus unterstützt und zweitens, falls eine
Zeitstempelanforderung konfiguriert wurde, der mit
angegebene Hash-Algorithmus vom TrustCenter
ebenfalls unterstützt wird.
signerIdentifier groupName Identifiziert den Namen der Gruppe, mit der Signatu-
ren erstellt werden sollen.
groupHash Gibt den Hashwert der zu benutzenden Gruppen an.
signRequestOptions Benennt Optionen, über die die Einzelheiten zur Art
der Signaturerstellung gesteuert werden können.
includeCertificates Legt fest, ob und – wenn ja - welche Zertifikate mit in
die Signatur eingebettet werden sollen.
• noCerts – Mit diesem Parameter werden
keine Zertifikate in die Signatur eingebettet.
• signerCerts – Mit diesem Parameter werden
die Zertifikate des Signaturkarteninhabers in
die Signatur eingebettet.
• certPath – Mit diesem Parameter werden die
Zertifikate des Signaturkarteninhabers und
des Zertifizierungsdiensteanbieters (Karten-
herausgeber) in die Signatur eingebettet.
• certPathWithRoot – Mit diesem Parameter
werden die Zertifikate des Signaturkartenin-
habers, des Zertifizierungsdiensteanbieters
(Kartenherausgeber) und des vertrauens-
würdigen Ankers (Wurzel-Zertifikat) in die
Signatur eingebettet.
Seite 55 von 94
AuthentiDate
V3.0

timeStatements Benennt die Parameter, welche für die Einbettung
von Zeitdaten in die Signatur verwendet werden.
signingTime Benennt die Parameter, welche für die Einbettung
des Zeitpunktes der Signaturerstellung verwendet
werden.
signingTimeAttribute Benennt den Zeitpunkt der Signaturerstellung.
Mit „currentTime“ wird die PC-Zeit übernommen.
Mit „givenTime“ wird die Zeit als Parameter überge-
ben.
signatureTimeStamp Falls der Wert auf „true“ gesetzt wird, wird nach der
Erzeugung der Signatur ein Zeitstempel der Signatur
von einem konfigurierten Zeitstempeldienst angefor-
dert.
Dieser Zeitstempel wird später in die unsignierten
Attribute der Signatur eingefügt.
contentTimeStamp Falls der Wert auf „true“ gesetzt wird, wird vor der
Erzeugung der Signatur ein Zeitstempel des zu sig-
nierenden Inhaltes von einem konfigurierten Zeit-
stempeldienst angefordert.
Dieser Zeitstempel wird später in die signierten Attri-
bute der Signatur eingefügt.
coreRequest Benennt die eigentliche Signierfunktion.
f1SignHashRequest Mit dieser Funktion wird eine neue Signatur zu einem
übergebenen Hashwert erstellt.
Dabei wird der Hashwert und das Signaturformat
(CMS, PKCS#7) übergeben.
f1SignContentRequest Mit dieser Funktion wird eine neue Signatur zu einem
übergebenen binären Datenblock erstellt.
Dabei wird der binäre Datenblock und das Signatur-
format (CMS, PKCS#7) übergeben.
f1ParallelSignRequest Mit dieser Funktion wird eine weitere parallele Signa-
tur zu einem übergebenen Hashwert erstellt.
Dabei wird der Hashwert und das Signaturformat
(CMS, PKCS#7) übergeben. Der Hashwert muss
auch bei Signaturen mit encapsulated Content mit
angegeben werden.
Die Signatur wird über das ursprüngliche Dokument
erstellt und parallel zur vorhandenen abgelegt.
Es ist nicht möglich eine Parallelsignatur mit einem
Signaturschlüssel anzufertigen, für den bereits eine
Signatur im Dokument vorhanden ist.
Der Signierende muss sämtliche Signaturprüfschlüs-
sel im Zugriff haben, für die bereits Signaturen er-
zeugt wurden. Diese können in das Dokument ein-
gebettet sein.
f1CounterSignRequest Mit dieser Funktion wird eine weitere Signatur zu
einer vorhandenen erstellt.
Dabei werden der Hashwert und das Signaturformat
(CMS, PKCS#7) übergeben.
Die Signatur wird nicht über das ursprüngliche Do-
kument, sondern über eine vorhandene Signatur
erstellt und mit der vorhandenen abgelegt.
Tabelle 22: F1Sign Anfragedokument
Seite 56 von 94
AuthentiDate
V3.0
3.2.2 F1Sign Antwortdokument
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokuments, welches
vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.

f1SignResponse producedAt Dieses Attribut enthält die Systemzeit zum Zeitpunkt der Erstel-
lung des XML-Dokuments.
nonce Dieses Attribut kann fehlen. Ist es vorhanden, spiegelt es den
Wert des gleichen Elementes aus der Anfrage. Dieses Attribut
wird immer genau dann gesetzt, wenn auch die Anfrage dieses
Attribut gesetzt hatte.
signatureFormat Benennt das Format der erstellten Signatur.
signatureValue Enthält die erstellte Signatur als Binärwert.
Tabelle 23: F1Sign Antwortdokument
3.2.3 F1Sign Fehlerdokument
Bei der Ausführung der Funktion F1Sign können Fehler auftreten. Einige davon werden in
Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets mit
einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als Wur-
zelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursachen
der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Wert von Bedeutung des Wertes

<code>
1000 Der angeforderte Signaturalgorithmus wird von SLMBC bzw. von den Signaturerstellungs-
einheiten der jeweiligen Gruppe nicht unterstützt.
1001 Zu der bei den Aufrufparametern benannten Gruppe sind derzeit keine Signaturerstel-
lungseinheiten verfügbar, mit denen die angeforderte Signatur erstellt werden könnte. Der
Name der Gruppe wurde nicht gefunden.
1002 Der Name der Gruppe von Signaturerstellungseinheiten wurde zwar in der aktuellen und
dynamischen Konfiguration gefunden, der zur Identifikation der Gruppenzusammensetzung
verwendete Hashwert weicht jedoch von der aktuellen Konfiguration ab. Möglicherweise
wurde eine Signaturerstellungseinheit zur Gruppe hinzugefügt bzw. entfernt.
1003 Der Name der Gruppe von Signaturerstellungseinheiten wurde zwar in der Konfiguration
gefunden, der zur Identifikation der Gruppenzusammensetzung verwendete Hash-
Algorithmus weicht jedoch von dem konfigurierten Wert ab.
1004 Die Signatur kann aufgrund eines aufgetretenen Fehlers nicht erzeugt werden.
1005 Gemäß den Aufrufparametern ist zur Erstellung oder nach Erstellung der Signatur ein Zeit-
stempel einzuholen. Dies ist fehlgeschlagen.
1006 Gemäß den Aufrufparametern ist zur Erstellung oder nach Erstellung der Signatur ein Zeit-
stempel einzuholen. Dies ist fehlgeschlagen, weil der Zeitstempeldienst den erforderlichen
Hash-Algorithmus nicht unterstützt.
1007 Es wurde keine aktive Signaturgruppe gefunden. Eventuell wurde die Signaturkarte nicht
eingelegt.
Tabelle 24: F1Sign Fehlerdokument
Seite 57 von 94
AuthentiDate
V3.0
3.3 F2Verify – Signaturprüfung zu Hashwerten
Mit dem Aufruf der Funktion wird SLMBC veranlasst, eine Signatur – bei Bedarf auch mit Hilfe
von Statusanfragen an Zertifizierungsdiensteanbieter - zu prüfen.
Unter dem Begriff „Signaturprüfung“ wird hier die sowohl die Prüfung von Signaturen als auch
die Prüfung von Parallelsignaturen, Gegensignaturen sowie Zeitstempeln verstanden.
SLMBC benutzt diese Funktion selbst für die Prüfung einer Signatur zu einer Datei. Im Betrieb
als vollständige Signaturanwendungskomponente stellt SLMBC dem Benutzer diese Funktion
nicht direkt zur Verfügung. Sie gehört deshalb eigentlich nicht zur externen Schnittstelle. Den-
noch ist sie hier beschrieben, weil SLMBC in zwei Teilen betrieben werden kann, eventuell so-
gar auf getrennten Rechnern (siehe Kapitel 3.1.2 „Vollständige SAK zur Signaturprüfung“).
Der Zweck der Funktion ist die Prüfung einer Signatur. Hierfür können die signierten Daten mit
den Funktionsparametern, also im XML-Dokument eingebettet, oder stellvertretend durch einen
Hashwert übergeben werden. Sind die signierten Daten in einer dieser beiden Formen angege-
ben, wird ihre kryptographische Bindung zur Signatur mit überprüft. Ansonsten erhält der Be-
nutzer den ehemals signierten Hashwert im Ergebnis der Funktion und kann die Bindung selbst
prüfen.
Die Wirkung des Aufrufes der Funktion ist, dass SLMBC veranlasst wird, sofort die Signatur zu
prüfen. Bei Bedarf wendet SLMBC sich dazu an Verzeichnisdienste und verwendet lokal konfi-
gurierte Vertrauensanker in der Form von Wurzelzertifikaten. Der Bedarf richtet sich nach der
vom Benutzer angeforderten Tiefe der Prüfung und nach den im Cache von SLMBC bereits
vorgefundenen Prüfergebnissen zu vormals geprüften Signaturen und Zertifikaten.
3.3.1 F2Verify Anfragedokument

f2VerifyRequest nonce Mit diesem Attribut des Tags f2VerifyRequest wird dem
Aufrufenden die Möglichkeit gegeben, einen eindeutigen
Wert mitzugeben, der in der Antwort wiedergeben wird.
SLMBC beachtet diesen Wert selber nicht, sondern er dient
nur dem Aufrufenden.
inputData Beinhaltet den zu prüfenden Signatur-Container.
signedData Beinhaltet optional das ursprüngliche Dokument, dessen
Signatur sich in <inputData> befindet.
verificationTime Benennt die Zeit, die für die Prüfung herangezogen werden
soll. Dieser Zeitpunkt ist wichtig, da beim Kettenmodell Zer-
tifikate ablaufen können, jedoch damit erstellte Signaturen
weiterhin gültig sind.
givenTime Benennt die zu prüfende Zeit als Parameter.
verificationTi- Benennt die Parameter, welche für die Einbettung von Zeit-
me-Source daten in die Signatur verwendet wurden.
Mögliche Werte sind:
• currentTime: aktuelle PC Zeit,
• signatureTimestamp: Zeitpunkt des Signaturzeit-
stempels,
Seite 58 von 94
AuthentiDate
V3.0

• contentTimestamp: Zeitpunkt des Dokument-
zeitstempels und
• signingTimeInSignedAttributes: Zeitpunkt der Sig-
naturerstellung, ausgelesen aus den signierten Att-
ributen der Signatur.
returnEncapContent Wenn der Wert auf „true“ gesetzt wird, wird der eingebettet
Inhalt der Signatur mit zurückgeliefert.
returnOfflineData Wenn der Wert auf „true“ gesetzt wird, werden alle Zertifika-
te und Datenstrukturen, die während einer Online-Prüfung
von den Zertifizierungsdiensteanbietern angefordert wur-
den, mit zurückgegeben. Bei einer späteren weiteren Prü-
fung derselben Signatur können diese Daten mit angege-
ben werden, so dass SLMBC bei der Online-Prüfung auf
diese Ergebnisse zurückgreift und somit keine Online-
Anfragen generieren muss.
useOfflineSourcesOnly Wenn der Wert auf „true“ gesetzt wird und alle oben ge-
nannten Daten mit übergeben werden, wird bei einer Onli-
ne-Prüfung keine Online-Anfrage generiert.
offlineValidationData Benennt eine Liste von Datenstrukturen, die bei einer vor-
herigen Online-Prüfung derselben Signatur mit zurückgeben
wurden.
offlineCert Benennt eine Liste von Zertifikaten, die bei einer vorherigen
Online-Prüfung derselben Signatur mit zurückgeben wur-
den.
verificationLevel Mit diesem Wert wird die Prüftiefe der Prüfung eingestellt
(siehe Kapitel 3.16 „Prüftiefe“).
Tabelle 25: F2Verify Anfragedokument
3.3.2 F2Verify Antwortdokument
Das XML-Dokument, welches bei der Funktion F2Verify als Antwort entsteht, ist sehr komplex,
da die Signatur in Form eines Signatur-Containers selbst mannigfaltige Gestalt haben kann. Es
enthält das gesamte Prüfergebnis. Darüber hinaus beinhaltet es die Gültigkeitsnachweise (z. B.
OCSP-Antworten) zu den geprüften Zertifikaten in Form eines Evidence-Record, falls diese vom
Benutzer gewünscht wurden.

f2VerifyResponse producedAt Dieses XML-Attribut enthält die Systemzeit zum Zeitpunkt der Er-
stellung des XML-Dokuments.
nonce Dieses Attribut kann fehlen. Ist es vorhanden, spiegelt es den Wert
des gleichen Attributs aus der Anfrage. Das Attribut wird immer
genau dann gesetzt, wenn auch die Anfrage dieses Attribut ge-
setzt hatte.
result Beschreibt detailliert das Prüfergebnis zu den im Signatur-
Container enthaltenen Unterzeichnern und auch eventuellen Ge-
genzeichnern. Bei den Prüfergebnissen der Unterzeichner werden
auch die Prüfergebnisse der zugehörigen Zertifikate dargestellt.
externalSignedData Signalisiert, ob die vom Benutzer angegebenen signierten Daten
HashMatches a) zu der Signatur gehören,
Seite 59 von 94
AuthentiDate
V3.0

b) nicht zu der Signatur gehören oder
c) ob dies nicht geprüft wurde, weil die Signatur gar nicht weit
genug geprüft werden konnte.
Dieses Attribut ist nur vorhanden, wenn signierte Daten vom Be-
nutzer angegeben wurden.
validationData Das Element kann mehrfach vorkommen. Jedes Element enthält
einen Nachweis über den Sperrstatus zu einem oder mehreren der
geprüften Zertifikate (OCSP-Antwort, CRL, …), wie sie vom jewei-
ligen Zertifizierungsdiensteanbieter ausgestellt und elektronisch
unterschrieben wurden. Solche Elemente sind nur vorhanden,
wenn diese Nachweise auch angefordert wurden. Nachweise, die
bereits in der Signatur enthalten sind, werden nicht wiederholt.
cert Das Element kann mehrfach vorkommen. Jedes Element enthält
ein Zertifikat, das zum Zwecke der Prüfung der Signatur von
SLMBC aus einem (öffentlichen) Verzeichnis geholt werden muss-
te.
Tabelle 26: F2Verify Antwortdokument
3.3.3 F2Verify Fehlerdokument
Bei der Ausführung der Funktion F2Verify können Fehler auftreten. Einige davon werden in

<code>
2001 Die Signatur konnte nicht decodiert werden. Entweder ist sie stark beschädigt, oder das
Format ist nicht bekannt.
2005 Die vom Benutzer angegebenen (vermutlich) signierten Daten haben kein Format, das zur
Berechnung von externalSignedDataHashMatches bearbeitet werden kann.
2006 Die vom Benutzer angeforderte Genauigkeit der Prüfung (Prüftiefe) wird von SLMBC gene-
rell nicht unterstützt.
2007 Die (vermutlich) signierten Daten wurden vom Benutzer stellvertretend mit einem Hashwert
angegeben. Dieser Hashwert wurde aber mit einem anderen Algorithmus erzeugt als der-
jenige, welcher in der Signatur vorgefunden wurde.
2008 Die (vermutlich) signierten Daten wurden vom Benutzer stellvertretend mit einem Hashwert
angegeben. Dieser Hashwert wurde aber mit einem Algorithmus erzeugt, der von SLMBC
nicht unterstützt wird.
2009 Die vom Benutzer angeforderte Genauigkeit der Prüfung (Prüftiefe) wird von SLMBC nicht
unterstützt, weil die Konfiguration dies nicht vorsieht oder nicht zulässt.
2010 Die vom Benutzer angegebenen (vermutlich) signierten Daten haben ein Format, das von
SLMBC nicht unterstützt wird.
Tabelle 27: F2Verify Fehlerdokument
Seite 60 von 94
AuthentiDate
V3.0
3.4 F3Lock – Anlegen eines Auftrags
Mit dem Aufruf der Funktion F3Lock wird ein Auftrag zur Verarbeitung von Signaturen erstellt.
Er dient gleichermaßen der Erstellung und der Prüfung von Signaturen.
Die Wirkung des Aufrufes der Funktion ist, dass die zu verarbeitenden Daten samt der Einstel-
lungen zur Erzeugung bzw. Prüfung von Signaturen unveränderbar festgelegt werden und zur
Betrachtung bereitstehen, bevor die eigentliche Verarbeitung stattfindet. Die zu verarbeitenden
Daten werden also durch SLMBC geschützt.
Der Auftrag wird hier nur initialisiert und nicht bereits gestartet, d. h. es werden noch keine Sig-
naturen erstellt bzw. geprüft.
Der Benutzer übergibt an SLMBC zur Ausführung der Funktion ein Verzeichnis und weitere
Steuerungsinformationen. Dieses Verzeichnis (mit seinen Unterverzeichnissen) legt die Menge
der Daten fest, welche später verarbeitet werden sollen.
Die Funktion überprüft dann, ob in dem benannten Verzeichnis keine Datei mit einem Namen
enthalten ist, welche SLMBC bei einer späteren Verarbeitung der Signaturen selbst anlegen
würde. Enthält das Verzeichnis eine solche Datei, erzeugt SLMBC keinen Vorgang, sondern
antwortet mit einem entsprechenden Fehler.
Verläuft diese Überprüfung erfolgreich, so verschiebt die Funktion das angegebene Verzeichnis
samt der darin enthaltenen Daten in das Auftragsbuch (ein durch die Konfiguration festgelegtes
Verzeichnis) von SLMBC, in dem alle Verzeichnisse zu allen aktuellen Vorgängen gesammelt
werden.
Dort stellt die Funktion die Zugriffsrechte auf die Daten, das benannte Verzeichnis und alle sei-
ne Unterverzeichnisse sicher ein, so dass außer durch SLMBC und durch vertrauenswürdige
Prozesse keine Manipulation der Daten erfolgen kann. Das Verzeichnis wird nach dieser Ände-
rung der Zugriffsrechte in diesem Dokument als „Sicheres Verzeichnis“ bezeichnet.
Erst nach der Veränderung aller Zugriffsrechte übermittelt SLMBC eine Antwort an den aufru-
fenden Benutzer. In dieser Antwort wird die Erstellung des sicheren Verzeichnisses bestätigt
und auch genannt, wie der absolute Pfad des „Sicheren Verzeichnisses“ lautet.
Durch den Schutz der Daten vor Manipulation ist sichergestellt, dass nur Daten, welche im si-
cheren Verzeichnis noch betrachten werden können, nach dem Aufruf einer der Funktionen
F5SignFile bzw. F6VerifyFile signiert werden.
Weiterhin bewirkt der Aufruf der Funktion, dass für die gesamte Lebensdauer des Vorganges im
sicheren Verzeichnis eine Status-Datei namens „jobStatus.xml“ von SLMBC gepflegt wird.
Die Datei wird vor der Antwort der Funktion F3Lock im sicheren Verzeichnis angelegt und bis
zum Aufruf der Funktionen „Abbruch“ oder „Löschen“ kontinuierlich aktualisiert.
Für den Benutzer dient sie als zusätzliche vertrauenswürdige Information, sofern er lesenden
Zugriff auf das sichere Verzeichnis hat. Der Inhalt der Datei „jobStatus.xml“ wird auch als Teil
der Antwort zu den Aufrufen der Funktionen „Statusabfrage“, „Löschen“ und „Abbruch“ zur Ver-
fügung gestellt.
Seite 61 von 94
AuthentiDate
V3.0
3.4.1 F3Lock Anfragedokument
vom Benutzer (Software-Applikation) an SLMBC gesendet wird. Da das Anlegen eines Auftrags
sowohl für die Signaturerstellung als auch für die Signaturprüfung über diese Funktion stattfin-
det, kann das XML-Dokument als XML-Tag entweder Daten vom Typ <parametersForSigning>
oder aber Daten vom Typ <parametersForVerification> enthalten.
Haupt XML-Tag XML-Tag Beschreibung

f3LockRequest nonce Mit diesem Attribut des Tags f3LockRequest wird
wiedergeben wird. SLMBC beachtet diesen Wert
selber nicht, sondern er dient nur dem Aufrufenden.
requestorIdentifier name Mit diesem Element wird der Benutzer der Gruppe
authentifiziert. Er muss in der Datei „user.xml“ konfi-
guriert werden.
password Mit diesem Element wird das Passwort des Grup-
penbenutzers angegeben.
dir Absoluter Name des Verzeichnisses, dessen Inhalt
komplett in das sichere Verzeichnis von SLMBC
verschoben wird. Nach Erfolg der Funktion F3Lock
gibt es dieses Verzeichnis nicht mehr, da es vorher
verschoben wurde.
parametersForSigning Wenn dieses XML-Tag vorhanden ist, werden alle
Daten im Verzeichnis zur Signaturerstellung heran-
gezogen.
signatureAlgorithm Mit diesem Element wird der Signaturalgorithmus
benannt, mit dem eine Signatur erstellt wird.
Zu beachten ist, dass erstens die Signaturkarte die-
sen Algorithmus unterstützt, und zweitens falls eine
Zeitstempelanforderung konfiguriert wurde, der mit
angegebene Hash-Algorithmus vom TrustCenter
ebenfalls unterstützt wird.
groupName Mit diesem Element wird die Gruppe der Signatur-
karten bestimmt, mit denen Signaturen erstellt wer-
den sollen.
base64Value Dieser Wert gibt den Hashwert der zu benutzenden
Gruppe an.
algorithm Dieser Wert gibt den Namen des Algorithmus (OID)
an, mit dem der Hashwert der Gruppe berechnet
wurde.
containerFormat Dieser Wert gibt das Container-Format für die zu
erstellenden Signaturen an. Mögliche Werte sind
„CMS“ und „PKCS#7“.
contentBinding Mit diesem Element wird bestimmt, wie die originale
Mode Datei und die Signatur verknüpft werden. Wobei nur
eines der drei nachfolgenden XML-Tags angegeben
werden kann.
escortContent Der Wert bestimmt, ob die Signatur begleitend er-
stellt wird („true“).
integrateInto Der Wert „fileFormat“ gibt das Dateiformat an, in das
Content die Signatur eingebettet wird. Möglich ist derzeit
lediglich TIFF.
encapsulate Durch dieses Element wird die originale Datei in die
Content Signatur eingebettet.
Seite 62 von 94
AuthentiDate
V3.0

supplementary Benennt Optionen für die Erzeugung einer Parallel-
Signing bzw. Gegensignatur.
Bei einer Gegensignatur muss der Name des gegen
zu signierenden Zertifikates (Signatur) mit angege-
ben werden.
includeContent Wird diese Einstellung auf „true“ gesetzt, so wird der
Timestamp zu signierende Inhalt mit einem Zeitstempel verse-
hen und als signiertes Attribut in die Signatur einge-
bettet.
includeSignature Wird diese Einstellung auf „true“ gesetzt, so wird der
Timestamp signierte Inhalt mit einem Zeitstempel versehen und
als unsigniertes Attribut in die Signatur eingebettet.
countRequired Wird der Wert auf „true“ gesetzt, so wird vor der
SignaturesIn Signaturerstellung die Anzahl der zu erstellenden
Advance Signaturen im Vorfeld berechnet und zur Abfrage
angeboten.
parametersForVerification Wenn dieses XML-Tag vorhanden ist, werden alle
Daten im Verzeichnis zur Signaturprüfung herange-
zogen.
requestedLevel Mit diesem Wert wird die Prüftiefe der Prüfung ein-
gestellt (siehe Kapitel 3.16 „Prüftiefe“). Für den Be-
trieb im signaturgesetzkonformen Umfeld, muss
immer die höchste Prüftiefe verwendet werden.
verificationTime 1-4 Benennt eine Reihenfolge, mit der der Verifikations-
zeitpunkt ausgelesen werden kann.
In der Regel sollte man hier vier Elemente angeben,
mit den folgenden Angaben für die Verifikationszeit:
signatureTimestamp
contentTimestamp
signingTimeInSignedAttributes
currentTime
Falls es einen Zeitstempel für die Signatur gibt, wird
dessen Zeitpunkt genommen. Ansonsten wird der
Zeitpunkt des Dokumentzeitstempels herangezogen.
Als dritte Möglichkeit prüft SLMBC die Zeit in den
signierten Attributen (Dies war der Standard in der
alten AD API). Wenn keine Zeitpunkte vorhanden
sind, wird zuletzt gegen die aktuelle Zeit geprüft.
contentBinding Mit diesem Wert wird die Art der Signaturbindung
Mode zur Zeitpunkt der Erstellung angegeben (begleitend,
eingebettet oder einbettend).
extractEncap Wenn dieser Wert auf „true“ gesetzt wird und die
Content originale Datei in die Signatur eingebettet wurde,
wird diese aus der Signatur extrahiert und zurückge-
liefert.
fileValidation Wird dieser Wert angegeben, werden alle Statusin-
DataForArchiving formationen und Zertifikate, die bei der Prüfung onli-
ne angefragt wurden, als Base64-kodierte Elemente
mit zurückgeliefert. Dieser Datensatz wird auch als
Evidence-Record bezeichnet.
useArchived Wird dieser Wert angegeben, so wird der oben er-
ValidationData haltene Evidence-Record genutzt, um die bereits
erhaltenen Online-Anfragen aus diesem zu auszule-
sen. Dadurch wird trotz einer hohen Prüftiefe
(„fullStatus“) keine Online-Verbindung aufgebaut, da
alle Daten bereits im Evidence-Record stehen.
countSignatures Wird der Wert auf „true“ gesetzt, so wird vor der
InAdvance Signaturprüfung die Anzahl der zu prüfenden Signa-
Seite 63 von 94
AuthentiDate
V3.0

turen im Vorfeld berechnet und zur Abfrage angebo-
ten.
applicationProperty Mit diesen Werten können Daten an den Auftrag
mitgegeben werden, die beim Aufruf der Funktion
F10GetStatus wieder zurückgeben werden. Dies
dient nur dem Aufrufenden und wird von SLMBC
nicht verarbeitet.
key Benennt den Schlüssel.
value Benennt den Wert.
Tabelle 28: F3Lock Anfragedokument
3.4.2 F3Lock Antwortdokument

f3LockResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung
des XML-Dokuments.
nonce Das Attribut kann fehlen. Ist es vorhanden, spiegelt es den Wert
des gleichen Elementes aus der Anfrage. Der Wert wird immer
genau dann gesetzt, wenn auch die Anfrage diesen Wert gesetzt
hatte.
originalDir Der Wert wiederholt die Angabe des Verzeichnisses aus dem XML-
Dokument zum Aufruf, welches vor dem Aufruf die zu signierenden
bzw. zu prüfenden Daten enthielt.
lockedAsDir Der Wert benennt das Verzeichnis, welches nun die zu prüfenden
bzw. zu signierenden Daten enthält und vor Manipulationen ge-
schützt ist.
Tabelle 29: F3Lock Antwortdokument
3.4.3 F3Lock Fehlerdokument
Bei der Ausführung der Funktion F3Lock können Fehler auftreten. Einige davon werden in

<code>
3001 Die Parameter im XML-Dokument des Aufrufes von f3Lock können nicht akzeptiert werden.
3002 Aufgrund eines Systemfehlers ist es nicht möglich, das sichere Verzeichnis zu erstellen.
Eine mögliche Ursache sind falsch gesetzte Benutzerrechte für das Quellverzeichnis.
3003 Das angegebene Quellverzeichnis ist nicht vorhanden.
3004 Das angegebene Quellverzeichnis ist kein Verzeichnis, sondern eine einzelne Datei. Es
dürfen aber nur Verzeichnisnamen angegeben werden.
3005 Im angegebenen Verzeichnis oder in den darunter liegenden Verzeichnissen wurden Datei-
en gefunden, die mit einer reservierten Endung versehen sind. Sowohl für den Signatur- als
Seite 64 von 94
AuthentiDate
V3.0

<code>
auch für den Prüfungsvorgang darf keine Datei mit der Endung .slmbc vorhanden sein.
Soll ein Prüfungsprozess gestartet werden, so ist zusätzlich das Vorhandensein einer Datei
mit der Endung .xml nicht erlaubt.
3006 Im angegebenen Verzeichnis oder in darunter liegenden Verzeichnissen wurden Dateien
gefunden, welche denselben Namen tragen wie die erzeugte Statusdatei „jobStatus.xml“.
3007 Es soll ein Signaturvorgang gestartet werden, bei dem die Signaturen in die Quelldatei in-
tegriert werden sollen. Im angegebenen Verzeichnis oder in den darunter liegenden Ver-
zeichnissen wurden jedoch Dateien gefunden, welche nicht dem angegebenen Dateityp
entsprechen. Erlaubte Dateitypen (bzw. Dateiendungen) sind TIF oder TIFF.
3008 Es soll ein Signaturvorgang gestartet werden, bei dem eine Parallelsignatur durchgeführt
werden soll, welche nicht in die Quelldatei integriert werden soll. Aber nicht jede Quelldatei
in dem angegebenen Verzeichnis oder in den darunter liegenden Verzeichnissen ist durch
eine Signaturdatei begleitet. Der Dateityp der Signaturdatei wird hierbei durch den in der
Anfrage genannten Container-Typ festgelegt. Zurzeit werden die Typen (bzw. Dateiendun-
gen) CMS und PKCS#7 unterstützt.
3009 Es soll ein Signaturvorgang gestartet werden, bei dem eine Gegensignatur durchgeführt
werden soll, welche nicht in die Quelldatei integriert werden soll. Es sind aber nicht nur Sig-
naturcontainer (deren Dateityp durch den in der Anfrage genannten Container-Typ festge-
legt wird) in dem angegebenen Verzeichnis oder in darunter liegenden Verzeichnissen vor-
handen, sondern auch weitere Dateien.
3010 Es soll ein Signaturvorgang gestartet werden, bei dem eine Signatur durchgeführt werden
soll, welche nicht in die Quelldatei integriert werden soll. Es sind aber bereits Signaturcon-
tainer (deren Dateityp durch den in der Anfrage genannten Container-Typ festgelegt wird) in
dem angegebenen Verzeichnis oder in darunter liegenden Verzeichnissen vorhanden.
3011 SLMBC befindet sich in einer schwach prozessgebundenen Umgebung, und es ist bereits
ein Signatur-Vorgang für diese Signaturgruppe in Bearbeitung.
3012 Es wurde die Beauftragung eines Signatur- oder Prüfungsvorganges übergeben, aber der
entsprechende Dienst ist nicht konfiguriert.
3013 Es wurde die Beauftragung eines Signatur- oder Prüfungsvorgangs übergeben, aber es
sind keine Dateien vorhanden, die zu signieren oder prüfen sind.
Tabelle 30: F3Lock Fehlerdokument
3.5 F4FetchTimeStamp – Anlegen eines Auftrags
Die Anforderung von Zeitstempeln durch SLMBC wird ohne eine vorherige Auftragserstellung
(Funktion F3Lock) nur mit der Funktion F4FetchTimestamp realisiert.
Die Funktion nimmt den Hashwert des zu zeitstempelnden Dokumentes entgegen, authentifi-
ziert sich gegenüber dem Zeitstempeldienst im AuthentiDate Trustcenter und übergibt diesem
die Daten, mit der Zeitstempelanforderung. Als Ergebnis wird der eigentliche Zeitstempel im
angegebenen Format (RF3161, PKCS#7) zurückgegeben. Dabei ist zu beachten, dass die Da-
ten direkt über den HTTPS-Request, und nicht über das sichere Verzeichnis ausgetauscht wer-
den.
Bitte beachten Sie: Diese Funktion ersetzt die Funktionalität des alten eTimeStamp Moduls aus
der AuthentiDate API 2.x.
Die Benutzerkonfiguration für den Zugriff auf den akkreditierten AuthentiDate Zeitstempeldienst
wird über die Konfiguration der Funktion F4FetchTimestamp umgesetzt, d.h. bei einer Anforde-
rung für Zeitstempel müssen diese Benutzerdaten im Gegensatz zum alten eTimestamp Modul
nicht mehr beim Aufruf übergeben werden, sondern liegen zentral in der oben genannten Konfi-
gurationsdatei.
Seite 65 von 94
AuthentiDate
V3.0
3.5.1 F4FetchTimestamp Anfragedokument
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfragedokumentes, wel-
ches vom Benutzer (Software-Applikation) an SLMBC gesendet wird.

f4FetchTimestamp nonce Mit diesem Attribut des Tags f4FetchTimestampRequest
Request wird dem Aufrufenden die Möglichkeit gegeben, einen
eindeutigen Wert mitzugeben, der in der Antwort wie-
dergeben wird. SLMBC beachtet diesen Wert selber
nicht, sondern er dient nur dem Aufrufenden.
accountName Benennt den Benutzernamen.
timeStampFormat Benennt das gewünschte Rückgabeformat des Zeit-
stempels. Mögliche Werte sind RFC3161 und PKCS#7.
tsRequestNonce Mit diesem Wert wird dem Aufrufenden die Möglichkeit
gegeben einen eindeutigen Wert mitzugeben, der in der
Antwort wiedergeben wird. SLMBC beachtet diesen
Wert selber nicht, er dient nur dem Aufrufenden.
digestAlgorithm Benennt die OID des Algorithmus für den Zeitstempel.
digest base64Value Beinhaltet den Hashwert, für den ein Zeitstempel ange-
fordert wird.
Tabelle 31: F4FetchTimestamp Anfragedokument
3.5.2 F4FetchTimestamp Antwortdokument
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwortdokumentes, wel-
ches vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.

f4FetchTimestamp producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der
Response Erstellung des XML Dokumentes.
nonce Das Attribut kann fehlen. Ist es vorhanden, spiegelt es
den Wert des gleichen Elementes aus der Anfrage. Der
Wert wird immer genau dann gesetzt, wenn auch die
Anfrage diesen Wert gesetzt hatte.
timeStampFormat Gibt das gewünschte Rückgabeformat des Zeitstempels
wieder. Mögliche Werte sind RFC3161 und PKCS#7.
timeStamp Gibt den berechneten Zeitstempel Base64 kodiert zu-
rück.
Tabelle 32: F4FetchTimestamp Antwortdokument
3.5.3 F4FetchTimestamp Fehlerdokument
Bei der Ausführung der Funktion F4TimeStamp können Fehler auftreten. Einige davon werden
in Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets
mit einem XML Dokument als Antwort signalisiert, welches das Element <errorResponse> als
Wurzelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursa-
chen der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.
Seite 66 von 94
AuthentiDate
V3.0
Wert von <code> Bedeutung des Wertes

4001 Der konfigurierte Zeitstempeldienst konnte im Moment nicht erreicht werden.
4002 Der Zeitstempel konnte vom Zeitstempeldienst nicht bezogen werden, bzw. enthält
Fehler.
Tabelle 33: F4FetchTimestamp Fehlerdokument
3.6 F5SignFile – Ausführung eines Signierauftrags
Mit dem Aufruf der Funktion wird SLMBC veranlasst, die in einem sicheren Verzeichnis befindli-
chen Dateien nun auch zu signieren. Der Zweck der Funktion ist, SLMBC den „Startschuss“ für
die massenhafte Erstellung von Signaturen zu geben.
Die Wirkung der Funktion ist die eines Signalgebers, weshalb SLMBC auch nach Kenntnisnah-
me des Signals direkt ein XML-Dokument als Antwortdatenstruktur zurückgibt.
Aufgrund des Signals wird SLMBC die Zugriffsrechte des zum Vorgang gehörenden sicheren
Verzeichnisses und aller rekursiv darin enthaltenen Dateien und Unterverzeichnisse derart än-
dern, dass auf diese nur noch SLMBC selbst und vertrauenswürdige Prozesse schreibend und
lesend zugreifen können.
Danach wird unverzüglich damit begonnen, die geforderten Signaturen zu erstellen und gemäß
Auftrag des Benutzers neben den zu signierenden Dateien abzulegen oder in die zu signieren-
den Dateien einzubetten.
Nach der erfolgreichen Erzeugung aller Signaturen werden die temporär erzeugten Dateien mit
ihrem endgültigen Namen versehen. Danach werden die Dateirechte des sicheren Verzeichnis-
ses dahingehend verändert, dass der Benutzer Leserechte auf das sichere Verzeichnis und alle
Unterverzeichnisse erhält.
Tritt hingegen während der Erzeugung der Signaturen ein Fehler auf, wird der Ursprungszu-
stand des sicheren Verzeichnisses vor dem Aufruf der Funktion F5SignFile wiederhergestellt.
Danach werden die Dateirechte des sicheren Verzeichnisses dahingehend verändert, dass al-
len Prozessen voller Zugriff auf das sichere Verzeichnis gewährt wird. Nach dieser Modifikation
der Dateirechte ist das sichere Verzeichnis nicht mehr als sicher anzusehen.
Ein wiederholter Aufruf der Funktion für einen Auftrag bewirkt die Fehlermeldung 5002 als Ant-
wort für die wiederholten Aufrufe (s. Kapitel „F5SignFile Fehlerdokument“).
3.6.1 F5SignFile Anfragedokument

f5SignFileRequest nonce Mit diesem Attribut des Tags f5SignFileRequest wird dem Aufrufen-
den die Möglichkeit gegeben, einen eindeutigen Wert mitzugeben, der
in der Antwort wiedergeben wird. SLMBC beachtet diesen Wert selber
requestorIdentifier name Mit diesem Element wird der Benutzer der Gruppe authentifiziert. Er
Seite 67 von 94
AuthentiDate
V3.0
muss in der Datei „user.xml“ konfiguriert werden.

password Mit diesem Element wird das Passwort des Gruppenbenutzers ange-
geben.
lockedAsDir Der Wert bezeichnet den absoluten Pfad des sicheren Verzeichnisses
des Vorganges, der durch F3Lock initiiert wurde.
Er dient als eindeutiger Schlüssel, damit der Benutzer seinen Auftrag
eindeutig identifizieren kann.
Tabelle 34: F5SignFile Anfragedokument
3.6.2 F5SignFile Antwortdokument
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Antwort-Dokuments, wel-
ches vom SLMBC an den Benutzer (Software-Applikation) zurückgesendet wird.

f5SignFileResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung
des XML-Dokuments.
genau dann gesetzt, wenn auch die Anfrage diesen Wert ge-
setzt hatte.
lockedAsDir Spiegelt den Wert des Elementes mit gleichem Namen aus dem
XML-Dokument des Aufrufes. Der Wert bezeichnet den absolu-
ten Pfad des sicheren Verzeichnisses des Vorganges.
Tabelle 35: F5SignFile Antwortdokument
3.6.3 F5SignFile Fehlerdokument
Bei der Ausführung der Funktion F5SignFile können Fehler auftreten. Einige davon werden in

<code>
5001 Während der Initialisierung oder der Durchführung des Vorganges ist ein allgemeiner Feh-
ler aufgetreten, welcher den Vorgang zum Signieren von Dateien verhindert hat.
5002 Der Vorgang ist bereits gestartet worden. Er kann nicht erneut gestartet werden.
5003 Der bezeichnete Prozess, welcher gestartet werden soll, ist nicht initialisiert worden. Er ist
unbekannt (oder existiert nicht mehr).
5004 Bei dem bezeichneten Vorgang handelt es sich nicht um einen Vorgang zur Erzeugung
von Signaturen.
5005 Bei der internen Nachfrage nach der Anzahl der aktivierten Signaturerstellungseinheiten ist
ein Fehler aufgetreten.
5006 Der bezeichnete Vorgang ist nicht bereit zu starten. Er befindet sich nicht im Zustand „lo-
cked“.
Tabelle 36: F5SignFile Fehlerdokument
Seite 68 von 94
AuthentiDate
V3.0
3.7 F6VerifyFile – Ausführung eines Verifikationsauftrags
Mit dem Aufruf der Funktion wird SLMBC veranlasst, die in einem sicheren Verzeichnis befindli-
chen Dateien zu prüfen. Der Zweck der Funktion ist, SLMBC den Startschuss für die massen-
hafte Prüfung von Signaturen zu geben.
Die Wirkung der Funktion ist die eines Signalgebers, weshalb SLMBC auch nach Kenntnisnah-
me des Signals direkt ein XML-Dokument als Antwortdatenstruktur zurückgibt.
Aufgrund des Signals wird SLMBC die Zugriffsrechte des zum Vorgang gehörenden sicheren
Verzeichnisses und aller rekursiv darin enthaltenen Dateien und Unterverzeichnisse so ändern,
dass nur noch SLMBC selbst und vertrauenswürdige Prozesse schreibend und lesend zugrei-
fen können.
Er wird danach unverzüglich begonnen, die geforderten Prüfergebnisse zu erstellen und gemäß
des Auftrages des Benutzers neben den signierten Dateien ablegen.
Nachdem alle Prüfungen erfolgreich durchgeführt wurden, werden die temporär erzeugten Da-
teien mit Ihrem endgültigen Namen versehen. Danach werden die Dateirechte des sicheren
Verzeichnisses dahingehend verändert, dass die aufrufende Rolle Leserechte auf das das si-
chere Verzeichnis und alle Unterverzeichnisse erhält.
Tritt hingegen während der Durchführung der Prüfungen der Signaturen ein Fehler auf, so wird
der Ursprungszustand des sicheren Verzeichnisses vor dem Aufruf der Funktion F6VerifyFile
wiederhergestellt. Danach werden die Dateirechte des sicheren Verzeichnisses dahingehend
verändert, dass allen Prozessen voller Zugriff auf das sichere Verzeichnis gewährt wird. Nach
dieser Modifikation der Dateirechte ist das sichere Verzeichnis nicht mehr als sicher anzusehen.
Ein wiederholter Aufruf der Funktion für einen Auftrag bewirkt eine Fehlerstruktur als Antwort für
die wiederholten Aufrufe.
3.7.1 F6VerifyFile Anfragedokument

f6VerifyFileRequest nonce Mit diesem Attribut des Tags f6VerifyFileRequest wird dem Aufru-
fenden die Möglichkeit gegeben, einen eindeutigen Wert mit-
zugeben, der in der Antwort wiedergeben wird. SLMBC beachtet
diesen Wert selber nicht, er dient nur dem Aufrufenden.
lockedAsDir Der Wert bezeichnet den absoluten Pfad des Sicheren Verzeichnis-
ses des Vorganges, der durch F3Lock initiiert wurde.
Er dient als eindeutiger Schlüssel, damit der Benutzer seinen Auf-
trag eindeutig identifizieren kann.
Tabelle 37: F6VerifyFile Anfragedokument
Seite 69 von 94
AuthentiDate
V3.0
3.7.2 F6VerifyFile Antwortdokument

f6VerifyFileResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung
des XML-Dokuments.
genau dann gesetzt, wenn auch die Anfrage diesen Wert ge-
setzt hatte.
XML-Dokument des Aufrufes. Der Wert bezeichnet den absolu-
ten Pfad des sicheren Verzeichnisses des Vorganges.
Tabelle 38: F6VerifyFile Antwortdokument
3.7.3 F6VerifyFile Fehlerdokument
Bei der Ausführung der Funktion F6VerifyFile können Fehler auftreten. Einige davon werden in

<code>
6001 Während der Initialisierung oder der Durchführung des Vorganges ist ein allgemeiner Fehler
aufgetreten, welcher den Vorgang zum Prüfen von Dateien verhindert hat.
6002 Der Vorgang ist bereits gestartet worden. Er kann nicht erneut gestartet werden.
6004 Bei dem bezeichneten Vorgang handelt es sich nicht um einen Vorgang zum Signieren von
Daten und nicht einen Prüfvorgang.
6006 Der bezeichnete Vorgang kann nicht starten, weil er sich nicht im Zustand „locked“ befindet.
Tabelle 39: F6VerifyFile Fehlerdokument
3.8 F7Unlock– Beenden eines Auftrags
Mit dem Aufruf der Funktion F7Unlock wird SLMBC veranlasst, einen bestehenden Auftrag zur
Erstellung bzw. Prüfung von Signaturen (hier auch kurz „Vorgang“ genannt) vorzeitig abzubre-
chen oder regulär aufzulösen.
Der Zweck der Funktion F7Unlock ist zweigeteilt. Einerseits ermöglicht sie dem Benutzer die
Löschung eines Vorganges aus dem Auftragsbuch von SLMBC. Andererseits ermöglicht sie
dem Benutzer, den vorzeitigen Abbruch eines Vorganges in jedwedem Zustand. Welchem
Seite 70 von 94
AuthentiDate
V3.0
Zweck ein konkreter Aufruf dient, ergibt sich aus der Kombination der Aufrufparameter und dem
aktuellen Zustand des Vorganges.
Die Wirkung des Aufrufes der Funktion F7Unlock hängt von dem vom Benutzer beabsichtigten
Zweck und dem aktuellen Zustand des Vorganges ab:
Will der Benutzer den Vorgang aus dem Auftragsbuch von SLMBC löschen, muss er in den
Aufrufparametern den Pfad eines noch nicht existenten Verzeichnisses nennen, durch das das
sichere Verzeichnis dem Benutzer wieder zur Verfügung gestellt werden soll. In diesem Falle
wird ein XML-Dokument als Antwort erst dann erzeugt, wenn das ehemals sichere Verzeichnis
für den Benutzer unter dem angegebenen Pfad bereitsteht. Diese Art des Funktionsaufrufes
wird in diesem Dokument auch als blockierender Aufruf von F7Unlock bezeichnet.
Die genaue Wirkung des Funktionsaufrufes hängt noch von dem aktuellen Zustand des Vor-
ganges ab. Ist der Vorgang bereits abgeschlossen, das heißt, wurden alle beauftragten Signa-
turen erzeugt bzw. geprüft, dann löst der Aufruf nur recht wenig Aktion seitens SLMBC aus. Er
löscht die Datei namens „jobStatus.xml“ aus dem sicheren Verzeichnis und setzt die Zugriffs-
rechte rekursiv für das sichere Verzeichnis des Vorganges so, dass auch der Benutzer wieder
lesend und schreibend zugreifen kann. Das Löschen der Datei namens „jobStatus.xml“ ge-
schieht sicherheitshalber, weil nach dem Freigeben der Zugriffsrechte die darin enthaltene In-
formation nicht mehr gegen Manipulationen geschützt und deshalb nicht mehr vertrauenswürdig
ist. Danach wird das Verzeichnis zu der gewünschten Position verschoben.
In jedem anderen Zustand des Vorganges erfolgt ein zusätzlicher Schritt vor der Änderung der
Zugriffsrechte des Sicheren Verzeichnisses: SLMBC löscht eventuelle Zwischenergebnisse, wie
bereits erstellte Signaturen oder erzeugte Prüfergebnisse, und stellt damit den ursprünglichen
Zustand des Verzeichnisses wieder her. Ein wiederholter Aufruf der Funktion zum Zwecke der
Löschung des Vorganges, während ein erster Aufruf noch schwebt, bewirkt eine Fehlerstruktur
als Antwort auf die wiederholten Aufrufe.
Jede andere Art des Aufrufes der Funktion F7Unlock gibt SLMBC lediglich ein Signal, dass der
Vorgang abzubrechen ist. Diese Art des Funktionsaufrufes wird in diesem Dokument auch als
nicht blockierender Aufruf von F7Unlock bezeichnet. Sie ist daran erkennbar, dass der Benutzer
in den Aufrufparametern kein Zielverzeichnis benennt. Die Antwort auf diesen Aufruf ist dann
lediglich die Bestätigung, dass der Abbruch erfolgen wird.
Die Wirkung des Aufrufes hängt vom Zustand des Vorganges ab. Ist der Vorgang bereits abge-
schlossen, das heißt, wurden alle beauftragten Signaturen erzeugt bzw. geprüft, ist der Aufruf
wirkungslos, nur der Status des Auftrages wird von „signingCompleted“ oder „verifyingComple-
ted“ auf „terminatedWithSuccess“ gesetzt. Der Aufruf ist auch wirkungslos, wenn für den Vor-
gang bereits mit der Funktion F7Unlock das Signal zum Abbruch gegeben wurde oder wenn
bereits ein Aufruf zum Zwecke der Löschung des Vorganges besteht.
Ansonsten bewirkt der Aufruf, dass SLMBC alle eventuell vorhandenen Zwischenergebnisse
des Vorganges, wie bereits erstellte Signaturen oder erzeugte Prüfergebnisse, löscht und so
den ursprünglichen Zustand des sicheren Verzeichnisses wieder herstellt.
Die Übergabe des sicheren Verzeichnisses an den Benutzer und die vorherige Freigabe seiner
Zugriffsrechte erfolgen nicht durch diesen Aufruf. Hierfür muss der Benutzer die Funktion
F7Unlock blockierend aufrufen, also mit Angabe eines Rückgabeverzeichnisses.
Der asynchrone Modus wird von SLMBC bereitgestellt, da bei einem größeren blockierenden
Aufruf, Timeout-Fehler innerhalb der HTTP-Verbindung auftreten können.
Seite 71 von 94
AuthentiDate
V3.0
3.8.1 F7Unlock Anfragedokument
Die folgende Tabelle erklärt die einzelnen XML-Tags innerhalb des Anfrage-Dokuments, wel-
ches vom Benutzer (Software-Applikation) an SLMBC gesendet wird.

f7UnlockRequest nonce Mit diesem Attribut des Tags f7UnlockRequest wird dem Aufrufenden
die Möglichkeit gegeben, einen eindeutigen Wert mitzugeben, der in
der Antwort wiedergeben wird. SLMBC beachtet diesen Wert selber
lockedAsDir Der Wert bezeichnet den absoluten Pfad des Sicheren Verzeichnisses
releaseAsDir Der Wert benennt das Zielverzeichnis, in das die Daten aus dem si-
cheren Verzeichnis verschoben werden sollen.
Dieses Verzeichnis darf vor dem Funktionsaufruf noch nicht existieren
und muss in der gleichen Partition wie das sichere Verzeichnis liegen.
Wird der Parameter nicht mit angegeben, arbeitet die Funktion
F7Unlock im asynchronen Modus, d.h. der Aufrufende erhält sofort
eine Antwort.
Wird der Parameter mit angegeben, so blockiert die Funktion, und der
Aufrufende erhält erst nach Beendigung eine Antwort.
Tabelle 40: F7Unlock Anfragedokument
3.8.2 F7Unlock Antwortdokument
Das XML-Dokument, welches beim Aufruf der Funktion f7Unlock als Antwort entsteht, hat zwei-
erlei Gestalt. Sie richtet sich nach dem Zweck des Aufrufes der Funktion. Wurde sie nur zum
Zwecke der Anweisung des Abbruchs eines Vorganges an SLMBC aufgerufen, enthält die Ant-
wort nur das Element <lockedAsDir> als Bestätigung ihres Aufrufes.
Wurde die Funktion hingegen zum Zwecke der Löschung des Vorganges aufgerufen, enthält
die Antwort zusätzlich das Element <jobStatus>, in dem der letzte Zustand in vertrauenswürdi-
ger und detaillierter Form an den Benutzer übermittelt wird. Diese Darstellung des Zustandes ist
als verlässliche Quittung für den Benutzer gedacht.

f7UnlockResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung
des XML-Dokuments.
hatte.
XML-Dokument des Aufrufes. Der Wert bezeichnet den absoluten
Pfad des sicheren Verzeichnisses des Vorganges.
jobStatus Das komplexe Element ist nur vorhanden, wenn die Funktion zum
Zwecke der Löschung des Vorganges aufgerufen wurde. In diesem
Seite 72 von 94
AuthentiDate
V3.0

Fall enthält die Funktion die detaillierte Beschreibung des letzten
Zustandes des Vorganges.
Tabelle 41: F7Unlock Antwortdokument
3.8.3 F7Unlock Fehlerdokument
Bei der Ausführung der Funktion F7Unlock können Fehler auftreten. Einige davon werden in

<code>
7001 Während der Initialisierung oder der Durchführung des Vorganges ist ein allgemeiner Feh-
ler aufgetreten, welcher den Vorgang zur Freigabe von Dateien verhindert hat.
7002 Der Vorgang ist bereits ‚unlocked’ worden. Er kann nicht erneut ‚unlocked’ werden.
7004 Der bezeichnete Vorgang ist nicht bereit, in den Zustand zu wechseln.
Tabelle 42: F7Unlock Fehlerdokument
3.9 F8Deactivate – Deaktivieren von Signaturkarten
Mit dem Aufruf der Funktion F8Deactivate wird SLMBC veranlasst, eine oder mehrere Gruppen
von Signaturerstellungseinheiten zu deaktivieren. Mit der Deaktivierung ist gemeint, dass die
Signaturerstellungseinheiten mit einer erneuten Authentisierung durch eine PIN-Eingabe akti-
viert werden müssen, bevor sie weitere Signaturen erzeugen können.
SLMBC benutzt diese Funktion selbst, wenn ein Vorgang zur Erstellung von Signaturen in einer
schwach prozessgebundenen Umgebung abgeschlossen wird. Im Betrieb als vollständige Sig-
naturanwendungskomponente stellt SLMBC die Funktion dem Benutzer nicht direkt zur Verfü-
gung. Sie gehört deshalb eigentlich nicht zur externen Schnittstelle. Dennoch ist sie hier be-
schrieben, weil der SLMBC in zwei Teilen betrieben werden kann, eventuell sogar auf getrenn-
ten Rechnern (siehe Kapitel 3.1.1 „Vollständige SAK zur Signaturerstellung“).
Der Zweck der Funktion F8Deactivate ist, alle verfügbaren Signaturerstellungseinheiten einer
Gruppe oder mehrerer Gruppen in einen Zustand zu versetzen, der erst wieder die Erstellung
von Signaturen ermöglicht, wenn der Schlüsselinhaber sich zuvor durch eine PIN-Eingabe au-
thentisiert hat.
Die Wirkung des Aufrufes der Funktion F8Deactivate ist, dass die betroffenen Signatur-
erstellungseinheiten deaktiviert werden und laufende Vorgänge zur Erzeugung von Signaturen
fehlerhaft abgebrochen werden, sofern sie die jeweilige Gruppe von Signaturerstellungs-
einheiten akut benötigen, um eine oder mehrere Signaturen zu erstellen.
Seite 73 von 94
AuthentiDate
V3.0
3.9.1 F8Deactivate Anfragedokument

f8Deactivate nonce Mit diesem Attribut des Tags f8DeactivateRequest wird dem Aufru-
Request fenden die Möglichkeit gegeben, einen eindeutigen Wert mit-
zugeben, der in der Antwort wiedergeben wird. SLMBC beachtet
diesen Wert selber nicht, sondern er dient nur dem Aufrufenden.
requestorIdentifier name Mit diesem Element wird der Benutzer der Gruppe authentifiziert. Er
muss in der Datei „user.xml“ konfiguriert werden.
password Mit diesem Element wird das Passwort des Gruppenbenutzers an-
gegeben.
groupName Dieser Wert kann mehrfach vorkommen. Er benennt die zu deakti-
vierenden Gruppen von Signaturkarten.
Tabelle 43: F8Deactivate Anfragedokument
3.9.2 F8Deactivate Antwortdokument

f8DeactivateResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstel-
nonce Das Attribut kann fehlen. Ist es vorhanden, spiegelt es den
Wert des gleichen Elementes aus der Anfrage. Der Wert wird
immer genau dann gesetzt, wenn auch die Anfrage diesen
Wert gesetzt hatte.
Tabelle 44: F8Deactivate Antwortdokument
3.9.3 F8Deactivate Fehlerdokument
Bei der Ausführung der Funktion F8Deactivate können Fehler auftreten. Einige davon werden in

<code>
8001 Zu der bei den Aufrufparametern benannten Gruppe sind derzeit keine Signaturerstellungs-
einheiten verfügbar, die deaktiviert werden können. Der/Die Name(n) der Gruppe(n) wur-
de(n) nicht gefunden.
Tabelle 45: F8Deactivate Fehlerdokument
Seite 74 von 94
AuthentiDate
V3.0
3.10 F9List – Auflisten von Signaturkarten
Mit dem Aufruf der Funktion wird SLMBC veranlasst, eine Liste von Gruppen von Signaturer-
stellungseinheiten im gewünschten Detailgrad zu erstellen und an den Aufrufenden zu überge-
ben.
Der Zweck dieser Funktion ist es, dem Benutzer die gewünschte Detailinformation über die
Gruppen von Signaturerstellungseinheiten zur Verfügung zu stellen. So erfährt der Benutzer,
welche Gruppen zur Erstellung von Signaturen verwendet werden können. Diese Information
wird in der Regel benötigt, um mit Hilfe der Funktion F3Lock einen Vorgang zur Erzeugung von
Signaturen zu erstellen.
Der Benutzer kann die Detailgenauigkeit der Information bestimmen und kann die Liste auf be-
stimmte Gruppen einschränken, um das Kommunikationsvolumen zu verringern. Die Auswahl
trifft er durch entsprechende Parametrisierung des Aufrufes dieser Funktion. In jedem Fall wer-
den Informationen zu der Identität der Gruppen bereitgestellt.
Weiterhin kann der Benutzer auf seinen Wunsch hin getrennt nach Gruppen erfahren:
• wie viele Signaturerstellungseinheiten aufgrund der Konfiguration bekannt sind,
• über wie viele Signaturerstellungseinheiten davon SLMBC aktuell verfügt,
• wie viele Signaturerstellungseinheiten davon aktiviert sind (ohne weitere Interaktion mit
dem Inhaber Signaturen erstellen können),
• welche Signaturerstellungseinheit, identifiziert anhand ihres Schlüsselzertifikates, konfi-

guriert ist,
• welche Signaturerstellungseinheit, identifiziert anhand ihres Schlüsselzertifikates, für

SLMBC aktuell verfügbar ist,
• welche Signaturerstellungseinheit, identifiziert anhand ihres Schlüsselzertifikates, für

SLMBC aktuell aktiviert ist (d. h. ohne weitere Interaktion mit dem Inhaber Signaturen
erstellen kann),
• welches Schlüsselzertifikat in binärer Form zu der jeweiligen Signaturerstellungseinheit

gehört,
• welche Attributzertifikate in binärer Form zu welcher Signaturerstellungseinheit gehören,
• welche Zertifikatspfade in binärer Form zu den Schlüsselzertifikaten und Attributzertifika-

ten gehören (inklusive der Wurzelzertifikate als Vertrauensanker),
• welches Schlüsselzertifikat samt Zertifikatspfad in XML-Form zu der jeweiligen Signatur-

erstellungseinheit gehört und
• welche Attributzertifikate samt Zertifikatspfad in XML-Form zu der jeweiligen Signaturer-

stellungseinheit gehören.
Die Ausführung dieser Funktion ist für Vorgänge zur Erstellung von Signaturen ohne Auswir-
kung. Sie erstellt lediglich eine Liste basierend auf Informationen von SLMBC.
Seite 75 von 94
AuthentiDate
V3.0
3.10.1 F9List Anfragedokument

f9ListRequest nonce Mit diesem Attribut des Tags f9ListRequest wird
wiedergeben wird. SLMBC beachtet diesen Wert
selber nicht, sondern er dient nur dem Aufrufenden.
groupName Dieser Wert kann mehrfach vorkommen. Er be-
nennt die Gruppen von Signaturkarten, zu denen
die Daten aufgelistet werden sollen. Kommt dieser
Wert nicht vor, werden Informationen zu allen
Gruppen abgefragt.
levelOfDetail Der Wert gibt an, welche Details in dem Antwortdo-
kument zurückgesendet werden sollen.
Die Angabe hat Auswirkungen auf die Antwortzeit
von SLMBC und die Menge der zu übertragenen
Daten.
summarizedListRequest Mit diesem Element wird nur eine Liste der vorhan-
denen Gruppen angefragt. Dies ist die schnellste
Abfrage.
listWithBinaryCertificatesRe- Mit diesem Element wird eine Liste der vorhande-
quest nen Gruppen und aller binären Zertifikate angefragt.
Die Menge der Zertifikate kann eingeschränkt wer-
den.
listWithCertificateInfosRequest Mit diesem Element wird eine Liste der vorhande-
nen Gruppen und aller dekodierten Zertifikate ange-
fragt. Die Menge der Zertifikate kann eingeschränkt
werden.
Dieser Aufruf verbraucht die meisten Ressourcen,
da die Zertifikate in eine lesbare Form dekodiert
werden.
Tabelle 46: F9List Anfragedokument
3.10.2 F9List Antwortdokument
Das XML-Dokument, welches bei der Funktion f9List als Antwort entsteht, ist vielgestaltig und
komplex. Seine konkrete Gestalt hängt von dem Detailgrad der angeforderten Informationen ab.
Deshalb wird hier auf das XML-Schema und die darin enthaltene Dokumentation verwiesen. Die
folgende Tabelle erklärt nur die direkt zum Wurzelelement <f9ListResponse> gehörenden Ele-
mente. Zwar nennt die Tabelle verschiedene Elemente, jede Antwort kann aufgrund der Sche-
madefinition nur genau eines davon enthalten.

f9ListResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstel-
Seite 76 von 94
AuthentiDate
V3.0

Wert gesetzt hatte.
summarizedList Stellt zu jeder Gruppe Summen zur Verfügung (Anzahl der
Signaturerstellungseinheiten, ...).
listWithBinaryCertificates Stellt zu jeder Gruppe eine Liste der Signaturerstellungsein-
heiten mit den angeforderten binären Zertifikaten zur Verfü-
gung.
listCertificateInfos Stellt zu jeder Gruppe eine Liste der Signaturerstellungsein-
heiten mit den angeforderten Zertifikaten in Form von XML-
Strukturen zur Verfügung.
Tabelle 47: F9List Antwortdokument
3.10.3 F9List Fehlerdokument
Bei der Ausführung der Funktion F9List können Fehler auftreten. Einige davon werden in
Wert von
Bedeutung des Wertes
<code>
9001 Zu der bei den Aufrufparametern benannten Gruppe sind derzeit keine Signaturerstel-
lungseinheiten verfügbar, deren Daten aufgelistet werden können. Der/die Name(n) der
Gruppe(n) wurde(n) nicht gefunden.
9002 Der interne Aufruf der List-Funktion auf dem Zielrechner ist fehlgeschlagen. Diese Fehler-
meldung tritt nur auf, wenn SLMBC in zwei Teilen betrieben wird (siehe Kapitel 3.1.1
„Vollständige SAK zur Signaturerstellung“).
Tabelle 48: F9List Fehlerdokument
3.11 F10GetStatus – Abfragen eines Auftragsstatus
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, dem Benutzer Auskunft über den Zu-
stand eines oder mehrer Vorgänge zu geben. Mit Vorgängen sind sowohl Vorgänge zur Erzeu-
gung als auch zur Prüfung von Signaturen gemeint.
Der Zweck der Funktion ist, dem Benutzer aktuelle Information zum Zustand seiner Vorgänge
verfügbar zu machen. Die Funktion ist dazu gedacht, vom Benutzer wiederholt aufgerufen zu
werden, damit dieser zeitnah erfährt, ob die mit dem Vorgang beauftragte Arbeit bereits erledigt
ist. Erledigt sein kann der Vorgang auch aufgrund eines aufgetretenen Fehlers.
Der Aufruf dieser Funktion hat keine Wirkung auf irgendeinen Vorgang. Es wird nur aktuelle
Information aus dem Arbeitsspeicher von SLMBC zur Verfügung gestellt.
Seite 77 von 94
AuthentiDate
V3.0
3.11.1 F10GetStatus Anfragedokument

f10GetStatus nonce Mit diesem Attribut des Tags f10GetStatusRequest wird dem Aufrufen-
Request den die Möglichkeit gegeben, einen eindeutigen Wert mitzugeben, der in
Dieses Element kann mehrfach mit verschiedenen Verzeichnisnamen
aufgerufen werden, um den Status für mehrere Aufträge gleichzeitig
anzufragen.
listFiles Wenn der Wert auf „true“ gesetzt wird und der Auftrag vorher durch die
Funktion F12Freeze eingefroren wurde, werden alle Dateinamen für
jeden Auftrag zurückgeliefert.
Tabelle 49: F10GetStatus Anfragedokument
3.11.2 F10GetStatus Antwortdokument
Das XML-Dokument, welches bei der Funktion F10GetStatus als Antwort entsteht, ist vielgestal-
tig und komplex. Seine konkrete Gestalt hängt von den angeforderten Informationen ab. Des-
halb wird hier auf das XML-Schema und die darin enthaltene Dokumentation verwiesen. Die
folgende Tabelle erklärt nur die direkt zum Wurzelelement <f10GetStatusResponse> gehören-
den Elemente.

f10GetStatusResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstel-
Wert gesetzt hatte.
job Das Element kann mehrfach vorkommen oder gar nicht (wenn
der Benutzer aktuell keine Vorgänge hat). Jedes dieser Ele-
mente beschreibt den Zustand eines Vorganges. Auf spezielle
Anforderung gemäß den Parametern in der Anfrage kann so-
gar eine Liste der zu signierenden bzw. zu prüfenden Dateien
enthalten sein.
Tabelle 50: F10GetStatus Antwortdokument
Innerhalb eines jeden <job> Element befindet sich ein <jobStatus> Element, darin wiederum ein
Element namens <progressInfo> und darin wiederum eines mit dem Namen <jobState>. Letzte-
Seite 78 von 94
AuthentiDate
V3.0
res enthält eine Kennung, welche den aktuellen Zustand des Vorgangs zusammenfassend be-
schreibt. Es hat für Vorgänge zur Erstellung von Signaturen einen der Werte, welche in der
nachfolgenden Tabelle aufgeführt und in der Bedeutung erklärt werden.
Zwei weitere wichtige aber optionale Elemente sind <frozenSince> und <baseUrlForDownlo-
ad>.
Wenn ein Auftrag durch die Funktion F12Freeze eingefroren wurde, ist das Element <frozen-
Since> vorhanden und gibt den Zeitpunkt des Einfrierens wieder Das Element <baseUrlFor-
Download> enthält die Basis-URL, mit der die einzelnen Dateien zur temporären Betrachtung
aus dem sicheren Verzeichnis heruntergeladen werden können.
Wert von <jobState> Bedeutung des Wertes

locked Der Vorgang wurde mit der Funktion F3Lock erzeugt und die zu signieren-
den bzw. zu prüfenden Daten liegen noch unverändert und unveränderlich
im sicheren Verzeichnis. Ohne weitere Aktion des Benutzers verbleibt der
Vorgang in diesem Zustand.
signing Zum Vorgang wurde die Funktion F5SignFile aufgerufen. Aktuell werden
deshalb die Daten gerade signiert. Um keine Zwischenergebnisse verfügbar
zu machen, besteht eventuell schon kein Leserecht mehr für andere Benut-
zer als SLMBC. Nach Erstellung aller Signaturen wechselt der Zustand des
Vorganges automatisch in den Zustand „signingCompleted“.
signingCompleted Zum Vorgang wurden die Funktion F5SignFile aufgerufen, und es sind be-
reits alle erforderlichen Signaturen erstellt. Die signierten Daten liegen voll-
ständig im sicheren Verzeichnis. Sie können von anderen als SLMBC gele-
sen, aber nicht manipuliert werden. Ohne weitere Aktion des Benutzers ver-
bleibt der Vorgang in diesem Zustand.
verifying Zum Vorgang wurde die Funktion F6VerifyFile aufgerufen. Aktuell werden
deshalb die Daten gerade verifiziert. Um keine Zwischenergebnisse verfüg-
bar zu machen, besteht eventuell schon kein Leserecht mehr für andere
Benutzer als SLMBC. Nach Prüfung aller Signaturen wechselt der Zustand
des Vorganges automatisch in den Zustand „verifyingCompleted“.
verifyingCompleted Zum Vorgang wurden die Funktion F6VerifyFile aufgerufen, und es sind
bereits alle erforderlichen Signaturen geprüft. Die signierten Daten und de-
ren Ergebnisse liegen vollständig im sicheren Verzeichnis. Sie können von
anderen als SLMBC gelesen, aber nicht manipuliert werden. Ohne weitere
Aktion des Benutzers verbleibt der Vorgang in diesem Zustand.
terminating Für den Vorgang wurde die Funktion F7Unlock zum Zwecke des Löschens
des Vorganges oder zum Einleiten der Beendigung aufgerufen, nachdem er
den Zustand „signingCompleted“ bzw. „verifyingCompleted“ erreicht hatte.
SLMBC führt gerade die oben beschriebenen abschließenden Arbeiten
durch. Danach wird der Zustand automatisch zu „terminatedWithSuccess“
übergehen. Im Falle eines Fehlers bei den Aufräumarbeiten wird der Vor-
gang in den Zustand „aborting“ versetzt.
terminatedWithSuccess Zu dem Vorgang sind alle Signaturen erstellt bzw. geprüft worden, und das
ehemals sichere Verzeichnis inklusive aller darin enthaltenen Daten ist nun
wieder für den Benutzer beschreibbar. Ohne weitere Aktion des Benutzers
oder einen schwebenden Aufruf von F7Unlock zum Zwecke des Löschens
verbleibt der Vorgang in diesem Zustand.
aborting Während der Erstellung bzw. Prüfung der Signaturen oder bei den abschlie-
ßenden Aufräumarbeiten trat ein Fehler auf, oder der Vorgang wurde vom
Benutzer vorzeitig abgebrochen. SLMBC führt für den Vorgang gerade die
oben beschriebenen Aufräumarbeiten durch. Der Vorgang wird darauf au-
tomatisch in den Zustand „terminatedDueToFailure“ versetzt.
terminatedDueToFailure Während der Erstellung bzw. Prüfung der Signaturen oder bei den abschlie-
ßenden Aufräumarbeiten trat ein Fehler auf, oder der Vorgang wurde vom
Benutzer vorzeitig abgebrochen (F7Unlock). Die folgenden Aufräumarbeiten
wurden durchgeführt. Die Daten liegen nun im ursprünglichen Zustand in-
nerhalb des ehemals sicheren Verzeichnisses. Die Zugriffsrechte sind be-
reits wieder so gesetzt, dass auch andere als SLMBC modifizierend zugrei-
Seite 79 von 94
AuthentiDate
V3.0
Wert von <jobState> Bedeutung des Wertes

fen können.
Tabelle 51: F10GetStatus Jobstatus
3.11.3 F10GetStatus Fehlerdokument
Bei der Ausführung der Funktion F10GetStatus können Fehler auftreten. Einige davon werden
in Tabelle 62 erklärt. Alle anderen Fehler sind spezifisch für diese Funktion. Sie werden stets
mit einem XML-Dokument als Antwort signalisiert, welches das Element <errorResponse> als
Wurzelelement hat. Die nachfolgende Tabelle beschreibt die speziellen Kategorien der Ursa-
chen der spezifischen Fehler anhand der konkreten Werte für das XML-Tag <code>.

<code>
aufgetreten, welcher den Vorgang zur Ausgabe der Statusinformationen verhindert hat.
10002 Der bezeichnete Prozess, zu welchem Statusinformationen eingeholt werden sollen, ist
nicht initialisiert worden, oder er ist unbekannt (oder existiert nicht mehr).
Tabelle 52: F10GetStatus Fehlerdokument
3.12 F12Freeze – Anhalten eines Auftrags
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, einen bestehenden Vorgang zur Er-
zeugung von Signaturen oder Prüfergebnissen anzuhalten, damit der Benutzer die zu signie-
renden bzw. zu prüfenden Daten sichten kann.
Der Zweck dieser Funktion ist, SLMBC anzuweisen, für den Vorgang sämtliche Modifikationen
an den Daten des Benutzers vorübergehend anzuhalten und ihm damit die Möglichkeit der Be-
trachtung zu geben. Der Vorgang wird dabei eingefroren.
Während SLMBC die Signaturen zu einem Signaturauftrag erzeugt, kann der Benutzer nicht auf
das sichere Verzeichnis lesend zugreifen. Bei einem eingefrorenen Vorgang kann er jedoch mit
dem Aufruf der Funktion F14GetURL zu einer oder mehrer seiner Dateien jeweils einen URL
erfahren, unter dem ihm SLMBC die jeweilige Datei im Originalzustand zum Herunterladen an-
bietet.
Die Wirkung dieser Funktion ist, dass SLMBC den Vorgang nicht weiter bearbeitet. Diese Funk-
tion darf nicht für einen bereits eingefrorenen Vorgang aufgerufen werden. Ein Vorgang kann
nur eingefroren werden, wenn er sich in einem der Zustände „locked“, „signing“, „verifying“,
„signingCompleted“ oder „verifyingCompleted“ befindet.
Ist er eingefroren, ist kein weiterer Zustandswechsel möglich, bis die Funktion F7unlock oder
F13Thaw für den Vorgang aufgerufen wurde.
Nur wenn ein Vorgang eingefroren ist, kann die Funktion F14GetURL aufgerufen und können
Dateien per URL heruntergeladen werden.
Seite 80 von 94
AuthentiDate
V3.0
3.12.1 F12Freeze Anfragedokument

f12Freeze nonce Mit diesem Attribut des Tags f12FreezeRequest wird dem Aufrufenden
Request die Möglichkeit gegeben, einen eindeutigen Wert mitzugeben, der in der
Antwort wiedergeben wird. SLMBC beachtet diesen Wert selber nicht,
sondern er dient nur dem Aufrufenden.
Tabelle 53: F12Freeze Anfragedokument
3.12.2 F12Freeze Antwortdokument

f12FreezeResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung
des XML-Dokuments.
hatte.
lockedAsDir Der Wert bezeichnet den absoluten Pfad des sicheren Verzeich-
nisses des Vorganges, der durch F3Lock initiiert wurde.
Er dient als eindeutiger Schlüssel, damit der Benutzer seinen
Auftrag eindeutig identifizieren kann.
baseUrlForDownload Der Wert stellt die Basis-URL für den Datei-Download dar.
Nachdem ein Auftrag eingefroren wurde, kann über die Kombi-
nation Basis-URL + Dateiname die originale Datei aus dem si-
cheren Verzeichnis über einen normalen HTTP-Download tem-
porär heruntergeladen und z. B. angezeigt werden.
Tabelle 54: F12Freeze Antwortdokument
3.12.3 F12Freeze Fehlerdokument
Bei der Ausführung der Funktion F12Freeze können Fehler auftreten. Einige davon werden in

<code>
Seite 81 von 94
AuthentiDate
V3.0

<code>
aufgetreten, welcher die erfolgreiche Durchführung verhindert hat.
12002 Der Vorgang ist bereits im ‚freeze’-Zustand. Er kann nicht erneut in diesen versetzt werden.
12003 Der bezeichnete Vorgang, welcher in den ‚freeze’-Zustand versetzt werden soll, ist nicht
initialisiert worden. Er ist unbekannt (oder existiert nicht mehr).
12004 Der bezeichnete Vorgang ist nicht bereit, in den ‚freeze’-Zustand zu wechseln.
Tabelle 55: F12Freeze Fehlerdokument
3.13 F13Thaw – Fortsetzen eines Auftrags
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, einen mit Hilfe der Funktion F12Freeze
angehaltenen Vorgang zur Erzeugung von Signaturen fortzusetzen.
Der Zweck dieser Funktion ist, SLMBC mitzuteilen, dass der Benutzer die Daten genügend be-
trachtet hat und dass er deshalb die Fortsetzung der Arbeit des Vorganges wünscht.
Die Wirkung des Aufrufes der Funktion ist abhängig von dem Zustand, in welchem der Vorgang
eingefroren wurde. Nur ein zuvor mit F12Freeze eingefrorener Vorgang kann mit einem Aufruf
der Funktion aufgetaut werden.
Wurde er im Zustand „locked“ eingefroren, bewirkt der Aufruf nur die Löschung der Markierung,
die besagt, dass der Vorgang eingefroren ist. Ansonsten wird zusätzlich die Erstellung bzw.
Prüfung von Signaturen fortgesetzt.
3.13.1 F13Thaw Anfragedokument

f13ThawRequest nonce Mit diesem Attribut des Tags f13ThawRequest wird dem Aufrufenden
die Möglichkeit gegeben, einen eindeutigen Wert mitzugeben, der in
lockedAsDir Der Wert bezeichnet den absoluten Pfad des Sicheren Verzeichnisses
Tabelle 56: F13Thaw Anfragedokument
3.13.2 F13Thaw Antwortdokument
Seite 82 von 94
AuthentiDate
V3.0

f13ThawResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung des
XML-Dokuments.
nonce Das Attribut kann fehlen. Ist es vorhanden, spiegelt es den Wert des
gleichen Elementes aus der Anfrage. Der Wert wird immer genau
dann gesetzt, wenn auch die Anfrage diesen Wert gesetzt hatte.
lockedAsDir Der Wert bezeichnet den absoluten Pfad des sicheren Verzeichnis-
Er dient als eindeutiger Schlüssel, damit der Benutzer seinen Auf-
trag eindeutig identifizieren kann.
frozenSince Der Wert nennt den Zeitpunkt, wann der Auftrag mit der Funktion
F12Freeze eingefroren wurde.
thawedAt Der Wert nennt den Zeitpunkt, wann der Auftrag mit der Funktion
F13Thaw wieder aufgetaut wurde.
Tabelle 57: F13Thaw Antwortdokument
3.13.3 F13Thaw Fehlerdokument
Bei der Ausführung der Funktion F13Thaw können Fehler auftreten. Einige davon werden in

<code>
13002 Der Vorgang ist bereits im ‚thaw’-Zustand. Er kann nicht erneut in diesen versetzt werden.
13003 Der bezeichnete Vorgang, welcher in den ‚thaw’-Zustand versetzt werden soll, ist nicht initia-
lisiert worden. Er ist unbekannt (oder existiert nicht mehr).
13004 Der bezeichnete Vorgang ist nicht bereit, in den ‚thaw’-Zustand zu wechseln.
Tabelle 58: F13Thaw Fehlerdokument
3.14 F14GetURL – Dateidownload vorbereiten
Mit dem Aufruf dieser Funktion wird SLMBC veranlasst, dem Benutzer einen (oder mehrere)
URL(s) zu benennen, von dem (oder denen) er jeweils eine Datei des Vorganges zur Prüfung
oder Erstellung von Signaturen im Originalzustand herunterladen kann.
Mit Originalzustand ist derjenige Zustand einer Datei gemeint, in dem sie ehemals vom Aufruf
F3Lock in das sichere Verzeichnis verschoben wurde.
Der Zweck der Funktion ist lediglich, dem Benutzer auf komfortable Weise Information bereitzu-
stellen. Er könnte sich den jeweiligen URL zu einer Datei auch selbst anhand der in dem Hand-
buch dokumentierten Regeln konstruieren. Fehlen ihm dazu die Dateinamen, kann er sich über
den Aufruf der Funktion F10GetStatus eine Liste erstellen lassen.
Seite 83 von 94
AuthentiDate
V3.0
Der Aufruf der Funktion hat keine Wirkung auf den jeweiligen Vorgang oder die damit verbun-
denen Daten. Er liefert lediglich Status-Informationen.
Die Funktion kann nur für einen Vorgang aufgerufen werden, der zuvor mit einem Aufruf der
Funktion F12Freeze eingefroren wurde.
3.14.1 F14GetURL Anfragedokument

f14GetURLRequest nonce Mit diesem Attribut des Tags f14GetURLRequest wird dem Aufrufen-
den die Möglichkeit gegeben einen eindeutigen Wert mitzugeben,
der in der Antwort wiedergeben wird. SLMBC beachtet diesen Wert
selber nicht, er dient nur dem Aufrufenden.
lockedAsDir Der Wert bezeichnet den absoluten Pfad des Sicheren Verzeichnis-
file Dieser Wert kann mehrfach vorkommen. Er benennt den Namen der
zur verarbeitenden Datei relativ zum sicheren Verzeichnis.
Jeder hier übergebene Wert wird in einen URL umgewandelt und im
Antwortdokument zurückgeben. Mit dieser URL kann dann das Do-
kument zur Anzeige heruntergeladen werden.
Tabelle 59: F14GetURL Anfragedokument
3.14.2 F14GetURL Antwortdokument

f14GetURLResponse producedAt Das Attribut enthält die Systemzeit zum Zeitpunkt der Erstellung
des XML-Dokuments.
hatte.
lockedAsDir Der Wert bezeichnet den absoluten Pfad des sicheren Verzeich-
nisses des Vorganges, der durch F3Lock initiiert wurde.
Er dient als eindeutiger Schlüssel, damit der Benutzer seinen
Auftrag eindeutig identifizieren kann.
fileURL Das Element kann mehr als einmal vorkommen. Jedes nennt
den URL zum Herunterladen einer Datei. Die Elemente sind in
der Reihenfolge angeordnet, in der die Dateien in dem XML-
Dokument der Anfrage aufgezählt wurden.
Tabelle 60: F14GetURL Antwortdokument
Seite 84 von 94
AuthentiDate
V3.0
3.14.3 F14GetURL Fehlerdokument
Bei der Ausführung der Funktion F14GetURL können Fehler auftreten. Einige davon werden in

<code>
14002 Der bezeichnete Vorgang ist nicht initialisiert worden. Er ist unbekannt (oder existiert nicht
mehr).
14003 Der bezeichnete Vorgang ist nicht bereit, die getURL-Funktion auszuführen. Er ist nicht im
‚freeze’-Zustand.
Tabelle 61: F14GetURL Fehlerdokument
3.15 Download – Download einzelner Dateien
SLMBC stellt dem Benutzer, d. h. der aufrufenden Applikation, bei Bedarf eine Kopie der zu
verarbeitenden bzw. verarbeiteten Daten über einen verschlüsselten Download bereit. Zur An-
zeige müssen Mittel verwendet werden, die eine korrekte Darstellung der Daten gewährleisten.
Zum Aufruf der Funktion muss sich der Aufrufende an die HTTPS-Kommunikationsschicht von
SLMBC wenden und innerhalb des HTTP-Protokolls den Befehl GET für einen bestimmten URL
senden. Die URL kann der Aufrufende über die Funktion F14GetURL erfahren, oder das Ant-
wortdokument der Funktion F12Freeze beinhaltet das <baseUrlForDownload>-Tag, welches die
Basis-URL für den Datei-Download darstellt. Eine Kombination aus <baseUrlForDownload> und
übergebenem Dateinamen stellt den Download dar, der auch über einen normalen Web-
Browser realisiert werden kann.
Mit dem Aufruf der Funktion wird SLMBC veranlasst, dem Benutzer eine Kopie einer Datei aus
dem sicheren Verzeichnis eines Auftrages bereitzustellen. Bei der Kopie handelt es sich um
eine Datei in der Form, wie sie ehemals beim Aufruf der Funktion F3Lock an SLMBC überge-
ben wurde.
SLMBC stellt die Datei in Form eines binären Datenstromes als Antwort innerhalb der HTTP-
Kommunikationsschicht bereit. Dies entspricht gänzlich dem gewohnten Herunterladen einer
Datei per Web-Browser aus dem Internet.
Tritt bei der Bedienung der Funktion „download“ ein Fehler auf, wird SLMBC innerhalb der
HTTP-Kommunikationsschicht den Fehler in der dort üblichen Weise anzeigen: Entsteht der
Fehler, bevor der HTTP-Header der Antwort von SLMBC gesendet wurde, wird mit der Anzeige
eines entsprechenden HTTP-Fehlerwertes reagiert. Bei den Fehlerwerten handelt es sich um
diejenigen, die in [RFC 2616] im Abschnitt „Status Code Definitions“ erklärt sind. Tritt während
der Bereitstellung des Datenstromes zum Inhalt der Datei ein Fehler auf, wird der Datenstrom
abgebrochen. Der Aufrufende erkennt den Fehler daran, dass ihm nicht alle Daten gesendet
wurden. Denn SLMBC meldet im HTTP-Header der Antwort die exakte Menge der Daten des
Datenstromes, bevor er beginnt, den Datenstrom zu senden.
Seite 85 von 94
AuthentiDate
V3.0
Bitte beachten Sie: Bei der Integration des SLMBC als technische Komponente für Zertifizie-
rungsdienste müssen diese Hinweise vom Hersteller der Anwendung („Integrator“) an die End-
benutzer dieser Anwendung weitergegeben werden.
3.16 Prüftiefe
Die Prüfung der Signaturen kann in fünf verschiedenen Tiefen (Level) stattfinden. Die Prüftiefe
sagt aus, bis zu welcher Qualität eine Signatur verifiziert werden soll.
Je höher die Prüftiefe eingerichtet wird, desto genauer werden die Prüfungen der einzelnen
Signaturen realisiert. Wird eine bestimmte Prüftiefe erreicht, bedeutet dies, dass die Prüftiefe für
diese und alle darin enthaltenen Prüfungen positiv war. Im Grunde genommen bedeutet dies,
dass bei einer Prüfung einfach alle Prüfungsschritte von der niedrigsten Prüftiefe bis zur ange-
forderten Prüftiefe in der Reihenfolge durchgeführt werden, bis entweder alle Prüfungen erfüllt
wurden oder eine fehlschlug.
Welche Schritte bei der jeweiligen Prüftiefe durchgeführt werden und was die jeweilige Prüftiefe
im Prüfresultat bedeutet, ist im Folgenden kurz aufgeführt.
Für den Betrieb im signaturgesetzkonformen Umfeld muss die Prüftiefe fullStatus gewählt wer-
den.
• decode
Bei dieser Prüftiefe werden nur die binäre Datenstruktur decodiert und die daraus ge-
wonnene Information im Prüfresultat bereitgestellt. Wenn diese Prüftiefe erreicht wird, ist
also die Struktur der binären Datenstruktur intakt und entspricht den Formatspezifikatio-
nen.
• signature
Bei dieser Prüftiefe wird der Level decode und zusätzlich die Signaturen in den Daten-
strukturen mathematisch geprüft. Wenn diese Prüftiefe erreicht wird, ist also der Finger-
abdruck des Dokuments in Ordnung. Dies bedeutet, dass das Dokument nicht verändert
wurde und damit in der ursprünglichen Version existiert.
• chain
Bei dieser Prüftiefe werden die oben genannten Level geprüft und zusätzlich der Zertifi-
katspfad zu jeder Signatur geprüft. Damit wird dann abgesichert, dass der jeweils Unter-
zeichnende wirklich die benannte Person ist, weil dies durch die Zertifikate von vertrau-
enswürdiger Stelle bestätigt wird.
• signerStatus
Bei dieser Prüftiefe werden die oben genannten Level geprüft und zusätzlich der Status
des Zertifikats des Unterzeichners beim Zertifizierungsdienstanbieter eingeholt. Damit
wird bestimmt, ob der private Schlüssel des Unterzeichners zum Zeitpunkt, welcher als
Prüfzeitpunkt gewählt wurde, gültig war.
Bitte beachten Sie: Zum Erreichen dieser Prüftiefe muss in der Regel Online-
Kommunikation stattfinden.
• fullStatus
Bei dieser Prüftiefe werden die oben genannten Level geprüft und zusätzlich Statusin-
formationen zu sämtlichen anderen Zertifikaten der zur Prüfung notwendigen Zertifikats-
kette eingeholt. Dies geschieht in ebensolcher Weise wie beim Zertifikat des Unter-
Seite 86 von 94
AuthentiDate
V3.0
zeichners. Dies wird für jede im Signaturcontainer enthaltene Signatur getrennt geprüft.
Bitte beachten Sie: Zum Erreichen dieser Prüftiefe muss in der Regel Online-
Kommunikation stattfinden.
Bei der gesetzten Prüftiefe „fullStatus“ greift der Caching-Mechanismus von SLMBC und ver-
mindert dadurch die Anzahl der Online-Zugriffe. Beim Cachen prüft SLMBC, ob es schon zu
den zu überprüfenden Zertifikaten eines Dokuments ein Ergebnis aus einer vorherigen Prüfung
gibt und nutzt dieses Ergebnis. Dies bedeutet, dass bei der Prüfung eines Stapels mit n-Seiten
bei der ersten Prüfung das Zertifikat des Signierenden online angefragt wird und alle weiteren
Prüfungen dann auf den Cache zugreifen, sofern die jeweiligen Zeitpunkte der Signaturerstel-
lung vor dem Zeitpunkt der Auskunft liegen.
Der erste Online-Zugriff kann im Vergleich zu Offline-Prüfungen abhängig von der Netzauslas-
tung langsamer sein. Jedoch ist jede weitere Prüfung innerhalb des Caches wesentlich schnel-
ler als die Erste. Auf einem Standard-PC können so bis zu vier Signaturen pro Sekunde geprüft
werden.
Auf Anforderung werden in den Prüfergebnissen Nachweise über die Existenz und Sperrung
von Zertifikaten im qualifiziert elektronisch signierten Original zusammen mit für die Prüfung
notwendigen und aus einem öffentlichen Verzeichnis abgefragten Zertifikaten bereitgestellt.
Diese Nachweise und Zertifikate sind zur Archivierung gedacht, damit auf Basis ihrer Informati-
on die Prüfung zu einem späteren Zeitpunkt wiederholt werden kann. Beim Erstellen eines Auf-
trages zur Prüfung von Signaturen kann SLMBC mitgeteilt werden, dass zu den zu prüfenden
Signaturen solche Nachweise und Zertifikate existieren, die sie dann anstelle erneut eingeholter
Nachweise ausschließlich verwendet. SLMBC prüft die Vertrauenswürdigkeit sowohl neu ein-
geholter als auch bereitgestellter Nachweise und Zertifikate anhand ihrer qualifizierten elektro-
nischen Signatur.
Zur Beurteilung der Vertrauenswürdigkeit von Zertifikaten und Nachweisen verlässt sich
SLMBC auf eine im lokalen Dateisystem sicher hinterlegte Menge von Vertrauensankern in
Form von Wurzelzertifikaten.
Das Ergebnis der Prüfung einer Signatur wird als so genannter „Evidence-Record“ in Form ei-
nes XML-Dokuments an den Aufrufenden zurückgegeben. Die Inhalte dieses „Evidence-
Record“ beschreiben:
• auf welche Daten sich die Signatur bezieht,
• ob die Daten unverändert sind,
• welchem Signaturschlüsselinhaber die Signatur zuzuordnen ist,
• welche Inhalte das qualifizierte Zertifikat, auf dem die Signatur beruht, aufweist,
• welche Inhalte zugehörige Attribut-Zertifikate aufweisen und
• zu welchem Ergebnis die Nachprüfung von Zertifikaten führte, durch die die Zuordnung
eines Signaturprüfschlüssels zu einer identifizierten Person durch ein qualifiziertes Zerti-
fikat zu bestätigen und dieses jederzeit für jeden über öffentlich erreichbare Kommunika-
tionsverbindungen nachprüfbar und abrufbar zu halten ist.
Seite 87 von 94
AuthentiDate
V3.0
4 Protokoll- und Fehlermeldungen
Nachfolgend sind die Einträge in die Protokolldateien beschrieben. Es wird darauf hingewiesen,
welche Einträge auf Fehlerzustände hinweisen können.
Ferner sind die Fehlermeldungen aufgeführt, die beim Start von SLMBC auftreten können. Dies
betrifft in der Regel Fehler in der Konfigurationsdatei oder Fehler bei der Sicherheit der Einsatz-
umgebung.
Außerdem sind die allgemeinen Fehler der Schnittstelle von SLMBC beschrieben, die bei allen
Funktionsaufrufen auftreten können.
4.1 Einträge in die Protokolldatei
Protokolleinträge weisen das Tag <log4j:event> auf, dass das Protokollereignis kennzeichnet.
Bei der SLMBC-Protokolldatei wird dabei aufgeführt, welcher Programmteil das Ereignis ausge-
löst hat, wann es aufgetreten ist (Timestamp), welchem Protokolllevel das Ereignis zugeordnet
ist und aus welchem Programmfaden (Thread) es stammt. Die EVG-Protokolldatei führt zusätz-
lich auf, welcher Benutzer für das Ereignis verantwortlich ist; dabei ist zwischen dem Betriebs-
systembenutzer und dem HTTP-Benutzer zu unterscheiden. Der Betriebssystembenutzer muss
immer der Benutzer sein, unter dem SLMBC läuft. Der HTTP-Benutzer ist der Benutzer, der
aufgrund der HTTP-Basic Authentication beim Funktionsaufruf erkannt wurde. Für die Funktio-
nen F1, F2, F8 und F9 ist dies der entsprechend konfigurierte interne Benutzer. Darüber hinaus
wird der Zeitstempel in UTC-Zeit angegeben.
Der eigentliche Protokolleintrag befindet sich innerhalb des Tags <log4j:message> und be-
schreibt das Protokollereignis im Klartext.
Die EVG-Protokolldatei führt noch im Tag <log4j:locationInfo> die Referenz zur Java-Methode
auf, die den Protokolleintrag erzeugt hat.
Einträge im Tag <log4j:throwable> weisen auf schwere Fehler hin. Diese sind umgehend zu
beheben, die Fehlerursache ist zu klären.
Fehler Eintrag in der Protokolldatei Ursache/Lösung

Signaturerstellungs- com.authentidate.common.exceptions. Ursache: Eine Signaturerstellungs-
einheit ist zwei Be- ConfigurationException: einheit wird über das dazugehörige
nutzergruppen zuge- (Gruppe2.0) new signer 'signer-1' of Zertifikat identifiziert. Diese Zertifikate
ordnet (SLMBC Pro- group 'Gruppe2' is already configured werden im Signaturerstellerverzeich-
tokoll) for group 'Gruppe1' as signer 'signer-1'. nis innerhalb des Gruppenverzeich-
nisses abgelegt. Ein Zertifikat wurde
mehreren Gruppen zugeordnet, ist
also mehrfach vorhanden.
Lösung: Löschen Sie das fehlerhafte
Signaturerstellerverzeichnis oder ko-
pieren Sie das korrekte Zertifikat in
das Verzeichnis und löschen das
fehlerhafte.
Signaturgruppenver- com.authentidate.common.exceptions. Ursache: Im Signaturgruppenver-
zeichnis enthält zu- ConfigurationException: zeichnis darf sich nur die Benutzerzu-
Seite 88 von 94
AuthentiDate
V3.0

sätzliche Datei found a file which is not a directory ordnungsdatei user.xml befinden. Es
(SLMBC Protokoll) underneath the group directory. only befindet sich eine weitere Datei in
directories are allowed here. diesem Verzeichnis.
Lösung: Löschen Sie die Datei aus
dem Signaturgruppenverzeichnis.
Kein Signatur- com.authentidate.common.exceptions. Ursache: Jedes Signaturerstellerver-
zertifikat im Signatu- ConfigurationException: zeichnis unter dem Signaturgruppen-
rerstellerverzeichnis found no PublicKeyCertificate (PKC) verzeichnis muss eine Zertifikatsdatei
(SLMBC Protokoll) underneath the signer identification enthalten, damit die Signaturerstel-
directory 'config\signer- lungseinheit eindeutig erkannt werden
groups\SIRA#1\signer-2'. kann. Ist kein Signaturzertifikat zu
finden, kann der Signaturersteller
nicht zugeordnet werden. Der Fehler
tritt auch dann auf, wenn sich nur ein
Attributzertifikat in dem Verzeichnis
befindet.
Lösung: Kopieren Sie das Signatur-
zertifikat in das Verzeichnis des
Signaturerstellers.
Keine Verzeichnisse com.authentidate.common.exceptions. Ursache: Das Signaturgruppenver-
Signaturgruppenver- ConfigurationException: zeichnis muss mindestens ein Signa-
zeichnis angelegt found no PublicKeyCertificates in the turerstellerverzeichnis sowie das Ver-
(SLMBC Protokoll) cert path certificates directory zeichnis ca-and-root-certs enthalten.
'C:\AD_SLMBC_3.0\Server\config\signe Diese Verzeichnisse dürfen nicht leer
r-groups\SIRA#2\ca-and-root-certs'. sein.
Lösung: Legen Sie entsprechende
Verzeichnisse an und legen Sie die
nötigen Zertifikate dort ab oder lö-
schen Sie das Signaturgruppenver-
zeichnis.
Keine Benutzerzu- com.authentidate.common.exceptions. Ursache: Jedes Signaturgruppenver-
ordnungsdatei ange- ConfigurationException: zeichnis muss eine Benutzerzuord-
legt (SLMBC Proto- java.io.IOException: IOException while nungsdatei enthalten, die festlegt,
koll) reading file welche Benutzer diese Signaturgrup-
'C:\AD_SLMBC_3.0\Server\config\signe pe bedienen dürfen. Die Benutzerzu-
r-groups\SIRA#1\user.xml': ja- ordnungsdatei ist nicht vorhanden.
va.io.IOException: Stream closed Lösung: Legen Sie die Benutzerzu-
ordnungsdatei an.
Mehrere Signaturzer- com.authentidate.common.exceptions. Ursache: Eine Signaturerstellungs-
tifikate in einem ConfigurationException: einheit muss eindeutig konfiguriert
Signaturerstellerver- found a 2nd PublicKeyCertificate (PKC) sein. Dies erfolgt durch das Signatur-
zeichnis (SLMBC underneath the signeridentification zertifikat, das in das Signaturersteller-
Protokoll) directory. only one PKC is allowed per verzeichnis kopiert wird. Befinden sich
signer. (config\signer- zwei Signaturzertifikate in einem
groups\SIRA#1\signer-1\USER- Signaturerstellerverzeichnis, liegt
799947429.crt) keine Eindeutigkeit vor.
Lösung: Löschen Sie das falsche
Signaturzertifikat aus dem Signatu-
rerstellerverzeichnis.
Signaturzertifikat und com.authentidate.common.exceptions. Ursache: Ein Attributzertifikat ist im-
Attributzertifikat ConfigurationException: mer einem Signaturzertifikat eindeutig
stimmen nicht über- the following attribute certificate(s) zugeordnet. Im Signaturerstellerver-
ein (SLMBC Proto- do(es) not belong to the user certifiate: zeichnis muss zum Signaturzertifikat
koll) (0) das passende Attributzertifikat (gege-
C:\AD_SLMBC_3.0\Server\config\signe benenfalls auch mehrere) abgelegt
r-groups\SIRA#1\signer-2\ATTR- werden. Es wurde in diesem Fall ein
799947428.crt falsches Attributzertifikat abgelegt.
# CertIssuer: Lösung: Löschen Sie das fehlerhafte
Seite 89 von 94
AuthentiDate
V3.0

0.2.262.1.10.7.20=1+CN=SigG Test CA Attributzertifikat aus dem Signatu-
6:PN,OU=TeleSec,O=Deutsche Tele- rerstellerverzeichnis.
kom AG,C=DE# CertSerial:
799947428# CertHolder:
0.2.262.1.10.7.20=1+CN=SigG Test CA
6:PN,OU=TeleSec,O=Deutsche Tele-
kom AG,C=DE# CertHolderSerial:
799947429# CertAttributes:
0.4.0.1862.1.2 (QCLimitValue)
Fehlerhafte PIN Ein- Authentication for terminal was not Ursache: Es wurde eine falsche PIN
gabe (EVG Protokoll) successful. Timeout or wrong PIN 'Cy- eingegeben.
berCti1' Lösung: Geben Sie die korrekte PIN
ein. Falls dieser Fehler auftaucht,
ohne dass ein Signaturkarteninhaber
eine PIN eingegeben hat, liegt ein
Missbrauchsfall vor!
Tabelle 62: Fehlermeldungen in den Protokolldateien
4.2 Fehlermeldungen beim Start von SLMBC
Kann SLMBC nicht starten, liegt entweder ein Fehler in der Konfigurationsdatei vor, oder die
Zugriffsrechte auf die Verzeichnisse sind nicht passend gesetzt.
Fehlermeldung Ursache/Lösung
configuration read from Ursache: Die Zugriffsrechte sind fehlerhaft gesetzt.
C:\AD_SLMBC_3.0\Server\slmbc-config.xml SLMBC meldet, welcher Benutzer unberechtigterweise
is wrong: Zugriff hat. Es wird ebenfalls das Verzeichnis mitgeteilt,
checking access permissions failed für das diese Zugriffsrechte bestehen.
Lösung: Prüfen Sie, weshalb die Zugriffsrechte beste-
hen. Dies kann ein Missbrauchsversuch sein! Setzen
Sie die Zugriffsrechte entsprechend.
error when trying to parse the configuration Ursache: Die Konfigurationsdatei ist syntaktisch fehler-
from C:\AD_SLMBC_3.0\Server\slmbc- haft.
config.xml: Lösung: Prüfen Sie die Fehlermeldung. Sie enthält
javax.xml.bind.UnmarshalException: Element Hinweise auf die fehlerhafte Syntax. Korrigieren Sie die
type "xml" must be followed by either Konfigurationsdatei entsprechend.
attribute specifications, ">" or "/>".
error when trying to parse the configuration Ursache: Die XML-Struktur der Konfigurationsdatei ist
from C:\AD_SLMBC_3.0\Server\slmbc- nicht wohlgeformt.
javax.xml.bind.UnmarshalException: The Hinweise auf die fehlerhafte XML-Struktur. Korrigieren
markup in the document preceding the root Sie die Konfigurationsdatei entsprechend.
element must be well-formed.
error when trying to parse the configuration Ursache: Die XML-Struktur der Konfigurationsdatei
from C:\AD_SLMBC_3.0\Server\slmbc- enthält ein unbekanntes Tag.
javax.xml.bind.UnmarshalException: Unex- Hinweise auf die fehlerhafte XML-Struktur. Korrigieren
pected end of element {}:httpServer Sie die Konfigurationsdatei entsprechend.
Exception in thread "main" ja- Ursache: Die Konfigurationsdatei enthält einen falschen
va.lang.IllegalArgumentException: unsup- Wert innerhalb eines Tags.
ported logLevel: INFOS Lösung: Prüfen Sie die Fehlermeldung. Sie enthält
Hinweise auf das falsche Tag. Korrigieren Sie die Konfi-
gurationsdatei entsprechend.
usage: SIRServer <confFile> Ursache: Die Konfigurationsdatei wurde nicht angege-
ben.
Seite 90 von 94
AuthentiDate
V3.0
Fehlermeldung Ursache/Lösung
Lösung: Geben Sie beim Start von SLMBC die Konfigu-
rationsdatei als einzigen Parameter an.
Exception in thread "main" ja- Ursache: Es wurde ein falscher Hostname angegeben.
va.net.UnknownHostException: testhost: Lösung: Tragen Sie den korrekten Hostname in die
testhost Konfigurationsdatei ein.
Exception in thread "main" Ursache: Es wurde eine Portnummer angegeben, die
org.mortbay.util.MultiException[java.net.Bind bereits verwendet wird.
Exception: Address already in use: Lösung: Geben Sie eine andere Portnummer an, unter
JVM_Bind] der SLMBC erreicht werden kann.
Exception in thread "main" Ursache: Es wurde eine nicht unterstützte Ciphersuite
org.mortbay.util.MultiException[java.io.IOExc konfiguriert.
eption: Lösung: Die Ciphersuites sollten nicht geändert wer-
Could not create JsseListener: ja- den. Konfigurieren Sie die korrekten Ciphersuites.
va.lang.IllegalArgumentException: Unsup-
ported ciphersuite
TLS_RSA_WITH_AES_512_CBC_SHA]
Tabelle 63: Fehlermeldungen beim Start von SLMBC
4.3 Fehlermeldungen der Schnittstelle von SLMBC
Aufgrund der Verwendung mehrerer klar getrennter Protokollschichten über dem TCP-Protokoll
ist SLMBC in der Lage, Fehler innerhalb der jeweiligen Schichten differenziert zu melden.
Wird zum Beispiel mit dem Benutzer (d. h. mit der Software-Applikation) keine Einigung über
das zu verwendende Verschlüsselungsverfahren innerhalb der SSL-Schicht für das HTTPS-
Protokoll erzielt, wird innerhalb dieses Protokolls auch die übliche Fehlermeldung erzeugt.
Bei den Aufrufen per XML über HTTPS verlangt SLMBC immer eine Identifikation und Authenti-
sierung des Aufrufenden per HTTP Basic Authentication. Wird dies vom Aufrufenden nicht ü-
bermittelt, reagiert SLMBC mit der vom Standard [RFC 2617] für das HTTP-Protokoll spezifizier-
ten Fehlermeldung innerhalb der HTTP-Schicht.
Formale Fehler auf der Ebene des proprietären Protokolls des SLMBC, das aus einem XML-
Dokument für den Aufruf und einem XML-Dokument für die Antwort besteht, werden innerhalb
dieser Schicht mit einem XML-Dokument zur Fehlerbeschreibung signalisiert.
Dieses XML-Dokument besitzt immer das Wurzelelement <errorResponse>. Es wird anstelle

des üblichen XML-Antwortdokuments der aufgerufenen Funktion an den Aufrufenden übermit-
telt. Seine Struktur ist bewusst einfach gehalten. Das Element <errorResponse> hat nur maxi-
mal zwei Attribute und immer genau drei eingebettete Elemente eines einfachen XML-
Datentyps.
Name und Bedeutung der Werte der Attribute und eingebetteten Elemente sind in der folgenden
Tabelle erklärt.
Name Bedeutung des Wertes

<producedAt> Der Wert enthält die Systemzeit zum Zeitpunkt der Erstellung der Fehlermeldung.
<nonce> Der Wert kann fehlen. Ist er vorhanden, spiegelt er den Wert des gleichen Elementes
aus der Anfrage. Der Wert wird immer genau dann gesetzt, wenn auch die wohlge-
formte Anfrage diesen Wert gesetzt hatte.
Seite 91 von 94
AuthentiDate
V3.0
Name Bedeutung des Wertes

<code> Enthält eine Zahl zur Kategorisierung der Ursache des Fehlers. Manche Ursachen
können bei allen Funktionen auftreten. Die Zahlen zu Ihrer Kategorisierung sind in der
nachfolgenden Tabelle erklärt. Andere Kategorien von Ursachen sind nur bei be-
stimmten Funktionen möglich. Diese sind dann bei der Erklärung der Funktionen ge-
sondert erwähnt.
<message> Enthält eine Beschreibung der Ursache des Fehlers in englischer Sprache.
<method> Enthält den Namen der Funktion, bei deren Aufruf die Fehlermeldung erzeugt wurde.
Ist der Namen nicht bekannt, zum Beispiel weil das XML-Dokument der Anfrage nicht
wohlgeformt war, enthält dieses Element den Wert „*unknown method*“. Ansonsten
handelt es sich bei dem angegebenen Wert um die Kurzbezeichnung der Funktion,
wie sie in Kapitel 3.2 bis 3.15 aufgeführt ist.
Tabelle 64: Allgemeine Fehlermeldungen (XML-Schemata)
Mit dem Wert des Elementes <code> innerhalb des XML-Dokuments mit dem Wurzelelement
<errorResponse> wird die Kategorie der Ursache des Fehlers in einer Form dargestellt, die ma-
schinell einfach weiterverarbeitbar ist. Somit kann der Prozess des Benutzers auf einige Fehler
selbständig reagieren und zum Beispiel bei einem temporären Fehler die gewünschte Aktion
später erneut veranlassen. Einige der konkreten Werte für <code> werden bei Fehlern benutzt,
die bei allen Funktionen von SLMBC entstehen können. Diese generellen Fehler sind bezüglich
der Werte für <code> in der Tabelle 65 erklärt. Andere Werte sind jeweils bei der jeweiligen
Funktion beschrieben.
Wert Bedeutung des Wertes

von
<code>
1 Das XML-Dokument der Anfrage ist nicht wohlgeformt. Es enthält syntaktische und / oder
semantische Fehler oder ist gar kein XML-Dokument.
2 Das XML-Dokument in der Anfrage ist vom Datenumfang her zu groß. Ob es sich um ein
wohlgeformtes XML-Dokument handelt, wurde eventuell noch nicht überprüft.
4 Das Wurzelelement des XML-Dokuments der Anfrage gehört zu keiner Funktion, die von der
aktuellen Installation und Konfiguration von SLMBC unterstützt wird.
5 Während der Ausführung der aufgerufenen Funktion trat ein Fehler in SLMBC auf, der per-
manent ist, weil er voraussichtlich bei einem erneuten Aufruf derselben Funktion mit densel-
ben Parametern wieder auftreten wird. Die Fehlerursache ist nicht näher spezifiziert. Dieser
Wert wird zum Beispiel verwendet, wenn Zugriffe auf das lokale Dateisystem nicht wie erfor-
derlich möglich sind.
6 Während der Ausführung der aufgerufenen Funktion trat ein Fehler in SLMBC auf, der tem-
porär ist, weil er voraussichtlich bei einem späteren erneuten Aufruf derselben Funktion mit
denselben Parametern wieder auftreten wird. Die Fehlerursache ist nicht näher spezifiziert.
Dieser Wert wird zum Beispiel verwendet, wenn Zugriffe über das Internet auf entfernte
Dienste (Zeitstempeldienst oder Verzeichnis eines Zertifizierungsdiensteanbieters) aktuell
nicht wie erforderlich möglich sind.
8 Der Anfragende hat sich nicht korrekt authentifiziert. Dieser Fehlerwert wird ausschließlich
für die Authentifizierung beim Aufruf verwendet. Entweder stimmt die angegebene Identität
nicht, oder das Passwort ist für die angegebene Identität nicht richtig.
9 Der Anfragende ist laut Konfiguration von SLMBC nicht berechtigt, die genannte Funktion
aufzurufen. Der Fehlerwert wird ausschließlich bezüglich der bei der Authentifizierung beim
Aufruf festgestellten Identität des Aufrufenden verwendet.
10 Die Lizenz von SLMBC erlaubt den Aufruf nicht. Mögliche Ursachen sind zum Beispiel, dass
die in der Lizenz bestimmte Nutzungsdauer abgelaufen ist oder dass eine Grenze der quanti-
tativen Nutzung überschritten wurde (maximale Anzahl erstellter bzw. geprüfter Signaturen).
11 Die Lizenz von SLMBC erlaubt den Aufruf der Funktion oder die Nutzung einer besonderen
Eigenschaft der Funktion nicht.
12 Der Lizenzmechanismus von SLMBC kann den Zählerstand zur quantitativen Nutzung der
Funktionen bzw. ihrer Eigenschaften nicht richtig abspeichern.
Seite 92 von 94
AuthentiDate
V3.0
Wert Bedeutung des Wertes

von
<code>
13 Der für die SSL-Kommunikation verwendete Algorithmus entspricht nicht den konfigurierten
Anforderungen von SLMBC.
14 Die Schlüssellänge des für die SSL-Kommunikation verwendeten Algorithmus entspricht
nicht den konfigurierten Anforderungen von SLMBC.
15 Die Parameter im XML-Dokument des Aufrufes einer Funktion können vom SLMBC so nicht
akzeptiert werden.
20001 Bei dem ersten Versuch einen Abbruch des Vorganges durchzuführen, ist ein Fehler aufge-
treten. Es wird ein zweiter Versuch gestartet, ohne jedoch das „Sichere Verzeichnis“ zurück-
zusetzen.
20002 Es ist bei der Bearbeitung des Auftrages ein nicht weiter spezifizierbarer Fehler aufgetreten.
Weitere Details stehen in der Protokoll-Datei.
Der EVG wurde gestoppt und erneut gestartet, es lag kein gültiger Zustand des Verarbei-
tungsvorgangs vor.
Weitere Details wurden als Rückgabewert zurückgeliefert.
Tabelle 65: Allgemeine Fehlermeldungen (Beschreibung)
Seite 93 von 94
AuthentiDate
V3.0
5 Literaturverzeichnis
[1] Gesetz über Rahmenbedingungen für elektronische Signaturen, 16. Mai 2001, Stand:
Geändert durch Art. 1 G v. 4. 1.2005 I 2
[2] Verordnung zur elektronischen Signatur, 16. November 2001, Stand: Geändert durch
Art. 2 G v. 4. 1.2005 I 2
[3] AuthentiDate SLM Base Component V3.0 Sicherheitshandbuch, Version 1.2.6,
22.11.2007
Seite 94 von 94

Sprache

Benutzerhandbuch SLMBC

Hochgeladen von

Dokumentinformationen

Beschreibung:

Originaltitel

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Benutzerhandbuch SLMBC

Originaltitel:

Hochgeladen von

Beschreibung:

Copyright:

Benutzer- und Administrationshandbuch

AuthentiDate SLM Base

© 2006, 2007 AuthentiDate Deutschland GmbH – Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung nur mit ausdrücklicher Genehmigung

AuthentiDate Deutschland GmbH, Großenbaumer Weg 6,

3.7.2 F6VerifyFile Antwortdokument............................................................................ 70

Abbildung 1: Steuerung eines Vorgangs.................................................................................... 11

Tabelle 1: Parameter des XML-Elements <httpServer>............................................................. 17

Tabelle 50: F10GetStatus Antwortdokument ............................................................................. 78

„AuthentiDate Signature Lifecycle Management Base Component“ (Kurzbezeichnung „SLMBC“)

1.1 Aufbau des Handbuchs

Das Kapitel „SLMBC-Schnittstelle“ beschreibt die Möglichkeiten, um SLMBC durch Benutzer

Einsatzszenarien sind zum Beispiel die Bestätigung des Medienbruchs im Scan-Capture-

1.3 Prozessumgebung (stark/schwach)

Im Gegensatz zu anderen Signaturanwendungskomponenten kann SLMBC nicht nur an Ar-

Aus diesem Grund werden zwei Einsatz-Szenarien definiert.

• Als stark prozessgebundener Einsatz wird ein abgeschlossener Betrieb bezeichnet,

Im schwach prozessgebundenen Einsatz können Multisignatur-SSEE eingesetzt werden, um

1.4 Vorgangs-/Auftragssteuerung (Signaturerzeu-

Erstellung Vorgang 1 f3Lock Datenübergabe f5SignFile f7Unlock Datenrückgabe Abschluss Vorgang 1

Abbildung 1: Steuerung eines Vorgangs

Erstellung Vorgang 2 f3Lock Datenübergabe f5SignFile f7Unlock Datenrückgabe Abschluss Vorgang 2

Erstellung Vorgang 3 f3Lock Datenübergabe f5SignFile f7Unlock Datenrückgabe Abschluss Vorgang 3

Erstellung Vorgang 4 f3Lock Datenübergabe f5SignFile f7Unlock Datenrückgabe Abschluss Vorgang 4

Abbildung 2: Steuerung paralleler Vorgänge

1.5 Sichere Verzeichnisse

2 Konfiguration von SLMBC

Mit den Nebenkonfigurationsdateien werden die Chipkartenleser, die Signaturerstellungs-

(1) Änderungen durch den Anwender ggfs. erforderlich bzw. möglich,

Da einige Konfigurationen komplexe XML-Subelemente beinhalten, die die Grenzen dieses

2.1.1 Element <httpServer>

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

2.1.2 Element <clientNetworkAccessParameter>

Mit dem Element <clientNetworkAccessParameter> werden Verbindungsparameter definiert,

• authenticationConfigs – Einfache Konfiguration mit Benutzername und Passwort.

• proxyConfigs – Konfiguration eines Proxys für HTTP-Verbindungen. Java-Parameter

• httpAccessConfigs – Vollständige Konfiguration der Zugangsdaten zu einer URL-

• httpClientsConfigurations – Beschreibung einer URL-Verbindung mit Referenzierung auf

• timestampClients – Vollständige Konfiguration des Zugangs zu einem Zeitstempel-

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

2.1.3 Element <logging>

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

2.1.4 Element <evgLogging>

20 general metronome factory

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

2.1.5 Element <weakProcessBoundEnvironment>

Zeile XML-Tag Level Beschreibung

2.1.6 Element <knownAttributeOid>

Zeile XML-Tag Level Beschreibung

2.1.7 Element <authenticationPolicies>

Mit dem Element <authenticationPolicies> werden einerseits die maximalen Wiederholungsver-

Zeile XML-Tag Level Beschreibung

Zeile XML-Tag Level Beschreibung

2.1.8 Element <license>

Zeile XML-Tag Level Beschreibung