FES — Chữ ký số tự làm — Tuân thủ EU và GoBD trong Git-Repo của chính mình

Luận điểm

Chữ ký điện tử nâng cao (FES — Fortgeschrittene elektronische Signatur) ngày nay là chuyện tự làm được. Các khối cấu thành — định danh tất định (V7GUID), chuỗi toàn vẹn (SHA-256), việc lập danh mục (JSON-Schemas + Sidecars), đồ họa chữ ký định vị (Facsimile trong PDF-Layer) và ràng buộc mật mã (PAdES) — là các tiêu chuẩn mở và công cụ tự do. Điều mà một dịch vụ chữ ký đóng gói với giá đắt đỏ, một tổ chức có thể tự xây dựng bằng Git, JSON và một công cụ ký PDF: tuân thủ EU (eIDAS-VO, § 126b/126a BGB, § 371a ZPO) và vững trước GoBD (một chuỗi bằng chứng an toàn kiểm toán không nằm ở nhà cung cấp dịch vụ, mà nằm trong repo của chính mình).

Không phải „tự làm" theo nghĩa kém hơn DocuSign — mà theo nghĩa nơi phát sinh nghĩa vụ chứng minh: tại chính tổ chức, trong Git-Repo của tổ chức đó. Sự khác biệt không nằm ở phần mật mã — phần đó là tiêu chuẩn. Sự khác biệt nằm ở nơi đặt bằng chứng: DocuSign sống trong một đám mây mà người kiểm tra không thể xem xét quy trình của nó; chuỗi GitCover nằm trong repo, có thể kiểm tra mà không cần công cụ chuyên dụng (sha256sum + jq) và tồn tại lâu dài hơn nhà cung cấp dịch vụ.

Chuỗi bài chứng minh luận điểm này qua ba phần:

Textform (Phần I): § 126b BGB trong đánh giá chứng cứ tự do — không cần mật mã, chỉ nhờ chuỗi (Signatur-Doc, Events, Sidecars).
FES & Facsimile (Phần II): kết nối tuân thủ eIDAS — đồ họa định vị trong PDF-Layer, Signaturplatte, Envelope-Report, Container-Paket.
PII, GPG & Governikus (Phần III, dự kiến): tầng khóa — Signing-Identity, Trust Registry, Key-Lifecycle, chứng thực OpenPGP được BSI hỗ trợ (pgp.governikus.de).

Tại sao có chuỗi bài này?

Mỗi doanh nghiệp sớm hay muộn cũng đứng trước câu hỏi: Làm thế nào chúng ta ký tài liệu dưới dạng số mà người kiểm tra (cơ quan thuế, kiểm toán viên, tòa án trong đánh giá chứng cứ tự do, BSFZ, công chứng viên) không bác bỏ chữ ký vì cho là chưa đủ?

Thực tế trả lời câu hỏi này bằng những câu trả lời quen thuộc: mua tài khoản DocuSign, đặt dịch vụ chữ ký đủ điều kiện, hoặc — tệ hơn — tiếp tục in, ký tay, scan. Cả ba câu trả lời đều không giải quyết được vấn đề thực chất: chúng tạo ra hoạt động ký bên ngoài Git-Repository — nơi tài liệu đang tồn tại. Chuỗi bằng chứng đứt gãy đúng ở nơi nó hứa hẹn sự an toàn kiểm toán.

Chuỗi bài này cho thấy con đường GitCover: Chữ ký trở nên có thể kết nối trong repo. Tài liệu vẫn là tệp MD trong Tenant-Repo; xung quanh nó hình thành một bộ artifact dựa trên JSON-Schema (Signatur-Doc, Accept-/Deny-Event, Sidecar-Verifikation), đáp ứng đầy đủ yêu cầu Textform của § 126b BGB trong đánh giá chứng cứ tự do — và về sau, khi đối tác kinh doanh yêu cầu, có thể nâng cấp lên quy trình FES-/ADES (chữ ký điện tử nâng cao, kiểu DocuSign) mà không phải rời khỏi repo.

Giới hạn của luận điểm

Luận điểm „FES tự làm" cần được hiểu một cách chính xác:

Tự làm = quy trình, chuỗi và bằng chứng nằm trong tay chính mình (repo, tiêu chuẩn mở, công cụ tự do). Điều đó không thay thế chứng chỉ: Ràng buộc mật mã cần một chứng chỉ ký — E1 có được chứng chỉ đó qua một dịch vụ chữ ký hoặc một chứng chỉ riêng (ví dụ: loại đủ điều kiện cá nhân — không: FES không cần loại đủ điều kiện; một chứng chỉ thông thường là đủ).
Tuân thủ EU = tuân thủ eIDAS. FES đáp ứng eIDAS Art. 25 (2) (tương đương chữ ký tay, § 126 Abs. 3 BGB). QES (thay thế cho Schriftform, § 126a BGB) vẫn nằm bên ngoài (Trust-Liste) — chuỗi bài kết nối nó, chứ không thay thế nó.
Vững trước GoBD = chuỗi bằng chứng (tài liệu nguồn → Signatur-Doc → Events → đồ họa → PDF) là repo-nativ, kiểm tra được bằng sha256sum, có thể lưu trữ 10 năm (§ 147 AO) — không phụ thuộc vào một nhà cung cấp dịch vụ mà cổng thông tin của họ có thể không còn tồn tại sau 10 năm.

Chuỗi bài trong một cái nhìn

Phần	Yếu tố khởi phát	Câu hỏi cốt lõi	Bài viết
Phần I — Textform	Một hợp đồng (GVB) cần được giao kết dưới dạng Textform	Làm thế nào chúng ta đáp ứng § 126b BGB theo kiểu Git-nativ, trong đánh giá chứng cứ tự do, mà không dùng dịch vụ chữ ký bên ngoài?	DS01–DS05
Phần II — FES & Facsimile	Một đối tác kinh doanh yêu cầu một chữ ký điện tử nâng cao	Làm thế nào chúng ta kết nối một FES vào repo — kiểu DocuSign, với đồ họa định vị trong PDF-Layer?	DS06–DS11
Phần III — GCPN-Container-Schema	Vụ chữ ký thực sự đầu tiên (Forschungsgewinn)	Làm thế nào để quy trình này có thể đọc bằng máy — dưới dạng một JSON-Schema mang tính quy phạm, không có sự dư thừa bên trong?	DS12–DS15
Phần IV — PII, GPG & Governikus (tách riêng)	Quản lý khóa, SSH so với OpenPGP, Trust Registry, chứng thực chính thức (gpg.governikus.de)	Làm thế nào chúng ta quản lý các khóa riêng và mô hình Signing-Identity — và kết nối chứng thực GPG được BSI hỗ trợ — mà không làm rò rỉ PII vào Git?	Dự kiến (DS16–DS21)
Phần V — Mobile & Community	Sử dụng di động với các công cụ GPG trên smartphone/thiết bị	Doanh nhân ký và kiểm tra trên di động như thế nào — và những giải pháp nào cần được phát triển như một lĩnh vực làm việc của cộng đồng?	Phác thảo (không có số DS)

Lưu ý về tách biệt: Các chủ đề PII/GPG (vật liệu khóa, Identity JSON-Schemas, cơ chế chữ ký GPG/SSH, quản lý Keyring) được cố ý chỉ xử lý trong Phần IV — chúng là một vòng tuân thủ riêng (xử lý PII trong TOP-Repo, các thư mục gitignored, Trust-Registries) và không được trộn lẫn với tầng tài liệu của các Phần I–III.

Bản saga: Mô hình yếu tố khởi phát

Giống như trong chuỗi Unternehmer-Diary, mỗi bài viết được khởi phát bởi một yếu tố khởi phát cụ thể trong đời sống doanh nghiệp — ở đây là các sự kiện chữ ký của một doanh nghiệp vừa và nhỏ (tổ chức hư cấu ORG-1, placeholder E1 với vai trò doanh nhân):

Yếu tố khởi phát	Sự kiện	Hệ quả
S1 — Nghị quyết	Một đại hội đồng thành viên (GVB) cần được lập dưới dạng Textform — tất cả các thành viên là một người (E1), nhưng nghị quyết phải được "ký" một cách truy vết được và an toàn kiểm toán	Mô hình Textform: MD-Doc + JSON-Artefakte trong repo (Phần I)
S2 — Câu hỏi xác minh	Một người kiểm tra hỏi: "Tài liệu có xác thực không? Ai đã 'ký' nó?"	Sidecar-Verifikation: SHA-256, V7GUID, dấu guid (Phần I)
S3 — Đối tác bên ngoài	(Placeholder `PARTNER-1`) yêu cầu DocuSign cho một hợp đồng dự án/mua bán	Kết nối FES: Signatur-Doc như một artifact riêng, Container-Paket (Phần II)
S4 — Signatur-Layer	Chữ ký FES cần xuất hiện dưới dạng đồ họa định vị trong PDF-Layer (kiểu DocuSign)	Facsimile-PNG/-SVG với SHA-256 + dấu guid, Signaturplatte (Phần II)
S5 — Câu hỏi về khóa	Làm thế nào chúng ta tự ký các Git-Commit — GPG hay SSH — và khóa riêng nằm ở đâu?	Vòng PII/GPG, Identity-JSON-Schemas (Phần III, dự kiến)

Những điều chuỗi bài này không phải là

Không phải tư vấn pháp lý. § 126b BGB, eIDAS-VO, § 371a ZPO và GOB/Normen được trích dẫn như một khung tham chiếu; việc đánh giá pháp lý từng trường hợp cụ thể vẫn thuộc về đánh giá chứng cứ tự do và — khi cần — việc tham vấn luật sư.
Không thay thế cho QES. Ở những nơi luật pháp yêu cầu chữ ký điện tử đủ điều kiện (ví dụ: văn bản công chứng, một số định dạng của cơ quan nhà nước), không có con đường Git-nativ nào — thay vào đó, chuỗi bài cho thấy hợp đồng QES được neo giữ trong repo và được tham chiếu như thế nào.
Không phải quản lý khóa. Private Keys, Keyring, cơ chế GPG/SSH là nội dung của Phần III — được cố ý tách riêng, vì chúng là các chủ đề về PII và hạ tầng.

Tham chiếu chéo

Entrepreneur-Diary-Serie — tuyến minh họa của chuỗi ED; bản saga chữ ký bắt đầu tại nơi các tài liệu cần được ký ra đời (GVB, hợp đồng, Receipts).
GCBoK-Chương 04 „GPG-Signierung" — khung quy phạm; chuỗi bài cụ thể hóa nó ở tầng tài liệu.
V7GUID-Spec — dấu guid, Composite Key V7GUID:uuidV7, bắt buộc Sidecar.

Đã tạo: 260913 | Nhà phát hành: ORG-1 (placeholder, góc nhìn của nhà phát hành) | Chuỗi: digital-signage