Detlef Hühnlein, Ulrike Korte, Andreas Kühne, Andrea Röck
OASIS und ETSI schaffen Programmierschnittstellen für die Erstellung, Validierung und langfristige Bewahrung von Signaturen, Siegeln, Zeitstempeln und Beweisdaten und bilden somit die Grundlage für die Entwicklung einer umfassenden „eIDAS-API“.
Mit der seit Juli 2016 vollständig anwendbaren „eIDAS-Verordnung“ haben sich zahlreiche neue Möglichkeiten zur vertrauenswürdigen Digitalisierung von Geschäftsprozessen in Wirtschaft und Verwaltung eröffnet. Damit diese Chancen auch praktisch genutzt werden können, haben die Standardisierungskomitees OASIS DSS-X und ETSI ESI kürzlich entsprechende Standards für die Erstellung, Validierung und langfristige Bewahrung von Signaturen, Siegeln, Zeitstempeln und Beweisdaten entwickelt. Der vorliegende Beitrag liefert einen kompakten Überblick über die neu geschaffenen Programmierschnittstellen (Application Programming Interface, API) und liefert einen Ausblick auf zukünftige Entwicklungen.
Einleitung
Die „Verordnung (EU) Nr. 910/2014 des Europäischen Parlaments und des Rates vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG“, die gemeinhin als „eIDAS-Verordnung” bekannt ist, verspricht das Vertrauen und die Effizienz von elektronischen Transaktionen in Europa zu steigern. Mit ihr wurde das bisherige Europäische Rahmenwerk für elektronische Signaturen und Zeitstempel um zahlreiche neue Vertrauensdienste und Aspekte der elektronischen Identifizierung erweitert. Neben der im Erwägungsgrund (52) erwähnten Fernsignatur, wurden in den Artikeln 33, 34 und 40 insbesondere auch Dienste zur Validierung und langfristigen Bewahrung von Signaturen und Siegeln eingeführt. Um die praktische Nutzung dieser neuen Vertrauensdienste in einer interoperablen Weise zu ermöglichen und somit ein solides Fundament für ein prosperierendes und langfristig tragfähiges „eIDAS-Ökosystem“ zu schaffen, haben die für elektronische Signaturtechnologien zuständigen Standardisierungskomitees bei OASIS (Digital Signature Services eXtended, DSS-X) und ETSI (Electronic Signatures and Infrastructures, ESI) nun entsprechende Standards für Programmierschnittstellen (Application Programming Interface, API) zur Erstellung, Validierung und langfristige Bewahrung von Signaturen, Siegeln, Zeitstempeln und Beweisdaten vorgelegt. Der vorliegende Artikel vermittelt einen groben Überblick über die neu geschaffenen Programmierschnittstellen und und geht darüber hinaus kurz auf mögliche zukünftige Entwicklungen ein.
Die neuen API-Standards
Überblick
Wie in Abbildung 1 angedeutet, stellen die neuen API-Standards Programmierschnittstellen für die wichtigen Dienste im eIDAS-Ökosystem bereit. Hierbei können über den Signatur- und Siegelerstellungsdienst (SigS) entsprechende Signaturen und Siegel erstellt, über den Validierungsdienst (ValS) geprüft und schließlich mit dem Bewahrungsdienst (PresS) langfristig beweiskräftig aufbewahrt werden. Dazu nutzen die Anwendungssysteme die bei ETSI ESI und OASIS DSS-X entwickelten Webservice-basierten Programmierschnittstellen. Während die Schnittstellen für die Erstellung (ETSI TS 119 432) und Validierung von elektronischen Signaturen und Siegeln (ETSI TS 119 442) auf der neuen Version 2.0 des OASIS DSS-X Core aufsetzen und diesen profilieren bzw. für JSON und die Erstellung auch auf den Vorarbeiten des von Adobe geführten „Cloud Signature Consortium“, werden für die Schnittstelle zum Bewahrungsdienst (ETSI TS 119 512) nur die grundlegenden Schemadateien von OASIS („Base“) importiert und es wird eine entsprechende Erweiterung vorgenommen. Neben den im Folgenden näher betrachteten technischen Schnittstellenspezifikationen wurden mit ETSI TS 119 431 (Teil 1 und Teil 2), ETSI TS 119 441 und ETSI TS 119 511 entsprechende Sicherheitsanforderungen spezifiziert, die die Grundlage für die Konformitätsprüfung von (qualifizierten) Vertrauensdiensten gemäß der eIDAS-Verordnung bilden.
Abbildung 1: Die neuen Signatur-APIs im Überblick
OASIS DSS-X Core 2.0
Im Rahmen eines auf Signaturdienste spezialisierten „Technical Committee“ (TC) wurde bei der internationalen Standardisierungsorganisation OASIS bereits im Jahre 2007 eine Kernspezifikation („Core“) standardisiert, die die Basisfunktionalität für die Erstellung (SignRequest / -Response) und Validierung (VerifyRequest / -Response) von CMS- und XMLDSig-konformen Signaturen festlegt. Aufgrund der großen Bandbreite von Anforderungen aus den verschiedenen Einsatzbereichen von Signaturen und Zeitstempeln wurde die Kernspezifikation um eine Reihe von sog. Profilen („Profile“) erweitert, z.B. für den Einsatz für Code Signing, Entity Seals oder für die Verarbeitung von XAdES- und CAdES-konformen Artefakten. In den Folgejahren wurden weitere Profile entwickelt, z.B. für detaillierte Signaturprüfberichte und zur Signaturerstellung mit nicht in der Serverinstanz lokalisierten Signaturerstellungseinheiten.
Aufbauend auf diesen Vorarbeiten wurden im OASIS Digital Signature Services eXtended (DSS-X) TC mit der Version 2.0 des Core die Herausforderungen einer neuen API-Landschaft adressiert und die Semantik der Schnittstelle von der konkreten Umsetzung in eine bestimmte Syntax separiert. Neben der von Version 1 geerbten XML-Syntax wird nun auch das in modernen Webanwendungen oftmals eingesetzte JSON unterstützt und weitere Syntaxen könnten bei Bedarf zusätzlich definiert werden. Denkbar wäre hier beispielsweise eine ASN.1-Syntax, um mit den „Packed Encoding Rules“ (PER) ein besonders kompaktes Format für mobile und eingebettete Anwendungen im „Internet der Dinge“ zu ermöglichen. Um eine möglichst große Sichtbarkeit und gute Akzeptanz des Standards sicherzustellen, hat das DSS-X TC in Zusammenarbeit mit dem OASIS-Infrastruktur-Team begonnen, die Schnittstelle auf der Kollaborationsplattform „SwaggerHub“ bereitzustellen. Dazu wird das JSON-Schema um eine Reihe von Meta-Informationen erweitert, um der OpenAPI-Spezifikation zu entsprechen.
Durch die jüngst bei ETSI und aktuell bei OASIS entstehenden Profile können die spezifischen Eigenschaften der AdES-Signaturformate in Verbindung mit lokalen und entfernten eIDAS-konformen Signaturerstellungseinheiten über die DSS-X-Schnittstelle genutzt werden. Durch die zusätzlichen Attribute der Signaturen (z.B. die eingebetteten Zertifikatstatusinformationen, Zeitstempel oder Evidence Records) wird eine breite Anwendbarkeit dieser Formatfamilie ermöglicht. Seit der initialen Standardisierung werden die zugehörigen Schnittstellenerweiterungen für die Formate XAdES und CAdES durch das AdES-Profil definiert. Im Rahmen der Version 2.0 wird aktuell das AdES-Profil dahingehend erweitert, dass die zwischenzeitlichen Weiterentwicklungen der AdES-Formate berücksichtigt werden. Insbesondere wird auch das auf der PDF-Spezifikation basierende PAdES-Format gemäß ETSI EN 319 142-1 unterstützt, mit dem mehrfache Signaturen in einem Workflow und die visuelle Repräsentation einer elektronischen Signatur in einem PDF-Dokument realisiert werden können.
Für den Einsatz im eIDAS-Umfeld erweist sich die Unterstützung von sog. „Policies“ durch die DSS-X-Spezifikation als wertvoll. Damit kann der Aufrufer eine für die gewünschte Aktion erforderliche „Policy“ an den Dienst übermitteln. Die angesprochene Serverinstanz entscheidet, ob sie dem geforderten Qualitätsniveau gerecht werden kann oder ob die Anfrage abgewiesen werden muss. Wird die Anforderung bearbeitet, so kann in der Antwortstruktur die angewandte „Policy“ an den Aufrufer übertragen werden. So wird sichergestellt, dass ein Konsens über das mindestens anzuwendende Qualitätsniveau erreicht wurde.
ETSI TS 119 432
ETSI TS 119 432 basiert auf Version 2.0 des OASIS DSS-X Core bzw. für JSON auch auf den Vorarbeiten des von Adobe geführten „Cloud Signature Consortium“ und spezifiziert Schnittstellen für die mit der eIDAS-Verordnung ermöglichten Fernsignatur. Hierbei wird im Einklang mit dem bei CEN erarbeiteten Standard CEN EN 419 241 (Teil 1 und Teil 2) zwischen der „Serversignaturanwendung“ („Server Signing Application“, SSA) und der „Signaturerstellungsanwendung“ („Signature Creation Application“, SCA) unterschieden, die jeweils entsprechende Webservice-Schnittstellen anbieten. Während die SSA ein HSM-basiertes „Unterschriftsaktivierungsmodul“ („Signature Activation Module“, SAM) enthält, das nach einer starken Authentisierung des Unterzeichners im „Signaturaktivierungsprotokoll“ („Signature Activation Protocol“, SAP) unter Verwendung der „Unterzeichner-Interaktionskomponente“ („Signer Interaction Component“) die Erstellung der rohen digitalen Signatur in einem „Low-Level-Format“ (z.B. RSA gemäß PKCS#1 oder ECDSA) auslöst, sorgt die SCA für die Bildung des erweiterten AdES-Signaturformats gemäß ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) oder ETSI EN 319 142 (PAdES).
Abbildung 2: Fernsignatursystem gemäß ETSI TS 119 432
ETSI TS 119 442
ETSI TS 119 442 definiert drei verschiedene Programmierschnittstellen, jeweils eine für Dienste, die Signaturvalidierung („Validation“ per VerifyRequest / VerifyResponse), Signaturerweiterung („Augmentation“ per AugmentRequest / AugmentResponse), oder beides kombiniert anbieten. Die erste Version dieses Dokuments behandelt die Validierung und Erweiterung von AdES-Signaturen, welche den aktuellen ETSI-Standards, wie z. B. ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) und ETSI EN 319 142 (PAdES) bzw. den vorausgegangenen AdES-Spezifikationen entsprechen. Bezüglich der AdES-Spezifikationen sind hier insbesondere die im Durchführungsbeschluss (EU) 2015/1506 erwähnten „Baseline Profiles“ ETSI TS 103 171, ETSI TS 103 172 und ETSI TS 103 173 bzw. die diesen Dokumenten zu Grunde liegenden AdES-Spezifikationen ETSI TS 101 733, ETSI TS 102 778 und ETSI TS 101 903 relevant.
Zukünftige Versionen dieses Dokuments könnten zum Beispiel auch die Validierung von Zeitstempeln, Evidence Records oder von Signaturen in ASiC-Containern behandeln.
ETSI TS 119 442 basiert so weit wie möglich auf Version 2.0 des OASIS DSS-X Core. Zum Zeitpunkt der Finalisierung von ETSI TS 119 442 war die endgültige Version des neuen OASIS DSS-X Core noch nicht veröffentlicht, so dass bei der Entwicklung des ETSI TS 119 442 letztlich auf eine Entwurfsversion des OASIS-Dokumentes aufgebaut werden musste. In Fällen, in denen der Funktionsumfang des OASIS-Drafts nicht ausreichend schien, um die gewünschte Funktionalität der Programmierschnittstelle zu bieten, wurden neue Elemente definiert.
Ähnlich wie in Version 2.0 des OASIS DSS-X Core wird jedes Element der Programmierschnittstelle zuerst allgemein beschrieben, bevor entsprechende Syntaxen für XML und JSON beschrieben werden.
Die definierte Validierungsschnittstelle erlaubt es, zusätzlich zur Signatur, statt dem signierten Dokument nur den Hash des entsprechen Dokumentes zu senden. Diese Funktionalität kann sehr nützlich sein, falls das signierte Dokument entweder sehr groß ist oder falls es aus Datenschutz- oder Geheimhaltungsgründen vermieden werden soll, dass es vollständig zum Validierungsdienst gesendet wird. Da im Fall einer Signaturerweiterung möglicherweise ein neuer Hash des signierten Dokuments berechnet werden muss, ist diese Option bei der Signaturerweiterung nicht vorgesehen.
Falls mehr als eine Signatur in einem Dokument enthalten ist, erlaubt es die Programmierschnittstellen nur einen Teil dieser Signaturen für die Validierung und/oder Erweiterung auszuwählen. Außerdem kann bei einem Aufruf spezifiziert werden, wie viele Details in der Antwort zurückgeliefert werden sollen. Dies kann von einer sehr einfachen Antwort bis zu einem umfassenden und signierten Signaturprüfbericht gemäß ETSI TS 119 102-2 reichen, wie er zur Erfüllung der Anforderungen aus Artikel 33 Absatz 1 (b) der eIDAS-Verordnung benötigt wird.
ETSI TS 119 512
Als Grundlage für die Entwicklung der technischen Spezifikationen im Bereich der Bewahrungsdienste wurde in ETSI ESI zunächst in einer Vorstudie ein Spezialbericht (“Special Report”) ETSI SR 019 510 erarbeitet. Auf dieser Basis erfolgte sodann die Entwicklung des eigentlichen Protokollstandards ETSI TS 119 512 und der zugehörigen Sicherheitsanforderungen („Policy and Security Requirements “) ETSI TS 119 511.
Wie in Abbildung 3 dargestellt, stellt ein Bewahrungsdienst gemäß ETSI TS 119 512 eine „Preservation-API“ bereit, die z.B. dazu genutzt wird, die zur langfristigen Aufbewahrung vorgesehenen Datenobjekte („Preservation Objects“) an einen Bewahrungsdienst zu senden. Ein Bewahrungsdienst kann wiederum externe Zeitstempeldienste („Time-Stamping Authority“) gemäß ETSI EN 319 422, Signatur- und Siegel-Erstellungsdienste (SigS) oder Validierungsdienste (ValS) nutzen, um Sperrinformationen abzurufen und um digitale Signaturen prüfen zu lassen. Alternativ kann der Bewahrungsdienst selbst die notwendigen Zertifikate zusammentragen und Zertifikatsstatusinformationen beim zuständigen Zertifikatsstatusdienst („Certificate Status Authority“) einholen.
Dabei gibt es drei Hauptvarianten für Bewahrungsdienste, abhängig von der Frage, ob sie (a) mit einem Langzeitspeicher („with long-term storage“, WST), (b) mit einem temporären Speicher („with a temporary storage“, WTS) oder (c) ohne Speicher („without storage“, WOS) betrieben werden. Im WST-Fall kann der Bewahrungsdienst einen internen Speicher oder einen externen Speicher unter seiner Kontrolle für die Bewahrung nutzen. Ein solcher Bewahrungsdienst mit Speicher funktioniert insgesamt sehr ähnlich, wie eine „TR-ESOR-Middleware“ gemäß der BSI-Richtlinie TR-03125, in der aktuell auch die „Preservation-API“ gemäß ETSI TS 119 512 integriert wird.
Abbildung 3: System mit Bewahrungsdienst
Die bei ETSI entwickelten Bewahrungsstandards ETSI TS 119 511 und ETSI TS 119 512 erlauben es, unterschiedliche Strategien für die Bewahrung („Preservation Schemes“) zu definieren und mit so genannten Bewahrungsprofilen („Preservation Profiles“) umzusetzen.
Die Bewahrungsprofile können wiederum die folgenden Bewahrungsziele verfolgen:
- PDS („Preservation of digital signatures”) – zum Beweis der Existenz und zur Bewahrung des Status digitaler Signaturen,
- PGD („Preservation of general data”) – zum Beweis der Existenz beliebiger Daten, die entweder signiert oder nicht signiert sein können, und
- AUG („Augmentation“) – für die Erweiterung von Beweisdaten, die von einem anderen Bewahrungsdienst erzeugt wurden, um eine langfristig beweiskräftige Bewahrung zu ermöglichen.
Die in ETSI TS 119 512 spezifizierten Bewahrungsstrategien nutzen entweder Evidence Records gemäß RFC 4998 bzw. RFC 6283, die für CAdES und XAdES vorgesehenen Archivzeitstempel oder die für PAdES vorgesehenen Dokumentenzeitstempel.
Abhängig vom Speichermodell (WST, WTS, WOS) müssen (M) bzw. können (K) die verschiedenen Operationen, wie in der folgenden Tabelle dargestellt, von einem Bewahrungsdienst gemäß ETSI TS 119 512 umgesetzt werden:
|
Operation |
Speichermodell |
Beschreibung der Funktion |
||
|
WST |
WTS |
WOS |
|
|
|
Retrieve |
M |
M |
M |
Liefert Informationen über die vom Bewahrungsdienst unterstützten Profile |
|
PreservePO |
M |
M |
M |
Übergabe von Datenobjekten (“Preservation Object”, PO) |
|
RetrievePO |
M |
M |
/ |
Abruf von Datenobjekten (Nutz- und Beweisdaten) |
|
DeletePO |
M |
/ |
/ |
Löschen von Datenobjekten |
|
UpdatePOC |
K[1] |
/ |
/ |
Erweiterung eines Aufbewahrungscontainers um eine neue Version |
|
Retrieve |
K |
K |
K |
Abruf von Protokolldaten |
|
Validate |
K |
K |
K |
Validierung von Beweisdaten |
|
Search |
K |
K |
/ |
Suche nach einem bestimmten |
Tabelle 1: Operationen der Preservation-API
Ähnlich wie bei den anderen API-Spezifikationen wurde auch in ETSI TS 119 512 zunächst die Semantik einer Operation definiert, bevor die konkrete Syntax für XML und JSON spezifiziert wurde.
Auf dem Weg zur „eIDAS-API“ und zur Interoperabilität für das eIDAS-Ökosystem
Ausgehend von den bislang von OASIS und ETSI vorgelegten Programmierschnittstellen ist es nur noch ein vergleichsweise kleiner Schritt hin zu einer umfassenden „eIDAS-API“, über die alle Dienste des eIDAS-Ökosystems über gängige, Webservice-basierte Mechanismen auf Basis von XML/SOAP oder JSON/REST angesprochen werden können.
Hierfür muss lediglich ein für die jeweiligen Technologieausprägungen geeigneter Authentisierungs- und Autorisierungsmechanismus ergänzt werden. Während bei SOAP der Einsatz von Web Service Security Mechanismen naheliegend ist, bietet sich bei REST der Einsatz von OAuth gemäß RFC 6749 bzw. allgemeiner der Einsatz von HTTP/1.1 basierten Authentisierungsmechanismen gemäß RFC 7235 an.
Eine solche „eIDAS-API“ wird sinnvoller Weise nicht nur die hier beschriebenen Funktionen zur Erstellung, Validierung und Bewahrung von Signaturen, Siegeln und Zeitstempeln umfassen, sondern auch die anderen Dienste des eIDAS-Ökosystems in geeigneter Weise integrieren. Dies umfasst nicht nur die elektronische Identifizierung und die auf dieser Basis sehr effizient mögliche Ausstellung von (qualifizierten) Zertifikaten, sondern beispielsweise auch die vertrauenswürdige Übermittlung und Zustellung elektronischer Dokumente und Einschreiben. Um die nahtlose und gleichzeitige Nutzung von Chipkarten- und HSM-basierten Signaturerstellungseinheiten zu ermöglichen, empfiehlt sich der Einsatz des kürzlich vorgeschlagenen und aktuell in OASIS DSS-X standardisierten „Local and Remote Signature Profile“, bei dem lokale und entfernte Signaturerstellungseinheiten über weitgehend identische Schnittstellen angesprochen werden können. Erste Schritte zur praktischen Umsetzung der geplanten „eIDAS-API“ wurden kürzlich mit dem Start des FutureTrust-Pilotportals und der Einsetzung der go.eIDAS-Arbeitsgruppe „API-Interoperabilität“ unternommen. Schließen Sie sich uns dort an, um den Traum von einem interoperablen eIDAS-Ökosystem Wirklichkeit werden zu lassen!
[1] Die Funktion setzt voraus, dass das verwendete Containerformat die Versionierung grundsätzlich unterstützt.