Dificultades expandiendo la firma electrónica

Nosotros en isigma tenemos una meta muy clara: que todo el mundo pueda firmar electrónicamente. Lo podemos llamar «signature made easy», «popularizando la firma electrónica» o como queramos, pero el objetivo es claro.

Pero con los navegadores hemos topado. Y no es que pongan dificultades porque sí. Generalmente están justificadas, lo que ocurre es que cada uno pone unas y dificultan mucho a los Prestadores de Servicios de Certificación (PSCs) definir unos perfiles de certificados y unos servicios de validación que funcionen correctamente con las soluciones de mercado, mayormente Microsoft (r) Internet Explorar y Firefox.

Desde isigma colaboramos con varios de estos PSCs en la inclusión de sus certificados en los

navegadores más extendidos (y otras aplicaciones.)

¿Y eso para qué sirve?

Básicamente para que cuando se trata de utilizar un certificado en una aplicación web no aparezca un aviso del navegador de que «no se confía en el certificado», lo que produce pavor en los usuarios y directamente no utilizan la aplicación.

Internet Explorer

Hace unos años, para que Microsoft cargara el certificado raíz del PSC y tantos certificados subordinados como quisieses, «bastaba» con pasar una auditoríaWebTrust for CA. «bastaba» entrecomillado pues no es baladí pasar esta auditoría y además cuesta unos buenos dineros. Pero con esto bastaba.

En la actualidad, aunque no es un requisito, es recomendable tener vigente una auditoría WebTrust o una sobre la ETSI y Microsoft sólo carga certificados raíz.

¿Y eso qué implica?

La mayoría de los PSCs tienen al menos una jerarquía de certificación de dos niveles, esto es, hay un primer nivel llamado Autoridad (o entidad) de Certificación raíz – AC raíz – (cuyas claves están extremadamente protegidas y suelen ser servicios off-line), un segundo  o más niveles de Autoridades de Certificación subordinadas – AC sub -, que emiten los certificados de entidad final (mi certificado, el certificado de la web de Hacienda, el certificado con el que isigma firma sus desarrollos, etc.)

La jerarquía de certificación del DNIe tiene dos niveles, como se puede apreciar en la web de zonatic. En cambio la jerarquía de la Agència Catalana de Certificació – CATCert tiene tres.

Si el navegador tiene cargado el certificado de la AC raíz y mi certificado lo emite una AC sub (de cuyo certificado NO dispone el navegador), el navegador no puede construir la cadena de confianza (es decir, enlazar cada certificado con su «padre») y nos da el mismo error (¡y eso que el PSC ha hecho los esfuerzos para que su certificado raíz esté en el navegador!)

Solución

Dos posibilidades. O cada usuario se instala a mano el certificado de la Autoridad de Certificación Subordinada en su navegador (para todo navegador y para toda AC sub de las que tenga certificados). Esto es inviable, el ciudadano no tiene conocimientos de certificación digital y además no tiene porqué tenerlos!

La otra posibilidad es usar una extensión de los certificados llamada Authority Information Access (AIA), que permite a la aplicaciones «buscar en la red» el certificado de la AC firmante (ya sea raíz o sub.) Esta solución también tiene sus pegas: primera, que todos los certificados emitidos hasta la fecha, no contarán con esta extensión (un certificado emitido no se puede modificar) y segunda que obliga a los PSCs a modificar los perfiles de sus certificados futuros. Pero es lo que hay.

Mozilla Firefox

Hace también unos años (los mismos), ayudamos a un PSC a que se cargasen sus certificados de AC en Mozilla Firefox y la cuestión se resolvió en tres meses escasos.

Hoy en día es necesario alrededor de cuatro o cinco veces más de tiempo para lograr lo mismo, entre otras razones porque Mozilla tarda muchísimo en poner en fase de discusión pública la inclusión de un certificado, porque cada vez son más exigentes con los procedimientos de los PSCs.

Además, igual que Microsoft, sólo cargan las AC raíz…¡¡y hacen caso omiso de la extensión AIA!!

Y para mayor dificultad de los PSCs, realizan una validación del estado de certificados mediante el protocolo OCSP un poco peculiar, que está obligando a los PSCs españoles que tiene varias AC sub a publicar tantos servicios OCSP como AC sub, cuando con uno podría bastar.

En fin que los PSCs están condenados a seguir invirtiendo recursos y tiempo en que los certificados que emiten trabajen de forma «transparente» con los navegadores, y los ciudadanos de a pie a aprender un poquito de certificación digital.

Quizá la interoperabilidad debería definirse desde el usuario final (ciudadano de a pie) hacia arriba, quizá no nos estaríamos preguntando porqué no se implanta la facturación electrónica en la PyMEs o porqué no se usa el DNI electrónico (como nos preguntamos nosotros aquí, aquí, aquí, aquí y aquí, ¡uff!)