Anatomía de una firma digital argentina: cómo se arma y cómo se verifica

1. El mapa de actores y por qué importa

Antes de entrar en bytes, conviene fijar quién hace qué. La Infraestructura de Firma Digital de la República Argentina (IFDRA) define cuatro actores con roles no intercambiables:

La Resolución SICYT 11/2025 actualizó todo el marco operativo, derogando las resoluciones 116/2017, 42/2019 y 946/2021. Sus ocho anexos son la norma técnica vigente que un CL debe cumplir. En particular, el Anexo III aprueba la Política Única de Certificación (PUC) y el Anexo IV define los perfiles de certificados y de listas de revocación. Ambos documentos son los que un verificador consulta para saber si un certificado está bien formado.

Quien quiera entender qué pasa cuando se firma o se verifica un documento en Argentina, tiene que entender estos cuatro actores. Todo lo demás — los formatos, los algoritmos, los timeouts — deriva de aquí.

2. La clave privada que nunca sale del HSM

La firma digital se construye con criptografía asimétrica. El suscriptor tiene un par de claves: una clave pública (que figura dentro del certificado) y una clave privada (que firma). El requisito legal — y técnico — más importante de toda la arquitectura es que esa clave privada no debe poder copiarse, exportarse ni interceptarse. La única forma de garantizarlo es que viva dentro de un módulo criptográfico de hardware: un HSM (Hardware Security Module).

La PUC y el Anexo II de la Resolución SICYT 11/2025 exigen, para certificados de firma digital, dispositivos criptográficos certificados FIPS 140-2 nivel 2 o superior, con certificación NIST en estado activo. En la práctica, la infraestructura del Certificador Licenciado opera con HSMs FIPS 140-2 nivel 3: el módulo detecta intentos de manipulación física y “zeroiza” (borra) las claves antes de que un atacante pueda extraerlas.

Qué entra y qué sale del HSM

Un HSM expone una API criptográfica acotada. Las operaciones típicas son: generación de claves, firma de un hash, descifrado, derivación de claves. Lo que nunca sale del módulo es el material privado. El HSM acepta el hash a firmar y devuelve la firma; la clave privada permanece dentro del perímetro físico, protegida por el sensor de tampering, los circuitos de bloqueo y los controles de acceso por roles.

// Pseudocódigo: solicitud de firma a un HSM (estilo PKCS#11)

session   = hsm.openSession(slot_id, user_pin)
key_obj   = session.findObject(label="cn=20-12345678-9", class=PRIVATE_KEY)

// El cliente envía el hash. NO envía el documento.
digest    = sha256(documentBytes)

// El HSM ejecuta la operación RSA con padding PSS.
signature = session.sign(
  mechanism = CKM_RSA_PKCS_PSS,
  key       = key_obj,
  data      = digest
)

// La clave privada nunca cruzó la frontera del módulo.
// El cliente recibe solamente la firma (256 o 512 bytes).

En arquitecturas de firma remota, el HSM no está en la máquina del firmante: vive en el datacenter del proveedor de la infraestructura criptográfica. El suscriptor se autentica (factor de posesión + factor de conocimiento, típicamente push notification + PIN) y el HSM aplica la firma en su nombre. Esa autenticación se traduce en un SAD (Signature Activation Data) que autoriza una y solo una firma. El modelo está descrito en el estándar ETSI EN 419 241-2 (Cloud Signature Consortium API).

El punto clave: aunque el HSM esté en otro continente, la firma se produce como si el suscriptor tuviera el módulo en su escritorio. La cadena de custodia criptográfica permanece intacta, y el certificado emitido por el CL argentino lo prueba.

3. Anatomía de un certificado X.509 argentino

