En criptografía , una lista de revocación de certificados (o CRL ) es "una lista de certificados digitales que han sido revocados por la autoridad de certificación (CA) emisora antes de su fecha de vencimiento programada y ya no deben ser confiables". [1]
Estados de revocación
Hay dos estados diferentes de revocación definidos en RFC 5280:
- Revocado
- Un certificado se revoca de forma irreversible si, por ejemplo, se descubre que la autoridad certificadora (CA) ha emitido un certificado de forma incorrecta, o si se cree que una clave privada ha sido comprometida. Los certificados también pueden revocarse si la entidad identificada no cumple con los requisitos de la política, como la publicación de documentos falsos, la tergiversación del comportamiento del software o la violación de cualquier otra política especificada por el operador de CA o su cliente. La razón más común para la revocación es que el usuario ya no está en posesión exclusiva de la clave privada (por ejemplo, el token que contiene la clave privada se perdió o fue robado).
- Mantener
- Este estado reversible se puede utilizar para anotar la invalidez temporal del certificado (por ejemplo, si el usuario no está seguro de si se ha perdido la clave privada). Si, en este ejemplo, se encontró la clave privada y nadie tuvo acceso a ella, el estado podría restablecerse y el certificado volverá a ser válido, eliminando así el certificado de futuras CRL.
Razones para la revocación
Las razones para revocar un certificado según RFC 5280 [2] son:
unspecified
(0)keyCompromise
(1)cACompromise
(2)affiliationChanged
(3)superseded
(4)cessationOfOperation
(5)certificateHold
(6)removeFromCRL
(8)privilegeWithdrawn
(9)aACompromise
(10)
Tenga en cuenta que el valor 7 no se utiliza.
Publicar listas de revocación
Una CRL se genera y publica periódicamente, a menudo en un intervalo definido. Una CRL también se puede publicar inmediatamente después de que se haya revocado un certificado. Una CRL es emitida por un emisor de CRL, que normalmente es la CA que también emitió los certificados correspondientes, pero alternativamente podría ser alguna otra autoridad de confianza. Todas las CRL tienen una vida útil durante la cual son válidas; este período de tiempo suele ser de 24 horas o menos. Durante el período de validez de una CRL, una aplicación habilitada para PKI puede consultarla para verificar un certificado antes de su uso.
Para evitar ataques de suplantación de identidad o de denegación de servicio , las CRL suelen llevar una firma digital asociada con la CA mediante la cual se publican. Para validar una CRL específica antes de confiar en ella, se necesita el certificado de su CA correspondiente.
Los certificados para los que se debe mantener una CRL suelen ser certificados de clave pública / X.509 , ya que este formato se usa comúnmente en los esquemas PKI.
Revocación versus vencimiento
Las fechas de vencimiento no sustituyen a una CRL. Si bien todos los certificados vencidos se consideran inválidos, no todos los certificados no vencidos deben ser válidos. Las CRL u otras técnicas de validación de certificados son una parte necesaria de cualquier PKI que funcione correctamente, ya que se espera que se produzcan errores en la verificación de certificados y la gestión de claves en las operaciones del mundo real.
En un ejemplo digno de mención, un certificado de Microsoft se emitió por error a una persona desconocida, que se había hecho pasar por Microsoft a la CA contratada para mantener el sistema de "certificado de editor" ActiveX ( VeriSign ). [3] Microsoft vio la necesidad de parchear su subsistema de criptografía para que verificara el estado de los certificados antes de confiar en ellos. Como solución a corto plazo, se emitió un parche para el software de Microsoft relevante (más importante, Windows) que enumera específicamente los dos certificados en cuestión como "revocados". [4]
Problemas con las listas de revocación de certificados
Las mejores prácticas requieren que donde sea y como sea que se mantenga el estado del certificado, se debe verificar siempre que se desee confiar en un certificado. De lo contrario, un certificado revocado puede aceptarse incorrectamente como válido. Esto significa que para utilizar una PKI de forma eficaz, se debe tener acceso a las CRL actuales. Este requisito de validación en línea niega una de las principales ventajas originales de la PKI sobre los protocolos de criptografía simétrica , a saber, que el certificado es de "autenticación automática". Los sistemas simétricos como Kerberos también dependen de la existencia de servicios en línea (un centro de distribución de claves en el caso de Kerberos).
La existencia de una CRL implica la necesidad de que alguien (o alguna organización) haga cumplir la política y revoque los certificados que se consideren contrarios a la política operativa. Si un certificado se revoca por error, pueden surgir problemas importantes. Dado que la autoridad certificadora tiene la tarea de hacer cumplir la política operativa para la emisión de certificados, normalmente son responsables de determinar si la revocación es apropiada y cuándo es apropiada mediante la interpretación de la política operativa.
La necesidad de consultar una CRL (u otro servicio de estado de certificado) antes de aceptar un certificado genera un posible ataque de denegación de servicio contra la PKI. Si la aceptación de un certificado falla en ausencia de una CRL válida disponible, no se pueden realizar operaciones que dependan de la aceptación del certificado. Este problema también existe para los sistemas Kerberos, donde la falta de recuperación de un token de autenticación actual impedirá el acceso al sistema.
Una alternativa al uso de CRL es el protocolo de validación de certificados conocido como Protocolo de estado de certificado en línea (OCSP). OCSP tiene el beneficio principal de requerir menos ancho de banda de red, lo que permite verificaciones de estado en tiempo real y casi en tiempo real para operaciones de alto volumen o valor.
A partir de Firefox 28, Mozilla ha anunciado que está desaprobando la CRL a favor de OCSP. [5]
Los archivos CRL pueden crecer bastante con el tiempo, por ejemplo, en el gobierno de EE. UU., Para determinadas instituciones, varios megabytes. Por lo tanto, las CRL incrementales se han diseñado [6] a veces denominadas "CRL delta". Sin embargo, solo unos pocos clientes los implementan. [7]
Listas de revocación de autoridad
Una lista de revocación de autoridad (ARL) es una forma de CRL que contiene certificados revocados emitidos a las autoridades de certificación , contrariamente a las CRL que contienen certificados de entidad final revocados. [8] [9]
Ver también
Referencias
- ^ "¿Qué es la lista de revocación de certificados (CRL)? - Definición de WhatIs.com" . TechTarget . Consultado el 26 de octubre de 2017 .
- ^ "RFC 5280" . tools.ietf.org . IETF. pag. 69. sección 5.3.1, Código de motivo . Consultado el 9 de mayo de 2019 .
- ^ Robert Lemos. "Microsoft advierte de certificados secuestrados - CNET News" . News.cnet.com . Consultado el 9 de mayo de 2019 .
- ^ "Boletín de seguridad de Microsoft MS01-017: los certificados digitales emitidos por VeriSign erróneos plantean un peligro de suplantación" . Technet.microsoft.com. 2018-07-20 . Consultado el 9 de mayo de 2019 .
- ^ "A partir de Firefox 28, Firefox no obtendrá las CRL durante la validación del certificado EV" . groups.google.com .
- ^ "RFC 5280 - Certificado de infraestructura de clave pública de Internet X.509 y perfil de lista de revocación de certificados (CRL)" . Tools.ietf.org . Consultado el 9 de mayo de 2019 .
- ^ Archiveddocs (20 de marzo de 2018). "Configurar períodos de superposición de CRL y Delta CRL" . Microsoft Docs . Consultado el 25 de junio de 2020 .
- ^ IBM (4 de febrero de 2021). "Configuración de servidores LDAP" . Centro de conocimiento de IBM . Consultado el 18 de febrero de 2021 .
- ^ IBM. "Creación de un punto de distribución ARL" . Centro de conocimiento de IBM . Consultado el 18 de febrero de 2021 .