跳至內容

DNS證書頒發機構授權

這是一篇優良條目，請按此取得更多資訊。
本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
互聯網安全協議（英語：Internet security）
密鑰管理
應用層
域名系統
網絡層

DNS證書頒發機構授權（英語：DNS Certification Authority Authorization，簡稱：CAA）是一種互聯網安全（英語：Internet security）政策機制，允許域名持有人指定可以為其域簽發證書的證書頒發機構。該政策憑藉一個新的域名系統資源記錄「CAA」來實現。

這一標準由計算機科學家菲利普·哈勒姆-貝克（英語：Phillip Hallam-Baker）和羅布·斯特拉德林（Rob Stradling）起草，旨在應對公眾對證書頒發機構安全性的擔憂。它是由互聯網工程任務組建議的一項互聯網標準。

背景

自2001年開始，曾出現一系列被錯誤頒發的數字證書[1][2]。這在損害公開可信證書授權機構可信度的同時[3]，也加速了各種安全機制的建設，包括證書透明度追蹤不當簽發，HTTP公鑰固定和DANE（英語：DANE）在客戶端側（英語：client-side）阻止不當簽發的證書，以及DNS證書頒發機構授權（CAA）在證書頒發機構方面阻止不當簽發。[4]

DNS證書頒發機構授權的第一稿由菲利普·哈勒姆-貝克（英語：Phillip Hallam-Baker）和羅布·斯特拉德林（Rob Stradling）起草，並於2010年10月提交為互聯網工程任務組（IETF）的互聯網標準（RFC）草案。[5]PKIX工作組（英語：X.509#PKIX Working Group）對此進行了逐步改進[6]，並於2013年1月向互聯網工程指導小組（英語：Internet Engineering Steering Group）提交了名為RFC 6844的標準提案。[7]不久後CA/瀏覽器論壇展開討論[4]，並於2017年3月形成投票，贊成於2017年9月之前強制所有證書頒發機構履行CAA[8][9]。但至少有一家證書頒發機構（科摩多）未能在截止日期前實施CAA[10]。慕尼黑工業大學於2017年的一項研究發現，證書頒發機構在很多情況下未能正確施行該標準的部分內容。[4]

截至2018年6月 (2018-06)，Qualys（英語：Qualys）的報告顯示，在最流行且支持TLS的前15萬個網站中，只有3.4%使用了CAA記錄。[11]

記錄

實現CAA的證書頒發機構對CAA資源記錄執行DNS查找，並檢查自己是否被列為授權方，之後再頒發數字證書。[7]每條CAA資源記錄由以下三個屬性組成，並以空格分隔[7]：

flag
一個實現了可擴展的（英語：Extensible）信號系統的位段，以供將來使用。截至2018年 (2018-Missing required parameter 1=month!)，它僅定義了發行者關鍵標誌，用於指示證書頒發機構在頒發證書之前必須理解相應的屬性標記。[7]此標誌允許將來通過強制擴展對協議進行擴展[4]，類似於X.509證書中的關鍵擴展。
tag
為下列屬性之一：
issue
此屬性授權關聯屬性值中指定的域名的持有者，向包含該屬性的域名頒發證書。
issuewild
此屬性的作用類似於上述的issue屬性，但僅授權頒發通配符證書。當請求為通配符證書時，這一屬性優先於issue屬性。
iodef
此屬性指定證書頒發機構使用「事件對象描述交換格式（英語：Incident Object Description Exchange Format）」（Incident Object Description Exchange Format，簡稱：IODEF）向域名持有者報告無效證書請求的方法。截至2018年 (2018-Missing required parameter 1=month!)，並非所有證書頒發機構都支持此標籤，因此不能保證所有證書在頒發時都會被報告。
value
與所選的tag屬性所相關聯的值。

當沒有任何CAA記錄時，頒發機構可以正常、不受限地進行頒發。而當存在一個空白的簽發（issue）標籤時，所有頒發被禁止。[7][9][12]

監視證書頒發機構行為的第三方，可能會根據域名的CAA記錄檢查新頒發的證書，但是他們須知道域名的CAA記錄有可能在證書頒發到他們檢查的期間發生過更改。客戶不能將CAA作為其證書驗證過程的一部分。[7]

擴展

