FES — Digital signature do-it-yourself — EU- and GoBD-compliant in your own Git repo
The thesis
The advanced electronic signature (FES) is a do-it-yourself matter today. The building blocks — deterministic identification (V7GUID), integrity chain (SHA-256), cataloguing (JSON schemas + sidecars), positioned signature graphic (facsimile in the PDF layer) and crypto binding (PAdES) — are open standards and free tools. What a signature service packages expensively, an organization builds itself with Git, JSON and a PDF signing tool: EU-compliant (eIDAS Regulation, § 126b/126a BGB, § 371a ZPO) and GoBD-proof (ver audit-proof chain of evidence that does not lie with the service provider, but in one's own repo).
Not "do-it-yourself" in the sense of worse than DocuSign — but in the sense of where the burden of proof lies: with the organization itself, in its Git repo. The difference is not the crypto — that is standard. The difference is the seat of proof: DocuSign lives in a cloud whose procedures the examiner cannot inspect; the GitCover chain lies in the repo, is verifiable without special tools (sha256sum + jq) and outlives the service provider.
The series substantiates the thesis in three parts:
- Text form (Part I): § 126b BGB under free evaluation of evidence — without crypto, 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 level — signing identity, trust registry, key lifecycle, BSI-supported OpenPGP certification (pgp.governikus.de).
Why this series?
Every company sooner or later faces the question: How do we sign documents digitally without an examiner (tax office, auditor, court under free evaluation 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 do not solve the actual problem: they generate signature activity outside the Git repository in which the document lives. The chain of evidence breaks precisely where it promises audit 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 emerges (signature doc, accept/deny event, sidecar verification) that sufficiently fulfils the text form requirement of § 126b BGB under free evaluation 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 thesis "FES do-it-yourself" must be understood precisely:
- Do-it-yourself = procedure, chain and proof lie in one's own hands (repo, open standards, free tools). It does not replace the certificate: the crypto binding requires a signature certificate — E1 obtained this via a signature service or its own certificate (e.g. personal qualified — no: FES does not require a qualified one; a regular certificate suffices).
- EU-compliant = eIDAS-compliant. The FES fulfils eIDAS Art. 25 (2) (equivalent to the handwritten signature, § 126 (3) BGB). The QES (replacement for written form, § 126a BGB) remains external (trust list) — the series docks it, does not replace it.
- GoBD-proof = the chain of evidence (source document → signature doc → events → graphic → PDF) is repo-native, verifiable with sha256sum, 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 fulfil § 126b BGB Git-natively, under free evaluation 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 to the repo — DocuSign-style, with 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) |
| Part VI — Git-signed documents | A contract is to be presented/approved in a traceable manner before signing | How are the events (display/approval/signature) recorded per document without changing the immutable original doc? | Signature artifact *.gcsig.md per original doc from draft onwards |
Separation note: The PII/GPG topics (key material, identity JSON schemas, GPG/SSH signature mechanics, keyring management) are deliberately dealt with only in Part IV — they are a separate compliance circle (PII handling in the TOP repo, gitignored directories, trust registries) and must not be mixed with the document level of Parts I–III.
The saga: trigger model
As in the entrepreneur diary series, each article is prompted by a concrete
trigger in business life — here the signature events
of an SME (fictional organization ORG-1, placeholder E1 as entrepreneur):
| Trigger | Event | Consequence |
|---|---|---|
| S1 — The resolution | A shareholders' meeting (GVB) is to be held in text form — all shareholders are one person (E1), but the resolution is to be traceably "signed" in an audit-proof manner | 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 a separate 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 stored? | 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/standards are cited as a framework; the legal assessment of the individual case remains subject to free evaluation of evidence and, where applicable, legal advice.
- No replacement for QES. Where a law requires the qualified electronic signature (e.g. notarial deeds, certain authority formats), there is no Git-native way — instead, the series shows how the QES contract is anchored and referenced in the repo.
- No key management. Private keys, keyrings, GPG/SSH mechanics are Part III material — deliberately separated because they are PII and infrastructure topics.
Cross-references
- Entrepreneur diary series — the illustrative line of the ED series; the signature saga starts where documents that must be signed come into being (GVB, contracts, receipts).
- GCBoK Chapter 04 "GPG signing" — normative framework; the series concretises it at document level.
- V7GUID spec — guid stamp, composite key
V7GUID:uuidV7, mandatory sidecar.
Created: 260913 | Publisher: ORG-1 (placeholder, publisher's view) | Series: digital-signage