La cadena de confianza: de AC-RAÍZ a su certificado digital

Fundamentos de PKI: Public Key Infrastructure

PKI (Public Key Infrastructure) es un sistema de gestión de certificados digitales basado en criptografía asimétrica. El concepto es simple en teoría: cada entidad tiene un par de claves (pública y privada), y una autoridad de confianza emite un certificado que vincula la clave pública con la identidad de su titular.

El problema que resuelve PKI es el de la autenticidad de la clave pública. Si alguien le envía una clave pública diciendo “soy Juan Pérez”, ¿cómo sabe que es realmente él y no un impostor? La respuesta es: porque un tercero de confianza (la Autoridad Certificante) verificó la identidad de Juan Pérez y firmó un certificado que dice “esta clave pública pertenece a Juan Pérez, CUIL 20-12345678-9”.

Pero eso solo traslada el problema: ¿cómo confía usted en la Autoridad Certificante? Porque su certificado, a su vez, está firmado por otra autoridad superior. Y así se construye la cadena de confianza.

La jerarquía de tres niveles

Una PKI jerárquica típica tiene tres niveles. En Argentina, la IFDRA sigue esta estructura con nombres específicos:

  ┌─────────────────────────────────────────────────────┐
  │                    AC-RAÍZ                        │
  │    Autoridad Certificante Raíz de la IFDRA       │
  │    Operada por: Ente Licenciante                  │
  │    Certificado: autofirmado (trust anchor)        │
  └─────────────────────────────────────────────────────┘
                          │
              firma el certificado de
                          │
  ┌─────────────────────────────────────────────────────┐
  │           CERTIFICADOR LICENCIADO              │
  │    Autoridad Certificante intermedia           │
  │    Ejemplos: ENCODE, Digilogix, AFIP          │
  │    Certificado: firmado por AC-RAÍZ            │
  └─────────────────────────────────────────────────────┘
                          │
              firma el certificado de
                          │
  ┌─────────────────────────────────────────────────────┐
  │                 SUSCRIPTOR                     │
  │    Entidad final (persona física o jurídica)  │
  │    Certificado: firmado por el certificador    │
  │    Usa su clave para firmar documentos         │
  └─────────────────────────────────────────────────────┘

Nivel 1: AC-RAÍZ (Root CA)

La AC-RAÍZ es la Autoridad Certificante Raíz de la IFDRA. Su certificado es autofirmado — no hay nadie por encima que la valide. Es el trust anchor, el punto de anclaje de toda la confianza del sistema. Está operada por el Ente Licenciante, dependiente de la Secretaría de Innovación Pública de la Jefatura de Gabinete de Ministros.

Las claves de la AC-RAÍZ se generan en una key ceremony formal: un evento presencial con múltiples testigos, escribano, y registro en acta. La clave privada reside en un HSM que solo se activa con un quórum de smart cards distribuidas entre custodios diferentes. La AC-RAÍZ solo firma certificados de certificadores licenciados — nunca emite certificados de usuario final.

Nivel 2: Certificador Licenciado (Intermediate CA)

Un certificador licenciado es una entidad pública o privada autorizada por el Ente Licenciante para emitir certificados de firma digital. Para obtener la licencia, debe cumplir requisitos legales, técnicos y operativos definidos en la Ley 25.506 y su Decreto Reglamentario 2628/2002:

• Requisitos legales: constitución societaria, seguros de responsabilidad civil, políticas de certificación aprobadas por el Ente Licenciante.
• Requisitos técnicos: HSMs certificados FIPS 140-2 Level 3+, infraestructura redundante, data center con controles de acceso físico, procedimientos de key ceremony documentados.
• Requisitos operativos: Autoridad de Registro (AR) con procedimientos de verificación de identidad presenciales o remotos validados, publicación de CRL, servicio OCSP, y auditorías periódicas.

Los certificadores licenciados activos en Argentina incluyen entidades como ENCODE S.A., la AFIP (para su propia operatoria), ANSES, y otros. Cada uno tiene su certificado intermedio firmado por la AC-RAÍZ.

Nivel 3: Suscriptor (End Entity)

El suscriptor es la persona física o jurídica titular del certificado. Su certificado está firmado por el certificador licenciado e incluye sus datos de identidad (nombre, CUIL/CUIT, organización si corresponde). La clave privada asociada reside en un dispositivo criptográfico (token USB o HSM del certificador en caso de firma remota).

