Wenn dies der Fall ist wird die zu diesem Zertifikat gehörige also die das ZDAZertifikat ausstellende Signatur

Der Ablauf der Prüfung nach dem Kettenmodell beginnt von unten (s. Abb. 1):

Die Signatur am Dokument muss auf einem im Zeitpunkt der Erstellung der Signatur gültigen Zertifikat beruhen. In unserem Beispiel ist dies ein Anwender-Zertifikat. Wenn dies der Fall ist, wird die zu diesem Zertifikat gehörige Signatur, also die das Zertifikat ausstellende Signatur des Zertifizierungsdiensteanbieters (ZDA) geprüft. Das zu dieser Signatur gehörige Zertifikat - in der Grafik eine Ebene darüber - muss im Zeitpunkt der Ausstellung des Anwender-Zertifikates gültig gewesen sein.

Wenn dies der Fall ist, wird die zu diesem Zertifikat gehörige, also die das ZDA-Zertifikat ausstellende Signatur geprüft.

Das zu dieser Signatur gehörige Root-Zertifikat der Bundesnetzagentur (BNetzA) - in der Grafik eine weitere Ebene darüber - muss im Zeitpunkt der Ausstellung des darunterliegenden ZDA-Zertifikates gültig gewesen sein. Das Zertifikat zu der Signatur, die das Root-Zertifikat ausgestellt hat, wird von der BNetzA veröffentlicht. Damit ist die Prüfung nach dem Kettenmodell beendet. Die "Vertrauenskette", die auf diese Weise technisch überprüft wird, bezieht ihre Vertrauenswürdigkeit aus den Regelungen des SigG für qualifizierte Signaturen, insbesondere den detaillierten Vorschriften für die ZDA.

Der Zeitpunkt des Signierens entspricht - für jegliche Art von Dokumenten und von qualifizierten Zertifikaten - dem des manuellen Unterzeichnens. Eine handschriftliche Unterschrift muss zum Zeitpunkt des Unterzeichnens echt sein, d.h. vom Unterzeichner stammen, und verliert diese Eigenschaft dann nicht mehr. Mit der Prüfung der qualifizierten Signatur nach dem geschilderten Kettenmodell wird dementsprechend die Frage "Ist das Dokument mit einer zum Zeitpunkt des Signierens gültigen Signatur versehen?" zuverlässig beantwortet.

Prüfung einer fortgeschrittenen Signatur Demgegenüber erfolgt die Prüfung fortgeschrittener Signaturen gemäß den RFC-Standards für elektronische Signaturen (RFC = "Request for Comments") nach dem Schalenmodell und auf Gültigkeit zum Zeitpunkt der Prüfung. Die HessenPKI, die derzeit unter der Verwaltungs-PKI des Bundes aufgebaut wird, legt diese Standards ebenso wie die VerwaltungsPKI selbst, in ihren jeweiligen Sicherheitskonzepten (Policies) und bei der Realisierung der Infrastruktur zugrunde. Dies entspricht der Empfehlung in der Anlage IV der EU-Signaturrichtlinie.

Anlage 4 EU-Signaturrichtlinie

Während des Signaturprüfungsvorgangs ist mit hinreichender Sicherheit zu gewährleisten, dass die Echtheit und die Gültigkeit des zum Zeitpunkt der Überprüfung der Signatur verlangten Zertifikats zuverlässig überprüft werden, .... 8.1.1.2.1 Ablauf der Prüfung nach dem Schalenmodell

Die Prüfung nach dem Schalenmodell bedeutet, dass zum Zeitpunkt der Prüfung die Gültigkeit des Anwenderzertifikates, die Gültigkeit des CA- und Sub-CA-Zertifikates und die Gültigkeit des Root-Zertifikates geprüft wird. Alle an der Ausstellung beteiligten (Root-, CA- und Sub-CA-)Zertifikate müssen zum Zeitpunkt der Prüfung gültig sein (s. Abb. 2a).

Das bedeutet, dass alle Prüfungen zum Ergebnis "ungültig" führen, die in einem Zeitpunkt erfolgen, in dem eines der Zertifikate nicht mehr gültig ist. Das kann - wie in Abb. 2a gezeigt - sein, wenn das Anwenderzertifikat seine Gültigkeit verloren hat oder auch - wie in Abb. 2b gezeigt - eines der darüberliegenden Zertifikate nicht mehr gültig ist. Dabei spielt es keine Rolle, dass jedes Zertifikat im Zeitpunkt des Signierens des jeweils direkt darunterliegenden Zertifikats bzw. Dokumentes gültig war und dass eines der Zertifikate erst später seine Gültigkeit verloren hat.

Beim Einsatz der fortgeschrittenen Signatur müssen folglich direkt mit dem Zeitpunkt der Ungültigkeit eines Zertifikats konsequenterweise alle darunterliegenden Zertifikate gesperrt und für alle diese Nutzer neue ausgestellt werden - was sehr teuer und aufwändig ist -, um das Erstellen einer von vornherein ungültigen Signatur zu vermeiden. Selbst dies löst aber nicht das Problem, dass ein mit einer seinerzeit gültigen Signatur versehenes Dokument bei der Gültigkeitsprüfung der Signatur fortan das Ergebnis "ungültig" erbringt.

