Juan Torchia

Posted on Jul 2 • Originally published at juanchi.dev

Firma digital: diferencia entre formato, certificado y política de validación

#spanish #espanol #seguridad #pki

Firma digital: diferencia entre formato, certificado y política de validación

La solución correcta cuando una firma digital falla es no mirar la criptografía primero. Sé que suena raro. Si el algoritmo es RSA-2048 y la cadena de certificación está intacta, ¿por qué fallaría la validación? Porque la firma puede ser criptográficamente perfecta y aun así ser rechazada por el validador. El problema no es el hash ni la clave privada: es el formato, el certificado incorrecto, o la política de validación que el sistema aplica.

Mi tesis es simple: la mayoría de los errores que parecen criptográficos en firma digital son, en realidad, errores de capa superior — formato incompatible, certificado que no cumple el perfil requerido, o política de validación que el emisor y el receptor nunca alinearon. Y confundir esas tres capas tiene un costo real: tiempo de debugging en el lugar equivocado.

El quilombo real: tres capas que la gente mezcla

Cuando una firma digital falla en validación, la secuencia mental común es: "¿El algoritmo es correcto? ¿La clave privada coincide con la pública? ¿Expiró el certificado?" Esas son preguntas razonables, pero son todas de la misma capa. El problema es que existen tres capas distintas, y cada una puede fallar de forma independiente.

Capa 1 — Formato de firma

El formato define cómo se empaqueta la firma junto con los datos firmados. No es lo mismo CMS/PKCS#7 que XAdES, PAdES o JAdES. Cada uno tiene variantes: BASELINE-B, BASELINE-T, BASELINE-LT, BASELINE-LTA. Elegir CAdES-BASELINE-B cuando el receptor espera XAdES-BASELINE-LT produce un rechazo que no tiene nada que ver con el algoritmo criptográfico.

La documentación pública de DSS (Digital Signature Service) de la Comisión Europea describe estas variantes en detalle. DSS es la librería de referencia para firmas conformes a eIDAS y su documentación es uno de los recursos más completos y verificables disponibles públicamente.

Capa 2 — Certificado

El certificado es la identidad del firmante, pero también es un conjunto de restricciones. El campo Key Usage define para qué se puede usar la clave: firma digital, cifrado, firma de certificados. Si el certificado fue emitido para un propósito y se usa en otro, el validador puede rechazarlo aunque la firma matemática sea correcta.

Además está la cadena de confianza. Un certificado emitido por una CA raíz que el validador no tiene en su trust store produce un error de "certificado no confiable" — otro error que no es criptográfico sino de configuración.

Capa 3 — Política de validación

La política define las reglas que el validador aplica para aceptar o rechazar una firma. Dos sistemas pueden usar el mismo formato y el mismo certificado válido, y uno aceptar la firma mientras el otro la rechaza — porque sus políticas de validación difieren.

La política puede exigir, por ejemplo, que la firma incluya un timestamp de una TSA (Time Stamping Authority) confiable. Una firma BASELINE-B no incluye timestamp. Si la política lo requiere, el rechazo es por política, no por criptografía.

Lo que DSS dice — y lo que no dice

La documentación oficial de DSS explica las variantes de formato (CAdES, XAdES, PAdES, JAdES) y sus niveles de conformidad. También describe el modelo de validación que implementa, basado en las especificaciones ETSI EN 319 102 y 319 132.

Lo que dice DSS:

Cada nivel BASELINE agrega atributos sobre el anterior. T agrega timestamp, LT agrega material de revocación (OCSP/CRL), LTA agrega archivado a largo plazo.
La validación en DSS puede configurarse con distintas políticas. La política default no es universal — cada implementación puede definir la propia.
DSS provee un conjunto de reportes de validación en XML que desagregan los errores por capa: firma, certificado, timestamp, política.

Lo que no dice DSS:

No define cuál formato usar en un contexto regulatorio específico (eso lo define el reglamento aplicable en cada jurisdicción).
No garantiza que un certificado emitido por cualquier CA sea aceptado por cualquier validador. La lista de CAs confiables es una decisión de política.
No reemplaza la asesoría legal sobre valor jurídico de la firma en cada país.

