¿Es una buena idea generar CRL específicos de certificados? ¿Cómo se llama esta técnica?

4

Supongamos que creo 3 certificados con las siguientes CRL

Cert1    http://crl.server.com/batch1/root1.crl    
Cert2    http://crl.server.com/batch2/root2.crl
Cert3    http://crl.server.com/batch3/root3.crl

Suponga que la CRL está formada correctamente, la próxima actualización es válida y está firmada correctamente por la CA (aquí denominada "raíz"). El contenido de root*.crl solo puede contener un certificado. (Supongamos que el software del servidor lo admite o que la CRL está formada por un comando openssl)

Pregunta

¿Esto resolvería los siguientes objetivos:

  • "Ocultar" el estado de revocación de un certificado, a menos que alguien realmente lo posea y, por lo tanto, necesite saberlo. (Suponga que la palabra "lote" es un GUID asignado)

  • Reduzca el tamaño de la CRL durante el mantenimiento en curso

¿Cuáles son los beneficios adicionales de este enfoque?

¿Existen otras soluciones mejores que puedan abordar esta necesidad o incorporan reducción de tamaño de CRL o privacidad?

¿Cómo se llama este enfoque?

(los objetivos de eficiencia y privacidad no son requisitos ... este es un experimento mental para mí)

    
pregunta random65537 08.01.2013 - 02:44
fuente

1 respuesta

7

Segmentar el espacio de los certificados para que se pueda calcular una CRL "parcial" es posible y se admite, pero debe hacerse correctamente. Un principio básico de la CRL es que una CRL debe poder procesarse independientemente de cómo se haya obtenido: ese es el punto central de tener objetos firmados. Dado que un certificado se considera no revocado en virtud de que no aparece en la CRL, debe ser posible verificar de manera inequívoca si una CRL determinada se aplica a un certificado determinado o no, en la terminología X.509 , si el certificado está en el alcance de la CRL.

La extensión a utilizar es CRL Distribution Points : consulte la sección 4.2.1.13 de RFC 5280 . Esta extensión tiene dos roles distintos: documenta la URL donde se puede obtener la CRL, e implementa la segmentación del espacio del certificado. Para la segmentación (en la que está interesado), la extensión debe estar marcada como crítica , y debe haber una coincidencia entre un "punto de distribución" y la estructura correspondiente en la extensión Issuing Distribution Point de la CRL . En efecto, cada punto de distribución caracteriza un subespacio del espacio del certificado; cada certificado está marcado con el subespacio al que pertenece, y cada CRL está marcado con el subespacio al que corresponde. Al igual que con todas las cosas X.509, los detalles son complejos y se necesitan algunas pruebas exhaustivas para evaluar la realidad del soporte de las aplicaciones existentes.

Dicha segmentación es útil para mantener el tamaño de CRL bajo. Se podría utilizar para crear un CRL de certificado único, aunque esto debería equilibrarse con el costo de firmar todos estos CRL (las firmas no son caras, pero un millón de firmas puede convertirse en una carga, no realmente las firmas en sí mismas, pero toda la codificación y la transferencia de archivos tiene cierta sobrecarga).

No se puede esperar mucho beneficio de privacidad de esa manera: los certificados son elementos inherentemente públicos, que viajan sin protección en muchos protocolos. No pueden ser considerados secretos. Hay poco más que se puede obtener de CRL; en realidad, una CRL completa ya es discreta, ya que solo se trata de certificados revocados: no dice nada sobre certificados no revocados y ni siquiera insinúa su existencia.

En última instancia, ya existe un CRL de certificado único, pero se llaman Respuestas de OCSP .

    
respondido por el Thomas Pornin 08.01.2013 - 03:39
fuente