8.1.1.2.2 Ungültigkeit eines Zertifikates und Anforderungen an die Signaturprüfsoftware Abgelaufene Zertifikate werden nicht gesperrt, weil im RFC-Standard der Ablauf nicht als Sperrgrund aufgeführt ist. Sie sind aber selbstverständlich nicht mehr gültig. Eine Abfrage von Sperrlisten oder eine Abfrage beim OCSP (Online Certificate Status Protocol) bringt aber für abgelaufene Zertifikate als Ergebnis, dass das Zertifikat nicht gesperrt und damit gültig ist. Das bedeutet, dass die Signaturprüfsoftware zuerst selbst prüfen muss, ob - zum Zeitpunkt der Prüfung - eines der beteiligten Zertifikate abgelaufen ist. Damit ist dann die Signatur ungültig und eine Abfrage von Sperrlisten erübrigt sich.

Geht die Prüfsoftware nicht diesen Weg, wird sie bei abgelaufenen Zertifikaten fälschlicherweise das Ergebnis "gültig" bringen.

8.1.1.2.3 Folgerungen für den Einsatz fortgeschrittener Signaturen

Der Einsatz einer fortgeschrittenen Signatur für eine reine Transportsicherung bezüglich Authentizität und Integrität bei EMails, bei der die Signatur direkt nach dem Kommunikationsvorgang geprüft werden sollte, also in unmittelbarer zeitlicher Folge des Erstellens der Signatur, ist akzeptabel. Weniger problematisch mag dies auch für Transaktionen (z.B. bei Banktransaktionen, die eine Widerspruchsfrist von sechs Wochen haben) sowie für Zutritts- und Zugangskontrollen sein.

Für Dokumente, wie sie auch in der Verwaltung fast ausschließlich zu finden sind, und für E-Mails, soweit es nicht um die reine Transportsicherung geht, ist dagegen der Zeitpunkt der Prüfung unwichtig; es kommt vielmehr ausschließlich auf den Zeitpunkt des Signierens des Dokuments an. Dementsprechend ist die Erwartungshaltung bei der Signaturprüfung von Dokumenten die Antwort auf die Frage: "Ist das Dokument mit einer zum Zeitpunkt des Signierens gültigen Signatur versehen?" Auch bei der handschriftlichen Unterschrift muss diese im Zeitpunkt des Unterzeichnens echt sein, d.h. von dem Unterzeichner stammen. Manuell unterschriebene Dokumente haben kein Verfallsdatum; wenn die Unterschrift echt ist, gilt sie ab dem Augenblick der Unterzeichnung unbefristet.

Aufgrund des für fortgeschrittene Signaturen festgelegten Prüfzeitpunkts und des verwendeten Schalenmodells kann die Signaturprüfung aber keine zuverlässige Antwort auf die Frage der Gültigkeit zum Zeitpunkt des Signierens geben. Das führt in vielen Fällen, nicht nur nach Ablauf der Gültigkeit des Anwender-Zertifikates, sondern ggf. schon vorher bei Ab lauf oder Ungültigkeit eines der darüberliegenden Zertifikate - im Hinblick auf die angenommene andere Fragestellung - zu nicht erwarteten bzw. zu sachlich falschen Ergebnissen.

Dies ist den Nutzenden nicht zu vermitteln. Es ist zu befürchten, dass sie dann entweder gar keine Signaturprüfung mehr vornehmen oder das Ergebnis ignorieren.

Konsequenzen für den Einsatz von Signaturen in der Verwaltung

Vor der Beschaffung von Signaturkarten und Signaturanwendungskomponenten sind noch eine Reihe von Fragen zu klären:

Es muss überlegt werden, ob überhaupt und ggf. wofür fortgeschrittene Signaturen in der Verwaltung sinnvoll eingesetzt werden können. Dabei sind rechtliche Fragen des Beweiswertes einer solchen Signatur ebenso wie die obigen Ausführungen zu berücksichtigen. Aus meiner Sicht scheidet jedenfalls die "Unterzeichnung" elektronischer Dokumente als Anwendungsfall aus.

Bei der Beschaffung bzw. beim Einsatz von Signaturprüfsoftware für die Prüfung eingehender, mit elektronischer Signatur versehener Dokumente ist darauf zu achten, dass diese Prüfsoftware fortgeschrittene und qualifizierte Signaturen nach dem jeweils zutreffenden Modell prüft. Sie muss zu Beginn der Prüfung klären, um welche Art Signatur es sich handelt, insbesondere, ob nach dem Schalen- oder dem Kettenmodell geprüft werden muss. Andernfalls führt die Prüfung zu einem falschen Ergebnis. An allen Arbeitsplätzen zur Prüfung von Signaturen darf nur Prüfsoftware eingesetzt werden, die sowohl fortgeschrittene als auch qualifizierte Signaturen zutreffend prüft.

