¿Por qué RFC 4158 (Construcción de rutas) restringe los anclajes de confianza a los certificados autofirmados?

Question

¿Por qué RFC 4158 (Construcción de rutas) restringe los anclajes de confianza a los certificados autofirmados?

#1 de Mike Ounsworth (1 votos)
#2 de CGretski (0 votos)

7

Tengo problemas para usar Wget para descargar un archivo a través de HTTPS desde ftp.gnu.org usando la raíz Let's Encrypt X3 . El Let's Encrypt X3 tiene certificación cruzada, lo que significa que tiene un emisor y no está autofirmado. Al utilizar Let's Encrypt X3 , Wget está fallando con el error y no puede encontrar el certificado del emisor aunque estoy tratando de enraizar la confianza en el certificado de Let's Encrypt.

Visité RFC 4158, Internet X.509 Infraestructura de clave pública: Creación de rutas de certificación para ver cuál debería ser el comportamiento . El documento analiza en detalle la creación de rutas desde la entidad final o los certificados de suscriptor hasta las raíces de CA y los anclajes de confianza. Es lo que uno esperaría.

Sin embargo, Sección 1.3 proporciona terminología y define los anclajes de confianza:

Lista de confianza : una lista de anclajes de confianza.
Ancla de confianza : la combinación de una clave pública de confianza y el nombre de la entidad a la que pertenece la clave privada correspondiente.
Trust Anchor Certificate : un certificado autofirmado para un ancla de confianza que se utiliza en el procesamiento de la ruta de certificación.
"Trust Anchor Certificate" y la definición que exige "autofirmado" significa que no podemos basar la confianza en un certificado subordinado, como el Let's Encrypt X3 raíz que ha sido certificada de forma cruzada.

Mi pregunta es, ¿por qué el RFC hizo eso? ¿Por qué nos vemos obligados a usar un certificado autofirmado como un ancla e incluir partes innecesarias de la PKI que solo sirven para complicar la construcción de la ruta y aumentar la superficie de ataque?

public-key-infrastructure certificates x.509 rfc

pregunta jww 15.10.2017 - 05:00

fuente

2 respuestas

Lea otras preguntas en las etiquetas public-key-infrastructure certificates x.509 rfc

_ ¿Hay servicios VPN de nivel de consumidor que admitan la autenticación de dos factores, como SecurID?

score 1 · Answer 1

Este es uno de esos enunciados sutiles difíciles. El significado completo de la RFC puede no ser obvio en la primera lectura. De tu pregunta ( énfasis mío ):

Ancla de confianza : la combinación de una clave pública confiable y el nombre de la entidad a la que pertenece la clave privada correspondiente. Certificado de anclaje de confianza : un certificado autofirmado para un ancla de confianza que se utiliza en el proceso de ruta de certificación.

Un almacén de confianza tiene dos propósitos:

Establezca que todas las firmas generadas por esta clave pública sean confiables, y
Enlazar la clave pública a un nombre (por lo general, el nombre distinguido (DN) de LDAP se define en RFC2253 )

Algunos corolarios de eso son:

Todas las firmas realizadas por esa clave serán confiables, incluidas las emisiones de certificados.
Debido a que lo marca explícitamente como de confianza, esta clave no puede ser revocada a través de métodos normales, la única forma es eliminarlo manualmente de su almacén de confianza.

Lo sutil aquí es que el RFC le permite anclar ya sea un certificado, o una clave pública directamente, sin embargo, si usted fija una certificado, entonces tiene que ser un certificado de raíz. El RFC da alguna justificación aquí:

1.5.1. Estructuras jerárquicas

Una PKI jerárquica, representada en la Figura 1, es una en la que todos los      las entidades finales y las partes dependientes utilizan una sola "CA raíz" como su      ancla de confianza.

Desde el punto de vista de la CA, es posible que no quieran que usted fije la CA intermedia porque eso elimina su capacidad de revocarla si se ve comprometida: incluso si publican una revocación para ella, su cliente la ignorará.

En el caso de que una CA quiera que usted pueda usar una CA intermedia como un ancla de confianza, he visto que le dan a un ancla de confianza ambos un certificado emitido, y un certificado autofirmado para la misma clave pública y DN. Supongo que Let's Encrypt no hace esto para sus CA intermedias.

En cuanto a su pregunta real sobre wget , ftp.gnu.org y el Let's Encrypt X3 middle CA, creo que tiene dos opciones:

Encuentre el certificado raíz autofirmado que emitió Let's Encrypt X3 y agréguelo a su almacén de confianza.
Averigua cómo colocar una clave pública directamente. Esto dependerá de la pila de software / SO que esté utilizando y de si es compatible con la parte arcaica y poco común del RFC que permite que un Ancla de confianza sea una clave y no un certificado.

score 0 · Answer 2

Como un supuesto general: si no es autofirmado; estás confiando en alguna otra entidad para imbuir confianza; esa otra entidad por definición se convierte en el ancla.

Aunque muchas implementaciones pueden confiar en algo más allá de la cadena, eso no es una función de PKI / x509, es una confianza fuera de banda; por lo tanto, fuera del alcance de la RFC.

Plantea una pregunta: ¿por qué imbuir la confianza implícita en un ancla, que en sí misma no tiene la confianza implícita de su emisor (podría ser revocada)?