Wie im letzten Blogbeitrag angekündigt, haben wir die kalte Winterzeit dazu genutzt, über aktuelle Standards und Software zu recherchieren. Natürlich haben wir uns bereits vor der NetIdee-Einreichung mit diesem Thema beschäftigt, aber waren dann dennoch etwas überrascht von der Komplexität aktueller Standards.

Standardisierung im Zeitverlauf

Eine Grundregel der menschlichen Zivilisation ist wohl, dass es für jede erdenkliche Situation einen passenden XKCD-Comic gibt. Für PDF-Signatur ist das XKCD 927. So gibt es alleine vom europäischen Standardisierungsgremium ETSI die Verfahren PAdES (PDF Advanced Electronic Signatures), CAdES (CMS Advanced Electronic Signatures) und XAdES (XML Advanced Electronic Signatures), jeweils wiederum mit mehreren Untertypen, im Falle von PAdES etwa BASELINE-B, BASELINE-T, BASELINE-LT und BASELINE-LTA. PAdES selbst setzt wieder auf den PDF-Standard auf, der wiederum ab der Version 1.3 eine Unterstützung für digitale Signaturen bietet, und dort dann wieder u.a. zwischen “adbe.pkcs7detached”, “adbe.x509.rsa.sha1” und “ETSI.CAdES.detached” unterscheidet. Alle diese verschiedenen Standards kommen dann jeweils wieder mit unterschiedlichen technischen Eigenschaften und rechtlichen Attributen. Was diese Aufzählung unterschiedlicher Standards beschrieben soll: Es ist kompliziert und für Anwender, die nicht Profis auf dem Gebiet der Kryptographie, der Juristerei und PDF-Signatur sind, nicht leicht durchschaubar.

Nach genauer Durchsicht der Standards haben wir uns deshalb entschieden, bei open-pdf-sign auf den PAdES-Standard und die Profile BASELINE-B und BASELINE-T zu setzen. Dies, weil PAdES als moderner Standard in allen aktuellen PDF-Viewern unterstützt wird, und alle für uns notwendigen Features, wie etwa das Anbringen mehrerer Unterschriften, bietet.

Dieser Standard erwartet zwar PDF-Version 1.7 als Minimum, ist aber rückwärtskompatibel auch für PDF-Version 1.4 einsetzbar, was wiederum notwendig ist, um für die österreichische Justiz und deren elektronischen Rechtsverkehr (“ERV”) verwendbar zu sein.

Eine ähnliche Vielfalt an Standards gibt es auch für die Speicherformate der zur Signatur verwendeten kryptografischen Schlüssel. So ist es unser Ziel, zumindest die häufigsten Formate (konkret: PEM, DER, PFX) zu unterstützen, so dass Nutzer open-pdf-sign möglichst direkt verwenden können.

Open Source als Hilfe

Es ist selten eine gute Idee, Kryptographie selbst zu implementieren. Auch bei open-pdf-sign greifen wir deshalb auf bestehende Bibliotheken zurück. Glücklicherweise gibt es für PAdES als europäischen Standard ein europäisches Open-Source-Projekt namens “Document Signature Service”, das unter der LGPL-2.1-Lizenz (mehr dazu in einem separaten Blog-Beitrag) PDF-Signatur für PAdES implementiert. Für die Anbringung einer sichtbaren Signatur im “gewohnten” Tabellen-Format greifen wir auf die PDFBox-Bibliothek der Apache Foundation (Lizenz: APL2) und die Tabellen-Bibliothek “easytable” zurück (Lizenz: MIT). Das Einlesen und Konvertieren der privaten Schlüssel übernimmt Bouncy Castle (Lizenz: MIT).

Nach der recht aufwendigen Recherche gelang die Orchestrierung der einzelnen Bestandteile dann verhältnismäßig einfach. Eine erste Version unseres Prototypen ist auf openpdfsign.org bereits abrufbar. Bei der PDF-Signatur stehen wir aktuell damit auf den bildhaften Schultern von Riesen, bei uns in der Form verschiedenster Open-Source-Projekte, ohne denen PDF-Signatur mit vertretbarem Aufwand kaum möglich wäre.

Die Veröffentlichung des Prototypen zur Signatur ist nun ein erster Schritt für open-pdf-sign. Wir werden die nächsten Monate weiter an der Optimierung, einer guten Dokumentation und einer möglichst einfachen Einbindungsmöglichkeit in bestehende Server arbeiten und hier im Blog davon berichten.