Es wird ferner die Frage der Behandlung von signierten Dokumenten und insbesondere die des Übersignierens zu klären sein:

Wird mit einem qualifizierten Zeitstempel übersigniert und zu welchem Zeitpunkt ist eine Übersignatur von Dokumenten vorgesehen? Wie erfolgt die Auswahl der mit der Übersignatur zu versehenden Dokumente? Ist sie automatisiert möglich?

Ausgehend von dem Ergebnis der Frage nach dem Beweiswert fortgeschrittener Signaturen und dem Ansatz der dortigen Signaturprüfung ist zu überlegen, ob die Übersignatur fortgeschritten signierter Dokumente sinnvoll ist bzw. erfolgen muss.

Jedenfalls kann der Beweiswert der ursprünglichen Signatur und deren Rechtswirkung für das Dokument durch eine Übersignatur mit einem qualifizierten Zertifikat nicht erhöht werden.

Insgesamt wird sich auch die Frage stellen, ob - angesichts der unterschiedlichen Anwendungsfelder beider Signaturarten und der Tatsache, dass nur qualifizierte Signaturen das Schriftformerfordernis erfüllen - nicht von vornherein durchgängig qualifizierte, akkreditierte Signaturen eingesetzt werden sollten. Diese müssen erst mehr als 33 Jahre nach dem ersten Einsatz, bzw. unbesehen alle beim Schwachwerden des technischen Verfahrens (Algorithmus, Parameter etc.) übersigniert werden.

Das HMDIS sollte mit Unterstützung der Stabsstelle Hessen-PKI die Ressorts vor Aufnahme des Echtbetriebs Hessen-PKI umfassend informieren über die Unterschiede nicht nur zwischen den Signaturarten, sondern vor allem über die Unterschiede bezüglich ihrer Gültigkeit, ihrer Prüfung und auch ihrer Rechtswirkung. Nur so können die Ressorts für ihren Bereich die Weichen bezüglich der elektronischen Signatur richtigstellen.

Angesichts des breiteren und für die Verwaltung einschlägigen Einsatzgebietes qualifizierter Signaturen sollte überlegt werden, ob vom Einsatz der fortgeschrittenen Signatur Abstand genommen wird und die eingesparten Kosten nicht besser für die Beschaffung qualifizierter Signaturen eingesetzt werden sollten. Unter dem Gesichtspunkt des breiteren Einsatzfeldes dieser Signaturform sollte auch ein günstigerer Preis für die erforderlichen Signaturerstellungseinheiten bzw. qualifizierten Zertifikate erzielbar sein.

Key-Back-up von privaten Root- und CA-Schlüsseln für fortgeschrittene Signaturen

In den RFC-Standards, die für fortgeschrittene Signaturen genutzt werden, ist festgelegt, dass die Sperrlisten - also die Listen der gesperrten, nicht mehr gültigen Zertifikate - jeweils mit dem Schlüssel signiert sein müssen, mit dem diese Zertifikate ursprünglich ausgestellt wurden. Das ist aber nur möglich, wenn die Schlüssel aufbewahrt werden, um sie für die Sperrung der Zertifikate vorzuhalten. Dieses Key-Back-up der privaten Signaturschlüssel auf der Root-, CA- und Sub-CAEbene führt allerdings zu Problemen mit der Erfüllung der Anforderungen des Signaturgesetzes, das - zu Recht - hohe Sicherheitsanforderungen setzt. Nach § 2 Nr. 2c SigG müssen fortgeschrittene Signaturen "mit Mitteln erzeugt werden, die der Signaturschlüsselinhaber unter seiner alleinigen Kontrolle halten kann". Dem widerspricht die Hinterlegung oder Zweitausfertigung privater Signaturschlüssel. Diese Anforderung muss auch für die Root-, CA- und Sub-CA-Zertifikate gelten, weil sonst die "Verankerung" der Anwenderzertifikate nicht vertrauenswürdig ist. Ohne einen solchen Vertrauensanker ist aber das gesamte System nicht vertrauenswürdig und weist nicht die erforderliche Sicherheit auf.

Deshalb sollte mittelfristig eine Änderung der Policies und ggf. der zugrunde liegenden RFC-Standards angestrebt werden.

Damit werden keineswegs unsignierte Sperrlisten gefordert, sondern eine andere Lösung für die Signatur von Sperrlisten.

Die Bundesnetzagentur löst dieses Problem bei den qualifizierten Signaturen mit "indirekten" Sperrlisten. Das bedeutet, die Sperrlisten werden statt mit dem das Zertifikat ausstellenden Schlüssel ("direkte" Sperrliste) mit eigens hierfür erzeugten Sperrlisten-Schlüsseln erstellt, deren Zertifikat und Bestimmungszweck nachgeprüft bzw. abgefragt werden können.

Mein Haus hat das Gesprächsangebot des Bundesamtes für Sicherheit in der Informationstechnik als Betreiber der Verwaltungs-PKI über die Verwaltungs-PKI-Policy angenommen.