Usando diferentes algoritmos en una sola PKI

Según X.509 , no hay problema. Puedes mezclar algoritmos a voluntad. Cada firma es independiente.

(X.509 incluye una disposición especial para cuando una CA usa DSS y emite un certificado que también usa el DSS con los mismos parámetros de grupo , en cuyo caso el certificado emitido puede omitir los parámetros del grupo. Esto se denomina "herencia de parámetros". Esto nunca se usa en la práctica y no fue transferido a ECDSA, aunque era una posibilidad y aparentemente se previó en algún momento. Este es el único caso, para mi conocimiento, donde los algoritmos de firma en varios niveles de la cadena tienen alguna relación juntos.)

Sin embargo , debe comprender que al usar varios algoritmos distintos, obliga a los "usuarios de confianza" (sistemas que deben validar estas cadenas) a implementarlos todos. Si bien esto normalmente no es un problema para los sistemas de escritorio, servidores y teléfonos inteligentes, podría ser un problema para los dispositivos pequeños e integrados que desean ahorrar en el tamaño del código, y prefieren no incluir el código para RSA y para la ECDSA.

Este tipo de problemática se encarna, por ejemplo. en SSL , donde el cliente y el servidor se dicen qué tipo de algoritmo admiten para validar firmas en los certificados (ver, por ejemplo, la Mensaje Certificate Request ). Esto está destinado a soportar mejor los dispositivos pequeños con poco espacio de código. Hacer una mezcla de RSA y ECDSA en sus cadenas de certificados lo pone un poco en desacuerdo con ese principio. Dependiendo de su contexto, esto puede o no puede importar ( probablemente no importará).

En cualquier caso, se espera ese tipo de cadena mixta para una transición . Supongamos que comienzas con un mundo RSA completo; La CA raíz se ha distribuido a todos los sistemas cliente (posiblemente a un alto costo). Ahora, toma la decisión de cambiar a ECDSA, porque el software del cliente es capaz de hacerlo (por ejemplo, vino con las actualizaciones normales del sistema operativo / navegador), pero la creación de una nueva raíz de ECDSA y su inserción en todos los clientes llevará mucho tiempo. Por lo tanto, para comenzar a usar ECDSA sin romper las cosas para la base instalada, haga certificados cruzados:

• oldRoot usa una clave RSA.
• newRoot usa una clave ECDSA.
• Para permitir que las personas validen certificados emitidos por newRoot, incluso si no conocen newRoot como una raíz confiable, se emite un certificado cruzado que contiene el nombre y la clave pública de newRoot, pero está firmado por oldRoot.

Este certificado cruzado permite a los sistemas que conocen newRoot como una raíz confiable validar un certificado con la ruta "newRoot- > cert", y los sistemas que solo conocen oldRoot usarán "oldRoot- > newRoot- > cert" (En este último caso, pasando por el certificado cruzado). En otras palabras, newRoot tiene dos certificados, uno autofirmado (con ECDSA), el otro firmado por oldRoot (haciendo de newRoot un intermedio CA).

Este es un método bastante estándar para manejar renovaciones con cambios clave, pero necesariamente implica, en el caso de una transición de RSA a ECDSA, cadenas de algoritmos mixtos. Por lo tanto, la situación que usted describe no solo es compatible sino también esperada.

Para resumir: el uso de PKI completamente separada permite PKI de algoritmo único, lo que puede ayudar a los dispositivos integrados (solo se debe implementar un algoritmo). Sin embargo, la PKI de algoritmo mixto es algo normal, bien soportado y esperado en el caso de transiciones de PKI a nuevos algoritmos.

Según mi conocimiento, no hay requisitos en el algoritmo para la CA subordinada que no sea el que la CA raíz quiere aplicar.

De hecho, en lugar de buscar una razón por la cual sería inaceptable, vería una razón por la que es aceptable. Cualquier certificado de CA subordinado debe estar firmado por la CA raíz. Y la CA raíz es la máxima confianza. Si la CA raíz confía en la CA subordinada con un certificado de algoritmo ECC / RSA / lo que sea, entonces está bien. La CA raíz firma el certificado y extiende su confianza.

Sin embargo, es probable que deba proporcionar una política de CA, donde indique lo que usted, como CA, autoriza, para que sus clientes puedan evaluar si desean confiar en su CA raíz o no. Mire qué algoritmo está obsoleto o roto y nunca lo acepte en sus certificados.