FES — Digitale Signatur selbst gemacht — EU- und GoBD-konform im eigenen Git-Repo
Die These
Fortgeschrittene elektronische Signatur (FES) ist heute Selbstmach-Sache. Die Bausteine — deterministische Identifikation (V7GUID), Integritätskette (SHA-256), Katalogisierung (JSON-Schemas + Sidecars), positionierte Signatur-Grafik (Facsimile im PDF-Layer) und Kryptobindung (PAdES) — sind offene Standards und freie Werkzeuge. Was ein Signaturdienst teuer verpackt, baut eine Organisation mit Git, JSON und einem PDF-Signier-Werkzeug selbst auf: EU-konform (eIDAS-VO, § 126b/126a BGB, § 371a ZPO) und GoBD-fest (ver revisionssichere Nachweiskette, die nicht beim Dienstleister liegt, sondern im eigenen Repo).
Nicht „selbst gemacht" im Sinne von schlechter als DocuSign — sondern im Sinne von dort, wo die Nachweispflicht liegt: bei der Organisation selbst, in ihrem Git-Repo. Der Unterschied ist nicht die Krypto — die ist Standard. Der Unterschied ist der Beweis-Sitz: DocuSign lebt in einer Cloud, dessen Verfahren der Prüfer nicht einsehen kann; die GitCover-Kette liegt im Repo, ist ohne Spezial-Werkzeug prüfbar (sha256sum + jq) und überdauert den Diensteanbieter.
Die Serie belegt die These in drei Teilen:
- Textform (Teil I): § 126b BGB bei freier Beweiswürdigung — ohne Krypto, allein durch Kette (Signatur-Doc, Events, Sidecars).
- FES & Facsimile (Teil II): eIDAS-konforme Andockung — positionierte Grafik im PDF-Layer, Signaturplatte, Envelope-Report, Container-Paket.
- PII, GPG & Governikus (Teil III, geplant): Schlüssel-Ebene — Signing-Identity, Trust Registry, Key-Lifecycle, BSI gestützte OpenPGP-Beglaubigung (pgp.governikus.de).
Warum diese Serie?
Jedes Unternehmen steht früher oder später vor der Frage: Wie signieren wir Dokumente digital, ohne dass ein Prüfender (Finanzamt, Auditor, Gericht bei freier Beweiswürdigung, BSFZ, Notar) die Signatur als nicht ausreichend verwirft?
Die Praxis gibt auf diese Frage die üblichen Antworten: DocuSign-Konto kaufen, qualifizierte Signaturdienste buchen, oder — schlimmer — weiter drucken, unterschreiben, scannen. Alle drei Antworten lösen das eigentliche Problem nicht: Sie erzeugen Signatur-Aktivität außerhalb des Git-Repositories, in dem das Dokument lebt. Die Nachweiskette reißt genau dort, wo sie Revisionssicherheit verspricht.
Diese Serie zeigt den GitCover-Weg: Die Signatur wird im Repo andockbar. Das Dokument bleibt die MD-Datei im Tenant-Repo; um sie herum entsteht ein JSON-Schema-basiertes Artefakt-Set (Signatur-Doc, Accept-/Deny-Event, Sidecar-Verifikation), das das Textform-Erfordernis des § 126b BGB bei freier Beweiswürdigung ausreichend erfüllt — und später, wenn es der Geschäftspartner verlangt, zum FES-/ADES-Verfahren (fortgeschrittene elektronische Signatur, DocuSign-artig) hochgerüstet werden kann, ohne das Repo zu verlassen.
Grenzen der These
Die These „FES selbst gemacht" ist präzise zu verstehen:
- Selbst gemacht = Verfahren, Kette und Nachweis liegen in der eigenen Hand (Repo, offene Standards, freie Werkzeuge). Sie ersetzt nicht das Zertifikat: Die Kryptobindung braucht ein Signaturzertifikat — das bezog E1 über einen Signaturdienst oder ein eigenes Zertifikat (z. B. persönliches Qualifiziertes — nein: FES braucht kein qualifiziertes; ein reguläres Zertifikat genügt).
- EU-konform = eIDAS-konform. Die FES erfüllt eIDAS Art. 25 (2) (gleichwertig der handschriftlichen Unterschrift, § 126 Abs. 3 BGB). Die QES (Schriftform-Ersatz, § 126a BGB) bleibt extern (Trust-Liste) — die Serie dockt sie an, ersetzt sie nicht.
- GoBD-fest = die Nachweiskette (Quell-Dokument → Signatur-Doc → Events → Grafik → PDF) ist repo-nativ, sha256sum-prüfbar, 10 Jahre aufbewahrbar (§ 147 AO) — ohne Abhängigkeit von einem Diensteanbieter, dessen Portal in 10 Jahren vielleicht nicht mehr existiert.
Die Serie in einem Blick
| Teil | Auslöser | Kernfrage | Artikel |
|---|---|---|---|
| Teil I — Textform | Ein Vertrag (GVB) soll in Textform geschlossen werden | Wie erfüllen wir § 126b BGB Git-nativ, bei freier Beweiswürdigung, ohne externe Signaturdienste? | DS01–DS05 |
| Teil II — FES & Facsimile | Ein Geschäftspartner verlangt eine fortgeschrittene elektronische Signatur | Wie docken wir eine FES an das Repo an — DocuSign-artig, mit positionierter Grafik im PDF-Layer? | DS06–DS11 |
| Teil III — GCPN-Container-Schema | Der erste echte Signatur-Vorgang (Forschungsgewinn) | Wie wird das Verfahren maschinenlesbar — als normatives JSON-Schema ohne innere Redundanz? | DS12–DS15 |
| Teil IV — PII, GPG & Governikus (abgetrennt) | Schlüssel-Verwaltung, SSH vs. OpenPGP, Trust Registry, amtliche Beglaubigung (gpg.governikus.de) | Wie verwalten wir die privaten Schlüssel und das Signing-Identity-Modell — und docken die BSI-unterstützte GPG-Beglaubigung an — ohne PII in Git zu leaken? | Geplant (DS16–DS21) |
| Teil V — Mobile & Community | Mobile Nutzung mit GPG-Tools auf Smartphones/Devices | Wie zeichnet und prüft der Unternehmer mobil — und welche Lösungen sind als Community-Arbeitsgebiet zu entwickeln? | Aufriss (keine DS-Nummern) |
Trennungs-Hinweis: Die PII/GPG-Themen (Schlüssel-Material, Identity JSON-Schemas, GPG/SSH-Signatur-Mechanik, Keyring-Verwaltung) werden bewusst erst in Teil IV behandelt — sie sind ein eigener Compliance-Kreis (PII-Handling im TOP-Repo, gitignored-Verzeichnisse, Trust-Registries) und dürfen nicht mit der Dokument-Ebene der Teile I–III vermischt werden.
Die Saga: Auslöser-Modell
Wie in der Unternehmer-Diary-Serie ist jeder Artikel durch einen konkreten
Auslöser im Unternehmensleben angestoßen — hier die Signatur-Ereignisse
eines KMU (fiktive Organisation ORG-1, Platzhalter E1 als Unternehmer):
| Auslöser | Ereignis | Konsequenz |
|---|---|---|
| S1 — Der Beschluss | Eine Gesellschafterversammlung (GVB) soll in Textform gefasst werden — alle Gesellschafter sind eine Person (E1), aber der Beschluss soll revisionsicher nachvollziehbar "signiert" sein | Textform-Modell: MD-Doc + JSON-Artefakte im Repo (Teil I) |
| S2 — Die Verifikationsfrage | Ein Prüfer fragt: "Ist das Dokument authentisch? Wer hat es 'signiert'?" | Sidecar-Verifikation: SHA-256, V7GUID, guid-Stempel (Teil I) |
| S3 — Der externe Partner | (Platzhalter PARTNER-1) verlangt DocuSign für einen Projekt-/Kaufvertrag |
FES-Andock: Signatur-Doc als eigenes Artefakt, Container-Paket (Teil II) |
| S4 — Der Signatur-Layer | Die FES-Signatur soll als positionierte Grafik im PDF-Layer erscheinen (DocuSign-artig) | Facsimile-PNG/-SVG mit SHA-256 + guid-Stempel, Signaturplatte (Teil II) |
| S5 — Die Schlüsselfrage | Wie signieren wir Git-Commits selbst — GPG oder SSH — und wo liegen die privaten Schlüssel? | PII/GPG-Kreis, Identity-JSON-Schemas (Teil III, geplant) |
Was die Serie nicht ist
- Kein Rechtsrat. § 126b BGB, eIDAS-VO, § 371a ZPO und die GOB/Normen werden als Rahmen zitiert; die rechtliche Bewertung des Einzelfalls bleibt der freien Beweiswürdigung und ggf. anwaltlicher Beratung überlassen.
- Kein Ersatz für QES. Wo ein Gesetz die qualifizierte elektronische Signatur verlangt (z. B. notarielle Urkunden, bestimmte Behördenformate), gibt es keinen Git-nativen Weg — die Serie zeigt stattdessen, wie der QES-Vertrag im Repo verankert und referenziert wird.
- Keine Schlüssel-Verwaltung. Private Keys, Keyrings, GPG/SSH-Mechanik sind Teil-III-Stoff — bewusst getrennt, weil sie PII- und Infrastrukturthemen sind.
Querverweise
- Entrepreneur-Diary-Serie — die Anschauungs-Linie der ED-Serie; die Signatur-Saga setzt dort an, wo Dokumente entstehen, die signiert werden müssen (GVB, Verträge, Receipts).
- GCBoK-Kapitel 04 „GPG-Signierung" — normativer Rahmen; die Serie konkretisiert ihn auf Dokument-Ebene.
- V7GUID-Spec — guid-Stempel, Composite Key
V7GUID:uuidV7, Sidecar-Pflicht.
Erstellt: 260913 | Herausgeber: ORG-1 (Platzhalter, Herausgeber-Sicht) | Serie: digital-signage