Validar correctamente una firma

Spec: RFC 5280, §6 Spec: RFC 6960 Spec: RFC 5652 Evidence: Test-backed

Visión general

«La firma es válida» suele significar que se comprobó una sola cosa: que los cálculos criptográficos cuadraban. Una validación correcta comprueba al menos cinco aspectos independientes, y cualquiera de ellos puede fallar de un modo que deja sin valor una marca de verificación verde. Esta página presenta el conjunto completo de comprobaciones y explica por qué una respuesta parcial es peligrosa.

Por qué esto importa

Un único valor booleano es la salida más peligrosa de todo este tema. Invita a quien lee a tratar «válida» como «fiable», cuando quizá «válida» solo signifique que los bytes no se alteraron, verificados mediante una clave de un certificado que caducó hace tres años, se revocó el mes pasado y no encadena con ninguna autoridad reconocida. Cada una de esas dimensiones es una comprobación independiente. Un software que informa de un único valor booleano ha decidido en silencio qué comprobaciones importaban, y lo decidió en su lugar. En un contexto regulado o contractual, «la herramienta dijo válida» no es una defensa si la herramienta solo verificó la propiedad más barata de comprobar.

La versión breve

Una validación completa responde a cinco preguntas distintas. Son independientes: superar una no dice nada sobre las demás:

Integridad — ¿el hash de los bytes firmados sigue coincidiendo con lo que cubre la firma? (Recalcular el resumen del intervalo de bytes; comparar.)
Autenticidad — ¿la firma criptográfica se verifica con la clave pública del certificado de firma, sobre los atributos firmados?
Ruta del certificado — ¿ese certificado encadena hasta un anclaje de confianza elegido explícitamente, con cada eslabón válido?
Tiempo — ¿el certificado estaba dentro de su ventana de validez en el momento pertinente, y ese tiempo es de confianza en lugar de estar autoafirmado?
Revocación — ¿el certificado no estaba revocado en ese momento, según evidencia (OCSP/CRL) que pueda obtenerse realmente o que esté incrustada?

Una respuesta de «válida» que no haya realizado las cinco es una respuesta incompleta que parece completa.

Cómo lo aborda NextPDF

La postura de NextPDF es que cada pregunta es independiente y debe responderse de forma explícita. Ninguna pregunta se reduce a un único indicador optimista, ni se omite en silencio porque una comprobación haya resultado incómoda. Esto se impone mediante pruebas. Por eso esta página se marca como respaldada por pruebas en lugar de respaldada por el estándar: el comportamiento queda fijado por el conjunto de pruebas, no solo se argumenta a partir de una cláusula.

La integridad y la autenticidad se prueban de extremo a extremo. Un certificado conocido firma una estructura real de atributos firmados, y el conjunto de pruebas verifica la firma con la clave pública correspondiente, con múltiples vectores de tiempo. Así, un cambio que rompe la estructura canónica rompe la prueba. La validación de la ruta del certificado se mantiene mediante pruebas que alteran deliberadamente un byte de la firma y comprueban que el resultado no es válido con un motivo estructurado: no una excepción descartada, sino un fallo explícito y registrado. La verificación del token de marca de tiempo se descompone en pasos discretos: decodificación, información del firmante, atributos firmados, resumen del mensaje, vinculación del certificado, uso de la clave, firma, fecha de producción (produced-at), y cada paso se prueba por separado, de modo que «la marca de tiempo se verificó» significa que se verificó cada paso. El fallo blando de revocación (un respondedor inalcanzable) se distingue, en el código y en las pruebas, de un «revocado» definitivo. Ambos nunca se confunden en la misma respuesta.

Integrity Recompute the byte-range digest and compare it to the value the signature covers.
Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
Certificate path Build and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

Las cinco preguntas independientes que responde una validación correcta de firma PDF, en orden. Cada una es independiente: superar una no dice nada sobre las demás, y omitir cualquiera de ellas hace que el resultado global sea incompleto.

Qué dice la evidencia

Evidence: Test-backed El comportamiento está anclado en pruebas, y esas pruebas implementan lo que exigen los estándares.

La integridad se evalúa según Spec: ISO 32000-2, §12.8.1 : el resumen se recalcula sobre el intervalo de bytes y se compara con el valor almacenado, y cualquier diferencia significa que la firma no es válida. La autenticidad sobre los atributos firmados queda cubierta por una prueba de integración que firma un conjunto real de atributos firmados y lo verifica con la clave pública correspondiente a lo largo de varios vectores de tiempo. La pregunta de la ruta del certificado corresponde a Spec: RFC 5280, §6.1 : las rutas válidas parten de un anclaje de confianza, y Spec: RFC 5280, §6.2 establece que ese algoritmo define las condiciones mínimas para que una ruta sea válida — una prueba unitaria del validador de rutas comprueba que una firma alterada produce valid = false con un motivo explícito, nunca con una aceptación silenciosa.

