¿Por qué se usan las CRL en lugar de las "listas de certificados válidas" y el funcionamiento interno de las CRL?

Primero, tenga en cuenta que X.509 se diseñó en ocasiones, no todos los sistemas estaban en línea todo el tiempo.

El hecho de mantener solo el tamaño pequeño tenía solo números de serie de certificados revocados en una lista de revocación de certificados (CRL). Algunas CA también eliminan los certificados revocados que expiraron en el tiempo de la CRL por exactamente este motivo. Los enfoques más sofisticados para abordar el tamaño de las CRL son las CRL particionadas y las CRL delta.

Hoy en día, muchas implementaciones de PKI favorecen las verificaciones de revocación en línea como OSCP . Al principio, esto también se diseñó para indicar la revocación (a veces se lee de CRL) pero algunos respondedores de OCSP también consultan la base de datos de CA. Incluso hubo un mecanismo de validación remota diseñado llamado SCVP que no está implementado ampliamente. OSCP y otros requieren estrictamente acceso en línea.

Al igual que los certificados X.509, las CRL X.509 también están firmadas por la propia CA o por otra autoridad de revocación delegada (CRL indirectas). Por lo tanto, no es un problema distribuirlos a través de HTTP de texto simple y no autenticado, siempre que el participante que confía valide la firma correctamente. (El uso de HTTPS puede causar problemas de gallina y huevo al verificar el certificado del servidor TLS con una CRL).

Un certificado revocado es una excepción, no la regla. Por lo tanto, acepta todos los certificados como válidos y crea una base de datos con los inválidos, una minoría muy pequeña.

  

haga que cada certificado se firme con una clave separada que se almacena en la base de datos de las CA

Cada certificado ya está firmado con la clave CA. Tener 2 teclas no agrega nada.

  ¿

y si desea revocar el certificado, solo tiene que eliminar su entrada?

Esto aumenta la complejidad. Cada vez que descargue un certificado, deberá conectarse a la CA para preguntar si el certificado sigue siendo válido.

  

¿no crea esto un margen de error (también conocido como la revocación de un certificado de cliente)?

Este proceso debe ser automatizado. Cuando finaliza la cuenta de un usuario, el proceso debe revocar sus cuentas, sus credenciales y sus certificados.

  

pero ¿no debería ser "opcional" el método "no válido hasta que se valide explícitamente"?

Y necesitaría una solución para validar la validación, y una solución para validar la validación validada, y así sucesivamente. Una acción de revocación es mejor que validar y validar nuevamente.

  

¿Por qué el CRL-URI en un certificado de DigiCert es http y no https, no significa que puedo falsificar esta dirección y devolver un "todo está bien y elegante" -CRL al cliente?

Desde el propio Digicert:

  

Está firmado digitalmente por un IA y se emite periódicamente o según sea necesario.

Entonces, no puedes. Si falsifica la dirección y falsifica la CRL, no puede firmar la CRL y nadie creerá que es Digicert.

  

¿No tendría más sentido obligar a las AC a mantener las bases de datos con los certificados que emitieron?

Transparencia del certificado es algo así, pero mejor.

  

¿se ha firmado cada certificado con una clave independiente que se almacena en la base de datos de las entidades emisoras de certificados y si desea revocar el certificado, solo tiene que eliminar su entrada?

¿Cómo es eso mejor que un CRL? Tener una clave separada para cada certificado parece inútil y innecesariamente complicado.

  

Porque si observa casos de uso como certificados de clientes en Apache, por ejemplo, siempre debe realizar un seguimiento de los certificados que emitió (por ejemplo, para cada empleado de una empresa). Una vez que un empleado abandona la empresa, tiene que revocar su certificado.

Este es un caso de uso muy diferente. Con un certificado de cliente, ya lo está enviando a ese servidor Apache, por lo que solo puede consultar su lista de revocaciones locales.

Puede forzar una verificación contra la CA para ver si un certificado sigue siendo válido cada vez que visita un sitio (eso es lo que OCSP is), pero eso viene con muchos de sus propios problemas (aunque muchos de estos problemas se resuelven mediante grapado ) .

  

¿Por qué el CRL-URI en un certificado de DigiCert es http y no https, no significa que puedo falsificar esta dirección y devolver un "todo está bien y elegante" -CRL al cliente?

Está firmado de todos modos , por lo que ya se proporciona autenticidad, y la confidencialidad no es realmente necesaria.

Tenemos que usar las herramientas para hacer la revocación correctamente: el grapado de OCSP combinado con Must-Staple (que indica a los navegadores que no deben fallar en su defecto si falta OCSP). El problema real es que nadie los implementa correctamente .

Las CRL están diseñadas para ser descargadas por quienquiera que necesite verificar la revocación. Obtener la lista de todos los certificados válidos de la AC en lugar de obtener solo la lista de los revocados supondría una gran diferencia y lo que sería necesario descargar.

Además, las CRL están diseñadas para el almacenamiento en caché y tienen un tipo de caducidad donde se debe descargar una nueva CRL. Si bien es aceptable no detectar un certificado revocado por poco tiempo (hasta la actualización de la CRL), sería inaceptable no aceptar un certificado válido hasta la próxima actualización de la lista de certificados válidos.

  

... siempre debe realizar un seguimiento de los certificados que emitió

La CRL no contiene el certificado completo, solo su número de serie. Por lo tanto, una CA solo necesita saber el número de serie para que se revoque el certificado específico y no necesita realizar un seguimiento del certificado completo.

  

¿Por qué el CRL-URI en un certificado de DigiCert es http y no https, no significa que puedo falsificar esta dirección y devolver un "todo está bien y elegante" -CRL al cliente?

Las CRL están firmadas, por lo que no es posible falsificar una CRL a menos que la clave privada del emisor de la CRL (es decir, la CA) sea robada.