Estructura de un certificado X.509 v3

Todos los certificados de la IFDRA siguen el estándar X.509 versión 3 (RFC 5280). Un certificado X.509 tiene tres partes principales: el tbsCertificate (datos a firmar), el algoritmo de firma, y la firma propiamente dicha.

Certificate ::= SEQUENCE {
  tbsCertificate       TBSCertificate,
  signatureAlgorithm   AlgorithmIdentifier,
  signatureValue       BIT STRING
}

TBSCertificate ::= SEQUENCE {
  version          [0]  Version (v3 = 2),
  serialNumber           INTEGER (unico por CA),
  signature              AlgorithmIdentifier (sha256WithRSAEncryption),
  issuer                 Name {
    C  = "AR",
    O  = "Nombre del Certificador Licenciado",
    CN = "AC del Certificador"
  },
  validity               SEQUENCE {
    notBefore   GeneralizedTime (2025-01-15T00:00:00Z),
    notAfter    GeneralizedTime (2027-01-15T23:59:59Z)
  },
  subject                Name {
    C            = "AR",
    O            = "Empresa del Suscriptor SA",
    SERIALNUMBER = "CUIL 20-12345678-9",
    CN           = "PEREZ JUAN"
  },
  subjectPublicKeyInfo   SEQUENCE {
    algorithm      AlgorithmIdentifier (rsaEncryption),
    subjectPublicKey BIT STRING (clave publica RSA-2048)
  },
  extensions       [3]  SEQUENCE {
    -- Key Usage: digitalSignature, nonRepudiation
    -- Extended Key Usage: id-kp-emailProtection
    -- Subject Key Identifier: hash de la clave publica
    -- Authority Key Identifier: hash de la clave de la CA
    -- CRL Distribution Points: URL de la CRL del certificador
    -- Authority Information Access: URL del servicio OCSP
    -- Certificate Policies: OID de la politica del certificador
    -- Subject Alternative Name: email del suscriptor
  }
}

Campos críticos para la operatoria de firma digital:

• serialNumber en subject: en certificados IFDRA, contiene el CUIL o CUIT del titular. Esto vincula criptográficamente la identidad legal con la clave.
• Key Usage = nonRepudiation: esta extensión indica que el certificado está habilitado para firma digital con no repudio. Sin esta extensión, el certificado no es válido para firma bajo Ley 25.506.
• CRL Distribution Points: URL donde el certificador publica la lista de certificados revocados. Esencial para verificación.
• Authority Information Access (AIA): contiene la URL del servicio OCSP y opcionalmente la URL para descargar el certificado del emisor (CA issuing).

Algoritmo de validación de cadena (paso a paso)

Cuando un sistema verifica una firma digital, debe validar toda la cadena de certificados desde el suscriptor hasta la AC-RAÍZ. El algoritmo, definido en RFC 5280 sección 6, funciona así:

1. Obtener la cadena completa: se recopilan todos los certificados intermedios. El certificado del suscriptor contiene en su extensión AIA la URL del certificado del emisor, que a su vez contiene la URL de su emisor, hasta llegar a la raíz.
2. Verificar firma de cada certificado: empezando desde la AC-RAÍZ (cuya clave pública se conoce a priori), verificar que la firma del certificado inmediatamente inferior es matemáticamente válida.
   verify(cert_intermedio.signature, cert_raiz.publicKey) == true?
verify(cert_suscriptor.signature, cert_intermedio.publicKey) == true?
3. Verificar vigencia temporal: para cada certificado, confirmar que notBefore ≤ ahora ≤ notAfter. Un certificado vencido invalida toda la cadena.
4. Verificar nombre consistente: el campo issuer de cada certificado debe coincidir exactamente con el campo subject del certificado que lo firmó.
5. Verificar Key Usage: el certificado del suscriptor debe tener nonRepudiation (o contentCommitment en nomenclatura moderna). Los certificados intermedios deben tener keyCertSign y cRLSign.
6. Verificar Basic Constraints: los certificados de CA deben tener cA=TRUE y opcionalmente pathLenConstraint que limita cuántos niveles de CA pueden existir debajo.
7. Verificar estado de revocación: para cada certificado en la cadena, consultar CRL u OCSP para confirmar que no fue revocado. Si el certificado aparece en la CRL o el OCSP responde “revoked”, la cadena es inválida.
8. Verificar políticas de certificación: opcionalmente, validar que las políticas declaradas en cada certificado son consistentes y aceptables.