El orden correcto de la revocación lo establece Spec: RFC 6960, §3.2 : antes de que un cliente acepte como válida una respuesta de revocación firmada, DEBERÁ confirmar que la propia firma de la respuesta es válida y que el firmante está autorizado en ese momento — y Spec: RFC 6960, §4.2.2.2 define esa autorización como una delegación id-kp-OCSPSigning emitida directamente por la CA en cuestión. Por tanto, una respuesta de revocación que no se haya validado a su vez frente a un firmante autorizado y verificable carece de sentido. La comprobación de la vinculación del certificado corresponde a Spec: RFC 5035, §5.4.2 : si el hash de certificado incluido en el atributo firmado signing-certificate-v2 no coincide con el certificado usado para verificar la firma, la firma debe considerarse no válida. Esto cierra la brecha de sustitución, en la que una firma se verifica frente a un certificado elegido por un atacante. El propio token de la marca de tiempo se verifica al estilo Spec: RFC 5652 como un objeto CMS, paso a paso, con cada paso probado por separado.

Ejemplo práctico

Lo instructivo no es una llamada a la API. Son las preguntas que deben poder responderse antes de actuar a partir de un resultado. Puede verse como la lista de verificación ante la que una revisión exigirá respuestas.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Si en alguna línea la respuesta es «no lo sé», el estado honesto no es «válida». Es «aún no determinada» — y tratar esa respuesta como equivalente a «válida» es el error que esta página existe para evitar.

Idea equivocada habitual

La trampa consiste en equiparar «criptográficamente válida» con «fiable». La integridad y la autenticidad, juntas, solo prueban que estos bytes fueron firmados por quien posee esta clave. No dicen nada sobre si el certificado asociado a la clave era de confianza, estaba vigente o no estaba revocado. Un documento firmado con un certificado autogenerado puede ser «criptográficamente válido» y no valer nada. La trampa inversa consiste en tratar una comprobación de revocación indeterminada (respondedor sin conexión) como un acierto — o como un fallo. No es ni una cosa ni la otra: es desconocida, y un validador correcto la informa como desconocida en lugar de adivinar en cualquiera de las dos direcciones. Una marca de verificación verde que oculta cuáles de las cinco comprobaciones se ejecutaron realmente no es un resultado de validación. Es una decisión que alguien tomó en su nombre.

Límites y alcance

NextPDF realiza y prueba las comprobaciones estructurales y criptográficas. No elige los anclajes de confianza ni garantiza la política que se construye sobre ellos. En qué certificados confiar es una decisión de despliegue que el motor no puede tomar. Una cadena que se valida hasta un anclaje en el que no debería haberse confiado sigue siendo una validación en la que no se puede confiar. La evidencia de revocación solo puede comprobarse si puede obtenerse o está incrustada. Un respondedor sin conexión da como resultado «indeterminada», y convertir ese estado en un veredicto es una decisión de política, no del motor. Esta página describe el conjunto de comprobaciones, no la suficiencia legal. Que una firma validada tenga un efecto legal concreto depende del certificado, del firmante, de la jurisdicción y de la obligación. Cómo la evidencia incrustada mantiene estas comprobaciones respondibles con el tiempo se trata en Validación a largo plazo; el mecanismo del intervalo de bytes que sustenta la comprobación de integridad está en Cómo se sitúan las firmas en un PDF.

Disponibilidad de la superficie de validación por nivel:

Signature validation checks — edition availability
Edition	Availability
Core	Integridad y autenticidad sobre los atributos firmados, además de la validación de la ruta del certificado conforme a RFC 5280 §6 frente a un anclaje de confianza suministrado.
Pro	Añade la verificación del token de marca de tiempo RFC 3161: la pregunta del tiempo de confianza, descompuesta en pasos comprobados de forma independiente.
Enterprise	Añade la evaluación de revocación (OCSP/CRL) y la validación frente a material incrustado de largo plazo, distinguiendo los resultados indeterminados de los definitivos.

Documentación relacionada

Validación a largo plazo — cómo la evidencia incrustada permite seguir respondiendo a las comprobaciones de tiempo y revocación años después.
Cómo se sitúan las firmas en un PDF — el mecanismo del intervalo de bytes con el que se recalcula la comprobación de integridad.
Marcas de tiempo y tiempo de confianza — qué permite responder a la pregunta del «tiempo» con algo distinto del reloj del firmante.

Glosario

Comprobación de integridad — recalcular el resumen del intervalo de bytes y compararlo con el valor cubierto por la firma.
Comprobación de autenticidad — verificar la firma criptográfica frente a la clave pública del certificado de firma, sobre los atributos firmados.
Atributos firmados — los atributos CMS autenticados (content-type, message-digest, signing-time, signing-certificate-v2) sobre los que realmente se calcula la firma.
Validación de la ruta del certificado — construir y comprobar la cadena desde el certificado de firma hasta un anclaje de confianza elegido (RFC 5280 §6).
Anclaje de confianza — una autoridad de certificación en la que se ha decidido confiar; la raíz de una ruta aceptable.
Comprobación de revocación — determinar si un certificado estaba revocado en el momento pertinente, mediante OCSP o una CRL.
Indeterminada — estado de revocación que no es ni «buena» ni «revocada» porque no se pudo obtener evidencia; no es ni un acierto ni un fallo.