Verificación de firmas: verificación criptográfica AdES / PAdES

Resumen

NextPDF Enterprise verifica criptográficamente firmas digitales. El componente de verificación lee un CMS SignedData o un token de marca de tiempo RFC 3161 del PDF, recalcula los resúmenes, comprueba las firmas, vincula cada firma a su certificado de firma y valida la cadena de certificados, incluido el procesamiento de directivas de certificado, frente a un almacén de anclajes de confianza proporcionado por el llamador. Esta página describe el comportamiento: qué se verifica, qué se rechaza con cierre seguro, qué algoritmos se admiten y dónde se sitúa el límite de confianza.

Esto difiere de Validación, que ejecuta comprobaciones de directivas estructurales de solo lectura y deliberadamente no realiza ninguna criptografía. También es la contraparte verificadora del productor de firmas, que escribe estructuras PAdES B-LT / B-LTA.

Instalación

composer require nextpdf/enterprise:^3

Descripción conceptual

La verificación se basa en evidencias y aplica cierre seguro: una comprobación que no pueda establecerse de forma positiva no produce un resultado positivo. Las piezas siguientes se integran en un único resultado encapsulado en un ValidationReport.

Verificación criptográfica de CMS / token de marca de tiempo. Una pila DER estricta, autónoma y de longitud definida analiza el CMS SignedData y el token de marca de tiempo RFC 3161. Un token se acepta únicamente cuando incluye exactamente un SignerInfo, sus atributos firmados se analizan de forma estricta, el certificado del firmante se resuelve, el atributo message-digest coincide con el resumen recalculado, se cumple el vínculo obligatorio del certificado de firma (ESS signing-certificate-v2) y la firma SignerInfo se verifica sobre los atributos firmados reetiquetados. La regla de coincidencia de resúmenes sigue el modelo de verificación de RFC 5652 §5.6 / §5.4: el destinatario recalcula el resumen del contenido y la firma es válida únicamente cuando ese valor es igual al atributo firmado messageDigest; un verificador nunca confía en un resumen proporcionado por el productor.

Validación del certificado TSA en genTime. El genTime de la marca de tiempo es el instante UTC en el que se creó el token (RFC 3161 §2.4.2). El certificado de firma TSA se valida en ese instante, no en «ahora»: su uso extendido de clave debe ser un único id-kp-timeStamping crítico (RFC 3161 §2.3), y su ventana de validez, su cadena, la procedencia del anclaje de confianza y su revocación se evalúan frente a genTime. Una cadena estructuralmente bien formada que no alcanza un anclaje de confianza configurado nunca puede sustentar un resultado positivo.

Firmas básicas de documento PAdES independientes. Un extractor concreto ejecuta la verificación básica AdES / PAdES real para una firma de documento independiente: el resumen del mensaje se recalcula sobre el intervalo de bytes firmado y se compara, la firma se verifica y el vínculo del certificado de firma es obligatorio. Esto sustituye la alternativa anterior basada solo en estructura. El verificador de marcas de tiempo y el extractor de firmas de documento comparten un único validador de emisor y número de serie ESS, de modo que no pueden diferir en el análisis del vínculo del certificado.

Cadena de cobertura DocTimeStamp de archivado. validateArchivalTimestampChain() valida una cadena de tokens DocTimeStamp de confianza sobre los intervalos de bytes del PDF como evidencia de archivado B-LTA. La huella de cada token está vinculada a los bytes reales de ByteRange que cubre, la cadena sigue el orden estricto de ETSI, la cadena TSA de cada token está anclada a la confianza y la cadena debe cubrir el archivo hasta su marcador de fin de archivo. Solo alcanza un resultado totalmente superado para una cadena completa, anclada a la confianza y que cubre hasta el EOF.