Esto es importante: DSS es una herramienta de referencia técnica, no una autoridad regulatoria. Usar DSS correctamente no garantiza conformidad legal — garantiza corrección técnica dentro del modelo que DSS implementa.

Dónde se equivoca la gente — y cuánto cuesta

El error más común que veo documentado en foros técnicos y en las issues del propio repositorio DSS es este: el desarrollador recibe un error de validación, asume que el problema es el algoritmo o la clave, cambia de proveedor de firma, y el error persiste. Porque el problema era de formato.

Un contraejemplo concreto: una firma XAdES-BASELINE-B es técnicamente válida — tiene la firma, el certificado del firmante y los atributos requeridos para ese nivel. Pero si el receptor espera XAdES-BASELINE-LT (que incluye material de revocación embebido), el validador rechaza por política, no por criptografía. La firma es matemáticamente correcta. El formato no cumple el nivel requerido.

El costo oculto de mezclar las capas es el debugging circular: se verifica la clave, se regenera el certificado, se cambia el algoritmo — y nada cambia porque el problema estaba en qué variante de formato se eligió o qué política aplica el validador.

Un criterio simple antes de debuggear: el error de validación de DSS siempre indica en qué capa ocurrió. El reporte XML que genera DSS separa los resultados en BasicBuildingBlocks, Timestamps, CertificateChain y SignatureQualification. Si el error está en BasicBuildingBlocks / FC (Format Checking), no es criptografía. Si está en CertificateChain, no es el algoritmo de firma.

Checklist de decisión: qué mirar primero

Antes de cambiar cualquier cosa en el stack de firma, este es el orden que tiene sentido seguir:

[ ] 1. FORMATO
    - ¿El formato elegido (CAdES/XAdES/PAdES/JAdES) coincide con lo que espera el receptor?
    - ¿El nivel BASELINE (B / T / LT / LTA) cumple lo que exige la política del receptor?
    - Si usás DSS: ¿el SignatureForm y SignatureLevel están configurados correctamente?

[ ] 2. CERTIFICADO
    - ¿El Key Usage del certificado incluye "digitalSignature"?
    - ¿La cadena de certificación es completa (leaf → intermediate → root)?
    - ¿El certificado está dentro del período de validez en el momento de la firma?
    - ¿La CA emisora está en el trust store del validador?

[ ] 3. POLÍTICA DE VALIDACIÓN
    - ¿El validador usa una política que requiere timestamp? ¿La firma lo incluye?
    - ¿Se requiere OCSP o CRL embebido (nivel LT)?
    - ¿El validador tiene actualizada la Trusted List aplicable (por ejemplo, LOTL de eIDAS)?

[ ] 4. REPORTE DE VALIDACIÓN
    - Si usás DSS: leer el XML de validación y localizar el bloque con el error.
    - Identificar si el error es de Format Checking, Certificate Chain, Revocation o Policy.
    - No cambiar nada hasta entender en qué capa cayó el error.

Este checklist no reemplaza los logs del validador, pero evita el debugging circular más común.

Límites: qué no se puede concluir sin datos propios

Antes de cerrar, hay que ser honesto sobre lo que esta guía no puede garantizar:

No puedo afirmar qué formato es el correcto en cada jurisdicción. Las regulaciones cambian, y la conformidad legal depende del reglamento aplicable (eIDAS en Europa, pero cada país tiene sus propias implementaciones). Para eso, la fuente es la normativa vigente y un asesor legal, no un post técnico.
No puedo afirmar que DSS sea la única herramienta válida. Es la librería de referencia de la Comisión Europea y está bien documentada, pero existen otras implementaciones. La elección depende del contexto.
El checklist de arriba es un criterio de diagnóstico, no una garantía de conformidad. Si el sistema de destino tiene una política de validación customizada o una Trusted List propia, puede haber casos borde que el checklist no cubre.
Sin logs del validador, cualquier diagnóstico es especulación. El reporte XML de DSS es la evidencia más confiable disponible para debuggear. Sin él, todo lo demás es hipótesis.