El certificado es la pieza pública que vincula la clave del suscriptor con su identidad. Sigue el formato X.509 v3 (RFC 5280) y, en el caso argentino, debe respetar los perfiles del Anexo IV de la Resolución SICYT 11/2025. Un certificado emitido por un CL argentino se ve, al inspeccionarlo, así:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 01:8a:42:9c:7e:14:f3:b1
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=AR, O=<Certificador Licenciado SA>,
                serialNumber=CUIT 30-71012345-6,
                CN=AC <Certificador Licenciado>
        Validity:
            Not Before: May  2 13:45:00 2026 GMT
            Not After : May  2 13:45:00 2030 GMT
        Subject: C=AR, CN=PEREZ JUAN,
                 serialNumber=CUIL 20-12345678-9,
                 2.5.4.5=20-12345678-9
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation
            X509v3 Certificate Policies: critical
                Policy: 2.16.32.1.3.1.1   ← OID PUC argentina
            X509v3 Authority Key Identifier:
                keyid:9F:8E:7D:6C:5B:4A:39:28:17:06
            X509v3 CRL Distribution Points:
                URI:http://crl.<cl>.com.ar/ac.crl
            Authority Information Access:
                OCSP - URI:http://ocsp.<cl>.com.ar
                CA Issuers - URI:http://<cl>.com.ar/ac.crt
            X509v3 Subject Alternative Name:
                email:juan.perez@empresa.com.ar
            qcStatements:
                id-etsi-qcs-QcCompliance
                id-etsi-qcs-QcSSCD
    Signature Algorithm: sha256WithRSAEncryption
        [firma de la AC sobre todo lo anterior]

Tres extensiones merecen atención especial porque son las que distinguen un certificado de firma digital de la Ley 25.506 de un certificado SSL cualquiera:

• Key Usage = Non Repudiation: el certificado está habilitado para crear firmas que comprometen jurídicamente al titular. Sin este bit, no hay no repudio. Un certificado SSL típico no lo tiene.
• Certificate Policies con el OID de la PUC: declara que el certificado se emitió bajo la Política Única de Certificación argentina. El verificador sabe, leyendo este OID, qué reglas se aplicaron al validar la identidad del suscriptor, qué tamaño de clave se exige, qué vigencia tiene el certificado, y bajo qué régimen se audita al emisor.
• Authority Information Access (AIA) y CRL Distribution Points: URLs del servicio OCSP y de la lista de revocación. Estos endpoints son los que un verificador consulta para saber si el certificado sigue vigente en el momento de la firma. Si el CL no los publica o los apaga, los certificados emitidos pierden verificabilidad.

Un certificado argentino bien emitido es, leyéndolo, un contrato técnico. Declara la jurisdicción (C=AR), la política (OID PUC), la finalidad (Non Repudiation), las URLs operativas (OCSP, CRL) y el ancla de confianza (cadena hasta AC-RAÍZ). Cualquier verificador serio puede leer todo esto sin acceder al CL.

4. El acto de firmar, paso a paso

Cuando el suscriptor hace clic en “firmar”, ocurren ocho operaciones. Las describimos para un PDF firmado en formato PAdES — el formato dominante en Argentina porque es el que Adobe Reader entiende nativamente:

1. El cliente abre el PDF y agrega un objeto /Sig (Signature Dictionary) que reserva un hueco vacío (/Contents) y declara el rango del archivo a firmar (/ByteRange).
2. El cliente calcula SHA-256 sobre todo el PDF excepto el hueco reservado.
3. El cliente arma una estructura CMS/PKCS#7 (RFC 5652) con los signedAttributes: contentType, messageDigest, signingTime, signingCertificateV2.
4. El cliente calcula el hash de los signedAttributes serializados (DER).
5. El cliente envía ese hash al HSM remoto. El suscriptor autoriza la operación con su segundo factor (push notification con PIN, OTP o biometría).
6. El HSM aplica la operación RSA con la clave privada del suscriptor y devuelve la firma (256 bytes para RSA-2048).
7. El cliente arma la estructura CMS final: signedAttributes + firma + certificado del suscriptor + cadena de certificados del CL.
8. El cliente inserta la estructura CMS en el hueco /Contents del PDF y lo guarda.

El resultado es un PDF firmado con una estructura CMS embebida que, abierta con un visor de firma, se ve así:

SignedData (CMS, RFC 5652)
│
├─ version: 1
├─ digestAlgorithms: [sha256]
├─ encapContentInfo:
│    └─ eContentType: id-data  (firma detached)
├─ certificates:
│    ├─ certificado del suscriptor (CN=PEREZ JUAN)
│    ├─ certificado del CL (CN=AC ...)
│    └─ certificado de AC-RAÍZ (opcional, suele incluirse)
└─ signerInfos:
     └─ SignerInfo:
          ├─ sid: IssuerAndSerialNumber
          ├─ digestAlgorithm: sha256
          ├─ signedAttrs:
          │    ├─ contentType: id-data
          │    ├─ messageDigest: [hash SHA-256 del PDF]
          │    ├─ signingTime: 2026-05-02T13:45:00Z
          │    └─ signingCertificateV2: [hash del cert]
          ├─ signatureAlgorithm: sha256WithRSAEncryption
          ├─ signature: [256 bytes producidos por el HSM]
          └─ unsignedAttrs:
               └─ signature-time-stamp-token (RFC 3161)

Esta estructura es interoperable: cualquier verificador conforme a ETSI EN 319 142 (PAdES), incluyendo Adobe Reader, los validadores oficiales argentinos y las librerías open source (DSS de la Comisión Europea, BouncyCastle, OpenSSL), puede leerla y validarla. La firma producida por un CL argentino vale globalmente porque cumple los mismos estándares que cualquier firma cualificada europea.

5. Cómo se integra el motor de firma con un CL argentino

En la práctica, las plataformas que orquestan flujos documentales (envelopes, recordatorios, firmantes múltiples, evidencias) no implementan PKCS#11 directamente contra el HSM. Usan un plugin de firma genérico: una interfaz que delega la operación criptográfica a un proveedor externo — en este caso, la infraestructura de un Certificador Licenciado argentino — mientras la plataforma se ocupa del workflow.

El contrato típico de un plugin de firma se reduce a tres operaciones:

// Interfaz del plugin de firma (simplificada)

interface SigningPlugin {
  // 1. Autenticar al firmante y obtener autorización de uso
  //    de la clave privada (SAD, RFC 419 241-2).
  AuthorizeSignature(subscriberId, documentHash, channel) -> SAD

  // 2. Solicitar la firma del hash al HSM remoto.
  SignHash(SAD, hashAlgo, hashBytes) -> signatureBytes

  // 3. Devolver el certificado y la cadena para embeber en CMS.
  GetCertificateChain(subscriberId) -> [certSubscriber, certCL, certRoot]
}

La plataforma maneja todo lo que rodea a la firma — UX, notificaciones, evidencias, branding, integración con CRMs, callbacks. El plugin se especializa en el puente con el CL argentino: autenticación del suscriptor (la app del CL muestra un push, el suscriptor ingresa su PIN, el HSM autoriza), firma del hash y entrega del certificado para que la plataforma lo embeba en la estructura CMS.

El diagrama de secuencia se ve así:

Suscriptor    Plataforma   Plugin    CL (HSM)    TSA
   │             │          │         │          │
   │-- abrir doc->│          │         │          │
   │             │-- hash -->│         │          │
   │             │          │-- auth->│          │
   │<------ push notification (PIN) ----│          │
   │-- PIN ---->│            │         │          │
   │             │          │<-- SAD --│          │
   │             │          │-- sign->│          │
   │             │          │<-- sig --│          │
   │             │<- sig+chain          │          │
   │             │-- hash de signedAttrs ------>│
   │             │<------ TSToken (RFC 3161) ----│
   │             │
   │             │[arma CMS, embebe en PDF, agrega DSS para LTV]
   │<-- PDF firmado ---│

El patrón se replica con cualquier plataforma que exponga una interfaz de plugin (Generic Signing Plugin, External Signature Provider, Connector). El código de pegamento es, en términos de líneas, sorprendentemente corto. Lo que pesa es lo que rodea al plugin: el contrato con el CL, la conformidad con la PUC, la auditoría, los acuerdos de servicio.

6. La estampa de tiempo y la fecha cierta

La firma criptográfica garantiza autoría e integridad, pero no responde una pregunta crítica: ¿cuándo se firmó? El reloj del cliente que firma no es confiable — un atacante puede cambiar la hora de su sistema. Por eso se agrega una estampa de tiempo emitida por un tercero independiente.

El protocolo se llama TSP (Time-Stamp Protocol) y está definido en el RFC 3161. La mecánica es:

1. El cliente calcula el hash del valor a sellar (en PAdES, el hash de la firma recién producida).
2. Envía ese hash a una TSA (Time-Stamping Authority).
3. La TSA agrega su tiempo confiable (sincronizado con UTC), firma el conjunto con su propia clave privada y devuelve un TimeStampToken en formato CMS.
4. El cliente embebe el token en los unsignedAttrs del CMS (perfil PAdES-T).

