En busca de la validación
El estándar emergente OCSP (Online Certificate Status Protocol) ofrece validación de certificados en tiempo real, necesaria para cualquier sitio de comercio electrónico de alto nivel.
Imaginemos un sitio Web que opera transacciones online de compraventa de divisas y que, lógicamente, cuenta con una infraestructura de clave pública para distribuir certificados con fines de autenticación. Cuando los clientes acceden al sitio, sus navegadores presentan los certificados y, en función de esta información, se les permite realizar órdenes. Como el sistema soporta transacciones por valor de millones de pesetas, dólares, euros y otras monedas, los certificados tienen un periodo de validez de seis meses, en vez de un año, como es lo más común.
Ahora supongamos que una de las compañías clientes rechaza a un comerciante dudoso cuyo certificado es válido aún durante tres meses. Para asegurarse de que dicho comerciante ya no tiene acceso se utiliza un procedimiento llamado revocación de certificado, por el que es declarado inválido antes de que expire.
El mecanismo básico de revocación es el conocido como CRL (Certificate Revocation List), que consiste en una lista firmada digitalmente de certificados revocados que no han expirado. La autoridad certificadora, es decir, la agencia que ha originado el certificado, se encarga de publicarla periódicamente.
MAS ALLA DE LAS LISTAS DE REVOCACION
Pero las CRL presentan algunos inconvenientes. Por ejemplo, no operan en tiempo real; de hecho, muchas autoridades de certificación editan las CRL sólo una vez al día, algo que sería inaceptable en el caso expuesto. Además, no es suficiente con incluir un certificado en la lista. La aplicación que precisa de la certificación debe chequear la CRL en cada operación, lo que resulta problemático por muchas razones. La primera es que la CRL rápidamente se hace inmanejable. Cada autoridad certificadora mantiene sólo una lista para cada certificado raíz, o certificado de alto nivel bajo el cual se publican otros muchos certificados individuales. Y las CRL son acumulativas: cada certificado revocado es añadido a la lista, donde se guarda hasta que expire.
Así, las CRL crecen enormemente. Por ejemplo, las CRL para algunos certificados raíces publicados por VeriSign (http://crl.verisign.com) pueden tener un tamaño de megabytes. Si una autoridad certificadora utiliza un único certificado raíz por cada certificado individual que publica, como puede ser el caso cuando una corporación es su propia autoridad de certificación, entonces todos los certificados revocados podrían ser listados en una CRL.
Por tanto, compilar, firmar, transmitir, publicar y procesar una CRL implica un largo proceso que consume potencia de CPU. En el peor de los casos, la culminación de esta tarea puede llevar varios segundos. El tiempo y los recursos crecen exponencialmente cuando un sitio Web debe chequear certificados en múltiples autoridades de certificación, como puede suceder después de una fusión de compañías que usan diferentes PKI.
Otro inconveniente consiste en que las autoridades certificadoras actualizan sus CRL sobrescribiendo el fichero previo, sin mantener datos históricos.
APLICACIONES B2C Y B2B
nte tal situación, no es de extrañar que las empresas demanden un mecanismo que permita a las aplicaciones verificar rápidamente la validez de un certificado en tiempo real. Y esto es justo lo que ya ofrece Online Certificate Status Protocol (OCSP), estandarizado por el IETF (Internet Engineering Task Force) en junio de 1999. OCSP hace posible seleccionar productos PKI y de validación independientes, si bien ahora sólo se está comenzando su implementación.
En un sistema basado en OCSP, cuando un certificado necesita validación, la aplicación pasa una petición a un servidor OCSP (responder en inglés), como Validation TrustPlatform de KiberPass o Validation Authority de ValiCert. El servidor verifica entonces el certificado, informando al cliente si ha sido o no revocado. Estos servidores OCSP, que son vendidos como paquetes independientes o integrados en soluciones PKI, pueden entrar en contacto con otros servidores remotos situados en las instalaciones de las autoridades certificadoras.
Dadas sus ventajas, parece claro que el chequeo de estado online debería ser parte de cualquier aplicación que dependa de certificados para las tareas de autenticación y autorización, así como de las arquitecturas basadas en certificados. Por tanto, OCSP –actualmente en su version 1– jugará pronto un papel destacado en el comercio electrónico, tanto B2B como B2C, al permitir a las partes implicadas en una transacción online estar realmente seguras del estado de las certificaciones que se están utilizando en la operación.
¿SCVP o OCSP v.2?
---------------------------
Internet Engineering Task Force definió OCSP versión 1 en RFC 2560 y actualmente ya trabaja en la versión 2. Esta nueva versión añadirá la posibilidad de solicitar información sobre el estado de un certificado en el pasado, una característica de Certificate Revocation Lists (CRL) que el actual estándar no soporta. La nueva versión, además, trata la validación de certificados de atributos. Los atributos permiten separar la información de autenticación, almacenada en un certificado utilizado para obtener acceso, de la información de autorización, almacenada en un certificado distinto que identifica los servicios específicos que pueden ser accedidos.
Sin embargo, algunos analistas de la industria afirman que extender la funcionalidad de OCSP, como propone la versión 2, convertirá innecesariamente en complicado un protocolo ahora bastante simple. De esta opinión es el propio editor de RFC 2560, Ambarish Malpani, que propone la alternativa SCVP (Simple Certificate Validation Protocol) como un modo de conseguir características adicionales a OCSP, cuya extensión estima que podría perjudicar su despliegue.
SCVP –todavía en proceso de borrador en el seno de IETF– no sólo amplía las funciones de validación a los atributos, como se propone en la versión 2 de OCSP, sino que va más allá, al permitir contestar, además de a la simple cuestión de si el certificado es válido, a la más compleja de si es válido para un propósito concreto. Asimismo, simplifica las tareas que el cliente debe realizar para validar un certificado, pasando al servidor el potencialmente complejo proceso de construir tales cadenas de certificados. Así, el software cliente se hace más ligero y más indicado para, por ejemplo, dispositivos inalámbricos. Lógicamente, en contrapartida el software servidor se hace más complejo.
Aunque todavía no está claro si los fabricantes soportarán OCSP Version 2 y SCVP, o si aparecerá un nuevo estándar que aglutine a los dos, es cierto que OCSP Version 1 tiene por delante un gran futuro y contribuirá a potenciar el despliegue de soluciones basadas en PKI.
OCSP en acción
----------------------
Online Certificate Status Protocol permite a una aplicación validar un certificado en tiempo real. Aquí se muestra cómo OCSP podría funcionar con una aplicación comercial online.
1- Un comerciante inicia una conexión al servidor Web de un
Imaginemos un sitio Web que opera transacciones online de compraventa de divisas y que, lógicamente, cuenta con una infraestructura de clave pública para distribuir certificados con fines de autenticación. Cuando los clientes acceden al sitio, sus navegadores presentan los certificados y, en función de esta información, se les permite realizar órdenes. Como el sistema soporta transacciones por valor de millones de pesetas, dólares, euros y otras monedas, los certificados tienen un periodo de validez de seis meses, en vez de un año, como es lo más común.
Ahora supongamos que una de las compañías clientes rechaza a un comerciante dudoso cuyo certificado es válido aún durante tres meses. Para asegurarse de que dicho comerciante ya no tiene acceso se utiliza un procedimiento llamado revocación de certificado, por el que es declarado inválido antes de que expire.
El mecanismo básico de revocación es el conocido como CRL (Certificate Revocation List), que consiste en una lista firmada digitalmente de certificados revocados que no han expirado. La autoridad certificadora, es decir, la agencia que ha originado el certificado, se encarga de publicarla periódicamente.
MAS ALLA DE LAS LISTAS DE REVOCACION
Pero las CRL presentan algunos inconvenientes. Por ejemplo, no operan en tiempo real; de hecho, muchas autoridades de certificación editan las CRL sólo una vez al día, algo que sería inaceptable en el caso expuesto. Además, no es suficiente con incluir un certificado en la lista. La aplicación que precisa de la certificación debe chequear la CRL en cada operación, lo que resulta problemático por muchas razones. La primera es que la CRL rápidamente se hace inmanejable. Cada autoridad certificadora mantiene sólo una lista para cada certificado raíz, o certificado de alto nivel bajo el cual se publican otros muchos certificados individuales. Y las CRL son acumulativas: cada certificado revocado es añadido a la lista, donde se guarda hasta que expire.
Así, las CRL crecen enormemente. Por ejemplo, las CRL para algunos certificados raíces publicados por VeriSign (http://crl.verisign.com) pueden tener un tamaño de megabytes. Si una autoridad certificadora utiliza un único certificado raíz por cada certificado individual que publica, como puede ser el caso cuando una corporación es su propia autoridad de certificación, entonces todos los certificados revocados podrían ser listados en una CRL.
Por tanto, compilar, firmar, transmitir, publicar y procesar una CRL implica un largo proceso que consume potencia de CPU. En el peor de los casos, la culminación de esta tarea puede llevar varios segundos. El tiempo y los recursos crecen exponencialmente cuando un sitio Web debe chequear certificados en múltiples autoridades de certificación, como puede suceder después de una fusión de compañías que usan diferentes PKI.
Otro inconveniente consiste en que las autoridades certificadoras actualizan sus CRL sobrescribiendo el fichero previo, sin mantener datos históricos.
APLICACIONES B2C Y B2B
nte tal situación, no es de extrañar que las empresas demanden un mecanismo que permita a las aplicaciones verificar rápidamente la validez de un certificado en tiempo real. Y esto es justo lo que ya ofrece Online Certificate Status Protocol (OCSP), estandarizado por el IETF (Internet Engineering Task Force) en junio de 1999. OCSP hace posible seleccionar productos PKI y de validación independientes, si bien ahora sólo se está comenzando su implementación.
En un sistema basado en OCSP, cuando un certificado necesita validación, la aplicación pasa una petición a un servidor OCSP (responder en inglés), como Validation TrustPlatform de KiberPass o Validation Authority de ValiCert. El servidor verifica entonces el certificado, informando al cliente si ha sido o no revocado. Estos servidores OCSP, que son vendidos como paquetes independientes o integrados en soluciones PKI, pueden entrar en contacto con otros servidores remotos situados en las instalaciones de las autoridades certificadoras.
Dadas sus ventajas, parece claro que el chequeo de estado online debería ser parte de cualquier aplicación que dependa de certificados para las tareas de autenticación y autorización, así como de las arquitecturas basadas en certificados. Por tanto, OCSP –actualmente en su version 1– jugará pronto un papel destacado en el comercio electrónico, tanto B2B como B2C, al permitir a las partes implicadas en una transacción online estar realmente seguras del estado de las certificaciones que se están utilizando en la operación.
¿SCVP o OCSP v.2?
---------------------------
Internet Engineering Task Force definió OCSP versión 1 en RFC 2560 y actualmente ya trabaja en la versión 2. Esta nueva versión añadirá la posibilidad de solicitar información sobre el estado de un certificado en el pasado, una característica de Certificate Revocation Lists (CRL) que el actual estándar no soporta. La nueva versión, además, trata la validación de certificados de atributos. Los atributos permiten separar la información de autenticación, almacenada en un certificado utilizado para obtener acceso, de la información de autorización, almacenada en un certificado distinto que identifica los servicios específicos que pueden ser accedidos.
Sin embargo, algunos analistas de la industria afirman que extender la funcionalidad de OCSP, como propone la versión 2, convertirá innecesariamente en complicado un protocolo ahora bastante simple. De esta opinión es el propio editor de RFC 2560, Ambarish Malpani, que propone la alternativa SCVP (Simple Certificate Validation Protocol) como un modo de conseguir características adicionales a OCSP, cuya extensión estima que podría perjudicar su despliegue.
SCVP –todavía en proceso de borrador en el seno de IETF– no sólo amplía las funciones de validación a los atributos, como se propone en la versión 2 de OCSP, sino que va más allá, al permitir contestar, además de a la simple cuestión de si el certificado es válido, a la más compleja de si es válido para un propósito concreto. Asimismo, simplifica las tareas que el cliente debe realizar para validar un certificado, pasando al servidor el potencialmente complejo proceso de construir tales cadenas de certificados. Así, el software cliente se hace más ligero y más indicado para, por ejemplo, dispositivos inalámbricos. Lógicamente, en contrapartida el software servidor se hace más complejo.
Aunque todavía no está claro si los fabricantes soportarán OCSP Version 2 y SCVP, o si aparecerá un nuevo estándar que aglutine a los dos, es cierto que OCSP Version 1 tiene por delante un gran futuro y contribuirá a potenciar el despliegue de soluciones basadas en PKI.
OCSP en acción
----------------------
Online Certificate Status Protocol permite a una aplicación validar un certificado en tiempo real. Aquí se muestra cómo OCSP podría funcionar con una aplicación comercial online.
1- Un comerciante inicia una conexión al servidor Web de un