Si el contexto es producción real con valor jurídico, el diagnóstico técnico es necesario pero no suficiente. La capa legal existe y no desaparece por tener el formato correcto.

FAQ

¿Cuál es la diferencia concreta entre CAdES, XAdES, PAdES y JAdES?

Son formatos de firma que difieren en el tipo de contenido que firman y cómo lo empaquetan. CAdES firma datos binarios usando CMS. XAdES firma documentos XML. PAdES firma documentos PDF. JAdES firma JSON. Todos están definidos en estándares ETSI y todos tienen los mismos niveles BASELINE (B, T, LT, LTA). La elección depende del tipo de documento que se firma, no del algoritmo criptográfico.

¿Qué es el nivel BASELINE-LT y por qué importa?

BASELINE-LT (Long-Term) agrega al paquete de firma el material de revocación del certificado — OCSP response o CRL — en el momento de la firma. Esto permite validar la firma tiempo después sin necesidad de consultar servicios externos que pueden haber desaparecido. Es el nivel mínimo recomendado cuando la firma tiene que tener valor a largo plazo.

¿Un certificado expirado siempre invalida la firma?

Depende de la política de validación. Si la firma incluye un timestamp válido (nivel T o superior) que fue generado mientras el certificado estaba vigente, muchos validadores aceptan la firma aunque el certificado haya expirado después. Eso es justamente el propósito del timestamp: anclar la firma en el tiempo.

¿Qué es la Trusted List (LOTL) en eIDAS y por qué afecta la validación?

La LOTL (List of Trusted Lists) es el registro oficial de las CAs de confianza bajo el marco eIDAS. Los validadores que quieren determinar si una firma es "qualificada" bajo eIDAS consultan esa lista para ver si la CA emisora está reconocida. Si la CA no aparece, la firma puede ser válida técnicamente pero no calificar como firma electrónica cualificada.

¿DSS valida si una firma tiene valor legal?

No directamente. DSS valida conformidad técnica con los perfiles ETSI y reporta el nivel de calificación según la política configurada. Pero el valor legal depende de la normativa de cada jurisdicción. DSS puede decir que una firma es "QES" (Qualified Electronic Signature) técnicamente — si tiene valor jurídico equivalente a una firma manuscrita en ese país, eso lo dice el marco legal, no la librería.

¿Puedo probar validación de firmas sin armar todo un stack propio?

Sí. DSS tiene una webapp de demo pública donde se puede subir un documento firmado y obtener un reporte de validación. Es útil para entender qué reporta el validador antes de implementar nada. El link está en las fuentes al final del post.

Postura final: no rompas lo que no entendés

Cuando una firma digital falla, el instinto es cambiar el algoritmo, regenerar el certificado o cambiar de librería. Ese instinto, la mayoría de las veces, es equivocado.

Mi punto es este: antes de tocar cualquier cosa, abrí el reporte de validación. Si usás DSS, está en XML y es legible. Identificá en qué capa falló — formato, certificado o política. Recién ahí sabés dónde actuar.

Lo que más me incomoda del tema es que la confusión entre estas tres capas no es ignorancia técnica — es falta de modelo mental. La criptografía es la parte sexy del tema, y todo el debugging va ahí. Pero el ecosistema de firmas digitales tiene dos capas más encima que son igual de determinantes y mucho más fáciles de corregir si las identificás correctamente.

El próximo paso concreto: si estás integrando validación de firmas, descargá la webapp de DSS, firmá un documento de prueba con distintos niveles y leé el reporte XML de validación antes de escribir una sola línea de código de producción. Eso va a ahorrar más tiempo que cualquier blog post.

Para otros temas donde el ecosistema tiene más capas de las que parecen a primera vista, estos posts pueden sumar contexto: cómo evaluar dependencias npm antes de meterlas en producción, rate limiting en Next.js y qué proteger primero, o OWASP LLM Top 10 en producción.

Fuente original: