Social Icons

twitter facebookgoogle pluslinkedinrss feedemail

viernes, 11 de abril de 2014

Rabos de lagartija y EV SSL Certificate Guidelines

Las EV SSL Certificate Guidelines se mueven más un rabo de lagartija.Y aquí acaba la relación entre los rabos de lagartija y las EV SSL Certificate Guidelines.

Con tres revisiones en los últimos tres meses, parece que estamos entrando en una espiral muy preocupante.

Si te parece exagerado, comprueba tú mismo las versiones y las fechas de publicación.

VersiónPublicación
EV SSL Certificate Guidelines Version 1.4.624 March 2014
EV SSL Certificate Guidelines Version 1.4.528 January 2014
EV SSL Certificate Guidelines Version 1.4.413 January 2014

Ya pasó lo mismo con los Baseline Requirements durante la primera mitad del 2013, como ya anticipaba en Las últimas horas del REGLAMENTO europeo eIDAS. Firma electrónica, para entendernos.

¿A quién afecta?

Los más afectados directamente son los Prestadores de Servicios de Certificación (PSC) que, con cada cambio, deben revisar si sus Prácticas y Políticas de Certificación siguen cumpliendo con la nueva versión y, eventualmente, corregirlas, publicarlas y avisar a sus clientes.

En España la cosa es algo peor, porque también se debe avisar al órgano que tenga las competencias de supervisión y control de los PSC's, el Ministerio de Industria, Energía y Turismo (MINETUR.)

En última instancia, a los usuarios. A los usuarios porque se logra justo lo contrario de lo que se pretende: se logra la desconfianza, cuando lo que se pretende es aumentar la seguridad y por tanto, la confianza en las transacciones por Internet.

Cuando se emiten tres versiones en tres meses, uno ya no sabe qué es lo que tiene que cumplir.

¿Por qué ocurre esto?

Los cambios tecnológicos cada son más frecuentes, ocurren más rápido entre uno y el siguiente. Lo mismo ocurre con las vulnerabilidades. El actual paradigma (mmmmm!, cuánto tiempo hacía que no usaba esta palabra tambor!) de desarrollo de aplicaciones se basa en iteraciones muy rápidas, sacando una primera versión con poca funcionalidad (¿y calidad?) para ir refinándola de forma constante.

Los navegadores no son una excepción. En agosto del 2011, Mozilla cambia su filosofía de actualización de Firefox, con el fin de aumentar la frecuencia de las publicaciones.
Su calendario de actualizaciones vigente es:
merge daterelease datecentralaurorabetarelease
2014-04-282014-04-29Firefox 32Firefox 31Firefox 30Firefox 29
2014-06-092014-06-10Firefox 33Firefox 32Firefox 31Firefox 30
2014-07-212014-07-22Firefox 34Firefox 33Firefox 32Firefox 31
2014-09-012014-09-02Firefox 35Firefox 34Firefox 33Firefox 32
2014-10-132014-10-14Firefox 36Firefox 35Firefox 34Firefox 33
2014-11-242014-11-25Firefox 37Firefox 36Firefox 35Firefox 34
En parte, este movimiento de Mozilla parece que, entre otras cosas, podría responder a la presión de Chrome que, con su ciclo contínuo de versiones (entre la versión 1 de diciembre del 2008 y la actualidad, han sacado 33 versiones!!) empezaba a comerse el mercado (como así ha sido.)

Y es que en el CA / Browser Forum, según mi opinión, quién tiene la sartén por el mango son los navegadores y las CAs, Prestadores de Servicios de Certificación o Proveedores de Servicios de Confianza acaban bailando al son que tocan los fabricantes de navegadores.

No obstante, he decir que el funcionamiento interno es totalmente transparente.

¿Qué cambios ha habido?

Los cambios, extraídos de los documentos originales, son los siguientes:

Ver.BallotDescriptionAdoptedEffective*
1.4.4113Revision to QIIS in EV Guidelines13 Jan 201413 Jan 2014
1.4.5114Improvements to the EV Definitions28 Jan 201428 Jan 2014
1.4.61191Remove “OfIncorporation” from OID descriptions in EVG 9.2.5 24 Mar 201424 Mar 2014

Si bien no tienen demasiado impacto (quizá el primero es el que más puede afectar a PSCs - QIIS: Qualified Independent Information Source, fuente de información independiente cualificada, es decir, si quiero saber si Zapatos López, S.A. es la dueña de www.zapatoslopez.es, no vale con que lo diga el sr. López, se han de consultar fuentes independientes que ofrezcan cierto nivel de garantía), el problema es la espiral en la que se puede entrar.

¿Qué se puede hacer?

Una propuesta para nada sofisticada. Se podrían ir acumulando modificaciones menores y tener una política de actualización al menos anual. Un año me parece una solución de compromiso entre la velocidad de los cambios tecnológicos y de ataques y los recursos que los PSC deben dedicar a estar al día con la normativa de referencia. Se podrían planificar los recursos en los presupuestos anuales.

Evidentemente, en casos extremos, como el reciente HeartBleed, si se requiere un cambio inmediato, se realiza una nueva versión, se publica y todos a correr, que es lo que toca en estos casos, pero esto siempre es así, se cambie la normativa o no, pues si el fallo de seguridad compromete la actividad del PSC, no os preocupéis, que no se demorará a solucionarlo hasta que una normativa se lo exige. Le va el negocio en ello.

Y tú, ¿crees que es adecuada la frecuencia de actualización de la "normativa que regula la seguridad en Internet" (como si eso se pudiese regular)?

--
Si este artículo te ha parecido interesante, por favor, compártelo.