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. 

外部链接