Can you summarize the following document?
        
  自2001年開始,曾出現一系列被錯誤頒發的數字證書。這在損害公開可信證書授權機構可信度的同時,也加速了各種安全機制的建設,包括證書透明度追蹤不當簽發,HTTP公鑰固定和DANE在客戶端側阻止不當簽發的證書,以及DNS證書頒發機構授權(CAA)在證書頒發機構方面阻止不當簽發。  DNS證書頒發機構授權的第一稿由和羅布·斯特拉德林()起草,並於2010年10月提交為網際網路工程任務組(IETF)的網際網路標準(RFC)草案。對此進行了逐步改進,並於2013年1月向提交了名為的標準提案。不久後CA/瀏覽器論壇展開討論,並於2017年3月形成投票,贊成於2017年9月之前強制所有證書頒發機構履行CAA。但至少有一家證書頒發機構(科摩多)未能在截止日期前實施CAA。慕尼黑工業大學於2017年的一項研究發現,證書頒發機構在很多情況下未能正確施行該標準的部分內容。 ,的報告顯示,在最流行且支援TLS的前15萬個網站中,只有3.4%使用了CAA記錄。

  實現CAA的證書頒發機構對CAA資源記錄執行DNS查詢,並檢查自己是否被列為授權方,之後再頒發數字證書。每條CAA資源記錄由以下三個屬性組成,並以空格分隔:  當沒有任何CAA記錄時,頒發機構可以正常、不受限地進行頒發。而當存在一個空白的簽發(issue)標籤時,所有頒發被禁止。  監視證書頒發機構行為的第三方,可能會根據域名的CAA記錄檢查新頒發的證書,但是他們須知道域名的CAA記錄有可能在證書頒發到他們檢查的期間發生過更改。客戶不能將CAA作為其證書驗證過程的一部分。

  2016年10月26日,CAA標準的首個擴充套件草案發布。該草案在簽發(issue)屬性後方提議了一個新的account-uri標識,其將一個域名繫結到一個特定的帳戶。2017年8月30日,這一草案得到修訂,再引入了validation-methods(驗證方法)標識,用以將一個域與一個特定的驗證方法繫結。2018年6月21日,進一步的修改刪除了account-uri和validation-methods的連字元,accounturi和validationmethods取而代之。

  若要表明只有標識為ca.example.net的證書頒發機構有權為example.com及所有子域名頒發證書,可以使用以下CAA記錄:  若要禁止頒發任何證書,可以列出一個空的頒發者列表:  若要標識證書頒發機構應將無效的證書請求報告給指定的電子郵件地址和端點:  若要使用該協議的一個未來擴充套件——例如,定義了一個新的future屬性,需要證書頒發機構理解該屬性後才能安全地繼續處理——可以設定issuer critical標籤:
DNS證書頒發機構授權(英語:DNS Certification Authority Authorization,簡稱:英語:CAA)是一種政策機制,允許域名持有人指定可以為其域簽發證書的證書頒發機構。該政策憑藉一個新的域名系統資源記錄“CAA”來實現。