# Declaración de Prácticas del Servicio de Confianza

**Marcos de referencia:** Reglamento (UE) n.º 910/2014 (eIDAS), modificado por el Reglamento (UE)
2024/1183 · ETSI EN 319 401 (requisitos generales para prestadores de servicios de confianza) ·
ETSI EN 319 421 (sellado de tiempo) · RFC 3161 · RFC 6962

**Organización:** Veritas Digital LLC · **Servicio:** Veritas UGC
**Versión:** 1.0 · 5 de agosto de 2026 · **Identificador:** `VUGC-DPS-1.0`

---

## 0 · Declaración de estatus — la parte que nadie debe saltarse

**Veritas UGC NO es un prestador cualificado de servicios de confianza en el sentido del
Reglamento eIDAS.** No figura en ninguna lista de confianza nacional, no ha sido auditada por un
organismo de evaluación de la conformidad y **sus sellos de tiempo no son sellos cualificados**.

En consecuencia, **los certificados de Veritas UGC no gozan de la presunción legal de exactitud
de la fecha y hora** que el artículo 41.2 de eIDAS reserva a los sellos cualificados. Cualquier
afirmación en sentido contrario sería falsa, y este documento existe en parte para impedir que
alguien la haga.

**Qué es este documento, entonces.** Una Declaración de Prácticas redactada según la estructura
que ETSI exige a un prestador cualificado, aplicada a un servicio que no lo es. Se publica por
tres razones concretas:

1. **Transparencia operativa.** El lector puede saber exactamente cómo se genera un sello, con qué
   fuente de tiempo, con qué algoritmos y con qué limitaciones — la misma información que
   publicaría un prestador cualificado.
2. **Preparación.** Si algún día se busca la cualificación, el trabajo documental está hecho y la
   distancia real es medible.
3. **Honestidad competitiva.** Varios servicios del sector insinúan valor legal cualificado sin
   tenerlo. Declararlo abiertamente es la posición más defendible.

**Y lo más importante:** el artículo 41.1 de eIDAS establece que **a un sello de tiempo electrónico
no se le pueden denegar efectos jurídicos ni admisibilidad como prueba por el mero hecho de no ser
cualificado**. La cualificación otorga una presunción; su ausencia no anula la prueba, solo obliga
a acreditarla. Este documento es, precisamente, el instrumento para acreditarla.

---

## 1 · Identificación del prestador

| Campo | Valor |
|---|---|
| Razón social | Veritas Digital LLC |
| Servicio | Veritas UGC — sellado, certificación y verificación de contenido |
| Dominio del servicio | `ugc.veritasdigital.tech` |
| Contacto de seguridad | `/.well-known/security.txt` |
| Estatus eIDAS | **No cualificado** |
| Identificador de esta declaración | `VUGC-DPS-1.0` |

---

## 2 · Servicios prestados

| Servicio | Descripción | Norma aplicada |
|---|---|---|
| **Sellado de tiempo** | Token de sello de tiempo emitido por una autoridad externa sobre la huella de la obra | RFC 3161 |
| **Anclaje en cadena de bloques** | Inclusión de la huella en un bloque de Bitcoin mediante calendarios públicos | OpenTimestamps |
| **Registro de transparencia** | Árbol de Merkle de solo-anexado con pruebas de inclusión y consistencia | RFC 6962 |
| **Certificación documental** | Documento firmado que consolida huella, sellos, anclaje y metadatos declarados | — |
| **Verificación pública** | Comprobación independiente de un certificado por cualquier tercero | — |

---

## 3 · Fuente de tiempo — el punto crítico

Un servicio de sellado se juega su credibilidad en de dónde saca la hora. Aquí la respuesta es
deliberadamente **redundante y externa**:

| Fuente | Naturaleza | Qué acredita | ¿La controla Veritas? |
|---|---|---|---|
| **Bitcoin (OpenTimestamps)** | Prueba de trabajo distribuida | Que la huella existía **antes** de un bloque determinado | **No** |
| **Autoridad de sellado RFC 3161** | Tercero de confianza externo | Fecha y hora firmadas por un tercero | **No** |
| **Reloj del servidor** | NTP | Momento de recepción, con valor meramente indicativo | Sí |

**La regla de oro del servicio: la fecha probatoria nunca es la del reloj de Veritas.** El sello
del servidor se registra por completitud operativa y se presenta explícitamente como tal. La
afirmación probatoria descansa en las dos fuentes que la organización no controla.

### Precisión declarada

| Fuente | Precisión | Naturaleza de la afirmación |
|---|---|---|
| RFC 3161 | Segundo | Afirmación puntual: «a las HH:MM:SS» |
| Bitcoin | Bloque (~10 min de media, ±2 h) | Afirmación de cota superior: «antes del bloque N» |

Se declara expresamente que la afirmación de Bitcoin es **una cota superior, no un instante**. Un
bloque no prueba que la huella se creara en ese momento: prueba que existía antes. Para el uso
probatorio real —demostrar anterioridad frente a un tercero— la cota superior es justo lo que
hace falta, pero presentarla como un instante exacto sería incorrecto.

### Las dos fases del anclaje, y por qué el certificado cambia

OpenTimestamps funciona en dos fases y **el certificado dice la verdad en cada una**:

| Fase | Estado | Qué dice el certificado |
|---|---|---|
| 1 · Sellado | `pending` | «Entregado a los calendarios públicos. Pendiente de confirmación en bloque» |
| 2 · Confirmación | `confirmed` | «CONFIRMADO en el bloque N. La huella existía antes de que ese bloque se minara» |

La transición la ejecuta un proceso automático cada seis horas. **Nunca se afirma la fase 2
mientras solo se tiene la fase 1.** Esta es una elección de producto con coste comercial —el
certificado inicial es más modesto de lo que el usuario querría— y se mantiene porque la
alternativa es mentir.

---

## 4 · Algoritmos y claves

| Uso | Algoritmo | Justificación |
|---|---|---|
| Huella de la obra | SHA-256 | Exigido por RFC 3161 y OpenTimestamps; sin ataques prácticos conocidos |
| Árbol de transparencia | SHA-256 con prefijos de dominio | Conforme a RFC 6962; los prefijos impiden la confusión entre hoja y nodo |
| Firma del certificado | Clave asimétrica, custodiada fuera de la imagen | Montada en solo lectura; nunca en el registro de contenedores |
| Cifrado de copias | AES-256 con derivación PBKDF2 | Protege el material probatorio fuera del servidor |

**Plan de transición criptográfica.** Se vigila el estado de SHA-256 y de los esquemas de firma
frente al avance de la computación cuántica. Cuando corresponda, la migración será **aditiva**:
se añadirá el algoritmo nuevo sin invalidar los sellos existentes, tal como exige la práctica del
sector. Un certificado emitido hoy no dejará de ser verificable porque mañana se añada otro
algoritmo.

---

## 5 · Qué acredita y qué NO acredita un certificado

Esta sección es la más importante del documento para un uso judicial.

### Lo que el certificado acredita

| Afirmación | Base técnica | Verificable por terceros |
|---|---|---|
| Este archivo tiene esta huella exacta | SHA-256 recalculable | **Sí**, con cualquier herramienta |
| La huella existía antes del bloque N de Bitcoin | Prueba OpenTimestamps | **Sí**, sin intervención de Veritas |
| La huella fue sellada por una autoridad externa | Token RFC 3161 | **Sí**, con OpenSSL |
| El registro no ha sido alterado a posteriori | Árbol de Merkle de solo-anexado | **Sí**, con la prueba de inclusión |
| La persona que registró declaró ser el titular | Declaración firmada del usuario | Parcialmente |

### Lo que el certificado NO acredita

| Lo que NO prueba | Por qué |
|---|---|
| **Que quien registró sea el autor** | Veritas no puede verificar la autoría. Registra una **declaración** de titularidad, y así lo dice el documento |
| **Que el contenido sea veraz** | Se sella la existencia y la integridad de un archivo, no la verdad de lo que afirma |
| **Que el contenido no infrinja derechos de terceros** | No se realiza búsqueda de anterioridad global |
| **Que la obra no existiera antes** | Se prueba anterioridad respecto a un momento, nunca originalidad absoluta |
| **Que sea un registro oficial** | No es un registro de propiedad intelectual ni de marcas, ni sustituye a ninguno |

**Estas limitaciones se imprimen en el propio certificado**, no solo en este documento. Un
certificado que no declara sus límites induce a error a quien lo usa, y ese error acaba
apareciendo en el peor momento posible: ante un juez.

---

## 6 · Requisitos de ETSI EN 319 401, uno a uno

| Cláusula | Requisito | Estado |
|---|---|---|
| 5 | Declaración de prácticas publicada | **Cumple** — este documento |
| 6.1 | Análisis de riesgos | **Cumple** — registro con 14 riesgos valorados |
| 6.2 | Políticas y prácticas | **Cumple** — manual de políticas |
| 6.3 | Términos y condiciones al usuario | **Cumple** — publicados en `/legal` |
| 6.4.1 | Organización interna | **Parcial** — sin segregación de funciones; declarado y compensado |
| 6.4.2 | Personal de confianza | **Parcial** — un operador; sin investigación de antecedentes formal |
| 6.4.3 | Gestión de activos | **Cumple** — inventario documentado |
| 6.4.4 | Control de acceso | **Cumple** — solo clave SSH; contenedores sin privilegios |
| 6.4.5 | Controles criptográficos | **Cumple** — sección 4 |
| 6.4.6 | Seguridad física | **Transferido** — proveedor del centro de datos |
| 6.4.7 | Seguridad de operaciones | **Cumple** — endurecimiento verificable |
| 6.4.8 | Seguridad de red | **Cumple** — segregación por proyecto; sin puertos publicados |
| 6.4.9 | Gestión de incidentes | **Cumple** — procedimiento con plazos del CRA |
| 6.4.10 | Recolección de evidencias | **Cumple** — registro de solo-anexado |
| 6.4.11 | Continuidad del negocio | **Cumple** — plan publicado con compromiso de volcado final |
| 6.4.12 | **Terminación del servicio** | **Cumple** — sección 7 |
| 6.4.13 | Cumplimiento legal | **Cumple** — registro de obligaciones |

**Distancia real hasta la cualificación.** Los huecos son cuatro y todos son organizativos, no
técnicos: segregación de funciones, investigación formal del personal, auditoría por organismo
acreditado y seguro de responsabilidad. Ninguno es un defecto de la prueba criptográfica; los
cuatro son propiedades de la empresa que la emite. Se declara así para que el lector pueda juzgar
por sí mismo cuánto pesa cada cosa en su caso concreto.

---

## 7 · Terminación del servicio

ETSI exige a un prestador cualificado un plan de terminación. Aquí se asume el mismo compromiso,
por escrito y de forma verificable:

| Compromiso | Detalle |
|---|---|
| **Preaviso** | Mínimo 90 días de aviso público antes del cierre |
| **Volcado final** | Publicación de todas las hojas y raíces del registro de transparencia en formato abierto |
| **Espejo** | El registro se replica en un repositorio público independiente de la infraestructura de Veritas |
| **Verificador abierto** | El código de verificación se publica con licencia libre, de modo que no dependa de que el servicio siga en pie |
| **Lo que sí se pierde** | Los archivos originales, si el usuario no conserva copia. Se dice expresamente |

**La garantía de fondo, y es la que sostiene todo lo demás:** un certificado emitido sigue siendo
verificable **sin Veritas**. La prueba vive en Bitcoin y en el token RFC 3161, que son
independientes de esta organización. El cierre del servicio impediría emitir sellos nuevos; no
invalidaría ni uno solo de los ya emitidos.

Esta es la respuesta concreta a la pregunta que el mercado tiene todo el derecho a hacer después
de que un servicio de sellado respaldado por Naciones Unidas cerrara en enero de 2022 por falta de
tracción: **«¿y cuando cerréis?»**.

---

## 8 · Revisión

| | |
|---|---|
| Ciclo de revisión | Anual, o ante cualquier cambio en algoritmos, fuentes de tiempo o estatus regulatorio |
| Próxima revisión | 5 de agosto de 2027 |
| Control de versiones | Cada versión se sella con el propio servicio y se ancla en el registro de transparencia |

---

*Veritas Digital LLC, 5 de agosto de 2026. Documento no cualificado en el sentido de eIDAS,
redactado conforme a la estructura de ETSI EN 319 401 y EN 319 421.*