La postura "oficial" de X.509 en la CA deshonesta es que la CA deshonesta está fuera del alcance de X.509. Se necesita un poco de esfuerzo para aceptar que ... La idea es que toda la estructura de la AC no se trata realmente de prevenir los ataques, sino de poder señalar a los culpables. Si una CA se vuelve maliciosa, entonces la cadena de certificados fraudulentos permitirá identificar qué CA se equivocó y, por lo tanto, culpar directamente a quien se debe.
La mayoría de los navegadores tratan el problema de las restricciones de nombre al no admitir restricciones de nombre, lo que significa que tratar de restringir una CA de un dominio específico es, por ahora, una búsqueda de tontos.
Si el soporte de las restricciones de nombre estaba muy extendido, entonces podría restringir que una sub-CA emita SSL / TLS para un dominio específico agregando restricciones de nombre que obligan al DN del sujeto a un prefijo que define el CN a un Valor que no puede ser un FQDN para una máquina. Por lo tanto, cualquier certificado "compatible con SSL" necesitaría necesariamente una extensión SAN, evitando así el problema al que alude. Pero esto todavía hace suposiciones sobre el comportamiento de las implementaciones que encuentran un certificado cuyo DN de sujeto contiene múltiples campos "CN"; si la SAN restringe el DN a "CN = INVALID FOR DOMAIN", y la sub-CA no autorizada emite un certificado, como DN: "CN = INVALID FOR DOMAIN, CN = www.google.com", ¿cómo reaccionará el software del cliente? ?
Para resumir, las restricciones de nombre no funcionan bien o no funcionan en absoluto en la práctica, por falta de soporte generalizado, pero incluso si fueran compatibles, el hecho de que funcionen en realidad seguirá siendo un juego exitoso.