Cadena de certificados y permiso para revocar

Respuesta corta: NO, Z no puede revocar X directamente. Excepción: SÍ, si las CRL de Z son, debido a un acuerdo previo entre Z & Y, en la lista de puntos de distribución de CRL del certificado de X emitido por Y.

RFC5280 se refiere a esto como " CRL indirecta ": donde Z puede emitir una CRL que incluye certificados emitido por Y. Solo funciona si el verificador sabe dónde verificar. El " CRL Extensión de puntos de distribución " de los certificados es el lugar donde deben (deberían) buscar.

Sin embargo, es bien sabido que la mayoría de los algoritmos de verificación de certificación no tienen un control estricto de la calidad con respecto a las normas, por lo que este sistema es falible en una medida no despreciable.

[Las dos respuestas existentes son buenas, pero como no tienen votos positivos, intentaré proporcionar una respuesta canónica]

En general, No . Quiero decir, Z puede revocar Y , que revoca automáticamente X y todos los demás certificados emitidos por Y , pero con los PKI y los motores TLS comúnmente utilizados Z no tiene ningún mecanismo para revocar X directamente. / p>

En términos generales, cada CA solo rastrea los certificados que emite; en un PKI típico, Z no sabrá acerca de la existencia de X , y la mayoría de los motores de verificación cert comprobarán el número de serie de X en Y s CRL, y el número de serie de Y en Z 's CRL. Podrías imaginar un sistema donde Y informa todos los certificados que emite a su CA principal para que Z sepa sobre X y pueda incluirlo en una CRL (aunque deberías preocuparte por la colisión del número de serie y tenga algún esquema para garantizar que no haya dos CA en la jerarquía emitirán el mismo número de serie). Entonces aún debe preocuparse por los clientes que realmente buscan el número de serie de X en la CRL de Z , que no es un comportamiento estándar.

Como @ Sas3 menciona en su respuesta, RFC5280 proporciona un mecanismo para hacer esto, llamado " CRL indirectas "(aunque parece que está más destinado a Y para copiar Z 'd revocaciones, o para que una CA delegue la administración de CRL a un" servidor de firmas CRL externo "en lugar de este escenario de tener raíces para poder eludir a sus subordinados). Dicho esto:

1. Para afirmar que esto es seguro, necesitaría la confianza de que todos los motores de validación de certificados que consumen sus certificados admiten CRL indirectos.
2. Soy un desarrollador del software PKI que impulsa la CA de confianza pública de Entrust, así como muchas otras CA, y a pesar de que nuestro nombre está en la lista de autores de esa RFC, que yo sepa, incluso nuestro software no admite CRL indirectos.
3. RFC 5280 se ha actualizado por RFC 6818 , que no hace mención de la "CRL indirecta", por lo que diría que si bien este mecanismo está técnicamente estandarizado, a nadie le importa realmente.

En pocas palabras: en un entorno cerrado donde tienes el control total de todas las entidades emisoras de certificados y todos los clientes que consumen certificados, probablemente puedas diseñar un esquema en el que Z pueda revocar X , pero en una PKI pública o cualquiera entorno que utiliza motores TLS estándar, esto no es ampliamente compatible.

Si se revoca Z, Y y X no se revocan, pero ya no se puede confiar, así que podemos decir que se revocó. Como Z no firmó con X, no puede revocarlo directamente en su CRL. Por cierto, nadie mirará a Z CRL si se revoca X allí, sino a X CRL. Lo que teóricamente puedes hacer es fusionar las CRL de X y Z, pero el problema está en la firma. ¿Quién firmará tal CRL? Z o X? ¿O ambos? Como no es estándar, diría que esto no funciona.

Si echas un vistazo a wiki encontrarás casi todo sobre los CRL allí.