FES — Firma digital hecha uno mismo — conforme a la UE y a GoBD en el propio repositorio Git
La tesis
La firma electrónica avanzada (FES) es hoy cosa de hacer uno mismo. Los componentes — identificación determinista (V7GUID), cadena de integridad (SHA-256), catalogación (esquemas JSON + 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 de forma costosa, 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 sólido frente a GoBD (la cadena de prueba resistente a auditorías, que no reside en el proveedor de servicios, sino en el propio repositorio).
No "hecho uno mismo" en el sentido de peor que DocuSign — sino en el sentido de allí donde reside 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 verificador no puede inspeccionar; la cadena GitCover está en el repositorio, 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 y facsímil (Parte II): acoplamiento conforme a eIDAS — gráfico posicionado en la capa PDF, placa de firma, Envelope-Report, paquete contenedor.
- PII, GPG y Governikus (Parte III, planificada): nivel de claves — Signing-Identity, Trust Registry, ciclo de vida de claves, certificación OpenPGP respaldada por 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 verificador (administración tributaria, auditor, tribunal en el marco de la libre valoración de la prueba, BSFZ, notario) rechace la firma por considerarla insuficiente?
La práctica da a esta pregunta las respuestas habituales: comprar una cuenta de DocuSign, contratar servicios de firma cualificada o — peor aún — seguir imprimiendo, firmando, escaneando. Ninguna de las tres respuestas resuelve el verdadero problema: generan actividad de firma fuera del repositorio Git en el que vive el documento. La cadena de prueba se rompe justo allí donde promete seguridad de auditoría.
Esta serie muestra el camino GitCover: la firma se vuelve acoplable en el repositorio. El documento sigue siendo el archivo MD en el repositorio del tenant; a su alrededor surge un conjunto de artefactos basado en esquemas JSON (documento de firma, evento de aceptación/denegación, verificación de sidecar) que cumple suficientemente el requisito de forma textual del § 126b BGB con libre valoración de la prueba — y que más tarde, cuando lo exija el socio comercial, puede equiparse para el procedimiento FES-/ADES (firma electrónica avanzada, al estilo DocuSign) sin abandonar el repositorio.
Límites de la tesis
La tesis "FES hecha uno mismo" debe entenderse con precisión:
- Hecho uno mismo = el procedimiento, la cadena y la prueba están en la propia mano (repositorio, estándares abiertos, herramientas libres). No sustituye al certificado: la vinculación criptográfica necesita un certificado de firma — que E1 obtuvo a través de un servicio de firma o mediante un certificado propio (p. ej., uno personal cualificado — no: la FES no necesita uno cualificado; basta un certificado normal).
- 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) sigue siendo externa (lista de confianza) — la serie la acopla, no la sustituye.
- Sólido frente a GoBD = la cadena de prueba (documento fuente → documento de firma → eventos → gráfico → PDF) es nativa del repositorio, 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, sin servicios de firma externos? | DS01–DS05 |
| Parte II — FES y facsímil | Un socio comercial exige una firma electrónica avanzada | ¿Cómo acoplamos una FES al repositorio — 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 y 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 BSI — sin filtrar PII en Git? | Planificada (DS16–DS21) |
| Parte V — Móvil y comunidad | Uso móvil con herramientas GPG en smartphones/dispositivos | ¿Cómo firma y verifica el empresario en movilidad — y qué soluciones deben desarrollarse como ámbito de trabajo comunitario? | Esbozo (sin números DS) |
| Parte VI — Documentos firmados con Git | Un contrato debe presentarse/aprobarse de forma comprensible antes de la firma | ¿Cómo se registran los eventos (visualización/aprobación/firma) por documento, sin modificar el documento original inmutable? | Artefacto de firma *.gcsig.md por documento original desde el borrador |
Nota de separación: Los temas de PII/GPG (material de claves, esquemas JSON 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 repositorio TOP, directorios ignorados por git, registros de confianza) y no deben mezclarse con el nivel documental de las partes I–III.
La saga: modelo de desencadenantes
Como en la serie Entrepreneur-Diary, cada artículo está motivado por un
desencadenante concreto en la vida empresarial — aquí, los eventos de firma
de una PYME (organización ficticia ORG-1, marcador de posición E1 como empresario):
| Desencadenante | Evento | Consecuencia |
|---|---|---|
| S1 — La resolución | Una junta de socios (GVB) debe adoptarse en forma textual — todos los socios son una sola persona (E1), pero la resolución debe estar "firmada" de forma trazable y a prueba de auditoría | Modelo de forma textual: documento MD + artefactos JSON en el repositorio (Parte I) |
| S2 — La pregunta de verificación | Un verificador pregunta: "¿Es auténtico el documento? ¿Quién lo ha 'firmado'?" | Verificación de 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/compraventa |
Acoplamiento FES: documento de firma como artefacto propio, paquete contenedor (Parte II) |
| S4 — La capa de firma | La firma FES debe aparecer como gráfico posicionado en la capa PDF (al estilo DocuSign) | PNG/SVG de facsímil con SHA-256 + sello guid, placa de firma (Parte II) |
| S5 — La cuestión de las claves | ¿Cómo firmamos nosotros mismos los commits de Git — GPG o SSH — y dónde están las claves privadas? | Círculo PII/GPG, esquemas JSON de identidad (Parte III, planificada) |
Lo que la serie no es
- No es asesoramiento jurídico. El § 126b BGB, el Reglamento eIDAS, el § 371a ZPO y las normas GOB se citan como marco; la valoración jurídica del caso concreto queda sujeta a la libre valoración de la prueba y, en su caso, al asesoramiento de un abogado.
- No sustituye a la QES. Donde una ley exige la firma electrónica cualificada (p. ej., escrituras notariales, determinados formatos administrativos), no existe una vía nativa de Git — la serie muestra, en cambio, cómo el contrato QES se ancla y referencia en el repositorio.
- No es gestión de claves. Las claves privadas, los keyrings y la mecánica GPG/SSH son materia de la Parte III — deliberadamente separados, porque son temas de PII e infraestructura.
Referencias cruzadas
- Serie Entrepreneur-Diary — la línea ilustrativa de la serie ED; la saga de firmas arranca allí donde surgen documentos que deben firmarse (GVB, contratos, recibos).
- Capítulo 04 de GCBoK "Firma GPG" — marco normativo; la serie lo concreta a nivel documental.
- Especificación V7GUID — sello guid, clave compuesta
V7GUID:uuidV7, obligatoriedad de sidecar.
Creado: 260913 | Editor: ORG-1 (marcador de posición, perspectiva del editor) | Serie: digital-signage