Procesamiento de directivas de certificado (RFC 5280 §6.1.4). La validación de ruta aplica el procesamiento completo de directivas de certificado: un árbol de directivas estructurado por nodos, la asignación de directivas con la alternativa anyPolicy y el plegado de policyConstraints / inhibitAnyPolicy, respaldado por un lector DER de extensiones de directiva con cierre seguro. Las variables de estado del procesamiento de ruta explicit_policy e inhibit_anyPolicy (RFC 5280 §6.1.2) determinan si se requiere un árbol de directivas válidas no vacío; el paso de cierre interseca el árbol de directivas válidas con el conjunto inicial de directivas del usuario (RFC 5280 §6.1.4). Sin directivas requeridas y con anyPolicy aceptado, el procesamiento no tiene restricciones: es el valor predeterminado y no cambia respecto al comportamiento anterior.

Algoritmos admitidos

El componente de verificación acepta el conjunto de algoritmos siguiente y aplica cierre seguro ante cualquier elemento fuera de él: un algoritmo no admitido es una verificación rechazada, nunca una aprobación silenciosa.

Familia	Admitido	Notas
RSA (PKCS#1 v1.5)	rsaEncryption con SHA-2, y los OID sha*WithRSAEncryption correspondientes	Aceptado
ECDSA	curvas P-256, P-384, P-521	Aceptado
RSASSA-PSS	—	No admitido → cierre seguro
EdDSA	—	No admitido → cierre seguro
Resúmenes SHA-3	—	No admitido → cierre seguro
SHA-1	—	Débil: una firma básica que se verifica con SHA-1 se degrada a un error de restricciones criptográficas, no a una aprobación

Superficie de la API

El componente de verificación se utiliza mediante el motor público y los contratos de Core / Pki. Las clases de estrategia concretas son internas.

Tipo	Clase	Función
AdESValidationEngine	clase	Punto de entrada del componente de verificación: validación de firmas y de la cadena de archivado.
AdESValidationEngine::validateArchivalTimestampChain()	método	Valida una cadena de cobertura DocTimeStamp de confianza sobre los intervalos de bytes del PDF.
ValidationReport	resultado	El resultado estructurado: el estado global más los hallazgos por comprobación.
PathValidatorInterface	interfaz (NextPDF\…\Pki)	La SPI de validación de ruta de certificación de la que depende el motor.
PathValidationOptions	objeto de valor	Controles de procesamiento de directivas: requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	interfaz	El conjunto de anclajes de confianza proporcionado por el llamador frente al que se evalúa la cadena.

El método para la cadena de archivado tiene esta firma:

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

Solo alcanza un resultado totalmente superado cuando la cadena DocTimeStamp está completamente verificada, anclada a la confianza y cubre el archivo hasta su marcador EOF.

CertificateChainValidator::validate() recibe un conjunto inicial de directivas (el conjunto inicial de directivas del usuario de RFC 5280). El valor predeterminado es anyPolicy — sin restricciones — de modo que una cadena ordinaria no se ve afectada; para exigir un árbol de directivas válidas no vacío, se debe pasar un conjunto explícito o establecer requireExplicitPolicy.

Ejemplo de código — Inicio rápido

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

Ejemplo de código — Producción

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

Cambios de comportamiento y notas de actualización

El componente de verificación pasó de una aceptación estructural / temporal a una verificación criptográfica completa. Quienes dependan del comportamiento anterior, más permisivo, deberían revisar estos cambios.

• Cierre seguro ante una marca de tiempo reconocible pero no verificable. Un DocTimeStamp o token de archivado que antes se aceptaba por motivos estructurales y temporales ahora requiere una verificación criptográfica completa: firma, message-digest y el vínculo del certificado de firma. Un token que no se verifica ya no produce una prueba de existencia positiva; se resuelve como un resultado indeterminado o fallido.
• Las firmas básicas con SHA-1 se degradan, no se aprueban. Una firma básica de documento que se verifica pero usa SHA-1 se notifica como un error de restricciones criptográficas en lugar de una aprobación completa.
• Se aplica el procesamiento de directivas de certificado de RFC 5280 §6.1.4. Una cadena cuyo explicit_policy llega a cero con un árbol de directivas válidas vacío ahora falla — incluso cuando un policyConstraints requireExplicitPolicy interno de la cadena lo provoca. Las cadenas predeterminadas, sin restricciones (sin directivas requeridas, con anyPolicy aceptado) no se ven afectadas.
• Cambio en la firma del constructor (ruptura de compatibilidad). AdESValidationEngine::__construct() ahora declara el tipo de su parámetro $chainValidator como la SPI Pki\PathValidatorInterface, con valor predeterminado diferido Pki\CertificateChainValidator::withDefaults(). Anteriormente era la clase concreta Ltv\CertificateChainValidator. Si se inyectaba el validador LTV concreto, ahora debe inyectarse la implementación de la SPI de Pki. El validador de Pki envuelve el mismo motor de ruta estructural y añade restricciones de nombre y procesamiento de directivas; no tiene ningún efecto para entradas predeterminadas conformes.

Casos límite y advertencias

• Algoritmo no admitido ≠ no concluyente. RSASSA-PSS, EdDSA y SHA-3 se rechazan con cierre seguro, no se aplazan. Si los firmantes usan esos algoritmos, este componente de verificación no devolverá un resultado positivo para ellos.
• La confianza es relativa al anclaje. La verificación siempre es relativa al almacén de anclajes de confianza proporcionado. Un conjunto de anclajes vacío o incorrecto produce un resultado no confiable, con independencia de la corrección criptográfica.
• genTime, no ahora. El certificado TSA se juzga en el genTime del token. Un certificado TSA que desde entonces ha caducado todavía puede sustentar un token creado mientras era válido; un certificado que aún no era válido en genTime no puede.
• Cobertura del EOF. La cadena de archivado debe cubrir el documento hasta su marcador EOF. Una marca de tiempo que cubre solo un prefijo del archivo no establece la cobertura de todo el documento.
• No constar como revocado no es Good. Un veredicto Valid necesita un estado concluyente de no revocado. Si tanto OCSP como CRL devuelven Unknown o Unavailable, incluso una firma criptográficamente sólida, con cadena válida y anclada a la confianza, se resuelve como Indeterminate; para alcanzar Valid, se debe proporcionar material Good OCSP/CRL incrustado para el certificado del firmante.

Rendimiento

La verificación se ejecuta dentro del proceso sobre los bytes del PDF proporcionados y el material de validación incrustado; el coste escala con la longitud de la cadena y el número de marcas de tiempo. No se realizan viajes de ida y vuelta de red durante la verificación: el material de revocación y de confianza se toma de lo que proporciona el llamador o de lo que está incrustado en el documento. La verificación es determinista: las mismas entradas y los mismos anclajes de confianza producen el mismo informe.

Notas de seguridad

• El cierre seguro es el valor predeterminado. Cada paso de aceptación rechaza el material que no puede verificar de forma positiva. Esto impide que un documento declare una validez que el motor nunca estableció.
• El anexado tras la marca de tiempo se neutraliza con la cobertura del EOF. Dado que la huella de cada marca de tiempo de archivado está vinculada a los bytes reales de ByteRange y la cadena debe llegar al EOF, el contenido anexado tras una marca de tiempo no queda cubierto por ella ni adquiere su peso probatorio.
• Tratar la entrada como hostil. Los bytes del PDF, el CMS incrustado y los tokens de marca de tiempo procedentes de fuentes no fiables se analizan mediante un lector DER estricto de longitud definida que rechaza las codificaciones malformadas o de longitud indefinida.

Residencia de datos y mitigaciones de PII

La verificación es local y se ejecuta dentro del proceso, sin E/S de red. Los certificados y las firmas contienen la identidad del sujeto; aplicar los controles propios de retención y minimización a los informes y a cualquier dato de certificado extraído.

Telemetría segura y depuración de registros

Los hallazgos incluyen identificadores de comprobación y estados. Algunos diagnósticos pueden reflejar los nombres del sujeto del certificado o los números de serie; depurar o redactar esos campos antes de reenviar los registros a destinos compartidos.

Límites de alcance

Indicar estos límites en la salida orientada al usuario para que un resultado positivo no se sobreinterprete.

• validateArchivalTimestampChain() prueba la cobertura del intervalo de bytes, no la accesibilidad de xref. Establece que una cadena de marcas de tiempo de confianza cubre criptográficamente los intervalos de bytes del documento hasta el EOF. No realiza análisis de accesibilidad de objetos a nivel de xref ni de startxref; eso queda fuera de alcance por diseño. Los ataques de anexado tras la marca de tiempo se neutralizan mediante la regla de cobertura del EOF junto con el anclaje de confianza, no mediante el análisis del grafo de objetos.
• Fuera de alcance por diseño. Los registros de evidencia (RFC 4998 / RFC 6283); la verificación de tokens de marca de tiempo RSASSA-PSS, EdDSA o SHA-3; la integración con listas de confianza (TSL) y TSA cualificadas; y la obtención en línea de la revocación de la TSA no los proporciona este componente de verificación. La revocación se evalúa a partir del material ya disponible para el verificador.

Conformidad

Comportamiento	Referencia	Estado
Valor de firma / token de marca de tiempo almacenado con codificación DER en /Contents	ISO 32000-2 §12.8.1	Analizado y verificado
Diccionario de marca de tiempo del documento	ISO 32000-2 §12.8.5	Leído para la cadena de archivado
El destinatario recalcula el resumen del contenido; debe ser igual al atributo messageDigest	RFC 5652 §5.6 / §5.4	Aplicado
El certificado TSA incluye un único id-kp-timeStamping crítico como EKU	RFC 3161 §2.3	Comprobado en genTime
genTime es el instante UTC de creación	RFC 3161 §2.4.2	Usado como instante de validación
Variables de estado del procesamiento de directivas (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Procesado
El cierre interseca el árbol de directivas válidas con el conjunto inicial de directivas del usuario	RFC 5280 §6.1.4	Aplicado
Entradas DSS y marcas de tiempo de documento para firmas de larga duración	ETSI EN 319 142-2 §5.5	Validado como evidencia de archivado

Todas las cláusulas están parafraseadas. NextPDF no reproduce el texto normativo; consultar los estándares publicados para la redacción autorizada. NextPDF no formula ninguna declaración de certificación AdES / PAdES. El componente de verificación implementa las comprobaciones criptográficas que describen las especificaciones citadas; no es un servicio de validación certificado y no produce ninguna certificación de terceros.

Comportamiento en modo FIPS

Cuando el perfil FIPS de Enterprise está activo, la restricción se aplica a los algoritmos de resumen y de firma que acepta el verificador. La lógica de verificación — recálculo de resúmenes, comprobaciones de firma, vínculo de certificado y validación de ruta — no cambia.

Modelo de amenazas

Activo	Adversario	Riesgo	Mitigación
Token de marca de tiempo	Token falsificado o alterado	Prueba de existencia falsa	Verificación criptográfica completa; cierre seguro ante cualquier elemento no verificable
Certificado TSA	Emisor no fiable	Confianza aparente que el verificador no debería afirmar	Cadena validada frente a un anclaje proporcionado por el llamador en genTime; una cadena no fiable nunca se aprueba
Bytes del documento	Anexado tras la marca de tiempo	El contenido adquiere el peso de una marca de tiempo sin cobertura	Huella vinculada a los bytes reales de ByteRange + regla de cobertura del EOF
Algoritmo débil	Degradación a SHA-1 / esquema no admitido	Firma débil leída como válida	SHA-1 degradado; RSASSA-PSS / EdDSA / SHA-3 con cierre seguro

Restricción de edición

Este componente de verificación es una capacidad de Enterprise y se distribuye en el paquete nextpdf/enterprise. NextPDF Core detecta la presencia de firmas y produce firmas B-B / B-T; no proporciona este componente de verificación criptográfica. Obtener una licencia.

Indicador de característica de licencia

El componente de verificación está restringido por la edición Enterprise (license_feature_flag: enterprise). Se resuelve mediante los contratos de Core y Pki; la API pública no cambia al actualizar la edición.

Contrato de comportamiento

• Un token CMS o de marca de tiempo se acepta únicamente con exactamente un SignerInfo, atributos firmados analizados de forma estricta, un certificado de firmante resuelto, un message-digest coincidente, el vínculo obligatorio del certificado de firma y una firma SignerInfo verificada.
• El certificado TSA se valida en el genTime del token: un único id-kp-timeStamping crítico como EKU, ventana de validez, cadena anclada a la confianza y revocación.
• Un veredicto Valid requiere además un estado concluyente de no revocado: al menos un Good autoritativo (una respuesta OCSP verificada como buena, o una CRL reciente que sitúa el número de serie fuera de una lista no caducada). Un estado que solo indica que no se ha probado la revocación, en el que OCSP y CRL son ambos Unknown o Unavailable, se resuelve como Indeterminate, nunca como Valid (ETSI EN 319 102-1: estado de revocación no disponible → INDETERMINATE). Dado que la ruta alternativa de CRL solo atestigua la frescura de la lista y no la revocación por número de serie, una cadena solo con CRL y sin un OCSP Good suele ser Indeterminate.
• validateArchivalTimestampChain() alcanza un resultado totalmente superado únicamente para una cadena DocTimeStamp completa, anclada a la confianza y que cubre hasta el EOF; prueba la cobertura del intervalo de bytes, no la accesibilidad de xref.
• El procesamiento de directivas de certificado sigue RFC 5280 §6.1.4; las cadenas predeterminadas sin restricciones no se ven afectadas.
• Los algoritmos admitidos son RSA (PKCS#1 v1.5 con SHA-2) y ECDSA (P-256/384/521); RSASSA-PSS, EdDSA y SHA-3 realizan cierre seguro; SHA-1 se degrada.

Estado de la revisión de NDA

Esta página pública describe únicamente el comportamiento del componente de verificación observable externamente. Menciona el motor público, los contratos de Pki / anclaje de confianza y el método validateArchivalTimestampChain() a través de la superficie admitida. Los detalles internos concretos de DER, CMS, el procesador de directivas y el validador de ruta están en la referencia profunda restringida bajo NDA.

Alternativa de Core

NextPDF Core detecta la presencia de una firma y produce firmas B-B / B-T, pero no verifica criptográficamente tokens CMS ni tokens de marca de tiempo, no valida una cadena de archivado ni ejecuta el procesamiento de directivas de RFC 5280 §6.1.4. Una implementación solo con Core no tiene un componente de verificación equivalente; consultar Seguridad / Firma (Core).

Alternativa de Pro

NextPDF Pro añade estrategias de firma y gestión de facturación electrónica, pero no proporciona este componente de verificación criptográfica; la validación de la cadena de archivado y el procesamiento de directivas de certificado se distribuyen solo en nextpdf/enterprise.

Nota sobre el límite de Enterprise

El componente de verificación se describe en términos de comportamiento. La pila DER estricta, el analizador CMS, el procesador de directivas y los detalles internos del validador de ruta quedan fuera de alcance para la superficie pública y no se reproducen aquí.

Límite de implementación

La verificación depende del almacén de anclajes de confianza y de cualquier material de revocación proporcionado por el llamador o incrustado en el documento. NextPDF Enterprise evalúa ese material; no opera una lista de confianza, una TSA ni un servicio de revocación. El operador es responsable de la selección de anclajes y de la frescura del material de revocación incrustado.

Límite legal y de cumplimiento

Esta página está marcada como export_control_class: legal-review-required; se refiere a la verificación criptográfica. Se requiere la aprobación legal antes de establecer el indicador publish. Un resultado de verificación positivo es una declaración criptográfica sobre las firmas y las marcas de tiempo del documento; no es una opinión legal, una determinación de cualificación eIDAS ni una certificación. NextPDF no formula ninguna declaración de certificación AdES / PAdES. Consultar con los asesores legales y de cumplimiento propios sobre las obligaciones regulatorias.

Véase también

• Firma: productor PAdES B-LT / B-LTA — el lado del productor.
• Validación — comprobaciones de directivas estructurales dentro del proceso (sin criptografía).
• Archivado: DSS, VRI, estado de LTV — archivado de larga duración y estado de LTV.
• Seguridad / Firma (Core) — CMS, RFC 3161, validación de ruta RFC 5280, OCSP/CRL.
• Mapeo de líneas base PAdES — B-B, B-T, B-LT, B-LTA en las distintas ediciones.
• PAdES · DSS · LTV — términos del glosario.