El artículo 2 de la Ley 25.506 define a la firma digital como un procedimiento que permite verificar autoría, integridad y la fecha cierta de un documento. La estampa de tiempo es la pieza técnica que materializa la “fecha cierta” jurídica. Sin TSA, la firma vale igual desde el punto de vista de no repudio, pero su fecha es la del reloj del firmante — impugnable.

En la práctica argentina, las plataformas serias agregan estampa de tiempo cualificada por defecto, generalmente provista por una TSA del mismo grupo del CL o por una TSA cualificada europea. El costo computacional es trivial — algunos milisegundos — y el costo legal de no agregarla es enorme.

7. PAdES-LTV: la firma que sobrevive al certificado y al CL

Hasta aquí la firma es válida hoy. Pero un contrato firmado en 2026 puede tener que verificarse en 2046. En 20 años, casi todo lo que sostiene la verificación ya no existirá: el certificado del suscriptor habrá vencido (vigencia típica de 4 años), los servicios OCSP del CL pueden estar apagados, el algoritmo de hash puede estar deprecado, y el CL mismo puede haber dejado de operar.

PAdES-LT (Long-Term) y PAdES-LTA (Long-Term Archival) resuelven esto embebiendo, dentro del PDF, toda la información de validación necesaria. La estructura clave se llama DSS Dictionary (Document Security Store):

/DSS <<
  /Certs [ <cert suscriptor> <cert CL> <cert AC-RAÍZ> ]
  /OCSPs [ <respuesta OCSP firmada al momento de firmar> ]
  /CRLs  [ <CRL firmada por el CL al momento de firmar> ]
  /VRI   << /signature-hash << ... >> >>
>>

El perfil LTA agrega además un document timestamp periódico que sella todo el documento (firma + DSS) con una nueva TSA. Cuando un algoritmo de hash o de firma queda obsoleto, se puede agregar un nuevo timestamp con un algoritmo más fuerte que protege todo el contenido anterior. El documento se vuelve auto-contenido: para verificarlo no hace falta consultar al CL ni a la TSA, todo está dentro del archivo.

Esto interlocuta directamente con el artículo 23 de la Ley 25.506: si un Certificador Licenciado cesa sus actividades, el Ente Licenciante asume la custodia de los certificados emitidos. Pero aun sin esa custodia, un PDF firmado en perfil LTA verifica solo, indefinidamente, sin necesidad de servicios externos.

Un PDF firmado en perfil PAdES-B se vuelve inverificable cuando vence el certificado o el CL apaga el OCSP. Un PDF firmado en perfil PAdES-LTA se mantiene verificable medio siglo después, sin depender de nadie. La diferencia computacional es de milisegundos. La diferencia probatoria es de magnitud.

8. Cómo se verifica una firma, byte a byte

Verificar una firma digital es ejecutar, en orden, una secuencia de comprobaciones. Si todas pasan, el verificador puede afirmar las tres propiedades fundamentales: autoría, integridad y fecha cierta. Si alguna falla, la firma es inválida.

Pseudocódigo del verificador

function verifySignature(pdfBytes):
  // 1. Extraer la firma del PDF
  sig    = pdf.findSignatureDictionary()
  range  = sig.byteRange      // [0, 840, 2560, 1200]
  cms    = sig.contents       // CMS/PKCS#7 hex

  // 2. Recalcular el hash sobre el ByteRange
  signed = pdfBytes[0:range[1]] + pdfBytes[range[2]:range[2]+range[3]]
  hash   = sha256(signed)

  // 3. Validar que el hash coincide con messageDigest
  signerInfo = cms.signerInfos[0]
  if signerInfo.signedAttrs.messageDigest != hash:
    return INVALID  // documento modificado tras firmar

  // 4. Validar la firma RSA sobre los signedAttrs
  pubKey = signerInfo.certificate.publicKey
  if not rsaVerify(pubKey, signerInfo.signature, signerInfo.signedAttrs):
    return INVALID  // firma falsa o cert no corresponde

  // 5. Validar la cadena de certificados hasta AC-RAÍZ
  chain = buildChain(signerInfo.certificate, cms.certificates)
  if not validateChain(chain, trustAnchor=AC_RAIZ_AR):
    return INVALID  // emisor no reconocido

  // 6. Validar que el certificado no estaba revocado
  //    al momento de firmar (signingTime o TSA)
  signTime = signerInfo.tsToken.genTime || signerInfo.signedAttrs.signingTime
  if certificate.revokedAt <= signTime:
    return INVALID

  // 7. Validar la cadena de revocación: OCSP o CRL
  status = checkRevocation(signerInfo.certificate, signTime)
  if status != GOOD:
    return INVALID

  // 8. Validar el TSToken (si existe)
  if signerInfo.tsToken:
    if not verifyTSToken(signerInfo.tsToken, hash(signerInfo.signature)):
      return INVALID
    if not validateChain(tsToken.tsa.chain, trustAnchor=...):
      return INVALID

  return VALID

