FES — Firma digital hecha por uno mismo — conforme a la UE y a GoBD en el propio repositorio Git
La tesis
La firma electrónica avanzada (FES) es hoy un asunto de hazlo-tú-mismo. Los componentes — identificación determinista (V7GUID), cadena de integridad (SHA-256), catalogación (JSON-Schemas + Sidecars), gráfico de firma posicionado (Facsimile en la capa PDF) y vinculación criptográfica (PAdES) — son estándares abiertos y herramientas libres. Lo que un servicio de firma empaqueta a precio elevado, una organización lo construye por sí misma con Git, JSON y una herramienta de firma de PDF: conforme a la UE (Reglamento eIDAS, § 126b/126a BGB, § 371a ZPO) y a prueba de GoBD (una cadena de evidencia a prueba de auditoría que no reside en el proveedor de servicios, sino en el propio repo).
No «hecho por uno mismo» en el sentido de peor que DocuSign — sino en el sentido de allí donde recae la obligación de prueba: en la propia organización, en su repositorio Git. La diferencia no es la criptografía — esa es estándar. La diferencia es la sede de la prueba: DocuSign vive en una nube cuyo procedimiento el examinador no puede inspeccionar; la cadena GitCover reside en el repo, es verificable sin herramientas especiales (sha256sum + jq) y sobrevive al proveedor de servicios.
La serie demuestra la tesis en tres partes:
- Forma textual (Parte I): § 126b BGB con libre valoración de la prueba — sin criptografía, solo mediante la cadena (documento de firma, eventos, sidecars).
- FES & Facsimile (Parte II): acoplamiento conforme a eIDAS — gráfico posicionado en la capa PDF, placa de firma, Envelope-Report, paquete de contenedor.
- PII, GPG & Governikus (Parte III, prevista): nivel de claves — Signing-Identity, Trust Registry, Key-Lifecycle, certificación OpenPGP respaldada por el BSI (pgp.governikus.de).
¿Por qué esta serie?
Toda empresa se enfrenta tarde o temprano a la pregunta: ¿Cómo firmamos documentos digitalmente sin que un examinador (Hacienda, auditor, tribunal en caso de libre valoración de la prueba, BSFZ, notario) desestime la firma como insuficiente?
La práctica da a esta pregunta las respuestas habituales: comprar una cuenta de DocuSign, contratar servicios de firma cualificados, o — peor — seguir imprimiendo, firmando, escaneando. Ninguna de las tres respuestas resuelve el problema real: generan actividad de firma fuera del repositorio Git, en el que vive el documento. La cadena de evidencia se rompe precisamente donde promete seguridad de auditoría.
Esta serie muestra el camino GitCover: La firma se vuelve acoplable en el repo. El documento sigue siendo el archivo MD en el Tenant-Repo; a su alrededor surge un conjunto de artefactos basado en JSON-Schema (documento de firma, evento de aceptación/rechazo, verificación sidecar) que cumple de forma suficiente el requisito de forma textual del § 126b BGB en caso de libre valoración de la prueba — y que más tarde, cuando lo exija el socio comercial, puede actualizarse al procedimiento FES/ADES (firma electrónica avanzada, al estilo DocuSign) sin abandonar el repo.
Límites de la tesis
La tesis «FES hecha por uno mismo» debe entenderse con precisión:
- Hecho por uno mismo = el procedimiento, la cadena y la evidencia están en manos propias (repo, estándares abiertos, herramientas libres). No sustituye al certificado: La vinculación criptográfica necesita un certificado de firma — E1 lo obtuvo a través de un servicio de firma o un certificado propio (p. ej., uno cualificado personal — no: la FES no necesita uno cualificado; basta un certificado ordinario).
- Conforme a la UE = conforme a eIDAS. La FES cumple eIDAS Art. 25 (2) (equivalente a la firma manuscrita, § 126 Abs. 3 BGB). La QES (sustituto de la forma escrita, § 126a BGB) permanece externa (Trust-Liste) — la serie la acopla, no la sustituye.
- A prueba de GoBD = la cadena de evidencia (documento fuente → documento de firma → eventos → gráfico → PDF) es nativa del repo, verificable con sha256sum, conservable durante 10 años (§ 147 AO) — sin dependencia de un proveedor de servicios cuyo portal quizá ya no exista dentro de 10 años.
La serie de un vistazo
| Parte | Desencadenante | Pregunta central | Artículos |
|---|---|---|---|
| Parte I — Forma textual | Un contrato (GVB) debe celebrarse en forma textual | ¿Cómo cumplimos el § 126b BGB de forma nativa en Git, con libre valoración de la prueba y sin servicios de firma externos? | DS01–DS05 |
| Parte II — FES & Facsimile | Un socio comercial exige una firma electrónica avanzada | ¿Cómo acoplamos una FES al repo — al estilo DocuSign, con gráfico posicionado en la capa PDF? | DS06–DS11 |
| Parte III — Esquema de contenedor GCPN | El primer proceso de firma real (beneficio de investigación) | ¿Cómo se vuelve el procedimiento legible por máquina — como esquema JSON normativo sin redundancia interna? | DS12–DS15 |
| Parte IV — PII, GPG & Governikus (separada) | Gestión de claves, SSH vs. OpenPGP, Trust Registry, certificación oficial (gpg.governikus.de) | ¿Cómo gestionamos las claves privadas y el modelo de Signing-Identity — y acoplamos la certificación GPG respaldada por el BSI — sin filtrar PII en Git? | Previsto (DS16–DS21) |
| Parte V — Mobile & Community | Uso móvil con herramientas GPG en smartphones/dispositivos | ¿Cómo firma y verifica el empresario desde el móvil — y qué soluciones deben desarrollarse como área de trabajo de la comunidad? | Esbozo (sin números DS) |
Nota de separación: Los temas PII/GPG (material de claves, JSON-Schemas de identidad, mecánica de firma GPG/SSH, gestión de keyrings) se tratan deliberadamente solo en la Parte IV — constituyen un círculo de cumplimiento propio (manejo de PII en el TOP-Repo, directorios gitignored, Trust-Registries) y no deben mezclarse con el nivel de documentos de las partes I–III.
La saga: modelo de desencadenantes
Como en la serie Unternehmer-Diary, cada artículo es impulsado por un
desencadenante concreto en la vida de la empresa — aquí los eventos de firma
de una pyme (organización ficticia ORG-1, marcador de posición E1 como empresario):
| Desencadenante | Evento | Consecuencia |
|---|---|---|
| S1 — El acuerdo | Una junta de socios (GVB) debe adoptarse en forma textual — todos los socios son una sola persona (E1), pero el acuerdo debe quedar "firmado" de forma trazable y con seguridad de auditoría | Modelo de forma textual: documento MD + artefactos JSON en el repo (Parte I) |
| S2 — La pregunta de verificación | Un examinador pregunta: "¿Es auténtico el documento? ¿Quién lo 'firmó'?" | Verificación sidecar: SHA-256, V7GUID, sello guid (Parte I) |
| S3 — El socio externo | (Marcador de posición PARTNER-1) exige DocuSign para un contrato de proyecto/compra |
Acoplamiento FES: documento de firma como artefacto propio, paquete de contenedor (Parte II) |
| S4 — La capa de firma | La firma FES debe aparecer como gráfico posicionado en la capa PDF (al estilo DocuSign) | Facsimile-PNG/-SVG con SHA-256 + sello guid, placa de firma (Parte II) |
| S5 — La pregunta de las claves | ¿Cómo firmamos nosotros mismos los Git-Commits — GPG o SSH — y dónde están las claves privadas? | Círculo PII/GPG, JSON-Schemas de identidad (Parte III, prevista) |
Lo que la serie no es
- No es asesoramiento jurídico. El § 126b BGB, el Reglamento eIDAS, el § 371a ZPO y las GOB/normas se citan como marco; la valoración jurídica del caso concreto queda reservada a la libre valoración de la prueba y, en su caso, al asesoramiento letrado.
- No es sustituto de la QES. Donde una ley exige la firma electrónica cualificada (p. ej., documentos notariales, determinados formatos de autoridades), no hay un camino nativo en Git — la serie muestra en cambio cómo el contrato QES se ancla y se referencia en el repo.
- No es gestión de claves. Las Private Keys, los keyrings y la mecánica GPG/SSH son material de la Parte III — deliberadamente separados, porque son temas de PII y de infraestructura.
Referencias cruzadas
- Serie Entrepreneur-Diary — la línea ilustrativa de la serie ED; la saga de firma comienza allí donde surgen documentos que deben firmarse (GVB, contratos, Receipts).
- Capítulo 04 de GCBoK «Firma GPG» — marco normativo; la serie lo concreta a nivel de documento.
- V7GUID-Spec — sello guid, Composite Key
V7GUID:uuidV7, obligación de sidecar.
Creado: 260913 | Editor: ORG-1 (marcador de posición, perspectiva del editor) | Serie: digital-signage