Durante la validación normal de la cadena, se supone que debe verificar el estado de revocación de cada certificado en la cadena. Para verificar el estado de revocación, debe obtener una CRL o una respuesta de OCSP; ambos tipos de objetos están firmados y, antes de su uso, deben validarse. La validación de una CRL o una respuesta OCSP implica verificar una firma, en relación con la clave pública del emisor del objeto, la clave pública que se obtiene de ... validar otra cadena de certificados. Todo el proceso es recursivo y puede terminar validando muchos certificados en el proceso.
Por supuesto, la recursión tiene potencial para los bucles, y los bucles son malos.
Considere un camino simple: Raíz - > SubCA - > EE.
Está validando la ruta, verificó todas las firmas y llegó a un punto en el que también verificó que SubCA no fue revocado. Ahora estás considerando el certificado de EE. El certificado de EE contiene una extensión AIA que apunta a un respondedor OCSP; usted habla con ese respondedor y obtiene una respuesta de OCSP. Excelente ! La respuesta de OCSP parece haber sido firmada directamente por SubCA, utilizando su clave privada (la misma clave privada que la utilizada para firmar el certificado EE). Esto es bueno: ya ha validado esa clave, incluido el estado de revocación , por lo que es suficiente verificar la firma en la respuesta de OCSP, y luego puede usarla ("usar" una respuesta de OCSP significa mirar sus contenidos y confiando en ellos).
Este modelo anterior es "situación 2" de la sección 4.2.2.2 de RFC 2560 : el certificado utilizado para validar el La respuesta de OCSP es la misma que el certificado de la CA que emitió el certificado de destino ("SubCA" en nuestro ejemplo).
Se supone que se debe admitir otro modelo, descrito como "situación 3" en la sección 4.2.2.2: la respuesta de OCSP está firmada por un respondedor dedicado, que tiene un certificado (llamémoslo "Resp") que es emitido por SubCA. El certificado de Resp está incrustado en la respuesta OCSP. ¿Cómo validar eso? Es bastante fácil verificar las firmas, y también verificar que Resp cuenta con el EKU específico que marca a los respondedores de OCSP delegados. Pero, ¿cómo se asegura de que el propio certificado de Resp no se haya revocado?
Las tres formas posibles son:
- Utiliza una CRL u otro contestador de OCSP que le dará la información. Esto, por supuesto, hace que el proceso sea recursivo.
- Resp se hace para incluir la extensión específica
id-pkix-ocsp-nocheck , lo que hace que el certificado de Resp sea "irrevocable" (por lo tanto, no necesita obtener su estado de revocación, ya que no se ha revocado por definición).
- A la CA no le importa, e incluye en Resp un AIA que apunta a sí mismo como un respondedor de OCSP. Por lo tanto, para validar Resp, primero debe validar Resp. Frente a este problema del huevo y la gallina, lloras, luego te unes a la CA en su apatía y simplemente consideras que Resp está "probablemente bien".
Desafortunadamente, me he encontrado con la tercera vía en una gran PKI patrocinada por grandes corporaciones o estados soberanos que realmente deberían saber mejor.
La Sección 4.2.2.2 de RFC 2560 también sugiere una "situación 1" donde el respondedor OCSP es "otra cosa" que el motor de validación de alguna manera sabe que es seguro a través de alguna "configuración local" (la expresión "configuración local" es RFC-hablar significa "por la magia de las hadas").
El texto que cita significa que Windows, hasta Vista, sabe cómo manejar las situaciones 2 y 3. Desde Vista SP1 en adelante, también maneja la situación 1, con el siguiente giro: el certificado de respuesta de OCSP puede ser "cualquier certificado" pero CryptoAPI requerirá CRL para validar esa. Esta es una forma drástica de evitar los bucles de validación.
Resumen: si está creando su PKI, el método que causará menos problemas es usar la clave de CA para firmar las respuestas de OCSP. Si realmente necesita usar una clave distinta (por ejemplo, se supone que la CA está desconectada, pero el respondedor OCSP, por naturaleza, está en línea), entonces haga que la CA emita un certificado dedicado para el respondedor OCSP . Este certificado de respondedor dedicado contendrá el id-kp-OCSPSigning EKU y la extensión id-pkix-ocsp-nocheck . Dado que un certificado irrevocable puede verse como un incumplimiento grave de la política, la forma recomendada es hacerlo de corta duración: configurar el certificado de respuesta para que sea válido durante aproximadamente quince días, y emitir uno nuevo una semana. >
Como han señalado otros, muchas implementaciones no verifican el estado de revocación en busca de certificados "extra" (certificados que no se encuentran en la cadena principal, pero que se usan para verificar objetos de revocación como las respuestas CRL o OCSP), lo cual es descuidado pero a menudo es necesario (de forma comercial) para hacer frente a grandes PKI que no hacen las cosas correctamente. Es su deber moral hacer mejor que eso (como lo expongo anteriormente) para acercarnos más al punto en el que PKI realmente trabajará y brindará seguridad.