Una CRL tiene valor, y es aceptable, en virtud de estar firmada . Dado que la CRL está firmada, su obtención no tiene ninguna importancia en cuanto a su aceptabilidad. Ese es el punto de los certificados y CRL: pueden distribuirse a través de redes arbitrarias, protegidas o no, incluso HTTP simple, correo electrónico, transportistas avia ... no importa.
A la inversa, que la CRL está "en línea" no lo hace mejor; Aún tiene que verificar la firma, las fechas, etc.
Por lo tanto, la CRL (o los certificados, o las respuestas de OCSP) pueden integrarse perfectamente, transmitirse junto con los datos que califican, o lo que sea. Por ejemplo, un objeto CMS (PKCS # 7) SignedData contiene campos llamados certificates y crls precisamente para incrustar certificados y CRL (y respuestas OCSP) que los receptores de tal objeto pueden encontrar útiles para fines de validación. De manera similar, cuando un servidor SSL / TLS envía su certificado, también envía algunos certificados adicionales (una "cadena") que el cliente puede usar (en su tiempo libre) para validar el certificado del servidor.
Cuando una CA divide la CRL en múltiples sub-CRL, el alcance de cada CRL se indica explícitamente: un certificado está en el alcance de una CRL si el certificado contiene una extensión (crítica) CRL Distribution Points con un "Punto de distribución "que coincide con la extensión Issuing Distribution Point en la CRL. Consulte RFC 5280 , sección 6.3.3, paso (b). (2). (I ). Por lo tanto, esta división de CRL no es un problema.
OCSP encarna una división aún más extrema. OCSP es tanto un formato para objetos firmados (las "respuestas de OCSP") como un protocolo de comunicación para obtener una respuesta de OCSP de un respondedor en línea. Cada respuesta de OCSP es funcionalmente equivalente a una CRL que habla de un solo certificado. Por lo tanto, esto es como la CRL más dividida que pueda imaginar y, sin embargo, no crea ninguna información ambigua porque cada respuesta de OCSP designa explícitamente de qué certificado se está hablando.
Por lo tanto, que una CRL esté dividida o no no induce ninguna debilidad; y obtener una CRL nueva de la CA tampoco solucionaría nada, ya que el proceso de descarga no está protegido de todos modos.
En cuanto a su segunda pregunta: de hecho, el estado de revocación es, por definición, una propiedad transitoria. Por un lado, que el certificado del firmante no fue revocado en algún momento en el pasado (esa es la información proporcionada por un antiguo CRL) no garantiza de ninguna manera que el certificado aún no se haya revocado, y, en particular, que la clave privada no fue comprometido en el tiempo medio. Por otro lado, las CRL recientes no hablan de certificados caducados (y ese es el punto de caducidad de los certificados: para evitar que las CRL crezcan para siempre).
La salida de este enigma es marcas de tiempo . Con una marca de tiempo, de alguna manera puede "congelar" un objeto en un momento en el tiempo. La idea es que, en la fecha T , tome el objeto firmado, junto con todos los certificados y CRL que se pueden usar para validar la firma en esa fecha. Pones todo esto en algún formato de archivo, luego obtienes una marca de tiempo en general. En una fecha posterior T ', validará la marca de tiempo; Si la marca de tiempo es válida (en la fecha T '), sabrá que todos los contenidos del archivo ya existían en la fecha T , y luego puede proceder a validar la firma. y use los certificados y la CRL como si la fecha actual aún fuera T . El concepto es que SI hubiera hecho la validación en la fecha T , ENTONCES aún lo recordaría y actuaría en consecuencia; con la marca de tiempo, sabe que en la fecha T todos los certificados y CRL existían tal como están y, por lo tanto, podría haber hecho esa validación.
Hay muchas sutilezas en ese proceso, por lo que se han definido algunos estándares para admitirlo correctamente. Busque CAdES (y posiblemente sus hermanos XAdES y PAdES, para XML-DSig y PDF firmado, respectivamente).