Paquete para el perito

El paquete de evidencia es un .zip que un perito, un juez o la contraparte verifican con herramientas estándar y sin acceso a Notificado. Descárguelo desde la notificación, en Notificaciones, junto con la constancia en PDF. Cada descarga queda registrada.

Desde la API o un asistente

Un asistente conectado por MCP no recibe los bytes del paquete: un .zip de decenas de megabytes no cabe en una respuesta de herramienta. La lectura evidenceDownloadInfo (alcance evidence:read, también en GET /v1/evidence-download-info) recibe orgId, notificationId, kind (zip si se omite, o constancia) y, si quiere una versión anterior, version. Responde el nombre del archivo (filename), su tipo (contentType), su tamaño en bytes (bytes), su huella SHA-256 (sha256), la versión del formato del paquete (zipVersion), la constancia a la que pertenece (constanciaId) y en fetch la llamada HTTP que lo descarga: method, path y el body exacto. Esa lectura no registra nada. La descarga es esa llamada, POST /v1/download-evidence con el mismo token, y queda registrada como cualquier otra descarga.

Sin constancia todavía, las dos responden 404 X_CONSTANCIA_NOT_FOUND; con el paquete aún armándose, 409 X_EVIDENCE_ZIP_NOT_READY (reintente en 30 segundos).

curl -X POST 'https://www.notificado.co/v1/download-evidence' \
  -H "authorization: Bearer $NOTIFICADO_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"orgId":"<orgId>","notificationId":"<notificationId>","kind":"zip","version":1}' \
  | jq -r .contentBase64 | base64 -d > evidencia.zip
sha256sum evidencia.zip

El ejemplo pide la versión 1; envíe el body de fetch tal como llegó, que nombra la versión descrita. La huella que imprime sha256sum debe ser la misma sha256 que respondieron evidenceDownloadInfo y la descarga. Si difiere, el archivo se dañó en el camino: descárguelo de nuevo antes de entregarlo.

Qué contiene

Verificación automática

Con Bun, openssl, sha256sum y pdfsig (poppler-utils) instalados, dentro de la carpeta descomprimida:

bun verificar.js

Salida 0 = verificado; 1 = algo no verifica (se nombra); 2 = paquete ilegible; 3 = falta openssl; 4 = verificado, salvo un archivo enlazado que no se entregó y no se comprobó.

El informe tiene cuatro partes, siempre en el mismo orden:

• Comprobado: cada área (archivos, cadena de eventos, archivos que nombran los eventos, anclaje diario, sellos) con OK, AVISO o FALLA; la huella SHA-256 de manifest.json, que identifica todo el paquete; y el tramo de la cadena (seq inicial y final).
• Sellos de tiempo: por cada sello, la autoridad, el archivo que cubre y la hora que afirma la propia autoridad, leída del token.
• Hallazgos: cada falla, aviso o nota, con el archivo o el evento que la causa.
• No comprobado por este programa: la firma PAdES del PDF (pdfsig), la confianza en cada autoridad de sellado y la firma de Amazon SNS de las respuestas crudas, que requiere red. Esas pruebas se hacen con las herramientas públicas indicadas.

La última línea es siempre el resultado. bun verificar.js --json entrega lo mismo en JSON.

Verificación manual

sha256sum -c SHA256SUMS
openssl ts -reply -in sellos/<sello>.tsr -text
openssl ts -verify -data mensaje/<destinatario>.eml -in sellos/<sello>.tsr -CAfile sellos/tsa-ca/<autoridad>.pem
pdfsig constancia.pdf

Cada sello debe responder Verification: OK. En la cadena, cada evento cumple hash = sha256(hash_anterior seguido del evento en JSON canónico RFC 8785): alterar, quitar o reordenar un evento rompe todos los siguientes.

Archivos enlazados

