¿Por qué las AC en lugar de la base de datos global de huellas digitales?

De hecho, son dos preguntas: por qué usar CAs en lugar de una base de datos de huellas digitales global, y por qué usar CAs en lugar de hacer lo que hace SSH. No hay una base de datos global de huellas dactilares para SSH, de hecho es todo lo contrario.

En el modelo SSH, no hay una forma integrada de obtener la huella digital de un servidor que no sea conectándose a él. El modelo habitual de seguridad es que cuando se conecta a un servidor por primera vez desde un cliente determinado, se le solicita que verifique manualmente la huella digital, y cuando se conecta de nuevo, el cliente verifica que la huella digital no ha cambiado. Un caso común en el que este modelo solo funciona es cuando el cliente está en una computadora portátil y usted realiza la primera conexión desde la misma red confiable que contiene el servidor. Aparte de eso, se supone que debes verificar la huella dactilar fuera de banda, pero la mayoría de los usuarios simplemente escriben "sí". Este sistema no escala realmente; es viable cuando solo se conecta a unos cuantos hosts nuevos por año, pero no para algo como la web donde puede conectarse a varios sitios HTTPS nuevos todos los días.

Si hubiera una base de datos global de huellas dactilares, entonces, para todos los fines, sería una CA universal. La definición de una CA es que usted confía en ella cuando le dice que cierta clave pública K pertenece a una determinada entidad E. En el protocolo SSL, una CA le dice esto al proporcionar un certificado que contiene una aseveración criptográfica de que K es la clave pública de E. Una base de datos de huellas dactilares, donde se busca E y se obtiene K o viceversa, es una implementación diferente de una aserción de relación de confianza. Entonces, con una base de datos global de huellas dactilares, tendríamos una base de datos aún más grande "demasiado grande para fallar".

Un enfoque que evita el problema "demasiado grande para fallar" es la web of trust como la utiliza PGP. El principio es que sabes que K es la clave de E porque alguien que conoces te lo dice. Este enfoque es bastante adecuado para aplicaciones como el correo electrónico, ya que muchos correos electrónicos se envían entre personas que tienen una relación anterior o que tienen amigos en común. No es aplicable en un caso como "Quiero conectarme al sitio web de este comerciante", donde nunca había oído hablar de este comerciante antes de ver un enlace al mismo en un sitio de comparación de precios, pero quiere saber que el sitio pertenece. a una entidad corporativa que ha estado haciendo negocios durante varios años, y no a algún estafador que tomará su dinero y se irá la próxima semana.

Tener una CA única plantearía preocupaciones distintas al riesgo para la integridad de la base de datos de relaciones de confianza. Cuando una entidad registra una clave, se supone que la CA verifica que el solicitante de registro tiene una reclamación válida a su identidad supuesta (que el usuario que registra una clave para "Joe Bloggs" realmente se llama Joe Bloggs, que el registrante para "Yoyodine, Inc. "es de hecho un oficial autorizado de Yoyodine, ...), por lo que el registrante no puede tener privacidad con respecto a la CA. Una elección de CA significa que los solicitantes de registro pueden elegir a quién enviar su identidad privada. Una CA estatal estaría en un buen lugar allí porque ya conoce la identidad del solicitante, pero ¿en qué estado? Las personas pueden querer declarar identidades que no son conocidas por el estado en el que viven. Otra preocupación con una única autoridad de certificación es que tendría un monopolio en el registro; tener muchas CA significa que es improbable que una entidad tenga prohibido participar.

Una forma de reducir el impacto de una falla de una CA sería tener claves certificadas por múltiples CA. Esto es algo que la gente suele hacer en una red de fideicomisos al estilo PGP: quiero verificar la clave de Alice, así que le pregunto a Bob, quien me dice que la clave es correcta. Pero aunque estoy seguro de que Bob me está diciendo esto porque he verificado su clave, no confío completamente en que Bob haya verificado la identidad de Alice. Así que también le pregunto a Carol, a Dan, y así sucesivamente. Con muchas suposiciones convergentes, tengo una mejor seguridad de que Alice es quien dice ser. De la misma manera, tener la clave de un sitio web certificada por varias CA, y no revocada por ninguna, reduciría las preocupaciones de que una de estas CA haya estado comprometida o haya sido laxa en la verificación de la identidad del titular. Sin embargo, esto requeriría actualizaciones de una gran cantidad de software que verifica los certificados SSL y aumenta el costo del registro de claves.

No puedo ver cómo esto sería un beneficio. Actualmente tenemos muchos CA, lo que significa que si uno se rompe por algún motivo (Diginotar, por ejemplo) podemos simplemente (bueno, relativamente simple) revocar los certificados para ese CA.

Si acaba de tener un dB grande, ¿qué sucede cuando se rompe, ya sea de forma deliberada o accidental? No tienes ninguna opción de recuperación rápida o útil.