En la arquitectura X.509, ¿cuáles son los usos de los certificados de firma cruzada de otra jerarquía?
¿Simplemente amplía la confianza?
Entonces, a partir de la respuesta, asumo que si CA3 está cruzada por CA2 (de otra jerarquía) y CA1 (un padre en su propia jerarquía) cuya clave privada se usa para cifrar el hash de autenticación en el certificado de CA3?
Se trata de expandir la confianza, sí. Si confía en ambos, CA1 y CA2, y un certificado está firmado por ambos, tiene un nivel de confianza muy alto porque dos entidades de la paridad en las que confía han verificado el certificado.
Tiene la ventaja adicional de aumentar la facilidad de verificación de confianza, como en situaciones en las que tienes clientes que confían en CA1 o CA2 (pero no en ambos). En tal caso, puede firmar en forma cruzada un certificado para que ambos confíen. Esto permite que más clientes verifiquen la confianza sin tener que distribuir certificados separados para diferentes CA.
Otra bonificación es en situaciones donde se filtra una clave privada de CA. Digamos que las fugas clave de CA1 y su certificado está firmado por CA1 y CA2. A raíz de la filtración, CA1 emite una revocación de su clave pública y ya no puede confiar en nada emitido por CA1. Sin embargo, como su certificado también tiene una firma cruzada con CA2, cualquier cliente que confíe en CA2 puede mantener un nivel de confianza en su certificado.
Las especificaciones X.509 solo admiten una firma. De la RFC concerniente a ellos:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
Para admitir múltiples valores de Signature, tendrías que hacer algo como "signatureValue SEQUENCE OF BIT STRING" y también hacer algunos otros cambios.
Si tienes un certificado X.509 que ha sido firmado por varios CA's, me encantaría verlo y hacer un pequeño asn1parse en él.
Lea otras preguntas en las etiquetas x.509