FES — Chữ ký số tự làm — tuân thủ EU và GoBD ngay trong Git-Repo của chính mình
Luận điểm
Chữ ký điện tử nâng cao (FES) ngày nay là việc tự làm. Các thành phần — nhận dạng tất định (V7GUID), chuỗi toàn vẹn (SHA-256), lập danh mục (JSON-Schema + Sidecar), đồ họa chữ ký được định vị (Facsimile trong lớp PDF) và liên kết mật mã (PAdES) — là những tiêu chuẩn mở và công cụ tự do. Điều mà một dịch vụ chữ ký đóng gói đắ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 (Quy định eIDAS, § 126b/126a BGB, § 371a ZPO) và vững theo GoBD (chuỗi bằng chứng có thể 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 nghĩa vụ chứng minh nằm: tại chính tổ chức, trong Git-Repo của họ. Sự khác biệt không nằm ở mật mã — nó là tiêu chuẩn. Sự khác biệt nằm ở vị trí 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 hơn nhà cung cấp dịch vụ.
Loạt bài chứng minh luận điểm này trong ba phần:
- Hình thức văn bản (Phần I): § 126b BGB trong đánh giá chứng cứ tự do — không cần mật mã, chỉ bằng chuỗi (Signatur-Doc, Events, Sidecar).
- FES & Facsimile (Phần II): kết nối tuân thủ eIDAS — đồ họa được định vị trong lớp PDF, bảng chữ ký, báo cáo phong bì, gói container.
- PII, GPG & Governikus (Phần III, dự kiến): cấp độ khóa — Signing-Identity, Trust Registry, vòng đời khóa, chứng thực OpenPGP được BSI hỗ trợ (pgp.governikus.de).
Vì sao có loạt bài này?
Mỗi doanh nghiệp sớm hay muộn đều đứng trước câu hỏi: Làm thế nào để chúng ta ký tài liệu bằng kỹ thuật số mà không bị 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) bác bỏ chữ ký vì cho là không đủ?
Thực tiễn đưa ra những câu trả lời thông thường cho câu hỏi này: 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, quét. Cả ba câu trả lời đều không giải quyết vấn đề thực sự: chúng tạo ra hoạt động ký bên ngoài Git-Repository, nơi tài liệu tồn tại. Chuỗi bằng chứng đứt đúng tại nơi nó hứa hẹn sự an toàn kiểm toán.
Loạt bài này chỉ ra 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ộ tạo tác dựa trên JSON-Schema (Signatur-Doc, sự kiện Accept/Deny, xác minh Sidecar), đáp ứng đầy đủ yêu cầu hình thức văn bản của § 126b BGB trong đánh giá chứng cứ tự do — và sau này, khi đối tác kinh doanh yêu cầu, có thể được 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 cần 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). Nó không thay thế chứng chỉ: liên kết mật mã cần một chứng chỉ chữ ký — E1 có được nó thông qua một dịch vụ chữ ký hoặc một chứng chỉ riêng (ví dụ chứng chỉ cá nhân đủ điều kiện — không: FES không cần chứng chỉ đủ đ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 Điều 25 (2) eIDAS (tương đương chữ ký viết tay, § 126 Abs. 3 BGB). QES (thay thế hình thức văn bản viết, § 126a BGB) vẫn là bên ngoài (Trust-Liste) — loạt bài kết nối nó, không thay thế nó.
- Vững theo GoBD = chuỗi bằng chứng (tài liệu nguồn → Signatur-Doc → Events → đồ họa → PDF) là bản địa trong repo, có thể kiểm tra bằng sha256sum, lưu trữ được 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 nữa.
Loạt bài trong một cái nhìn tổng quan
| Phần | Tác nhân kích hoạt | Câu hỏi cốt lõi | Bài viết |
|---|---|---|---|
| Phần I — Hình thức văn bản | Một hợp đồng (GVB) cần được giao kết dưới dạng văn bản | Làm thế nào để chúng ta đáp ứng § 126b BGB theo cách thuần Git, trong đánh giá chứng cứ tự do, không cần 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 chữ ký điện tử nâng cao | Làm thế nào để chúng ta kết nối FES vào repo — kiểu DocuSign, với đồ họa được định vị trong lớp PDF? | DS06–DS11 |
| Phần III — Schema container GCPN | Quy trình ký thực sự đầu tiên (lợi ích nghiên cứu) | Làm thế nào để quy trình trở nên máy đọc được — như một JSON-Schema quy chuẩn không có dư thừa nội bộ? | 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 — Di động & Cộng đồng | Sử dụng di động với các công cụ GPG trên điện thoại thông minh/thiết bị | Làm thế nào để doanh nhân ký và kiểm tra trên thiết bị di động — 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ộng đồng? | Đề cương (không có số DS) |
| Phần VI — Tài liệu được ký bằng Git | Một hợp đồng cần được trình bày/phê duyệt một cách có thể theo dõi trước khi ký | Làm thế nào để ghi nhận các sự kiện (hiển thị/phê duyệt/chữ ký) cho từng tài liệu mà không thay đổi Ur-Doc bất biến? | Tạo tác chữ ký *.gcsig.md cho mỗi Ur-Doc từ bản nháp |
Lưu ý tách biệt: Các chủ đề PII/GPG (tài liệu khóa, JSON-Schema nhận dạng, cơ chế ký GPG/SSH, quản lý keyring) được cố ý chỉ đề cập ở Phần IV — chúng là một vòng tuân thủ riêng (xử lý PII trong TOP-Repo, thư mục bị gitignore, Trust-Registry) và không được trộn lẫn với cấp độ tài liệu của các Phần I–III.
Saga: Mô hình tác nhân kích hoạt
Như trong loạt bài Nhật ký Doanh nhân, mỗi bài viết được khởi phát bởi một
tác nhân kích hoạt cụ thể trong đời sống doanh nghiệp — ở đây là các sự kiện chữ ký
của một KMU (tổ chức hư cấu ORG-1, placeholder E1 là doanh nhân):
| Tác nhân kích hoạt | Sự kiện | Hệ quả |
|---|---|---|
| S1 — Nghị quyết | Một cuộc họp hội đồng thành viên (GVB) cần được lập dưới dạng văn bản — tất cả thành viên chỉ là một người (E1), nhưng nghị quyết cần được "ký" một cách có thể theo dõi và an toàn kiểm toán | Mô hình dạng văn bản: MD-Doc + tạo tác JSON 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 này có xác thực không? Ai đã 'ký' nó?" | Xác minh Sidecar: 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 tạo tác riêng, gói container (Phần II) |
| S4 — Lớp chữ ký | Chữ ký FES cần xuất hiện như đồ họa được định vị trong lớp PDF (kiểu DocuSign) | Facsimile-PNG/-SVG với SHA-256 + dấu guid, bảng chữ ký (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à các khóa riêng nằm ở đâu? | Vòng PII/GPG, JSON-Schema nhận dạng (Phần III, dự kiến) |
Loạt bài này không phải là gì
- Không phải tư vấn pháp lý. § 126b BGB, Quy định eIDAS, § 371a ZPO và GOB/các chuẩn mực được trích dẫn như khuôn khổ; 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à nếu cần thì tư vấn luật sư.
- Không thay thế QES. Ở nơi luật 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ơ quan nhà nước), không có con đường thuần Git — thay vào đó, loạt bài chỉ ra cách hợp đồng QES được neo và tham chiếu trong repo.
- Không quản lý khóa. Khóa riêng, keyring, cơ chế GPG/SSH là nội dung Phần III — được tách biệt có chủ đích vì chúng là các chủ đề PII và hạ tầng.
Tham chiếu chéo
- Loạt bài Nhật ký Doanh nhân — tuyến minh họa của loạt ED; saga chữ ký bắt đầu ở nơi hình thành các tài liệu cần được ký (GVB, hợp đồng, biên lai).
- Chương 04 GCBoK „Ký GPG" — khuôn khổ quy chuẩn; loạt bài cụ thể hóa nó ở cấp độ tài liệu.
- V7GUID-Spec — dấu guid, khóa tổng hợp
V7GUID:uuidV7, yêu cầu bắt buộc Sidecar.
Tạo: 260913 | Nhà phát hành: ORG-1 (placeholder, góc nhìn nhà phát hành) | Loạt bài: digital-signage