Archivo de la etiqueta: Authority Information Access

¿Cómo evolucionan las TSL europeas?


Ayer incluía en este blog la actual relación de TSL europeas que determinan los certificados que deben aceptarse en España y en todos los demás países europeos. Hace unos años, en 2011 ya preparé otra información parecida titulada EU Trusted Lists of Certification Service Providers

Son 2 muestras de mi larga cruzada para difundir el sistema de entre los estandarizados que mejor permite resolver el problema de conocer los Prestadores de Servicios de Certificación que merecen la confianza de los sistemas informáticos.

Así y todo, creo que el sistema es imperfecto, y además está mal implementado.

Todavía recuerdo retazos de una larga charla telefónica que tuve hace muchos años con Francisco Jordán, uno de los expertos españoles en certificación digital, puede que fuera en 1.999. Seguramente el ya no se acordará. Le contaba una idea que yo tenía de que el inicio de la confianza de las jerarquías de certificación pudieran gestionarse con listas nacionales gestionadas por los supervisores, con una técnica semejante a la de los DNS o LDAP. Los ordenadores, navegadores y programas que usan o admiten certificados (firmas, autenticaciones,…) tendrían una personalización nacional que además de tener en cuenta el idioma, la moneda, la fecha del cambio de hora equinoccial, la configuración del teclado o la forma de reflejar las fechas incluiría elementos esenciales hoy en día como la URL de sincronización horaria nacional (el servicio NTP que en España fue hora.roa.es y en Estados Unidos time.nist.gov) y la lista de confianza de CAs admitida a nivel nacional (construida con las de todos los países con un nivel de supervisión equivalente).

Lo más parecido a eso que tenemos en la actualidad son las listas TSL nacionales partiendo de la lista de listas, si bien su efectivo uso todavía requiere de cierto procesamiento manual.

Un detalle interesante comparando las dos listas, separadas casi cuatro años (se actualizan cada 6 meses) es que no son uniformes ciertos aspectos que deberían serlo.

Por ejemplo, incluir ficheros con la extensión ZIP para las listas en PDF no me parece una buena práctica. No se ahorra mucho espacio y el uso de ficheros comprimidos es una invitación a los rastreadores de los buscadores para que no indexen su contenido.

Algunos países hacían referencia a ficheros que incluían espacios en la denominación. Eso ya se ha corregido en las listas recientes.

Otro aspecto preocupante es el aparente cambio de organismo supervisor (el que publica las listas) en algunos países, incluido España. Por ejemplo, Finlandia, Eslovenia, Holanda, Luxemburgo,…

Algunos países incluyen solo una de las dos listas nacionales en la europea, unas veces la XML y otras la PDF. Se supone que todos tienen las dos listas. Además el criterio parece que va cambiando a lo largo del tiempo.

En mi opinión el manejo de URL más adecuado es el que hace Bélgica, y que debería ser copiado por todos los países:

Según este modelo, las TSL de España deberían figurar como:

Y lo mismo para el resto de países.

Yo incluiría en en las TSL una información que me parece crítica: la dirección (URL) de los servicios OCSP de cada prestador de servicios de certificación. Es una pena que en la última versión que yo he mirado de la norma ETSI TS 102 231 ni siquiera existe la posibilidad de incluir esa información por restricciones del estándar.

Nuestras esperanzas están puestas en la futura norma ETSI TS 119 612 Electronic Signatures and Infrastructures (ESI); Trusted Lists que incluye extensiones opcionales (para mi obligatorias) al respecto, como expiredCertsRevocationInfo, y que deberá evolucionar para incluir los servidores OCSP de todos los Prestadores de Servicios de Confianza Digital (PSCD) cualificados que expidan certificados cualificados.

Información OCSP en AIA


El servicio OCSP (Online Certificate Status Protocol) ofrece información estandarizada, definida en la especificación RFC 6960 (que actualiza la RFC 2560) sobre el estado de un certificado digital. Es decir, informa sobre si el certificado consultado esta vigente o revocado. Este servicio responde a las aplicaciones cliente que realicen una petición estandarizada y sepan interpretar la respuesta.

La extensión AIA (Authority Information Access, en español Acceso a la Información de Autoridad) está definida en la norma RFC 6818 (que actualiza la especificación RFC 5280, que ha tenido otras versiones y actualizaciones (RFCs  3280, 4325, 4630).

The authority information access extension indicates how to access  information and services for the issuer of the certificate in which  the extension appears.  Information and services may include on-line  validation services and CA policy data.  (The location of CRLs is not  specified in this extension; that information is provided by the  cRLDistributionPoints extension.)  This extension may be included in  end entity or CA certificates.

Traducción:

La extensión de acceso a la información de autoridad indica cómo acceder a  información y servicios del emisor del certificado en el que aparece esta extensión. Entre la Información y los servicios referenciados se pueden incluir  servicios de validación en línea y datos de política de la CA. Esta extensión se puede incluir tanto en certificados de entidad final como en certificados de CA (Autoridad de Certificación).

La ubicación de las CRL no se indica en esta extensión, ya que existe otra para ello:

cRLDistributionPoints

La especificación de la estensión en formato ASN.1 es la siguiente:

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

   AuthorityInfoAccessSyntax  ::=
           SEQUENCE SIZE (1..MAX) OF AccessDescription

   AccessDescription  ::=  SEQUENCE {
           accessMethod          OBJECT IDENTIFIER,
           accessLocation        GeneralName  }

   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

   id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

   id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }