2013年にRFC 6844で定義されたCAA（Certification Authority Authorization）は、特定のドメインに対して証明書を発行できる認証機関を制御する新しい手段でPKIエコシステム（公開キー基盤）を強化するために提案されました。 。
CAAが4年以上前に導入されたという事実にもかかわらず、今日ではまだほとんど知られておらず、現時点では100か約200のサイトでしか使用されていません。 ただし、認証局とブラウザ開発者のフォーラム（CA /ブラウザフォーラム）は、CAAをセキュリティ証明書を発行するための基本条件の標準セットの一部として必須として承認しているため、重要な変更が行われています。 新しい基準は2017年9月に施行されます。
任意のドメインの任意の証明機関（CA）がセキュリティ証明書を発行する機能は、PKIエコシステムの最も弱い点として繰り返し示されています。 認定センターは特定の一般規則に違反することなく運営されるべきであるという事実にもかかわらず、彼らが何をしているかを監視する技術的手段はまだありません。 ここから、システム内、および数百のCAが存在する特定の弱いリンクが発生します。そのようなリンクは、それぞれ数百です。
CAAは、ドメイン所有者がドメインの証明書を発行できるDNSレコードのレベルでセンターのホワイトリストを作成できるメカニズムを作成します。 これを行うために、新しいDNSリソースレコードであるCAA（タイプ257）が導入されました。 ドメイン所有者は、このエントリで認証局アドレスを明示的に指定することにより、証明書の発行を制限します。
たとえば、次のように：
example.org。 CAA 128の問題「letsencrypt.org」
そしてそれだけです。 ドメインの証明書を発行する前に、CAはそのCAA DNSリソースレコードを確認し、そのアドレスが見つかった場合にのみ証明書を発行します。 上記の例の「issue」ディレクティブに加えて、拡張ワイルドカード証明書の発行を制限する「issuewild」ディレクティブ、および何かがうまくいかない場合にCAが連絡できるURLを含む「iodef」ディレクティブもあります認定ポリシーまたは技術的な問題。 （128は上位ビットが設定された制御バイトであり、このディレクティブが重要であり、無条件に実行する必要があることを示します）。
いくつかの観点から、CAAはHPKP（HTTP公開キーピニング）とほぼ同じ機能を実行しますが、わずかに異なる方法で実行します。 まず、CAAは証明書の発行を防ぎますが、HPKPは実行時にクライアント側の検証を実行し、既に発行された証明書を有効または無効として識別します。
第二に、HPKPはブラウザ用であり、CAAは認証機関用です。 キーのリストを提供するHPKPは技術的な制御手段であり、CAAはより多くの管理制御を実行します。 はい。CAAレコードに一貫性がない場合、認証局は証明書の発行を停止しますが、認証局は手動モードに切り替え、リクエストがまだ本物と見なされる場合はリリースを決定することができます。 はい、これもまた困難です-多くの認証センターがあり、それらの主な問題は、特定の「社会的」圧力要因に耐え、それにもかかわらずCAAレコードの違反の場合に特定の正式な規則に従うことです。
しかし、CAAが役に立たない、またはHPKPと交差すると言うことは価値がありません。 特にHPKPと比較して、特定の利点があります。CAAには、オンラインスペースでの財産権の濫用や侵害の機会が少なくなります。
誤動作している場合、HPKPはWebビジネスを完全に台無しにする可能性があり、CAAは何かがうまくいかない場合にわずかに迷惑になります。
さらに、「Webリソースの所有権を確認するために公開キーを添付する」ことは、CAA DNSレコードの単純さに比べて複雑で扱いにくいため、潜在的なHPKPユーザーを怖がらせます。
パブリックドメインのDNSレコードの構成を分析するオンラインサービスを使用して、CAAレコードの可用性を確認できます。