La autorización de la autoridad de certificación del DNS ( CAA ) es un mecanismo de política de seguridad de Internet que permite a los titulares de nombres de dominio indicar a las autoridades de certificación si están autorizados a emitir certificados digitales para un nombre de dominio en particular . Lo hace mediante un nuevo registro de recursos del Sistema de nombres de dominio (DNS) "CAA" .
Estado | Norma propuesta |
---|---|
Publicado por primera vez | 18 de octubre de 2010 |
Ultima versión | RFC 8659 Noviembre de 2019 |
Organización | IETF |
Autores |
|
Abreviatura | CAA |
Fue redactado por los informáticos Phillip Hallam-Baker y Rob Stradling en respuesta a las crecientes preocupaciones sobre la seguridad de las autoridades de certificación de confianza pública. Es un estándar propuesto por el Grupo de Trabajo de Ingeniería de Internet (IETF) .
Fondo
Una serie de certificados emitidos incorrectamente desde 2001 en adelante [1] [2] dañó la confianza en las autoridades de certificación de confianza pública, [3] y aceleró el trabajo en varios mecanismos de seguridad, incluida la transparencia de certificados para rastrear la emisión incorrecta , la fijación de claves públicas HTTP y el DANE para bloquear los certificados emitidos incorrectamente en el lado del cliente y CAA para bloquear la emisión incorrecta en el lado de la autoridad de certificación. [4]
El primer borrador de CAA fue escrito por Phillip Hallam-Baker y Rob Stradling, y presentado como un Borrador de Internet IETF en octubre de 2010. [5] Este fue mejorado progresivamente por el Grupo de Trabajo PKIX , [6] y aprobado por el IESG como RFC 6844 , un estándar propuesto , en enero de 2013. [7] El debate CA / Browser Forum comenzó poco después, [4] y en marzo de 2017 votaron a favor de que la implementación de CAA fuera obligatoria para todas las autoridades de certificación para septiembre de 2017. [8] [9] Al menos una autoridad certificadora, Comodo , no implementó CAA antes de la fecha límite. [10] Un estudio de 2017 de la Universidad Técnica de Múnich encontró muchos casos en los que las autoridades de certificación no implementaron correctamente alguna parte del estándar. [4]
En septiembre de 2017, Jacob Hoffman-Andrews presentó un Borrador de Internet destinado a simplificar el estándar CAA. Esto fue mejorado por el Grupo de Trabajo LAMPS y aprobado como RFC 8659 , una propuesta de norma, en noviembre de 2019. [11]
A partir de enero de 2020[actualizar], Qualys informa que todavía, sólo el 6,8% de los 150.000 sitios web que admiten TLS más populares utilizan registros CAA. [12]
Registro
Las autoridades de certificación que implementan CAA realizan una búsqueda de DNS para los registros de recursos de CAA y, si se encuentra alguno, asegúrese de que estén incluidos como parte autorizada antes de emitir un certificado digital . Cada registro de recursos de CAA consta de los siguientes componentes: [11]
- bandera
- Un byte de banderas que implementa un sistema de señalización extensible para uso futuro. A partir de 2018 [actualizar], solo se ha definido la bandera de emisor crítico , que indica a las autoridades de certificación que deben comprender la etiqueta de propiedad correspondiente antes de emitir un certificado. [11] Esta bandera permite que el protocolo se extienda en el futuro con extensiones obligatorias, [4] similar a las extensiones críticas en los certificados X.509 .
- etiqueta
- Una de las siguientes propiedades:
- asunto
- Esta propiedad autoriza al titular del dominio especificado en el valor de la propiedad asociada a emitir certificados para el dominio para el que se publica la propiedad.
- tema salvaje
- Esta propiedad actúa como problema, pero solo autoriza la emisión de certificados comodín y tiene prioridad sobre la propiedad de emisión para las solicitudes de certificado comodín.
- iodef
- Esta propiedad especifica un método para que las autoridades de certificación notifiquen solicitudes de certificado no válidas al titular del nombre de dominio mediante el formato de intercambio de descripción de objeto de incidente . A partir de 2018 [actualizar], no todas las autoridades de certificación admiten esta etiqueta, por lo que no hay garantía de que se notifiquen todas las emisiones de certificados.
- Email de contacto
- Cada vez más, la información de contacto no está disponible en WHOIS debido a preocupaciones sobre posibles infracciones del RGPD. Esta propiedad permite a los titulares de dominios publicar información de contacto en DNS. [13] [14]
- teléfono de contacto
- Como arriba, para los números de teléfono. [15]
- valor
- El valor asociado con la etiqueta de propiedad elegida.
La falta de cualquier registro de CAA autoriza la emisión normal sin restricciones, y la presencia de una sola etiqueta de emisión en blanco no permite toda emisión. [11] [9] [16]
Los terceros que monitorean el comportamiento de la autoridad de certificación pueden verificar los certificados recién emitidos con los registros de CAA del dominio, pero deben tener en cuenta que los registros de CAA de un dominio pueden haber cambiado entre el momento en que se emitió el certificado y el momento en que el tercero los verifica. Los clientes no deben utilizar CAA como parte de su proceso de validación de certificados. [11]
Extensiones
RFC 8657 especifica "accounturi"
y "validationmethods"
parámetros que permiten a los usuarios especificar los métodos deseados de validación de control de dominio como se define en el protocolo ACME . Por ejemplo, el administrador del sitio web puede vincular un dominio que controlan a una cuenta particular registrada con la Autoridad de Certificación deseada.
Historia
El 26 de octubre de 2016 se publicó un borrador de la primera extensión del estándar CAA, que proponía un nuevo token uri de cuenta al final de la propiedad de emisión , que vincula un dominio a una cuenta específica del Entorno de gestión de certificados automatizados . [17] Esto se modificó el 30 de agosto de 2017 para incluir también un nuevo token de métodos de validación , que vincula un dominio a un método de validación específico, [18] y luego se modificó nuevamente el 21 de junio de 2018 para eliminar el guión en la cuenta -uri y validation-methods convirtiéndolos en cuentauri y validationmethods . [19]
Ejemplos de
Para indicar que solo la autoridad de certificación identificada por ca.example.net está autorizada a emitir certificados para example.com y todos los subdominios, se puede usar este registro CAA: [11]
ejemplo.com. EN CAA 0 problema "ca.example.net"
Para rechazar cualquier emisión de certificado, se puede permitir la emisión solo a una lista de emisores vacía:
ejemplo.com. EN CAA 0 problema ";"
Para indicar que las autoridades de certificación deben informar las solicitudes de certificados no válidas a una dirección de correo electrónico y un punto final de Defensa entre redes en tiempo real :
ejemplo.com. EN CAA 0 iodef "mailto: [email protected]"ejemplo.com. EN CAA 0 iodef "http://iodef.example.com/"
Para usar una extensión futura del protocolo, por ejemplo, una que defina una nueva propiedad futura , que debe ser entendida por la autoridad de certificación antes de que puedan proceder de manera segura, se puede establecer la bandera crítica del emisor :
ejemplo.com. EN CAA 0 problema "ca.example.net"ejemplo.com. IN CAA 128 "valor" futuro
Incidentes de cumplimiento conocidos
En 2017, se descubrió que Camerfirma validaba incorrectamente los registros de CAA. Camerfirma afirmó haber entendido mal los requisitos básicos de CA / Browser Forum que describen la validación de CAA. [20]
A principios de 2020, Let's Encrypt reveló que su software consultaba y validaba incorrectamente los registros de CAA que podrían afectar a más de 3 millones de certificados. [21] Let's Encrypt trabajó con clientes y operadores de sitios para reemplazar más de 1,7 millones de certificados, pero decidió no revocar el resto para evitar el tiempo de inactividad del cliente y dado que todos los certificados afectados caducarían en menos de 90 días. [22]
Ver también
- Compromiso de la autoridad de certificación
- Transparencia del certificado
- Autenticación basada en DNS de entidades nombradas
- Fijación de claves públicas HTTP
- Lista de tipos de registros DNS
Referencias
- ^ Ristić, Ivan. "Historial de SSL / TLS y PKI" . Pato luchador . Consultado el 8 de junio de 2018 .
- ^ Bright, Peter (30 de agosto de 2011). "Otro certificado fraudulento plantea las mismas viejas preguntas sobre las autoridades de certificación" . Ars Technica . Consultado el 10 de febrero de 2018 .
- ^ Ruohonen, Jukka (2019). "Una encuesta empírica sobre la adopción temprana de la autorización de la autoridad de certificación del DNS". Revista de tecnología de seguridad cibernética . 3 (4): 205–218. arXiv : 1804.07604 . doi : 10.1080 / 23742917.2019.1632249 . S2CID 5027899 .
- ^ a b c d Scheitle, Quirin; Chung, Taejoong; et al. (Abril de 2018). "Un primer vistazo a la autorización de la autoridad de certificación (CAA)" (PDF) . Revisión de comunicación informática ACM SIGCOMM . 48 (2): 10–23. doi : 10.1145 / 3213232.3213235 . ISSN 0146-4833 . S2CID 13988123 .
- ^ Hallam-Baker, Phillip ; Stradling, Rob (18 de octubre de 2010). Registro de recursos de autorización de la autoridad de certificación del DNS (CAA) . IETF . Proyecto de identificación-hallambaker-donotissue-00. CS1 maint: parámetro desalentado ( enlace )
- ^ Hallam-Baker, Phillip ; A horcajadas, Rob; Ben, Laurie (2 de junio de 2011). Registro de recursos de autorización de la autoridad de certificación del DNS (CAA) . IETF . Proyecto de identificación-ietf-pkix-caa-00. CS1 maint: parámetro desalentado ( enlace )
- ^ Hallam-Baker, Phillip ; Stradling, Rob (enero de 2013). Registro de recursos de autorización de la autoridad de certificación del DNS (CAA) . IETF . doi : 10.17487 / RFC6844 . ISSN 2070-1721 . RFC 6844 . CS1 maint: parámetro desalentado ( enlace )
- ^ Hall, Kirk (8 de marzo de 2017). "Resultados en la balota 187 - Hacer obligatoria la verificación CAA" . CA / Foro de navegadores . Consultado el 7 de enero de 2018 .
- ^ a b Beattie, Doug (22 de agosto de 2017). "¿Qué es CAA (autorización de la autoridad de certificación)?" . GlobalSign . Consultado el 2 de febrero de 2018 .
- ^ Cimpanu, Catalin (11 de septiembre de 2017). "Comodo atrapado rompiendo el nuevo estándar CAA un día después de que entró en vigor" . Ordenador que suena . Consultado el 8 de enero de 2018 .
- ^ a b c d e f Registro de recursos de autorización de la autoridad de certificación del DNS (CAA) . IETF . Noviembre de 2019. doi : 10.17487 / RFC8659 . ISSN 2070-1721 . RFC 8659 .
- ^ "Pulso SSL" . Laboratorios SSL . Qualys . 3 de enero de 2020 . Consultado el 31 de enero de 2020 .
- ^ "Infraestructura de clave pública usando parámetros X.509 (PKIX)" . www.iana.org . Consultado el 22 de agosto de 2020 .
- ^ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf
- ^ Beattie, Doug (7 de enero de 2019). "Boleta SC14: Propiedad de contacto CAA y métodos asociados de validación telefónica" . CA / Browser Forum (lista de correo) . Consultado el 19 de octubre de 2020 .
- ^ "¿Qué es la autorización de la autoridad de certificación (CAA)?" . Symantec . Consultado el 8 de enero de 2018 .
- ^ Landau, Hugo (26 de octubre de 2016). Extensiones de registro CAA para enlace de método ACME y URI de cuenta . IETF . Proyecto de identificación-ietf-acme-caa-00.
- ^ Landau, Hugo (30 de agosto de 2017). Extensiones de registro CAA para enlace de método ACME y URI de cuenta . IETF . Proyecto de identificación-ietf-acme-caa-04.
- ^ Landau, Hugo (21 de junio de 2018). Extensiones de registro CAA para enlace de método ACME y URI de cuenta . IETF . Proyecto de identificación-ietf-acme-caa-05.
- ^ "CA: Problemas de Camerfirma - MozillaWiki" . wiki.mozilla.org . Consultado el 27 de abril de 2021 .
- ^ Claburn, Thomas (3 de marzo de 2020). "Let's Encrypt? Vamos a revocar 3 millones de certificados HTTPS el miércoles, más como: Verifique los errores del bucle de código" . www.theregister.com . Consultado el 27 de abril de 2021 .
- ^ Barrett, Brian (3 de marzo de 2020). "Internet evitó un desastre menor la semana pasada" . Cableado . ISSN 1059-1028 . Consultado el 27 de abril de 2021 .
enlaces externos
- RFC 8659
- Lista de identificadores de CA para su uso en registros CAA en Common CA Database