La extensión Key Usage , cuando está presente, contiene la lista exhaustiva de tipos de uso que Se permiten con la clave pública. Cuando un sistema procesa un certificado, lo hace para un propósito determinado y, por lo tanto, debe verificar que la extensión Key Usage , si está presente, permita ese uso. Específicamente, cuando un sistema analiza un certificado de CA y quiere usar su clave pública para verificar la firma sobre otro certificado (que la CA emitió supuestamente), entonces este es un uso de "signo de certificado"; por lo tanto, si el certificado de CA contiene una extensión Key Usage , entonces el sistema requerirá que la extensión contenga el indicador keyCertSign .
¡Nada impide que una extensión Key Usage contenga también las marcas otras ! La verificación es solo positiva: los sistemas verifican si la bandera que desean está realmente allí; nunca verifican que una bandera que no quieren esté ausente.
Como se supone que una CA debe emitir un certificado y una CRL, debe tener, en general, las banderas keyCertSign y cRLSign . Estas dos banderas son suficientes . Si la CA no tiene intención de firmar su propia CRL, entonces puede omitir el indicador cRLSign ; sin embargo, una CA sin el indicador keyCertSign tiene poco sentido. Uno puede querer incluir otras banderas si la clave de CA está destinada a hacer otras cosas también (aunque esto no es recomendable: una regla general es que una clave criptográfica debe usarse para una sola cosa). Uno puede imaginar, por ejemplo, hacer clave de custodia cifrando la clave privada de los certificados emitidos con la clave pública de la AC, de modo que la CA puede recuperar la clave privada bajo ciertas condiciones (esto no es una mala opción). idea cuando la clave del usuario es para el cifrado de datos).
Por lo tanto, nada impide que la extensión Key Usage contenga otras banderas. Alternativamente, la extensión Key Usage puede faltar por completo; esto es equivalente a "todos los usos permitidos".
La "firma de CRL fuera de línea" de Microsoft es solo otro nombre para "firma de CRL". De hecho, la página a la que te vinculas dice esto:
Para aplicar este uso de clave si se solicita un certificado de CA, escriba lo siguiente en el símbolo del sistema y luego presione INTRO:
echo 03 02 01 06 > Nombre_de_archivo.txt
Aquí reconocemos la codificación ASN.1 / DER de un BIT STRING de longitud 7 bits, con los bits 5 y 6 establecidos, y los bits 0 a 4 borrados; esta es la codificación de una extensión Key Usage con las marcas keyCertSign y cRLSign . Aunque utilizan su propia terminología, Microsoft cumple con el estándar para ese punto (no inventaron un nuevo indicador de uso de clave no estándar para "firma de CRL sin conexión").
Todo lo anterior es la interpretación normal de certificados . Sucede que, en lo que respecta a los estándares, los "certificados de CA raíz" no existen . Una "raíz" se denomina ancla de confianza y consiste principalmente en un nombre (DN) y una clave pública. Es tradicional codificar el ancla de confianza como "certificados", es decir, la secuencia de bytes que siguen las reglas de codificación de los certificados (estos certificados suelen ser autofirmados, porque el formato de un certificado no es opcional ranura para una "firma", por lo que debe haber algo en esa ranura).
Dado que esto no es estándar, la interpretación de la extensión del certificado en una estructura similar a un certificado de este tipo está abierta a las variantes locales. Algunas implementaciones interpretan la extensión Key Usage en un certificado raíz de las formas explicadas anteriormente. Algunos ignoran esa extensión por completo.
En general, es seguro (para la interoperabilidad) rellenar los certificados de CA raíz con contenidos que serían perfectamente válidos si ese "certificado" fuera real, en lugar de un contenedor de codificación conveniente para un ancla confiable.