跳至內容

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」