2016年10月26日，CAA標準的首個擴展草案發布。該草案在簽發（issue）屬性後方提議了一個新的account-uri標識，其將一個域名綁定到一個特定的自動化證書管理環境（英語：Automated Certificate Management Environment）帳戶。[13]2017年8月30日，這一草案得到修訂，再引入了validation-methods（驗證方法）標識，用以將一個域與一個特定的驗證方法綁定。2018年6月21日，進一步的修改刪除了account-uri和validation-methods的連字符，accounturi和validationmethods取而代之。[14][15]

例子

若要表明只有標識為ca.example.net的證書頒發機構有權為example.com及所有子域名頒發證書，可以使用以下CAA記錄[7]：

example.com. IN CAA 0 issue "ca.example.net"

若要禁止頒發任何證書，可以列出一個空的頒發者列表[7]：

example.com. IN CAA 0 issue ";"

若要標識證書頒發機構應將無效的證書請求報告給指定的電子郵件地址和實時網絡間防禦（英語：Real-time Inter-network Defense）端點[7]：

example.com. IN CAA 0 iodef "mailto:[email protected]"
example.com. IN CAA 0 iodef "http://iodef.example.com/"

若要使用該協議的一個未來擴展——例如，定義了一個新的future屬性，需要證書頒發機構理解該屬性後才能安全地繼續處理——可以設置issuer critical標籤[7]：

example.com. IN CAA 0 issue "ca.example.net"
example.com. IN CAA 128 future "value"

另見

參考來源

  1. ^ Ristić, Ivan. SSL/TLS and PKI History. Feisty Duck. [2018-06-08]. （原始內容存檔於2018-03-11） （英語）. 
  2. ^ Bright, Peter. Another fraudulent certificate raises the same old questions about certificate authorities. Ars Technica. 2011-08-30 [2018-02-10]. （原始內容存檔於2018-02-10） （美國英語）. 
  3. ^ Ruohonen, Jukka. An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization. April 20, 2018. arXiv:1804.07604 可免費查閱 [cs.CR]. 
  4. ^ 4.0 4.1 4.2 4.3 Scheitle, Quirin; Chung, Taejoong; et al. A First Look at Certification Authority Authorization (CAA) (PDF). ACM SIGCOMM Computer Communication Review. April 2018, 48 (2): 10–23 [2019-05-19]. ISSN 0146-4833. doi:10.1145/3213232.3213235. （原始內容存檔 (PDF)於2018-06-12）. 
  5. ^ Hallam-Baker, Phillip; Stradling, Rob. DNS Certification Authority Authorization (CAA) Resource Record. IETF. 2010-10-18. I-D draft-hallambaker-donotissue-00. 
  6. ^ Hallam-Baker, Phillip; Stradling, Rob; Ben, Laurie. DNS Certification Authority Authorization (CAA) Resource Record. IETF. 2011-06-02. I-D draft-ietf-pkix-caa-00. 
  7. ^ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 Hallam-Baker, Phillip; Stradling, Rob. DNS Certification Authority Authorization (CAA) Resource Record. IETF. January 2013.
    doi:10.17487/RFC6844
    . RFC 6844.
    ISSN 2070-1721
    .     
  8. ^ Hall, Kirk. Results on Ballot 187 - Make CAA Checking Mandatory. CA/Browser Forum. 2017-03-08 [2018-01-07]. （原始內容存檔於2017-09-29）. 
  9. ^ 9.0 9.1 Beattie, Doug. What is CAA (Certificate Authority Authorization)?. GlobalSign. 2017-08-22 [2018-02-02]. （原始內容存檔於2018-02-03） （英語）. 
  10. ^ Cimpanu, Catalin. Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect. Bleeping Computer. 2017-09-11 [2018-01-08]. （原始內容存檔於2017-09-15） （英語）. 
  11. ^ SSL Pulse. SSL Labs. Qualys. 2018-06-03 [2018-06-09]. （原始內容存檔於2017-12-02）. 
  12. ^ What is Certificate Authority Authorization (CAA)?. Symantec. [2018-01-08]. （原始內容存檔於2018-01-08）. 
  13. ^ Landau, Hugo. CAA Record Extensions for Account URI and ACME Method Binding. IETF. 2016-10-26. I-D draft-ietf-acme-caa-00. 
  14. ^ Landau, Hugo. CAA Record Extensions for Account URI and ACME Method Binding. IETF. 2017-08-30. I-D draft-ietf-acme-caa-04. 
  15. ^ Landau, Hugo. CAA Record Extensions for Account URI and ACME Method Binding. IETF. 2018-06-21. I-D draft-ietf-acme-caa-05. 

外部連結

取自「https://zh.wikipedia.org/w/index.php?title=DNS证书颁发机构授权&oldid=71805807」