Interoperabilidad de los Prestadores de Servicios de Certificación


En pasados artículos he hecho referencia a que un cumplimiento diligente de la Directiva 199/93/CE de firma electrónica implicaba la aceptación de los certificados reconocidos (o cualificados) de todos los prestadores de servicios de certificación europeos.

Este punto de vista ha quedado recogido, por ejemplo en la Orden EHA/962/2007, pero hay quien piensa que la Ley 11/2007 y el Esquema Nacional de Interoperabilidad dejan margen para que un organismo concreto pueda establecer criterios propios de aceptación.

Debe aclararse que “los criterios propios” de aceptación solo son de aplicación a las firmas avanzadas, y que el criterio general es que las firmas avanzadas basadas en un certificado reconocido (es decir, cualificado), o en un certificado en cuya política se han utilizado mecanismos de verificación de identidad del firmante presenciales o equivalentes a presenciales, tienen un nivel de aceptación próximo al de las firmas reconocidas o cualificadas.

Sin embargo para facilitar la interoperabilidad de las firmas electrónicas en el marco europeo, hay algunos detalles que conviene tener en cuenta:

  1. Las URL de la CRL y del OCSP del prestador deben estar correctamente codificados en todos sus certificados (extensión AIA).
  2. El servicio OCSP, o, al menos el de CRL, de los prestadores válidos (los que figuran en la TSL) han de estar accesibles sin coste
  3. La información de URL de la Root, de la CPS, de los servicios OCSP y CRL de cada prestador de servicios de certificación deben estar codificados en las TSL de cada estado (que en España corresponde al MITyC, no al MAP) y en la TSL armonizada.
  4. Siempre que el destinatario de una firma sea una entidad privada, la firma electrónica debería construirse con arreglo a las especificaciones XAdES-XL o CAdES-XL (respectivamente descritas en las normas TS 101 903 y TS 101 733). En general, este tipo de firma debería ser de elección en todos los casos. Las administraciones públicas que generen firmas siempre deberían hacerlo con estos formatos (ya que eliminan la carga de la verificación de validez del certificado al receptor)

Es necesario contar con una lista actualizada de prestadores europeos, que debería ser posible obtener a partir del sistema de notificación del artículo 11 de la directiva 1999/93/CE. La información de cada prestador debería contener, además de la URL de la home page, su dirección, email y teléfono (lo que más o menos ya se recoge hoy en día) junto con las URL de la Root, de la CPS, de los servicios OCSP y de la CRL de sus CAs (lo que es esencial para la interoperabilidad, pero resulta difícil de encontrar en la página web del prestador en el sistema actual) .

Es necesario que los sistemas nacionales de supervisión que notifican el estado de gestión de los sistemas de certificación de su pais a la Comisión Europea recojan los datos mencionados en sus repositorios. En España, esta responsabilidad corresponde al MITyC, según se establece en la Ley 59/2003.

Conviene poner en valor los Sistemas Voluntarios de Acreditación, como el de ASIMELEC.

Y es conveniente ir eliminando mecanismos alternativos de verificación de validez de certificados como los definidos en la orden EHA/1181/2003 que tuvieron su razón de ser antes de la publicación de la Ley 59/2003, pero no tienen sentido en el actual marco legislativo. El repositorio de la AEAT ya solo tendría sentido en el marco de la normativa de factura electrónica. En su momento supuso un gran empuje a los prestadores de servicios de certificación españoles, pero en la actualidad supone  un ejemplo mal copiado por muchos organismos públicos que crean sus propias listas de prestadores de servicios de certificación sin ser conscientes con que basta con remitirse a la lista del MITyC.

El problema de censar a los prestadores de servicios de certificación, que NUNCA debería ser un problema del tercero que confía, se está convirtiendo en uno de los frenos al desarrollo de la firma electrónica. Y hubiera sido algo muy sencillo de desarrollar si se hubiera aplicado correctamente el artículo 11 de la directiva 1999/93/CE. Es decir, si los datos antes indicados (URL de la Root, de la CPS, de los servicios OCSP y de la CRL de las CAs de cada pais) se hubieran recogido correctamente desde el principio, y el comité del artículo 9 hubiera sido más proactivo.

Por esta ineficiencia de la Comisión ha sido necesario gastar cientos de miles de euros en proyectos de interoperabilidad cuyos resultados están por ver, y se han creado malas costumbres que se tardará años en erradicar.

Otros artículos relacionados:

8 pensamientos en “Interoperabilidad de los Prestadores de Servicios de Certificación

  1. Pingback: Lista de confianza de prestadores de servicios de certificación (TSL) « Todo es electrónico

  2. Pingback: Web del artículo 11 de la Directiva 1999/93/CE « Todo es electrónico

  3. Pingback: Jornada “Construyendo la identidad digital” « Todo es electrónico

  4. Pingback: Estándares de firma electrónica « Todo es electrónico

  5. Ramiro

    Buen artículo Julián, aunque voy a abrir la caja de Pandora.

    A ver, en nuestro país, nuestra legislación traslada al Gobierno el deber de poner a disposición una plataforma de validación de certificados pública y sin coste, que soporte los certificados de uso común en el ámbito administrativo.

    A día de hoy me pregunto cuál es esta plataforma (sic).

    Si algunos han pensado en @Firma del MAP, dejo dos cuestiones en el aire:

    1.- ¿Por qué sólo está accesible para las Administraciones Públicas y dentro de la red SARA?

    2.- ¿Por qué se requiere convenio con la FNMT para validar certificados clase 2 CA a través de @Firma?

    Responder
    1. inza Autor de la entrada

      Ramiro,

      Te contesto a la segunda pregunta.

      Según la DPC de CERES, los certificados solo son de confianza para miembros de la comunidad electrónica y no deben ser aceptados por terceros no miembros.

      De hecho, no tiene mucha lógica que los certificados de CERES se puedan validar a través de @firma, ya que al tener convenio, las entidades que confían disponen de diferentes mecanismos de validación, entre los que están los propios servicios OCSP de la FNMT.

      Responder
    2. Javier Peña

      Respecto la primera cuestión yo creo que el tipo de servicios que ofrece @Firma en forma de servicios web está pensado para facilitar el trabajo a la administración.
      Tampoco el proyecto VALIDe es para el usuario final (yo pensaba que si lo sería) pues este proyecto ya es un portal de acceso para hacer comprobaciones de validación. ¿No debería ser este portal público al ciudadano?

      Completando temas pendientes de @firma.
      ¿Cuándo tendremos firmas de larga duración?

      Responder

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s