Phần IV — PII, GPG & Governikus (dự kiến)
Trạng thái: Dự kiến (DS16–DS21). Phần này được tách ra một cách có chủ đích khỏi phần còn lại của loạt bài — nó xử lý phạm vi PII (khóa riêng, dữ liệu Identity) và cơ chế chữ ký Git (SSH/OpenPGP), vốn tuân theo các quy tắc compliance riêng. Mới so với kế hoạch ban đầu: Dịch vụ chứng thực chính thức gpg.governikus.de (được BSI hỗ trợ) — đã được thảo luận trong các tài liệu Patent/GBM (DPMA-Recherche, D15) và trong bối cảnh BSFZ/FZul — sẽ được tích hợp như một điểm neo tin cậy.
Tại sao phải tách riêng?
Phần I–III xử lý tầng tài liệu (tài liệu nguồn, Signatur-Doc, Events, PDF-Layer, Container-Schema). Phần IV xử lý tầng khóa — và đây là một phạm vi compliance riêng:
| Khía cạnh | Phần I–III (tầng tài liệu) | Phần IV (tầng khóa) |
|---|---|---|
| Loại dữ liệu | Tài liệu kinh doanh | PII (khóa, dữ liệu Identity) |
| Nơi lưu trữ | Tenant-Repo (Git) | Thư mục PII (gitignored) |
| Quy tắc thư mục | Git-tracked, bắt buộc Sidecar | Không bao giờ commit |
| Khung pháp lý | § 126b BGB, § 371a ZPO, eIDAS | DSGVO, GoBD, NIS2, BSI TR-03124 |
| V7GUID-Classes | SIGNATURE_DOC/EVENT/GRAPHIC | SIGNING_IDENTITY, SIGNING_KEY, GOVERNIKUS_CERT |
Việc trộn lẫn cả hai tầng trong một bài viết sẽ làm pha loãng quy tắc PII
(Elektronische Unterschrift AD/ và vật liệu khóa không bao giờ nằm trong Git)
— vì thế mới có sự tách riêng này.
Điểm neo tin cậy: gpg.governikus.de
Dịch vụ gpg.governikus.de (bán chính thức, BSI là bên đặt hàng, do
Governikus GmbH & Co. KG vận hành) lấp khoảng trống mà chuỗi Textform (Phần I)
và FES (Phần II) để hở: danh tính của người sở hữu khóa được bảo đảm một
cách chính thức.
| Tầng | Bằng chứng | Tham chiếu chéo |
|---|---|---|
| Chuỗi Textform | Gán nguồn gốc qua Signatur-Doc + Events | Phần I (DS02–DS04) |
| FES/ADES | Ràng buộc mật mã + Chứng chỉ + Facsimile-Layer | Phần II (DS07–DS09) |
| Chứng thực GPG | Xác thực eID (Personalausweis) → đối chiếu tên → chứng thực Public Key bởi Governikus (ID khóa 0x5E5CCCB4A4BF43D7) | Phần IV |
| QES | Chứng chỉ đủ điều kiện (EU-Trust-Liste) | bên ngoài, kết nối (DS06) |
Luồng quy trình (6 giai đoạn, từ công việc chuẩn bị 250831 „GitCover® Identity Verification Procedures"):
- Tạo cặp khóa GPG (khuyến nghị Ed25519, tên trùng khớp chính xác với Personalausweis)
- Xác thực eID qua
gpg.governikus.de(AusweisApp, NFC/máy đọc thẻ, PIN) - Đối chiếu tên Personalausweis ↔ khóa GPG
- Governikus ký khóa công khai (chứng thực chính thức)
- Tích hợp vào các chuỗi bằng chứng GitCover (Signatur-Doc
signing_key_ref, Trust Registry) - Đăng ký các Git-Hash (chữ ký Commit ↔ khóa đã được chứng thực)
Nhờ đó hình thành một mức tin cậy „cao" được neo chính thức (BSI TR-03124, eIDAS) bên dưới QES — lý tưởng cho Identity-Registry (DS15) và các Key-Binding-Claim (DS17).
Các liên hệ với tài liệu Patent/GBM và BSFZ/FZul
Luồng Governikus đã được neo sẵn trong các tài liệu:
- DPMA-Recherche GCEP 260209 (D15): „Governikus GmbH & Co. KG: Dienste unter pgp.governikus.de für PGP-Beglaubigung und qualifizierte elektronische Signaturen" — là kỹ thuật hiện có, so với đó đóng góp riêng của GitCover đã được phân định.
- Đơn BSFZ GCUCB 2026 (dự án GitCover.IdP): Luồng chứng thực như một thành phần của kiến trúc chuỗi bằng chứng.
- Công việc chuẩn bị 250831 (
AIChats/…/GitCover®_Identity_Verification_Procedures): quy trình 6 giai đoạn, khuyến nghị Ed25519, tích hợp AusweisApp, Governikus-Fingerprint864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7.
Phần IV cụ thể hóa những công việc chuẩn bị này thành các bài viết có thể áp dụng.
Các bài viết dự kiến (DS16–DS21)
| Bài | Tiêu đề (dự kiến) | Câu hỏi cốt lõi | Yếu tố khởi phát |
|---|---|---|---|
| DS16 | Mô hình Signing-Identity: identity, signing-keys, authorization | Làm thế nào để chúng ta tách biệt danh tính được khai báo, Public Key được phép và thao tác Git thực sự được ký? | S5 |
| DS17 | Trust Registry: PII-Repo như nguồn khóa được phiên bản hóa | Làm thế nào để users/*/signing-keys.json được tạo một cách tất định thành allowed_signers (gpg.ssh.allowedSignersFile)? |
S5 |
| DS18 | Key-Lifecycle: validity, revocation, supersededBy | Làm thế nào để một chữ ký lịch sử vẫn còn hiệu lực khi khóa được xoay vòng? valid-after/valid-before | S5 |
| DS19 | Merge có chữ ký: mô hình --no-ff |
Tại sao Fast-Forward-Merge không có gì để ký — và hành động phê duyệt có chữ ký hình thành như thế nào? | S5 |
| DS20 | Chữ ký SSH ≠ SSH-Transport | Tại sao git commit -S với gpg.format ssh lại là một thứ khác với push qua ssh://? signatureScheme vs. transportAuthentication |
S5 |
| DS21 | Chứng thực chính thức: gpg.governikus.de như điểm neo tin cậy | Làm thế nào để gắn chứng thực eID (được BSI hỗ trợ) của khóa GPG vào Identity-Registry — quy trình 6 giai đoạn, đối chiếu tên, chữ ký chứng thực? | S5 |
Bốn Claim (chuẩn bị)
Saga của Phần IV sẽ được xây dựng trên bốn Claim riêng biệt (từ nghiên cứu 260912, Chat „GPG Daten Im JSON Schema"):
- Identity Claim — "Người dùng này là ai?"
- Key Binding Claim — "Public Key nào thuộc về người dùng này tại thời điểm đó?"
- Authorization Claim — "Người dùng này được phép làm gì trong repository này?"
- Signature Claim — "Chính khóa này đã ký chính xác đối tượng Git này chứ?"
Chuỗi kiểm định: Git Commit → gpgsig → Cryptographic verification → signer key → Key Registry (valid at commit timestamp? revoked?) → Identity Registry (user active?) → Authorization (may commit/merge/release?).
Với DS21, Claim thứ năm được bổ sung:
- Attestation Claim — "Danh tính này đã được chứng thực chính thức bằng quy trình eID (Personalausweis, BSI TR-03124)" — tức là chữ ký chứng thực của Governikus trên Public Key.
Kết nối với Phần I–III
Signatur-Doc (DS02) có trường tùy chọn signing_key_ref — trường này để trống
trong Phần I–III và được điền trong Phần IV: Đồ họa Facsimile (DS07) là đặc
điểm hiển thị được; khóa là đặc điểm mật mã; chứng thực Governikus
là chứng nhận chính thức cho việc sở hữu khóa. Cả ba đều gắn với cùng một
Identity-Registry.
Tạo: 260913 | Phần IV (dự kiến) của loạt bài digital-signage