FES — DIY digital signature — EU- and GoBD-compliant in your own Git repo
The Thesis
The advanced electronic signature (FES) is now a DIY matter. The building blocks — deterministic identification (V7GUID), integrity chain (SHA-256), cataloging (JSON schemas + sidecars), positioned signature graphic (Facsimile in the PDF layer), and cryptographic binding (PAdES) — are open standards and free tools. What a signature service packages at a premium, an organization builds itself with Git, JSON, and a PDF signing tool: EU-compliant (eIDAS Regulation, § 126b/126a BGB, § 371a ZPO) and GoBD-proof (a revision-safe evidence chain that does not reside with the service provider but in your own repo).
Not "DIY" in the sense of worse than DocuSign — but in the sense of where the duty to provide evidence lies: with the organization itself, in its Git repo. The difference is not the cryptography — that is standard. The difference is the seat of evidence: DocuSign lives in a cloud whose procedure the examiner cannot inspect; the GitCover chain resides in the repo, is verifiable without special tools (sha256sum + jq), and outlasts the service provider.
The series demonstrates the thesis in three parts:
- Text form (Part I): § 126b BGB under free assessment of evidence — without cryptography, solely through the chain (signature doc, events, sidecars).
- FES & Facsimile (Part II): eIDAS-compliant docking — positioned graphic in the PDF layer, signature plate, envelope report, container package.
- PII, GPG & Governikus (Part III, planned): key layer — signing identity, trust registry, key lifecycle, BSI-supported OpenPGP certification (pgp.governikus.de).
Why This Series?
Sooner or later, every company faces the question: How do we sign documents digitally without an examiner (tax office, auditor, court under free assessment of evidence, BSFZ, notary) rejecting the signature as insufficient?
Practice gives the usual answers to this question: buy a DocuSign account, book qualified signature services, or — worse — keep printing, signing, scanning. All three answers fail to solve the actual problem: they generate signature activity outside the Git repository in which the document lives. The evidence chain breaks precisely where it promises revision security.
This series shows the GitCover way: The signature becomes dockable in the repo. The document remains the MD file in the tenant repo; around it, a JSON-schema-based artifact set is created (signature doc, accept/deny event, sidecar verification) that sufficiently fulfills the text form requirement of § 126b BGB under free assessment of evidence — and later, when the business partner demands it, can be upgraded to the FES/ADES procedure (advanced electronic signature, DocuSign-style) without leaving the repo.
Limits of the Thesis
The "DIY FES" thesis is to be understood precisely:
- DIY = procedure, chain, and evidence are in your own hands (repo, open standards, free tools). It does not replace the certificate: the cryptographic binding needs a signature certificate — E1 obtained it via a signature service or their own certificate (e.g., a personal qualified one — no: FES does not need a qualified one; a regular certificate suffices).
- EU-compliant = eIDAS-compliant. The FES fulfills eIDAS Art. 25 (2) (equivalent to the handwritten signature, § 126 Abs. 3 BGB). The QES (substitute for written form, § 126a BGB) remains external (trust list) — the series docks it in, but does not replace it.
- GoBD-proof = the evidence chain (source document → signature doc → events → graphic → PDF) is repo-native, sha256sum-verifiable, retainable for 10 years (§ 147 AO) — without dependence on a service provider whose portal may no longer exist in 10 years.
The Series at a Glance
| Part | Trigger | Core question | Articles |
|---|---|---|---|
| Part I — Text form | A contract (GVB) is to be concluded in text form | How do we fulfill § 126b BGB Git-natively, under free assessment of evidence, without external signature services? | DS01–DS05 |
| Part II — FES & Facsimile | A business partner demands an advanced electronic signature | How do we dock an FES onto the repo — DocuSign-style, with a positioned graphic in the PDF layer? | DS06–DS11 |
| Part III — GCPN container schema | The first real signature process (research gain) | How does the procedure become machine-readable — as a normative JSON schema without internal redundancy? | DS12–DS15 |
| Part IV — PII, GPG & Governikus (split off) | Key management, SSH vs. OpenPGP, trust registry, official certification (gpg.governikus.de) | How do we manage the private keys and the signing identity model — and dock the BSI-supported GPG certification — without leaking PII into Git? | Planned (DS16–DS21) |
| Part V — Mobile & Community | Mobile use with GPG tools on smartphones/devices | How does the entrepreneur sign and verify on mobile — and which solutions are to be developed as a community work area? | Outline (no DS numbers) |
Separation note: The PII/GPG topics (key material, identity JSON schemas, GPG/SSH signature mechanics, keyring management) are deliberately covered only in Part IV — they are a compliance circle of their own (PII handling in the TOP repo, gitignored directories, trust registries) and must not be mixed with the document layer of Parts I–III.
The Saga: Trigger Model
As in the entrepreneur diary series, each article is set off by a concrete trigger in the life of the company — here, the signature events of an SME (fictional organization ORG-1, placeholder E1 as the entrepreneur):
| Trigger | Event | Consequence |
|---|---|---|
| S1 — The resolution | A shareholders' meeting resolution (GVB) is to be passed in text form — all shareholders are one person (E1), but the resolution is to be "signed" in a revision-safe, traceable way | Text form model: MD doc + JSON artifacts in the repo (Part I) |
| S2 — The verification question | An examiner asks: "Is the document authentic? Who 'signed' it?" | Sidecar verification: SHA-256, V7GUID, guid stamp (Part I) |
| S3 — The external partner | (Placeholder PARTNER-1) demands DocuSign for a project/purchase contract |
FES docking: signature doc as its own artifact, container package (Part II) |
| S4 — The signature layer | The FES signature is to appear as a positioned graphic in the PDF layer (DocuSign-style) | Facsimile PNG/SVG with SHA-256 + guid stamp, signature plate (Part II) |
| S5 — The key question | How do we sign Git commits ourselves — GPG or SSH — and where are the private keys? | PII/GPG circle, identity JSON schemas (Part III, planned) |
What the Series Is Not
- No legal advice. § 126b BGB, the eIDAS Regulation, § 371a ZPO, and the GOB/norms are cited as a framework; the legal assessment of the individual case is left to the free assessment of evidence and, where applicable, legal counsel.
- No substitute for QES. Where a law requires the qualified electronic signature (e.g., notarial deeds, certain public-authority formats), there is no Git-native path — instead, the series shows how the QES contract is anchored and referenced in the repo.
- No key management. Private keys, keyrings, and GPG/SSH mechanics are Part III material — deliberately kept separate, because they are PII and infrastructure topics.
Cross-References
- Entrepreneur Diary series — the illustrative line of the ED series; the signature saga picks up where documents are created that must be signed (GVB, contracts, receipts).
- GCBoK chapter 04 "GPG signing" — normative framework; the series concretizes it at the document level.
- V7GUID-Spec — guid stamp, Composite Key
V7GUID:uuidV7, sidecar obligation.
Created: 260913 | Publisher: ORG-1 (placeholder, publisher view) | Series: digital-signage