La lista de revocación de certificados es una lista de certificados que la autoridad de certificación ha marcado como revocados . Las listas de revocación de certificados (CRL) se utilizan para determinar si el certificado de un usuario o de una CA ha sido revocado debido a una clave comprometida. Una propiedad importante de COS es que contiene información solo sobre certificados que no han caducado.
La historia de la creación de PKI ( Infraestructura de clave pública ) se remonta al trabajo original de Whitfield Diffie y Martin Hellman sobre criptografía de clave pública , que propone un directorio de archivos públicos que los usuarios pueden usar para encontrar las claves públicas de otros usuarios.
Al darse cuenta de algunas de las desventajas de este enfoque, incluido que deshabilitar el acceso al directorio impediría que los usuarios se comunicaran de manera segura, Confelder propuso el concepto de certificados en 1978. Los certificados separan la funcionalidad de firma y búsqueda, lo que permite que una CA asocie un nombre con una clave mediante una firma digital y luego almacene el certificado resultante en un repositorio. Debido a que el almacenamiento se puede replicar y hacer tolerante a fallas, el enfoque de CA elimina muchos de los problemas asociados con la durabilidad del directorio.
Unos años después de que Confelder publicara su disertación, los desarrolladores incorporaron el uso del certificado en X.500 , un directorio global de entidades nombradas operado por compañías de telecomunicaciones monopólicas. El directorio X.500 propone un modelo de base de datos jerárquico, con una ruta a través del directorio definida por una serie de componentes de Nombre Distinguido Relativo (RDN), que juntos forman un Nombre Distinguido (DN). Para proteger el acceso al directorio, sus desarrolladores han propuesto varios mecanismos de control de acceso, que van desde simples medidas basadas en contraseñas hasta un enfoque relativamente nuevo para el uso de firmas digitales. Este estándar, incluido en X.500 , era el estándar X.509v1 . Actualmente existe una versión x.509v3.
Los desarrolladores basaron el concepto de SOS en listas negras de tarjetas de crédito que se utilizaron en la década de 1970. Las compañías de tarjetas de crédito imprimían periódicamente folletos con números de tarjetas cancelados y los distribuían a los comerciantes, con la expectativa de que verificaran todas las tarjetas con las que trataban en la lista negra antes de aceptarlas. Los mismos problemas que afectaron la lista negra de tarjetas de crédito afectan a SOS hoy.
La autoridad de certificación emite periódicamente un listado que publica en el repositorio. Cada COS incluye un campo nextUpdate que indica la hora en que se lanzará el próximo COS. Cualquier usuario de confianza que necesite información sobre el estado del certificado y aún no tenga una CRL actual obtiene la lista actual del almacén. Si el certificado que el cliente está verificando no está en la lista, el trabajo continúa normalmente y la clave se considera un certificado validado. Si el certificado está presente, la clave se considera no válida y no se puede confiar en ella.
Para mejorar el rendimiento, las copias de la CRL se pueden distribuir en varias tiendas. Cada usuario de confianza necesita la lista más actualizada para realizar la verificación. Una vez que una parte confiante recibe el SOS más reciente, no necesitará solicitar información adicional del repositorio hasta que se emita un nuevo SOS. Como resultado, durante el período de tiempo durante el cual el COS es válido (es decir, el más actual), cada parte que confía no enviará más de una solicitud al almacenamiento para el COS. Esta solicitud se realizará por primera vez después de que se publique el SOS actual.
También hay un mecanismo delta-SOS, que es un mecanismo opcional especificado en RFC 2459 que se puede utilizar para mejorar la propagación de la información de revocación. Las CRL delta tienen un tamaño relativamente pequeño y contienen solo los cambios en las listas de revocación de certificados que han tenido lugar desde que la CA compiló la última versión de la lista absoluta (CRL completa). Debido a que las delta-CRL son pequeñas, los clientes de PKI pueden descargarlas con más frecuencia que las CRL completas, por lo que la CA brinda a sus clientes información más precisa sobre los certificados revocados.
Algunos problemas dificultan el trabajo con SOS. COS es, en algunos casos, poco fiable como mecanismo para propagar el estado del certificado. Las aplicaciones críticas requieren una revocación inmediata, o más específicamente, información del estado del certificado en tiempo real, y las CRL no siempre resuelven este problema básico por varias razones.
Los principales problemas de SOS:
SOS sufre de varios otros problemas prácticos. Para garantizar actualizaciones de estado oportunas, el servidor debe emitir un SOS con la mayor frecuencia posible. Sin embargo, emitir un SOS aumenta la carga sobre el servidor y la red que lo transmite, y en menor medida sobre el cliente que lo recibe. Por ejemplo, 10 millones de clientes descargan 1 MB de SOS emitido una vez por minuto = tráfico ~ 150 GB/s. Por lo tanto, es una operación costosa. Emitir un SOS una vez por minuto proporciona una revocación moderadamente oportuna a expensas de una gran sobrecarga, ya que cada parte de confianza descarga un nuevo SOS (en muchos casos, esta tarea recae en Delta SOS y el problema se resuelve). Por otro lado, retrasar la emisión a una hora o un día no asegura la revocación oportuna, siempre que algunos certificados hayan sido revocados durante este período.
Las CRL también carecen de mecanismos para cobrar a las partes que confían por verificar la revocación. Cuando una autoridad de certificación emite un certificado, cobra una tarifa al usuario. La cantidad que cobra una CA generalmente depende de cuánto verifica antes de emitir un certificado. Por otro lado, los usuarios esperan que las CA creen y emitan SOC de forma gratuita. Ni el usuario ni la CA pueden decir de manera inequívoca quién verificará el certificado, con qué frecuencia se verificará o qué demora será aceptable. Esta situación sirve como elemento disuasorio activo para que las CA se concentren en gran medida en SOS, ya que requieren tiempo de procesamiento, uno o más servidores y un ancho de banda de red significativo para crearlos y distribuirlos.
Por el momento, hay varios análogos de SOS que no tienen las desventajas de SOS, pero al mismo tiempo tienen las suyas.
Uno de los análogos es OCSP - Protocolo de estado de certificado en línea . Esta solución proporciona una respuesta en tiempo real del servidor sobre ese certificado solicitado en particular. Este enfoque resuelve muchos de los problemas inherentes a SOS al crear un SOS único y nuevo con una sola entrada por solicitud. Por el contrario, el modelo basado en COS requiere que las partes de confianza obtengan repetidamente una gran cantidad de registros irrelevantes para obtener información de estado para el certificado que necesitan. Sin embargo, OCSP tiene un costo. En lugar de preparar el COS como una operación fuera de línea en segundo plano, la CA ahora debe realizar una operación de búsqueda de certificados y generación de pseudo-COS para cada solicitud. Para que OCSP sea rentable, la CA debe cobrar una tarifa por cada verificación de revocación. OCSP resuelve este problema mediante la firma de solicitudes de identificación del remitente con fines de facturación.
Este método también tiene sus inconvenientes. La principal desventaja de OCSP es que en lugar de una simple respuesta de sí o no a una solicitud de validez, utiliza varios valores de estado de certificado no ortogonales , ya que no puede dar una respuesta verdaderamente precisa. Esta ambigüedad se deriva, al menos en parte, del mecanismo original de estado del certificado basado en COS. Dado que el COS solo puede proporcionar un resultado negativo, el hecho de que un certificado no esté presente en el COS no significa que haya sido emitido alguna vez o que siga siendo válido.
El principal problema con los enfoques basados en listas negras como COS y OCSP es que hacen la pregunta equivocada. En lugar de preguntar "¿El certificado es actualmente válido?" preguntan "¿El certificado está revocado?" porque esa es la única pregunta que puede responder una lista negra.
OCSP también expone el historial de conexión del cliente a un tercero (CA).
El grapado OCSP es grapado OCSP Elimina la necesidad de volver a enviar la solicitud OCSP emitiendo una respuesta OCSP junto con el propio certificado. Esto se denomina Grapado OCSP porque el servidor debe "grapar" la respuesta OCSP con el certificado y emitirlos juntos. Cuando se establece una conexión, el servidor envía su cadena de certificados al cliente junto con las respuestas OCSP correspondientes. La respuesta OCSP solo es válida por un período corto de tiempo y está firmada por una CA de la misma manera que un certificado. Esto también elimina el problema de privacidad de OCSP, ya que el encuestado no tiene acceso a los detalles de los visitantes del sitio web. No está ampliamente implementado, solo el 3% de los servidores admiten el grapado OCSP.
Una posible aplicación de la infraestructura de clave pública es HTTPS . Muchos navegadores utilizan 2 enfoques principales: SOS y OCSP. Mozilla Firefox no descarga automáticamente el SOS. El navegador usa OCSP para verificar si el certificado ha sido revocado. Internet Explorer y Opera hacen un trabajo mucho más completo; ambos admiten OCSP y CRL y realizan comprobaciones adecuadas para todos los tipos de certificados. Pero SOS se usa principalmente como alternativa en esta prueba.
Un área importante de aplicación de PKI, y SOS en particular, es la firma electrónica . El certificado certifica que las claves pública y privada pertenecen a su propietario. Revocar el certificado significa que la clave ha sido comprometida .
El algoritmo de verificación es el siguiente: