Modelo de confianza PKI jerárquico

Creo que debes ser más específico acerca de lo que quieres decir con "Qué pasa si Alice explícitamente no confía en C." Alice, y solo Alice, ha decidido no confiar en C, o A ha revocado el certificado de C?

Mi comprensión del proceso (abstracto) de Alicia es:

// encuentra una firma que ella pueda verificar

1 . Alice verá que cert_Doris está firmado por cert_C y preguntará "¿Tengo una clave de verificación para cert_C ?" .... No .

2 . cert_C está firmado por cert_A , "¿Tengo una clave de verificación para cert_A ?" ... Sí .

// luego retroceda por la cadena realizando verificaciones

3 . ¿Se revisa la firma en cert_A y es válido el certificado (es decir, no se ha revocado)? ... Sí

4 . ¿Se revisa la firma en cert_C y es válido el certificado (es decir, no se ha revocado)? ... Sí

5 . ¿Se revisa la firma en cert_Doris y es válido el certificado (es decir, no se ha revocado)? ... Sí

6 . Ahora Alice confía en Doris porque tienen un ancla común de confianza.

Los detalles de este proceso dependerán obviamente del software PKI que use su organización.

Como señala @MaartenBodewes: note que este proceso no requiere que Alice esté conectada a A, de hecho, ese proceso funcionará bien para Eric, quien ni siquiera tiene certificados, siempre y cuando haya decidido confiar A. (Así es como funciona la fijación de certificados en los navegadores, ya que los clientes TEM de TLS normalmente no tienen certificados, son como Eric).

En cuanto a

  

¿Qué sucede si Alice explícitamente no confía en C.

Es completamente posible que su software PKI permita que Alice (o cualquiera de las CA anteriores a Alice) incluya en una lista negra a un usuario específico, o una CA específica, sin revocar globalmente su certificado, aunque nunca he oído hablar de una PKI que ofrece eso.

En cuanto a

  

¿Necesita Alicia tener un certificado de D, B y C también?

Técnicamente no, tener la clave de verificación para A es criptográficamente suficiente, aunque para organizaciones grandes, como un gobierno, con muchas CA y usuarios departamentales, hacer una búsqueda completa cada vez puede ser muy lento, por lo que Alice puede almacenar certificados localmente. una vez que los ha considerado confiables para que las búsquedas futuras sean más rápidas. Esto podría llevar a problemas de seguridad si la revocación no se revisa completamente a la raíz cada vez. Eso depende del software específico y de las políticas de la organización para decidir si ese riesgo merece las molestias de las búsquedas lentas.

La idea general de que es necesario que haya un camino de Alicia a Doris es incorrecta. Solo tiene que haber una cadena de certificados válida desde Doris hasta un certificado de confianza en el almacén de confianza de Alice. Y Doris, por supuesto, debe demostrar que tiene la clave privada que pertenece al certificado de Doris.

Todo lo que Alice requiere es un certificado de confianza A o C. Necesita recuperar todos los certificados intermedios si no tiene una cadena completa (si solo tiene A, necesita recuperar C: generalmente se envía a Alice a través de Doris). Ella necesita poder verificar la firma de los certificados y la validez de los certificados en la cadena. El procedimiento de validación puede verificar el uso de la clave, las extensiones de la clave, el período de validez y, por supuesto, el estado / revocación del certificado, etc. La cadena también puede consistir en solo el certificado de Doris si se confía directamente (identificación del certificado).

Finalmente, la firma de la clave privada debe verificarse utilizando la clave pública del certificado Doris. O puede ser necesario usar la clave privada para descifrar un desafío o clave de sesión.

Alice ni siquiera necesita un certificado / clave privada. Actualmente mi navegador tampoco tiene mi certificado. Solo aquellas entidades que deben autenticarse deben tener una clave privada y el certificado correspondiente.