PAdES, CAdES, XAdES: qué formato de firma usa cada documento

Por qué importa el formato de firma

Cuando se firma un documento digitalmente, la firma en sí es un objeto criptográfico que contiene (como mínimo) el hash del documento cifrado con la clave privada del firmante y el certificado del firmante. Pero eso es solo el núcleo. Los estándares de firma agregan capas de información que resuelven problemas reales:

Interoperabilidad: que cualquier software compatible pueda verificar la firma, no solo el que la creó.
Validación a largo plazo (LTV): que la firma sea verificable años después, incluso cuando el certificado haya expirado o el servicio OCSP ya no exista.
No repudio probatorio: que la firma contenga toda la evidencia necesaria para demostrar su validez en un juicio sin depender de servicios externos.
Compatibilidad con el tipo de documento: un PDF requiere un formato diferente que un archivo XML de factura electrónica.

Los tres formatos principales — PAdES, CAdES y XAdES — están definidos por ETSI (European Telecommunications Standards Institute) y son reconocidos internacionalmente. Cada uno está diseñado para un tipo específico de contenido.

PAdES: firma embebida en PDF

PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 142) es el formato de firma diseñado específicamente para documentos PDF. A diferencia de los otros formatos, PAdES incrusta la firma dentro del propio archivo PDF, usando la estructura nativa de firmas de Adobe (ISO 32000-1/2).

Esto significa que un PDF firmado con PAdES sigue siendo un PDF válido — cualquier lector de PDF puede abrirlo, y los lectores que soportan firmas (como Adobe Reader) muestran automáticamente el panel de firmas con el estado de validación.

Cómo se embebe en la estructura PDF

Un archivo PDF es internamente un conjunto de objetos referenciados por una tabla de cross-reference (xref). Cuando se firma:

Se agrega un objeto Sig (Signature Dictionary) al PDF que reserva un espacio (ByteRange) para la firma.
Se calcula el hash SHA-256 de todo el PDF excepto el espacio reservado para la firma.
Se firma el hash con la clave privada del firmante.
Se inserta la firma (estructura CMS/PKCS#7) en el espacio reservado.
Se agrega un incremental update al PDF (el PDF original no se modifica, la firma se agrega como un apendix).

Estructura simplificada de un PDF firmado:

%PDF-1.7
... contenido original del PDF ...
%%EOF

%% Incremental update (firma)
1 0 obj  <</Type /Sig
          /Filter /Adobe.PPKLite
          /SubFilter /adbe.pkcs7.detached
          /ByteRange [0 840 2560 1200]
          /Contents <308206... firma CMS en hex ...>
          /Reason (Aprobacion del contrato)
          /Location (Buenos Aires, Argentina)
          /ContactInfo (juan.perez@empresa.com)
          /M (D:20260228143000-03'00')
        >>

%% La firma CMS contiene:
%%   - SignerInfo (algoritmo, hash firmado)
%%   - Certificado del firmante
%%   - Cadena de certificados (intermedios)
%%   - Timestamp token (RFC 3161)
%%   - Respuestas OCSP embebidas
%%   - CRLs embebidas (en perfiles LT/LTA)

Perfiles PAdES

PAdES define cuatro perfiles que representan niveles crecientes de información incluida en la firma:

Perfil	Nombre	Incluye	Validación
PAdES-B	Baseline	Firma + certificado del firmante	Solo mientras el cert esté vigente y servicios online disponibles
PAdES-T	Timestamp	B + sello de tiempo (TSA)	Prueba de existencia en momento específico
PAdES-LT	Long-Term	T + cadena de certs + respuestas OCSP/CRL	Sin dependencia de servicios externos
PAdES-LTA	Long-Term Archival	LT + document timestamp periódico	Validable indefinidamente (re-sellado)

PAdES-B es el mínimo viable. PAdES-LTA es lo que debería usar cualquier organización seria. La diferencia de costo computacional es mínima — agregar el sello de tiempo, la cadena de certificados y las respuestas OCSP es cuestión de milisegundos. La diferencia legal es enorme.

Por qué PAdES-LTA es el estándar de oro

Considere este escenario: usted firma un contrato hoy con PAdES-B. En 3 años, su certificado vence. En 5 años, el certificador licenciado que lo emitió deja de operar y su servicio OCSP se apaga. En 10 años, alguien necesita verificar la firma en un juicio.

Con PAdES-B: imposible verificar. No hay forma de obtener la cadena de certificados ni confirmar que el certificado no estaba revocado al momento de la firma.

Con PAdES-LTA: verificación completa. El documento contiene el sello de tiempo que prueba cuándo se firmó, la cadena completa de certificados, y las respuestas OCSP/CRL que prueban que ninguno estaba revocado en ese momento. Es auto-contenido.

El “A” de LTA (Archival) agrega un document timestamp periódico que protege contra la obsolescencia de algoritmos. Si SHA-256 se considera inseguro en 2040, se puede agregar un nuevo timestamp con SHA-3 que protege toda la estructura anterior.

CAdES: firma para cualquier archivo binario

CAdES (CMS Advanced Electronic Signatures, ETSI EN 319 122) extiende el formato CMS/PKCS#7 (RFC 5652) para firma digital avanzada. A diferencia de PAdES, CAdES no se embebe dentro del archivo firmado — se genera como un archivo separado (.p7s o .p7m) o se adjunta al contenido.

CAdES puede firmar cualquier tipo de archivo: imágenes, ejecutables, archivos ZIP, bases de datos, lo que sea. No depende de la estructura interna del archivo firmado.

Modos de CAdES

CAdES detached: la firma es un archivo .p7s separado. El documento original no se modifica. Para verificar, se necesitan ambos archivos. Ideal cuando no se quiere alterar el original.
CAdES enveloping (attached): el documento se incluye dentro de la estructura CMS junto con la firma, produciendo un archivo .p7m. Un solo archivo contiene todo, pero para acceder al documento original hay que “extraerlo”.

Los perfiles de CAdES son análogos a PAdES:

CAdES-B: firma básica + certificado.
CAdES-T: + sello de tiempo.
CAdES-LT: + cadena de certificados + datos de revocación.
CAdES-LTA: + archive timestamp para validación a largo plazo.

Cuándo usar CAdES

CAdES es la elección correcta cuando el contenido a firmar no es un PDF ni un XML. Ejemplos: firmar un paquete de software para garantizar su integridad, firmar un archivo de base de datos para evidencia forense, o firmar cualquier archivo binario que necesite no repudio. En la práctica argentina, es menos común que PAdES porque la mayoría de los documentos legales circulan como PDF.

XAdES: firma para datos estructurados XML

XAdES (XML Advanced Electronic Signatures, ETSI EN 319 132) extiende XML-DSig (W3C) para firma digital avanzada sobre contenido XML. Es el formato nativo para firmar datos estructurados: facturas electrónicas, mensajes SOAP, documentos de gobierno electrónico, y cualquier dato que ya esté en XML.

Modos de XAdES

Enveloped: la firma se incrusta dentro del documento XML firmado. El XML contiene un elemento <ds:Signature> como hijo del elemento raíz.
Enveloping: el documento XML se incluye dentro del elemento de firma. La firma “envuelve” al contenido.
Detached: la firma es un documento XML separado que referencia al documento original por URI.

Ejemplo simplificado de XAdES enveloped:

<Factura xmlns="urn:afip:factura:v1">
  <Emisor CUIT="30-12345678-9">Empresa SA</Emisor>
  <Receptor CUIT="20-87654321-0">Cliente SRL</Receptor>
  <Total moneda="ARS">150000.00</Total>

  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod
        Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod
        Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <ds:Reference URI="">
        <ds:Transforms>
          <ds:Transform
            Algorithm="http://www.w3.org/.../xmldsig#enveloped-signature"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/.../xmlenc#sha256"/>
        <ds:DigestValue>dGhpcyBpcyBhIGhhc2g=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>MEUCIQD7...</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIIFgTCC...</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <!-- Extensiones XAdES: timestamp, OCSP, etc. -->
    <xades:QualifyingProperties>...</xades:QualifyingProperties>
  </ds:Signature>
</Factura>

XAdES en Argentina: factura electrónica

En Argentina, la AFIP utiliza XML firmado para factura electrónica. Si bien el formato específico de AFIP no es XAdES puro (usa XML-DSig con extensiones propias), el concepto es el mismo: un documento XML estructurado con firma digital embebida. Cualquier sistema que intercambie datos estructurados (HL7 para salud, UBL para comercio electrónico, XBRL para reportes financieros) se beneficia de XAdES.

Comparación directa: PAdES vs. CAdES vs. XAdES

Aspecto	PAdES	CAdES	XAdES
Tipo de contenido	PDF exclusivamente	Cualquier binario	XML
Ubicación de la firma	Dentro del PDF	Separada (.p7s) o envolvente (.p7m)	Dentro del XML o separada
Visualización	Adobe Reader nativo	Requiere software específico	Requiere procesamiento XML
Múltiples firmas	Sí (incremental updates)	Sí (co-signing o counter-signing)	Sí (múltiples elementos Signature)
Estándar base	ISO 32000 + CMS	CMS (RFC 5652)	XML-DSig (W3C)
Caso de uso típico	Contratos, escrituras, poderes	Paquetes de software, archivos	Factura electrónica, EDI, SOAP
Ley 25.506	Plenamente compatible	Plenamente compatible	Plenamente compatible

Los tres formatos son igualmente válidos bajo la Ley 25.506. La ley no prescribe formato — exige firma digital basada en criptografía asimétrica con certificado de certificador licenciado. El formato es una decisión técnica basada en el tipo de documento.

Adobe AATL: por qué importa estar en la lista

Adobe Approved Trust List (AATL) es una lista de certificados raíz que Adobe Reader confía automáticamente para la validación de firmas PAdES. Cuando un PDF firmado se abre en Adobe Reader, el software verifica la cadena de certificados del firmante contra su trust store. Si la raíz de la cadena está en la AATL, el usuario ve el checkmark verde sin tener que configurar nada.

Para estar en la AATL, un prestador de servicios de confianza debe pasar una auditoría de Adobe que verifica:

Que los certificados se emiten bajo políticas de certificación auditadas (WebTrust, ETSI EN 319 411, o equivalente).
Que las claves de CA están en HSMs certificados.
Que los procedimientos de verificación de identidad cumplen estándares mínimos.
Que se publican CRLs y se opera servicio OCSP.

Namirial está en la AATL. Esto significa que las firmas realizadas con certificados Namirial se validan automáticamente en los más de 250 millones de instalaciones de Adobe Reader en el mundo. Para documentos que se envían a contrapartes internacionales, esto es crítico — el destinatario no necesita instalar software adicional ni importar certificados raíz manualmente.

Qué verifica exactamente el checkmark verde de Adobe Reader

Cuando Adobe Reader muestra “Signed and all signatures are valid” con checkmark verde, ha verificado:

Integridad del documento: el hash del PDF coincide con el hash firmado. El documento no fue modificado después de la firma.
Validez de la firma criptográfica: la firma se descifra correctamente con la clave pública del certificado del firmante.
Cadena de confianza: el certificado del firmante se encadena hasta una raíz en la AATL (o en la lista EUTL para certificados europeos).
Vigencia del certificado: el certificado no estaba vencido al momento de la firma (si hay timestamp) o al momento de la verificación (si no hay timestamp).
Estado de revocación: el certificado no estaba revocado, verificado por OCSP o CRL (embebidos en la firma o consultados online).
Sello de tiempo (si presente): el token de timestamp es válido y emitido por una TSA reconocida.

Si alguno de estos pasos falla, Adobe muestra un triángulo amarillo de advertencia o una X roja, según la severidad. Un certificado autofirmado o con raíz desconocida produce “The signature validity is UNKNOWN” — no significa que sea inválida, sino que Adobe no puede verificar la cadena automáticamente.

Validación a largo plazo: el problema de los 20 años

Un contrato de hipoteca dura 20 años. Una escritura pública debe ser verificable indefinidamente. ¿Qué pasa con las firmas digitales cuando pasa el tiempo?

Problema 1: vencimiento de certificados

Los certificados de suscriptor vencen en 1-3 años. Los certificados de CA intermedia en 5-10 años. Incluso la AC-RAÍZ tiene una vigencia finita (típicamente 20-30 años). Si la firma incluye un sello de tiempo, prueba que se realizó cuando los certificados estaban vigentes. Sin sello de tiempo, la verificación falla después del vencimiento.

Problema 2: obsolescencia de algoritmos

SHA-1 fue considerado seguro en 2005. Hoy está roto. ¿Qué garantiza que SHA-256 será seguro en 2046? Nada. La solución es el re-sellado periódico: agregar un nuevo document timestamp con el algoritmo más seguro disponible. El perfil PAdES-LTA está diseñado exactamente para esto.

El re-sellado funciona así: antes de que SHA-256 se considere inseguro, una TSA agrega un timestamp con SHA-3 (o lo que sea el estándar en ese momento) que cubre todo el contenido anterior. Esto “congela” la validez de la firma anterior bajo la protección del nuevo algoritmo.

Problema 3: desaparición de servicios

Un certificador licenciado puede dejar de operar. Su servicio OCSP se apaga. Sus CRLs dejan de publicarse. Si la firma no embebe esta información, no hay forma de verificar que el certificado no estaba revocado al momento de la firma.

La solución para los tres problemas es la misma: PAdES-LTA. Incluye timestamp, cadena completa, datos de revocación, y permite re-sellado periódico. Un documento firmado con PAdES-LTA y resellado periódicamente es verificable indefinidamente.

Estructura interna de una firma PAdES en un PDF

Para quienes quieran inspeccionar la firma a nivel binario, la estructura CMS embebida en el campo /Contents del signature dictionary sigue esta jerarquía ASN.1:

ContentInfo (OID: 1.2.840.113549.1.7.2 = signedData)
└─ SignedData
   ├─ version: 1
   ├─ digestAlgorithms: { sha-256 }
   ├─ encapContentInfo:
   │    contentType: id-data (1.2.840.113549.1.7.1)
   │    [content absent - detached signature]
   ├─ certificates: [SET OF Certificate]
   │    ├─ Certificado del firmante (end-entity)
   │    ├─ Certificado de CA intermedia (certificador licenciado)
   │    └─ Certificado de AC-RAIZ (opcional, puede omitirse)
   ├─ crls: [SET OF CertificateList]  (CRLs embebidas, perfil LT+)
   └─ signerInfos: [SET OF SignerInfo]
      └─ SignerInfo
         ├─ version: 1
         ├─ sid: issuerAndSerialNumber
         ├─ digestAlgorithm: sha-256
         ├─ signedAttrs:
         │    ├─ contentType: id-data
         │    ├─ messageDigest: [hash SHA-256 del PDF]
         │    ├─ signingTime: 2026-02-28T14:30:00Z
         │    └─ signingCertificateV2: [hash del cert del firmante]
         ├─ signatureAlgorithm: sha256WithRSAEncryption
         ├─ signature: [firma RSA sobre signedAttrs]
         └─ unsignedAttrs:
              ├─ id-aa-signatureTimeStampToken:
              │    [Token RFC 3161 de la TSA]
              └─ id-aa-ets-revocationValues:  (perfil LT+)
                   [Respuestas OCSP embebidas]

Puede inspeccionar esta estructura con herramientas como openssl asn1parse, dumpasn1, o el visor de firmas de Adobe Reader (Advanced > Show Certificate). Cada campo tiene un OID (Object Identifier) que lo identifica unívocamente.

Guía práctica: qué formato elegir

Escenario	Formato	Perfil mínimo
Contratos, acuerdos, poderes	PAdES	PAdES-LTA
Escrituras públicas	PAdES	PAdES-LTA + re-sellado
Facturas electrónicas XML	XAdES	XAdES-T
Intercambio de datos HL7/XBRL	XAdES	XAdES-LT
Paquetes de software, archivos binarios	CAdES	CAdES-T
Evidencia digital (forense)	CAdES	CAdES-LTA
Firma masiva de documentos PDF	PAdES	PAdES-LT (mínimo)

Regla general: si el documento es un PDF, use PAdES-LTA. Para todo lo demás, evalúe si el contenido es XML (XAdES) o binario genérico (CAdES). En caso de duda, convierta a PDF y use PAdES — es el formato con mayor interoperabilidad y soporte universal.

Conclusión

El formato de firma no es un detalle de implementación — es una decisión que afecta la verificabilidad, interoperabilidad y valor probatorio del documento a lo largo del tiempo. PAdES-LTA para PDFs, XAdES para XML, CAdES para binarios. Siempre con timestamp, siempre con datos de revocación embebidos, siempre con la cadena completa de certificados.

Simplisigner genera firmas PAdES-LTA por defecto: firma digital con certificador licenciado bajo Ley 25.506, sello de tiempo, cadena completa, respuestas OCSP embebidas. Un documento que puede verificarse hoy y dentro de 20 años, sin depender de ningún servicio externo.

simplisigner