¿Cómo puede ser válido un certificado en el modelo híbrido pero no en el modelo en cadena?

5

¡Todas las fechas en formato europeo!

Estoy aprendiendo sobre modelos de validez, pero la solución para esta tarea me confunde.

Traducción:

  

Losdatosrelevantesparaloscertificadosaplicablessemuestranacontinuación.  Supongamosquetodaslasfirmassonválidas,esosignificaquefueronemitidaspor  el"Emisor" escrito en el certificado.

Traducción:

  

QuieresverificarlasfirmasdeAliceyBob[nota:nolohice  CopialatablaparaBob]el1.2.2010.Rellenalatablacon"gültig"   o "ungültig" para resultados válidos e inválidos, respectivamente.

No entiendo cómo un certificado puede ser válido (gültig) en el Modelo Híbrido, pero no en el Modelo de Cadena (Kettenmodell) [vea la primera línea de la tabla de soluciones].

Alice es la entidad final, y la validez de su certificado debería ser independiente de Bob. Pero de acuerdo con la primera línea de la tabla de soluciones, la firma no es válida el 1.2.2010, incluso si se creó el 1.5.2009, cuando el certificado de Alice aún era válido.

    
pregunta Janus Troelsen 19.11.2012 - 12:34
fuente

2 respuestas

0

El certificado es válido en el modelo híbrido ya que los certificados de Alice, SubCA y RootCA son válidos en el momento de la creación de la firma (que es la condición del modelo híbrido).

El certificado no es válido en el modelo de cadena, ya que el certificado de Alice no es válido en el momento de la creación del certificado.

    
respondido por el Janus Troelsen 23.11.2012 - 10:52
fuente
3

Hay un tiempo de firma, y hay un tiempo de verificación. Primero simplifiquemos la situación: asumimos que la fecha actual es 2009-07-08. Para ese valor de "ahora mismo", los certificados RootCA y SubCA siguen siendo válidos, pero el certificado de Alice no lo es. Verá una firma que fue supuesta producida por Alice el 2009-05-01.

Si intenta validar el certificado de Alice, encontrará que está "caducado" y, por X.509 , ese es el final de la historia (sección 6.1.3, paso a.2). Posiblemente, podría existir una prueba de que la firma ya existía en una fecha pasada, por ejemplo. 2009-05-02; marcas de tiempo pueden ser tales pruebas. En esa fecha, el certificado de Alice todavía era válido, por lo que prácticamente podría imaginarse mirando la firma y los certificados en 2009-05-02 y ejecutando el algoritmo de validación en ese momento. Si estuviera convencido de la validez de la firma en ese momento, todavía lo recordaría ahora. Esta es la base de la validación anterior .

¿Pero puedes realmente viajar en el tiempo de esa manera? Hay un problema con la revocación . De manera genérica, ¿cómo sabrías si la clave privada de Alice fue robada? Imagina que, el 2009-04-15, un individuo malvado (llamémoslo Albert) robó la llave de Alice. Seguramente, una firma calculada con esa clave en el 2009-05-01 no puede sin duda atribuirse a Alice, ya que Albert podría haber computado lo mismo. En X.509, la información sobre las claves robadas ("claves comprometidas" en el lenguaje X.509) se distribuye a través de la revocación. La CRL publicada por SubCA incluiría el certificado de Alice con una "fecha de revocación" del 2009-04-15 (el robo podría haber sido descubierto unos días más tarde, pero el formato de la CRL incluye un campo que establece la fecha de corte). Ahora es el punto difícil: una CRL producida en la fecha T incluye información sobre certificados que aún son válidos (según las "fechas de validez") en la fecha T . En 2009-07-08, la CRL publicada actualmente por SubCA no incluye el certificado de Alice porque el certificado de Alice está caducado , y no puede saber si fue revocado en algún momento o no.

Por lo tanto, para la validación anterior, necesita más que una marca de tiempo en la firma; también necesita una marca de tiempo en algunos objetos de revocación (CRL, respuestas de OCSP ...) que se emitieron cuando el certificado de Alice aún no estaba vencido.

En la discusión anterior, puedes ver las dos herramientas esenciales:

  • Las marcas de tiempo permiten algunas formas de viaje en el tiempo, en las cuales se imaginó en una fecha pasada, operando sobre algunos valores (firmas, certificados, ...) que se ha comprobado que existen desde esa fecha.
  • Revocación es la forma en que se le informa de los compromisos clave.

Si ahora nos consideramos el 2010-02-01, tenemos dos niveles adicionales de complejidad:

  • El certificado de SubCA también ha caducado. Por lo tanto, también debe tener en cuenta la posibilidad de un robo de la clave de SubCA. Este es el mismo problema, un nivel más arriba: el certificado de SubCA se considera válido porque fue firmado por la CA raíz.
  • El certificado de RootCA también ha "caducado". Esta es una CA raíz, por lo que no es realmente un "certificado" (¿por quién está certificada?), Sino cierta información confiable a priori sobre un nombre y una clave pública. Si RootCA tiene una fecha de caducidad, esto significa que más allá de esa fecha, considerará que no se le avisaría necesariamente si la clave privada raíz estuviera comprometida. Estrictamente hablando, más allá de esa fecha, no tienes confianza en absoluto, por lo tanto, perdiste.

Todos los "modelos" de validación son simplemente formas elaboradas de bailar alrededor de estos temas, ignorando algunas posibilidades de compromiso clave. Por ejemplo, uno consideraría que un robo de la clave privada de la raíz sería conocido de todos modos, incluso más allá del "vencimiento" formal de la raíz, y que la fecha de finalización de la vida de la raíz es solo un asunto administrativo. Si comienza a ignorar algunos posibles problemas de seguridad, dependiendo del llamado "modelo", entonces no es sorprendente que algunas firmas se consideren válidas, o no válidas, según el modelo.

Sin embargo, como se presentó, su problema está muy incompleto, ya que no dice nada acerca de las marcas de tiempo, CRL y marcas de tiempo en CRL.

    
respondido por el Thomas Pornin 19.11.2012 - 13:34
fuente

Lea otras preguntas en las etiquetas