Si cualquiera de estos pasos falla, toda la cadena se considera inválida. No hay grises: la cadena es completamente válida o completamente inválida. Por eso un certificado revocado o vencido en cualquier nivel rompe la confianza para todos los certificados que dependen de él.

CRL vs. OCSP: dos mecanismos de revocación

Un certificado puede necesitar ser invalidado antes de su fecha de vencimiento: el titular perdió el dispositivo, la clave fue comprometida, o los datos del titular cambiaron. Para esto existen dos mecanismos:

CRL (Certificate Revocation List)

La CRL es un archivo firmado por la CA que contiene la lista de números de serie de todos los certificados revocados, junto con la fecha de revocación y opcionalmente el motivo. El certificador licenciado publica la CRL en la URL indicada en la extensión CRL Distribution Points de cada certificado.

CertificateList ::= SEQUENCE {
  tbsCertList  SEQUENCE {
    version              Version (v2),
    signature            AlgorithmIdentifier,
    issuer               Name (= subject de la CA),
    thisUpdate           Time (cuando se emitio esta CRL),
    nextUpdate           Time (cuando se emitira la siguiente),
    revokedCertificates  SEQUENCE OF {
      serialNumber       INTEGER,
      revocationDate     Time,
      crlEntryExtensions SEQUENCE {
        reasonCode       ENUMERATED {
          keyCompromise(1), cACompromise(2),
          affiliationChanged(3), superseded(4),
          cessationOfOperation(5)
        }
      }
    }
  },
  signatureAlgorithm     AlgorithmIdentifier,
  signatureValue         BIT STRING
}

Ventaja: se puede cachear localmente; no requiere conectividad en el momento de la verificación si se tiene una CRL válida (no vencida).
Desventaja: puede crecer mucho (miles de entradas), hay un window of vulnerability entre la revocación y la publicación de la próxima CRL, y no ofrece información en tiempo real.

OCSP (Online Certificate Status Protocol)

OCSP (RFC 6960) permite consultar el estado de un certificado individual en tiempo real. El verificador envía el número de serie del certificado al responder OCSP del certificador, y recibe una respuesta firmada: good, revoked, o unknown.

Ventaja: respuesta en tiempo real, tamaño fijo (no crece con la cantidad de certificados revocados), ideal para verificación online.
Desventaja: requiere conectividad al momento de verificar, y si el servicio OCSP está caído, la verificación puede fallar (a menos que se use OCSP stapling).

En la práctica, las firmas PAdES-LTA (Long-Term Archival) embeben tanto la respuesta OCSP como la CRL dentro del propio documento PDF. De esta forma, el documento es auto-contenido: puede verificarse años después sin necesidad de que el servicio OCSP o la CRL sigan disponibles online.

La IFDRA en detalle: cómo funciona en Argentina

La Infraestructura de Firma Digital de la República Argentina fue creada por la Ley 25.506 (promulgada en 2001) y reglamentada por el Decreto 2628/2002. Sus componentes institucionales son:

• Autoridad de Aplicación: la Jefatura de Gabinete de Ministros (a través de la Secretaría de Innovación Pública). Define las políticas generales.
• Ente Licenciante: otorga y revoca las licencias a los certificadores. Opera la AC-RAÍZ. Realiza auditorías periódicas. Publica la lista de certificadores licenciados.
• Certificadores Licenciados: emiten certificados de firma digital, operan sus propias CA intermedias, mantienen Autoridades de Registro (AR) para verificación de identidad.
• Autoridades de Registro (AR): entidades (generalmente oficinas o representantes) autorizadas por un certificador para verificar la identidad de los solicitantes de certificados. Pueden ser presenciales o remotas (con videoconferencia y biometría).
• Suscriptores: titulares de certificados que los usan para firmar documentos.
• Terceros usuarios: quienes verifican las firmas digitales.

El certificado de la AC-RAÍZ está pre-instalado en los navegadores y sistemas operativos, o puede obtenerse del sitio oficial del Ente Licenciante. Esto es lo que permite que cualquier persona pueda verificar una firma digital emitida bajo IFDRA sin necesidad de instalar software especial (Adobe Reader reconoce la cadena si la AC-RAÍZ está en su trust store).