Un archivo demasiado grande para viajar adjunto al correo se pone a disposición del destinatario por enlace de descarga. Ese archivo no está dentro del zip: el paquete lo nombra por su huella SHA-256 y la constancia lo lista como «puesto a disposición por enlace de descarga». Un paquete con archivos enlazados dice "version": 2 en manifest.json y trae la lista linkedFiles (huella, tamaño, nombre y fecha hasta la que Notificado conserva el archivo). Un paquete sin ellos sigue siendo versión 1.

Cómo obtener el archivo. Pida una copia a la firma que envió la notificación, que conserva su original, o al destinatario. Cualquier copia sirve: lo que identifica el archivo es su huella SHA-256, no de dónde viene.

Cómo comprobarlo. Copie el archivo en una carpeta enlazados/ dentro del paquete descomprimido, o indique la carpeta donde lo tiene:

mkdir enlazados && cp /ruta/al/archivo enlazados/
bun verificar.js
bun verificar.js --linked /ruta/a/la/carpeta
sha256sum enlazados/*

El verificador calcula la huella de cada copia y la compara con la que congeló el evento message.frozen. También comprueba que el nombre que manifest.json da al archivo sea el que congeló ese evento. El resultado tiene tres casos:

• La copia es el archivo. El informe la marca como verificada y la salida es 0.
• Nadie entregó una copia. El resto del paquete verifica, el archivo aparece como NO COMPROBADO y la salida es 4. No es una falla y tampoco es un visto bueno: el programa no vio ese archivo.
• La copia tiene el nombre del archivo y otra huella. Es una falla (linked-file-hash) y la salida es 1: no es el archivo notificado.

El sello de tiempo de un archivo enlazado cubre su huella y se comprueba con openssl ts -verify -digest <huella>; LEEME.txt trae la línea exacta. En la constancia, cada destinatario lista lo registrado sobre cada archivo enlazado: Descarga iniciada (evento link.download) y Transmisión del servidor (evento link.download.transmitted, con los bytes transmitidos y la huella de lo transmitido), o «sin descarga registrada».

link.download.transmitted dice lo que hizo el servidor de Notificado: escribió el archivo completo en la conexión desde la que se usó el enlace. No prueba que el destinatario lo haya recibido ni guardado: una conexión que se cierra sin leer los últimos bytes no se distingue de una que los leyó.

Cómo cotejar una copia entregada

Si el destinatario o la contraparte aportan el correo que llegó a su buzón, no lo compare por la huella SHA-256 del .eml: el archivo de mensaje/ es lo que Notificado entregó al proveedor de correo, y el proveedor recodifica el mensaje y pone sus propios encabezados en el tránsito (la fecha, los límites MIME, el orden de los encabezados, la firma DKIM). La huella del archivo completo será distinta aunque el contenido sea el mismo. Coteje así:

• El Message-ID. El encabezado Message-ID de la copia entregada es el mismo del .eml y el que nombra el evento message.frozen.
• Cada adjunto. Extraiga los adjuntos de la copia entregada y calcule su SHA-256: debe ser el de adjuntos/, el de manifest.json y el que imprime la constancia.
• El texto. El texto y el HTML son los mismos, salvo espacios al final de las líneas. El remitente, el destinatario, la dirección de respuesta y el asunto dicen lo mismo.

grep -i '^Message-ID:' copia-entregada.eml mensaje/<destinatario>.eml
sha256sum adjuntos/*

Qué versión del método aplica

LEEME.txt indica la versión del método de evidencia bajo la que se emitió la constancia (por ejemplo, 2026-09-v3). Esa versión queda registrada en el evento encadenado constancia.issued (methodVersion). En paquetes anteriores a este registro, la versión aparece en la constancia, en el campo «Versión del software».

Qué no prueba

Que una persona leyó el mensaje: las aperturas son indicios. Tampoco quién hizo clic en un enlace de descarga, solo cuándo, desde qué IP y con qué navegador. La validez de la notificación la determina el juez.