Un par de cosas fundamentales:

• La base de una CRL es una promesa para un cierto período de tiempo. Eso significa una hora de inicio y una hora de finalización. Una vez que se hace y firma un CRL, no se puede cambiar, por lo que dura todo el tiempo que dura, y no se puede confiar en él después de eso.

• En esencia, no lo sabrás hasta que lo verifiques. Una CRL en su forma regular es una gran lista. No puede asumir que el tamaño es una indicación ... el verificador debe saber exactamente en qué Certificados ya no se confía. Así que necesitas obtener una copia nueva, de cualquier manera. No hay ningún protocolo para verificar "¿es esto lo mismo que el anterior?"

• La implementación principal de las CRL no es "ir a buscar una cuando la necesite", sino "obtenerla antes de tiempo y verificarla cuando la necesite". Lo que significa que el principal mecanismo de distribución es una serie de descargas de archivos y cachés. Un servidor no sabrá que la próxima CRL es exactamente la misma que la actual CRL hasta que tenga ambas. En ese momento, si tiene una versión nueva, ¿por qué verificar? Si lo que se necesita es un "preguntar cuando lo necesite, siempre tendrá acceso" al tipo de estructura, luego vaya con OSCP.

• El fundamento básico de las fechas de validez es permitir que los implementadores de PKI tomen una decisión consciente acerca de cuánto tiempo se va sin consultar con el emisor de CRL. Un sistema PKI tomará esta decisión emisor por emisor, de acuerdo con el riesgo para el sistema y los patrones de uso previstos. Es un verdadero desafío: la validez debería ser acorde con el riesgo. ¿Cuánto tiempo están dispuestos a esperar los protectores del sistema antes de registrarse en la lista de "conocidos tipos malos"?

• Aquí hay una premisa básica que relaciono con mirar alimentos enlatados en un submarino ... la fecha de vencimiento es por cuánto tiempo el fabricante promete que estará bien consumirlo . ¿Se puede comer carne un día después de la fecha de caducidad? Sí. De hecho, la carne de un día es una opción mucho mejor que morir de hambre. ¿Qué pasa con la carne que es 6 meses después de su fecha de caducidad? Bueno ... ¿contra qué tipo de gérmenes te enfrentas? Existe una posibilidad real de que esta comida lo haga sentir más enfermo que no comer nada (solo cerrar y no hacer transacciones hasta que tenga un CRL nuevo). En todos los casos, la realidad es que usted sopesa el costo de hacer negocios frente al riesgo de datos inciertos.

NOTA: Todo esto se aplica solo a una CRL general de variedades de jardín. Hay una serie de formatos alternativos por ahí. La última vez que miré, todos eran propietarios ... pero ha pasado un tiempo ... algunos de estos formatos alternativos pueden funcionar de manera diferente, ya que todos buscan simplificar.

En el modelo X.509, no hay restricción en descargar . Cuando un verificador (por ejemplo, un navegador web) quiere validar un certificado, intentará obtener información adicional a través de otros objetos: certificados, CRL ... y puede obtener estos objetos a través de canales inseguros. Ese es el punto de la firma de la CRL: un verificador confiará en una CRL no porque la haya obtenido de un sitio web específico, sino porque la CRL está firmada por un emisor de CRL autorizado (generalmente la propia CA) .

El lado positivo de este principio es que hace que los certificados X.509 sean aplicables a todo tipo de redes. De lo contrario, tendría un problema bastante grave de gallina y huevo: ¿cómo confiaría en que obtuvo la información de revocación más reciente y correcta? ¿Porque lo descargaste de un servidor HTTPS? Pero, ¿cómo verificaste el certificado de ese servidor? Y así sucesivamente ...

Pero hay un lado oscuro, por supuesto: una CRL es una instantánea de la información de revocación en una fecha determinada. Al ser firmado, es inmutable. No se puede cambiar. Por lo tanto, siempre es un poco rancio. Un verificador requerirá que la CRL que utiliza "no sea demasiado antigua", y eso, inherentemente, implica la publicación regular de una CRL más reciente.

Desde el punto de vista técnico, podemos imaginar un tipo específico de CRL que no contenga la lista completa de certificados revocados (que pueden ser voluminosos) pero solo un mensaje corto que indica "sin certificado revocado desde esa fecha ", permitiendo así extender de alguna manera la vida útil de una CRL. Esto existe se llama delta CRL . Con la CRL delta, una nueva CRL se emite virtualmente a intervalos regulares, sin forzar necesariamente la descarga de un nuevo archivo grande.

Desafortunadamente, no todo el software que hay por ahí sabe cómo usar el CRL delta.

Otra técnica es segmentación : divide la CRL en muchos archivos más pequeños, cada uno de los cuales habla solo de un subconjunto de certificados. Por ese camino se encuentran CRL muy pequeñas que afirman el estado de revocación de solo un certificado a la vez; esto se conoce como OCSP . Una vez más, el soporte está en la implementación.

¿Qué es crl? ¿Por qué debería revocarse?

De RFC 3280

  

Una lista de revocación de certificados (CRL) es una identificación de lista con marca de tiempo   Certificados revocados firmados por un emisor de CA o CRL y realizados   Disponible gratuitamente en un repositorio público. Cada certificado revocado es   identificado en una CRL por el número de serie de su certificado.

     

Cuando un sistema que utiliza un certificado usa un certificado (por ejemplo, para   verificar la firma digital de un usuario remoto), ese sistema no solo   comprueba el certificado de firma y validez, pero también adquiere un   Adecuadamente reciente CRL y comprueba que el número de serie del certificado es   no en esa CRL.

De RFC 5280

  

El significado de "adecuadamente reciente" puede variar con la política local, pero   por lo general significa la CRLA más reciente emitida en una   base periódica periódica (por ejemplo, por hora, diaria o semanalmente).

     

Se agrega una entrada a la CRL como parte de la próxima actualización siguiente   Notificación de revocación. Una entrada NO DEBE ser eliminada de la CRL   hasta que aparezca en una CRL programada regularmente emitida más allá del   Período de validez del certificado revocado.

     

Una ventaja de este método de revocación es que las CRL pueden ser
  distribuidos por los mismos medios que los certificados,   a saber, a través de servidores no confiables y comunicaciones no confiables.

     

Los CRl se revocarían cuando la clave privada de una clave de encriptación asimétrica   el par (cuya clave pública ha sido certificada por la AC) es robado. En tal   una situación, cualquiera con la clave privada podría descifrar todo   Comunicación entre un usuario y la entidad certificada.

     

Las CRL se emitirán periódicamente, en cuyo caso los certificados que   han caducado pueden ser etiquetados como revocados, o pueden ser emitidos tan pronto   como se revoca un certificado. Para evitar que las CRL se falsifiquen, son   firmado por la clave pública de la CA y contiene una marca de tiempo, después de   los cuales caducan los propios CRL.

Razones para la revocación :

Según ietf los motivos comunes de la revocación fueron:

keyCompromise 
CACompromise 
affiliationChanged 
superseded 
cessationOfOperation 
certificateHold 
removeFromCRL 
privilegeWithdrawn 
AACompromise 

Referencia 2

Referencia 3