# Autorización de la Autoridad de Certificación

Autorización de la Autoridad de Certificación en el Sistema de Nombres de Dominio (en idioma inglés: "DNS Certification Authority Authorization"), abreviado como DNS CAA o simplemente CAA, es un mecanismo de política de seguridad en Internet que permite a los titulares de nombres de dominio indicar a las autoridades certificadoras si están autorizadas a emitir certificados digitales para un nombre de dominio particular utilizando un registro de recursos del Sistema de Nombres de Dominio (DNS). Fue redactado por 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. Actualmente es un estándar propuesto de la Grupo de Trabajo de Ingeniería de Internet (IETF).

## Historia

Una serie de certificados emitidos incorrectamente a partir de 2001 dañó la confianza en las autoridades certificadoras de confianza pública, y aceleraron el trabajo en varios mecanismos de seguridad, incluida la transparencia del certificado para rastrear errores de emisión, HTTP Public Key Pinning y DANE a bloquear certificados emitidos erróneamente en el lado del cliente, y CAA para bloquear la emisión errónea en el lado de la autoridad certificadora. El primer borrador de CAA fue escrito por Phillip Hallam-Baker y Rob Stradling, y presentado como borrador de Internet del IETF en octubre de 2010. Esto fue progresivamente mejorado por el Grupo de Trabajo PKIX, y presentado al IESG como RFC 6844, un Estándar Propuesto, en enero de 2013. El software BIND, el cual es un estándar de facto en el campo de los DNS, adoptó el uso de la norma CAA en la versión 9.10.1B en agosto de 2014.
La discusión en CA/Browser Forum comenzó poco después, y en marzo de 2017 votaron a favor de que la implementación de la CAA sea obligatoria para todas las autoridades de certificación en septiembre de 2017. Al menos una autoridad de certificación, Comodo, no implementó CAA antes de la fecha límite. Los servidores DNS de Microsoft Azure fueron actualizados para prestar este servicio en noviembre de 2017. Un estudio de 2017 realizado por la Universidad Técnica de Múnich encontró muchas instancias en las que las autoridades de certificación no implementaron correctamente alguna parte del estándar. A partir de junio de 2018, Qualys informa que el 3,4% de los 150,000 sitios web más populares de TLS respaldan los registros de CAA.

## Normativa

El registro CAA se caracteriza por tres propiedades fundamentales:
* Bandera o indicador, flag: un valor entero sin signo, 0 para valor normal, 1 (o mayor) para representar el indicador crítico que tiene un significado específico según la norma RFC 6844.
* Etiqueta, tag: una cadena de texto ASCII que puede albergar uno de los siguientes valores
** issue: permite a los propietarios del dominio especificar las Autoridades de Certificación a las que se les permite emitir todos los tipos de certificados.
** issuewild: permite a los propietarios del dominio especificar las Autoridades de Certificación a las que se les permite emitir certificados de todos los tipos (solo certificados con comodines del tipo *.example.com pero no del tipo *.mail.example.com)
** iodef (Incident Object Description Exchange Format, RFC 5070, RFC 6685 y RFC 7970): permite a los propietarios de dominios especificar una dirección de correo electrónico (mailto:) o un nombre de anfitrión al que las Autoridades de Certificación pueden notificar las solicitudes de emisión de certificados para dominios que de otro modo no estarían autorizados a través de los registros CAA, según formato XML especificado en RFC 6546.
* Valor: el valor asociado con la etiqueta específica utilizada.
Además se encuentran reservadas para uso futuro las siguientes tres propiedades: auth, path y policy (HB2011 RFC 6844).
Para aquellos servidores DNS que aun no hayan implementado los CAA o les sean desconocidos, deberán responder a las solicitudes con un código de NOERROR en vez de un código NOTIMP (NOT IMPlement) de acuerdo a RFC 1035.
Esta normativa es apenas un paliativo de seguridad: un atacante sofisticado podría establecer un falso servicio de DNS, por ejemplo en un lugar público ofreciendo acceso a Internet de manera inalámbrica y gratuita.

## Ejemplos

Para informar a las autoridades de certificación que solo la autoridad de certificación identificada por ca.example.net está autorizada para emitir certificados para example.com y todos los subdominios, y que las autoridades de certificación deben informar de las solicitudes de certificado no válidas a seguridad@example.net, uno puede usar este registro CAA:
Para rechazar cualquier emisión de certificado, uno puede permitir la emisión solo a una lista de emisor vacía:
Al usar un subdominio, las autoridades de certificación escalan el árbol de nombres DNS buscando un registro CAA hasta que encuentran uno o alcanzan el dominio de segundo nivel, en este ejemplo la Autoridad Certificadora permitirá avalar certificados para example.com y certs.nocerts.example.com pero no para nocerts.example.com:
Si un registro está vacío, cualquier registro CNAME se verifican para un registro CAA antes de pasar a un subdominio superior:
Autorizar la emisión de certificados normales, mientras se restringe la emisión de certificado comodín:
Para autorizar la emisión de example.com pero no de nocerts.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 certificadora antes de que puedan proceder de manera segura, se puede configurar la bandera emisor crítico (128):