¿Varias CA firman un solo Cert / CSR?

Sobre los cambios en SSL / TLS: el protocolo SSL / TLS envía certificados como anónimos blobs que pueden tener cualquier tamaño, hasta aproximadamente 16 MB (lo cual es ridículo). El protocolo en sí no necesita ser cambiado si uno quiere usar algunos formatos de certificados nuevos.

Las implementaciones de SSL / TLS esperan que los blobs estén codificados certificados X.509 . Dicho certificado tiene espacio para un solo emisor (el nombre de la CA está escrito en él) y una única firma. Por lo tanto, no puede tener un "certificado de firma múltiple" dentro de los límites del estándar X.509 existente. Usted podría obtener varios certificados, con la misma clave pública en cada uno, y luego solo necesitará algún tipo de convención para que al software cliente SSL no le importe recibir más de un certificado para el servidor, y los revisa todos.

Acerca de la emisión de los certificados: una solicitud de certificado es solo un barco para la clave pública del solicitante, su nombre previsto y cualquier tipo de información que la AC sea gratuita. para replicar, o no, en el certificado emitido. No hay ningún problema teórico en tener varios certificados, incluso de distintas CA, que contengan su nombre y su clave pública; en realidad, cualquier CA podría emitir un certificado de este tipo sin necesidad de interacción con usted. Todos podrían usar la misma solicitud de certificado. En la práctica , requeriría algunos cambios, ya que las CA existentes emiten certificados como parte de los escenarios basados en la Web, donde se indica al navegador del comprador que genere un nuevo par de claves y envíe la parte pública a la CA Sin ninguna interacción con el comprador humano. Dado que la idea de que cada servidor posea al menos 3 certificados básicamente triplica el mercado de certificados de servidor, estoy bastante seguro de que la AC comercial estaría dispuesta a implementar los ajustes relevantes en su plataforma.

Sobre la solidez de la idea: solicitar validación múltiple es una buena idea (la OpenPGP el formato ya lo hace, principalmente para lidiar con la falta de fiabilidad inherente de una CA de web de confianza, pero puede ser contraproducente: si tener una única CA deshonesta o comprometida no afecta la seguridad general, es probable que el próximo evento similar a Comodo Recibirá menos publicidad, posiblemente ninguna en absoluto. La validación múltiple tiende a fomentar la indulgencia general y la pérdida de responsabilidad.

Sobre convergencia: de lo que habla la cita de slashdot es Convergence . Este es un nuevo sistema que intenta conseguir un punto de apoyo. Consulte esta respuesta para algunos detalles e indicaciones sobre el protocolo.

Realmente creo que esta sería una muy buena idea. Pero requeriría una nueva versión de SSL y TLS para ser compatible. Actualmente, todo está diseñado con el supuesto de que hay exactamente un ancla de confianza. Lo que significa que probablemente nunca sucederá. Todavía tengo discusiones con personas que afirman que "necesitamos" que sea compatible con Windows 98.

Dudo que esta idea funcione. Las CA requerirían una API entre sí para automatizar la firma de certificados. ¿Qué estarían revisando? Si no verifican las solicitudes de los demás, un pirata informático que obtuvo acceso a una API de CA (como en los casos de Comodo y DigiNotar) todavía ganaría. Si do comprueba las solicitudes de firma entre CA, ¿qué debe verificar?

Lo que podría impedir el enfoque de múltiples CA es que un atacante obtenga certificados para dominios de alto perfil como * .google.com, si una segunda CA firmante marcaría aquellos en los que el primero falló.

Personalmente, sin embargo, me gusta el enfoque de perspectiva de red de moxie. Sobre todo porque pone la decisión de confianza en manos del usuario, sin convertirla en una solución exclusiva para técnicos.

Probablemente llego unos años tarde, pero de todos modos ...
Un problema que se me viene a la mente es que un mitm puede evitar que el cliente negocie varios certificados y solo obtenga el que piratea de una CA.
La solución fácil IMO es usar otro puerto o simplemente inventar otro nombre de protocolo para que el cliente SABE que debe obtener MÁS DE UN certificado.

Una mejor manera ya está en las obras en forma de DNSSEC y DANE. La principal vulnerabilidad en el sistema actual de certificados de sitio es que cualquiera de las CA puede emitir certificados para cualquier nombre de dominio. Por lo tanto, solo se necesita una CA incorrecta para comprometer cualquier dominio. En su lugar, se puede especificar la clave que firma los certificados de sitio para un determinado dominio:

De enlace (la especificación DANE):

"El modelo de CA público del cual TLS ha dependido es fundamentalmente vulnerable porque le permite a cualquiera de estas CA emitir un certificado para cualquier nombre de dominio. Una única CA de confianza que traiciona su confianza, ya sea voluntariamente o proporcionando menos de La protección vigorosa de sus secretos y capacidades puede socavar la seguridad ofrecida por los certificados empleados con TLS. Este problema surge porque una CA comprometida puede emitir un certificado de reemplazo que contiene una clave falsa. Las experiencias recientes con compromisos de CA o sus socios de confianza han liderado a problemas de seguridad muy graves, como los gobiernos de varios países que intentan interceptar y / o subvertir los principales sitios web protegidos por TLS en los que confían millones de usuarios ".