The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain.Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.
Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification control to be performed by a relying party after the certificate is issued.
[...]
A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain. Since a certificate is typically valid for at least a year, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Applications MUST NOT use CAA records as part of certificate validation.
[...]
CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take account of the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator.
[...]
Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies.
L'idée est intéressante. Elle peut permettre de limiter la casse quand un revendeur (qui dispose d'une API auprès d'une AC bien établie) se fait dégommer ou autre (comme dans le cas de l'émission de faux certificats x509 par Comodo en 2011 (d'où les auteurs du présent RFC sont des employés de Comodo ?)). Ça sera inutile dans un cas où l'AC se fait totalement trouer (comme dans le cas de l'attaque contre Diginotar en 2011) car, dans ce cas, la vérification logicielle sera contournée. C'est aussi inutile contre un attaquant client de la même AC (ce qui est devenu fréquent avec Let's Encrypt), sauf à utiliser les extensions de CAA permettant de préciser quel compte LE et/ou quelle méthode de validation sont autorisés.
Dommage d'avoir salopé cette bonne idée en introduisant la possibilité d'un contournement du résultat de la validation en se basant sur la politique de certification propre à chaque AC. En gros, on laisse à chaque AC la possibilité d'implémenter puis ensuite de débrayer la sécurité ajoutée en fonction d'un contrat moral… Ça signifie qu'il y aura une fonctionnalité prévue, codée dans le logiciel d'émission de certificats utilisé par l'AC, pour débrayer la sécurité. Fonctionnalité que le pirate pourra utiliser tranquillou. :)
De plus, tous les logiciels ont des bugs : « Let's Encrypt announced that it had discovered a bug in its CAA (Certification Authority Authorization) code. The bug opens up a window of time in which a certificate might be issued even if a CAA record in that domain's DNS should prohibit it. » (source).