Los pasos 5, 6 y 7 son los más sutiles. El verificador necesita saber si el certificado estaba vigente y no revocado al momento exacto de la firma. Esto se hace con una de dos fuentes:

• OCSP (RFC 6960): el verificador envía el número de serie del certificado al endpoint OCSP del CL y obtiene una respuesta firmada con tres estados posibles: good, revoked, unknown. Es una consulta en línea, rápida.
• CRL (RFC 5280): el verificador descarga la lista de revocación del CL y busca el número de serie del certificado. La PUC argentina obliga al CL a publicar CRLs completas con frecuencia regular y delta CRLs nunca con más de 24 horas de retraso. Si la URL de la CRL está en el certificado (extensión CRL Distribution Points), cualquier verificador puede descargarla sin permisos especiales.

Si el documento está en perfil LTV, los pasos 7 y 8 se resuelven sin acceso a Internet: las respuestas OCSP y las CRLs ya están embebidas en el DSS. La verificación es offline y reproducible 20 años después.

9. Por qué el ancla de confianza es la AC-RAÍZ argentina

Un verificador necesita un trust anchor: un certificado que se considera válido por definición, sin que nadie más lo respalde. Toda la cadena se valida hacia atrás hasta llegar a ese ancla. Si el ancla está presente y la cadena cierra contra ella, la firma vale.

Para la firma digital argentina, el ancla es el certificado autofirmado de la AC-RAÍZ de la República Argentina, operada por la Subsecretaría de Innovación. Su huella digital y su clave pública están publicadas oficialmente; el certificado se distribuye con los validadores estatales y se puede instalar en cualquier sistema operativo o aplicación.

Esto resuelve, sin ambigüedad, dos preguntas que un juez puede hacer:

• ¿Quién autorizó al CL a emitir certificados de firma digital? El Ente Licenciante. Lo prueba el certificado de la AC del CL, firmado por la AC-RAÍZ.
• ¿Quién autoriza a la AC-RAÍZ? El Estado argentino, por imperio de la Ley 25.506 art. 28 y del Decreto 182/2019. La AC-RAÍZ es autofirmada porque es soberana — no depende de ninguna entidad superior.

Cualquier validador oficial, como firmar.gob.ar, valida contra esta AC-RAÍZ. Adobe Reader puede configurarse para hacer lo mismo. Una firma argentina abierta en una máquina sin la AC-RAÍZ instalada mostrará un cartel de “identidad del firmante desconocida”: la firma es matemáticamente válida, pero el verificador no tiene con qué cerrar la cadena. La solucion es trivial: instalar el certificado de AC-RAÍZ. El error es sintáctico, no sustantivo.

10. La auditoría que sostiene todo el modelo

Toda la criptografía anterior depende de una premisa: que el Certificador Licenciado opera bien. Que sus HSMs están donde dice, que sus procedimientos siguen la PUC, que sus sistemas no fueron comprometidos, que sus operadores no emiten certificados a personas que no son. La forma de verificar esa premisa no es técnica — es legal y procedimental: la auditoría.

El régimen de auditoría argentino es uno de los más estrictos del mundo. Se sostiene en cuatro pilares:

La pieza que sorprende a quien viene del mundo eIDAS: las auditorías al CL las realiza la SIGEN (Sindicatura General de la Nación), no una auditora privada acreditada. Es decir: un órgano de control del Estado argentino entra al datacenter del CL, revisa los HSMs, los logs y los procedimientos, y emite un dictamen público. Esto le da al sistema una capa de control externa que no existe en jurisdicciones donde la auditoría queda en manos privadas.

El efecto práctico es que un comprador, un juez o un escribano que recibe un PDF firmado bajo Ley 25.506 no necesita auditar al CL: el Estado argentino lo audita por él. La presunción del artículo 7 (autoría) y del artículo 8 (integridad) descansa sobre esa cadena de auditoría, no solo sobre la matemática.

11. Por qué el modelo Namirial + CL argentino es distinto

Uno de los hallazgos técnicos más interesantes de los últimos años es la integración entre la infraestructura de un QTSP europeo — típicamente Namirial, prestador cualificado bajo eIDAS — y un Certificador Licenciado argentino bajo Ley 25.506. El modelo combina dos régimenes que, leídos por separado, parecen redundantes; leídos juntos son complementarios.

Lo que aporta cada uno:

El argumento técnico para combinar ambos es directo. Una firma digital tiene tres actores que pueden fallar: el motor criptográfico (HSM), la cadena de confianza (PKI) y el régimen de auditoría. En el modelo Namirial + CL argentino, cada actor está doblado:

• Motor criptográfico: HSMs FIPS 140-2 nivel 3 de Namirial, con la escala y redundancia de un QTSP europeo, integrados a la PKI argentina. La probabilidad de que un HSM individual falle de forma indetectable es bajo en cualquiera de las dos infraestructuras — combinarlas no incrementa el riesgo, lo distribuye.
• PKI: el certificado emitido lo firma el CL argentino, ancla en AC-RAÍZ argentina. Pero los timestamps cualificados pueden venir de TSAs de la lista UE. El documento queda con un pie en cada régimen.
• Auditoría: SIGEN audita al CL anualmente; los organismos acreditados europeos auditan a Namirial bajo ETSI. Para un comprador o un juez, esto significa dos sistemas de control independientes — uno argentino, uno europeo — verificando la misma operación.

Una firma producida bajo este modelo es, simultáneamente, una firma digital argentina (con todos los efectos de la Ley 25.506) y una firma cualificada bajo el reglamento eIDAS para uso en la Unión Europea. No hay que elegir — se obtienen ambas validaciones del mismo acto. Para empresas con operaciones cross-border, esto es una propiedad concreta y difícil de replicar con otros stacks.

12. Síntesis: cada paso, anclado en la norma

Cierre conceptual: cada operación técnica del proceso anterior se apoya en un artículo legal o un estándar técnico específico. La tabla siguiente mapea unos con otros, y es el resúmen que conviene tener a mano cuando se especifica un sistema de firma digital argentino:

Esta tabla puede usarse como checklist al evaluar un proveedor de firma digital. Si para cada fila el proveedor puede mostrar evidencia concreta — certificados FIPS, código abierto del cliente, dictamen SIGEN, certificado de la AC-RAÍZ — el sistema cumple. Si en alguna fila la respuesta es “es propietario” o “no aplica en nuestro caso”, hay un hueco que va a aparecer en juicio.

Conclusión

La firma digital argentina no es una caja negra. Es un proceso descomponible en operaciones criptográficas precisas, cada una sostenida por una norma técnica o un artículo legal específico. El que firma, el que verifica y el que audita pueden — y deben — entender los doce pasos anteriores, porque la confianza en la firma viene de poder reconstruir, en caso de duda, exactamente qué pasó cuando se firmó.

El tilde verde en Adobe Reader es la versión comprimida de un argumento de doce pasos: el HSM con auditoría, la clave que no sale, el certificado emitido bajo PUC, la firma con padding RSA-PSS, la cadena hasta AC-RAÍZ, el OCSP que confirma que el certificado está vivo, el sello de tiempo de una TSA independiente, la PUC firmada con OID estatal, el DSS embebido para sobrevivir 20 años, la validación offline, la auditoría SIGEN que respalda al CL, y el artículo 23 de la ley que protege todo eso aunque el CL desaparezca.

Cada vez que esto se entiende un poco mejor, hay menos discusiones en juicio y más tiempo para discutir el negocio. Que es, al final, para lo que se firman los contratos.