Cómo encaja Namirial en esta arquitectura

Namirial es un Qualified Trust Service Provider (QTSP) bajo el reglamento europeo eIDAS. Opera su propia jerarquía PKI en Europa con certificados reconocidos por la TSL (Trusted Service List) de la Unión Europea. Pero en Argentina, la firma digital se rige exclusivamente por la Ley 25.506 y la IFDRA.

¿Cómo se conectan ambos mundos? Namirial provee la tecnología de plataforma (software de firma, gestión de certificados, servicio de sello de tiempo, workflow de firma) mientras que los certificados de firma digital para uso legal en Argentina son emitidos por un certificador licenciado local bajo la jerarquía IFDRA.

Un beneficio adicional: Namirial está en la Adobe Approved Trust List (AATL). Esto significa que las firmas realizadas con certificados Namirial se validan automáticamente en Adobe Reader con el checkmark verde, sin que el destinatario tenga que configurar nada. Esto es especialmente útil para documentos que se envían a contrapartes internacionales.

La combinación es: certificado IFDRA para validez legal en Argentina + plataforma Namirial para operatoria, interoperabilidad internacional y validación automática en Adobe.

Qué pasa cuando un certificado expira o se revoca

La vigencia de un certificado de suscriptor es típicamente de 1 a 3 años. Cuando vence, ya no puede usarse para generar nuevas firmas. Pero las firmas realizadas durante su vigencia siguen siendo válidas, siempre que la firma incluya un sello de tiempo (timestamp) que demuestre que se realizó antes del vencimiento.

La revocación es diferente: implica que el certificado dejó de ser confiable a partir de cierto momento. Las razones pueden ser:

• keyCompromise: la clave privada fue (o se sospecha que fue) comprometida. Todas las firmas posteriores a la fecha de compromiso son sospechosas.
• affiliationChanged: el titular cambió de organización. Las firmas anteriores siguen siendo válidas.
• superseded: se emitió un nuevo certificado que reemplaza a este. Las firmas anteriores siguen siendo válidas.
• cessationOfOperation: el certificador dejó de operar. Las firmas con timestamp anterior siguen siendo válidas.

Por esto es crucial que las firmas digitales incluyan sello de tiempo y datos de revocación embebidos (perfil PAdES-LTA). Sin sello de tiempo, no se puede demostrar cuándo se firmó, y una revocación podría invalidar retroactivamente firmas legítimas.

El proceso de auditoría del Ente Licenciante

Un certificador licenciado no obtiene la licencia una vez y se olvida. El Ente Licenciante realiza auditorías periódicas (al menos anuales) que verifican:

• Estado de los HSMs: certificaciones vigentes, logs de acceso, procedimientos de key ceremony documentados.
• Políticas de certificación (CP) y Declaración de Prácticas de Certificación (CPS): que se cumplan los procedimientos declarados.
• Seguridad física del data center: controles de acceso, cámaras, registros de ingreso.
• Publicación correcta de CRLs: periodicidad, disponibilidad, firma válida.
• Operatoria de Autoridades de Registro: procedimientos de verificación de identidad, formación del personal, registros de cada emisión.
• Continuidad operativa: planes de disaster recovery, backups de HSM, procedimientos de failover.
• Incidentes: reporte y resolución de incidentes de seguridad, revocaciones masivas si las hubo.

Si un certificador no cumple con los estándares, el Ente Licenciante puede suspender o revocar su licencia. Esto implicaría revocar todos los certificados emitidos por ese certificador — un evento de impacto masivo que, en la práctica, se ha evitado gracias a la rigurosidad del proceso de licenciamiento.

Conclusión

La cadena de confianza no es un concepto abstracto — es un mecanismo matemático verificable que conecta su certificado con la AC-RAÍZ del Estado argentino. Cada eslabón (firma criptográfica de la CA superior, vigencia temporal, estado de revocación) debe estar intacto para que la firma digital tenga validez legal.

Cuando un tercero verifica su firma digital, lo que realmente hace es recorrer esta cadena paso a paso: ¿el certificado del firmante está firmado por un certificador licenciado? ¿Ese certificador está firmado por la AC-RAÍZ? ¿Ningún eslabón está vencido ni revocado? Si todas las respuestas son afirmativas, la firma es válida bajo la Ley 25.506 con la presunción del Artículo 7: la carga de la prueba recae sobre quien la desconoce.