Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 6844 Comodo Group, Inc.
Category: Standards Track R. Stradling
ISSN: 2070-1721 Comodo CA, Ltd.
January 2013
Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 6844 Comodo Group, Inc.
Category: Standards Track R. Stradling
ISSN: 2070-1721 Comodo CA, Ltd.
January 2013
DNS Certification Authority Authorization (CAA) Resource Record
DNS证书颁发机构授权（CAA）资源记录
Abstract
摘要
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers.
证书颁发机构授权（CAA）DNS资源记录允许DNS域名持有人指定一个或多个被授权为该域颁发证书的证书颁发机构（CA）。CAA资源记录允许公共认证机构实施额外的控制，以降低意外证书错误颁发的风险。本文件定义了CAA记录的语法以及证书颁发者处理CAA记录的规则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6844.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6844.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Requirements Language ......................................3
2.2. Defined Terms ..............................................3
3. The CAA RR Type .................................................5
4. Certification Authority Processing ..............................7
4.1. Use of DNS Security ........................................8
5. Mechanism .......................................................8
5.1. Syntax .....................................................8
5.1.1. Canonical Presentation Format ......................10
5.2. CAA issue Property ........................................10
5.3. CAA issuewild Property ....................................12
5.4. CAA iodef Property ........................................12
6. Security Considerations ........................................13
6.1. Non-Compliance by Certification Authority .................13
6.2. Mis-Issue by Authorized Certification Authority ...........13
6.3. Suppression or Spoofing of CAA Records ....................13
6.4. Denial of Service .........................................14
6.5. Abuse of the Critical Flag ................................14
7. IANA Considerations ............................................14
7.1. Registration of the CAA Resource Record Type ..............14
7.2. Certification Authority Restriction Properties ............15
7.3. Certification Authority Restriction Flags .................15
8. Acknowledgements ...............................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Requirements Language ......................................3
2.2. Defined Terms ..............................................3
3. The CAA RR Type .................................................5
4. Certification Authority Processing ..............................7
4.1. Use of DNS Security ........................................8
5. Mechanism .......................................................8
5.1. Syntax .....................................................8
5.1.1. Canonical Presentation Format ......................10
5.2. CAA issue Property ........................................10
5.3. CAA issuewild Property ....................................12
5.4. CAA iodef Property ........................................12
6. Security Considerations ........................................13
6.1. Non-Compliance by Certification Authority .................13
6.2. Mis-Issue by Authorized Certification Authority ...........13
6.3. Suppression or Spoofing of CAA Records ....................13
6.4. Denial of Service .........................................14
6.5. Abuse of the Critical Flag ................................14
7. IANA Considerations ............................................14
7.1. Registration of the CAA Resource Record Type ..............14
7.2. Certification Authority Restriction Properties ............15
7.3. Certification Authority Restriction Flags .................15
8. Acknowledgements ...............................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.
证书颁发机构授权（CAA）DNS资源记录允许DNS域名持有人指定有权为该域颁发证书的证书颁发机构（CA）。CAA资源记录的发布允许公共认证机构实施额外的控制措施，以降低意外证书错误颁发的风险。
Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification control to be performed by a relying party after the certificate is issued.
与基于DNS的命名实体身份验证（DANE）[RFC6698]中定义的TLSA记录一样，CAA记录被用作检查PKIX证书数据的机制的一部分。这两个规范之间的区别在于，CAA记录规定了证书颁发者在颁发证书之前要执行的授权控制，TLSA记录规定了依赖方在颁发证书之后要执行的验证控制。
Conformance with a published CAA record is a necessary but not sufficient condition for issuance of a certificate. Before issuing a certificate, a PKIX CA is required to validate the request according to the policies set out in its Certificate Policy. In the case of a public CA that validates certificate requests as a third party, the certificate will typically be issued under a public trust anchor certificate embedded in one or more relevant Relying Applications.
符合公布的CAA记录是颁发证书的必要条件，但不是充分条件。在颁发证书之前，需要PKIX CA根据其证书策略中规定的策略验证请求。在作为第三方验证证书请求的公共CA的情况下，证书通常将在嵌入一个或多个相关应用程序中的公共信任锚证书下颁发。
Criteria for inclusion of embedded trust anchor certificates in applications are outside the scope of this document. Typically, such criteria require the CA to publish a Certificate Practices Statement (CPS) that specifies how the requirements of the Certificate Policy (CP) are achieved. It is also common for a CA to engage an independent third-party auditor to prepare an annual audit statement of its performance against its CPS.
在应用程序中包含嵌入式信任锚证书的标准不在本文档的范围内。通常，此类标准要求CA发布证书实践声明（CPS），该声明指定如何实现证书策略（CP）的要求。CA通常也会聘请独立的第三方审计师根据其CPS编制年度审计报告。
A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain. Since a certificate is typically valid for at least a year, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Applications MUST NOT use CAA records as part of certificate validation.
一组CAA记录仅描述为相应DNS域颁发证书的当前授权。由于证书通常至少有效一年，因此与当前发布的CAA记录不一致的证书可能与颁发证书时发布的CAA记录一致。依赖申请不得使用CAA记录作为证书验证的一部分。
CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take account of the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator.
CAA记录可被证书评估人员用作违反安全策略的可能指标。这种使用应考虑到在颁发证书和证书评估员观察证书期间，已发布的CAA记录发生变化的可能性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following terms are used in this document:
本文件中使用了以下术语：
Authorization Entry: An authorization assertion that grants or denies a specific set of permissions to a specific group of entities.
授权条目：一种授权断言，用于向特定的实体组授予或拒绝特定的权限集。
Certificate: An X.509 Certificate, as specified in [RFC5280].
证书：X.509证书，如[RFC5280]所述。
Certificate Evaluator: A party other than a relying party that evaluates the trustworthiness of certificates issued by Certification Authorities.
证书评估人：除依赖方以外的一方，负责评估认证机构颁发的证书的可信度。
Certification Authority (CA): An issuer that issues certificates in accordance with a specified Certificate Policy.
证书颁发机构（CA）：根据指定的证书策略颁发证书的颁发者。
Certificate Policy (CP): Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates. See [RFC3647].
证书策略（CP）：指定证书颁发机构在颁发证书时承诺满足的标准。参见[RFC3647]。
Certification Practices Statement (CPS): Specifies the means by which the criteria of the Certificate Policy are met. In most cases, this will be the document against which the operations of the Certification Authority are audited. See [RFC3647].
认证实践声明（CPS）：指定满足证书策略标准的方法。在大多数情况下，这将是审核认证机构运营的文件。参见[RFC3647]。
Domain: A DNS Domain Name.
域：一个DNS域名。
Domain Name: A DNS Domain Name as specified in [STD13].
域名：在[STD13]中指定的DNS域名。
Domain Name System (DNS): The Internet naming system specified in [STD13].
域名系统（DNS）：在[STD13]中指定的互联网命名系统。
DNS Security (DNSSEC): Extensions to the DNS that provide authentication services as specified in [RFC4033], [RFC4034], [RFC4035], [RFC5155], and revisions.
DNS安全性（DNSSEC）：DNS的扩展，提供[RFC4033]、[RFC4034]、[RFC4035]、[RFC5155]和修订版中规定的身份验证服务。
Issuer: An entity that issues certificates. See [RFC5280].
颁发者：颁发证书的实体。见[RFC5280]。
Property: The tag-value portion of a CAA Resource Record.
属性：CAA资源记录的标记值部分。
Property Tag: The tag portion of a CAA Resource Record.
属性标记：CAA资源记录的标记部分。
Property Value: The value portion of a CAA Resource Record.
属性值：CAA资源记录的值部分。
Public Key Infrastructure X.509 (PKIX): Standards and specifications issued by the IETF that apply the [X.509] certificate standards specified by the ITU to Internet applications as specified in [RFC5280] and related documents.
公钥基础设施X.509（PKIX）：IETF发布的标准和规范，将ITU规定的[X.509]证书标准应用于[RFC5280]和相关文件中规定的互联网应用。
Resource Record (RR): A particular entry in the DNS including the owner name, class, type, time to live, and data, as defined in [STD13] and [RFC2181].
资源记录（RR）：DNS中的特定条目，包括所有者名称、类别、类型、生存时间和数据，如[STD13]和[RFC2181]中所定义。
Resource Record Set (RRSet): A set of Resource Records or a particular owner name, class, and type. The time to live on all RRs with an RRSet is always the same, but the data may be different among RRs in the RRSet.
资源记录集（RRSet）：一组资源记录或特定所有者名称、类和类型。在具有RRSet的所有RRs上的生存时间始终相同，但RRSet中的RRs之间的数据可能不同。
Relying Party: A party that makes use of an application whose operation depends on use of a certificate for making a security decision. See [RFC5280].
依赖方：使用应用程序的一方，该应用程序的运行依赖于证书的使用来做出安全决策。见[RFC5280]。
Relying Application: An application whose operation depends on use of a certificate for making a security decision.
依赖应用程序：其操作依赖于使用证书来做出安全决策的应用程序。
A CAA RR consists of a flags byte and a tag-value pair referred to as a property. Multiple properties MAY be associated with the same domain name by publishing multiple CAA RRs at that domain name. The following flag is defined:
CAA RR由一个标志字节和一个称为属性的标记值对组成。通过在同一域名上发布多个CAA RRs，可以将多个属性与该域名相关联。定义了以下标志：
Issuer Critical: If set to '1', indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer.
Issuer Critical（发卡机构关键）：如果设置为“1”，则表示如果发卡机构要正确解释CAA记录的语义，则必须理解相应的属性标记。
Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.
如果相关CAA资源记录集包含具有关键位集的未知属性标记，则颁发者不得为域颁发证书。
The following property tags are defined:
定义了以下特性标记：
issue <Issuer Domain Name> [; <name>=<value> ]* : The issue property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue certificates for the domain in which the property is published.
issue<Issuer Domain Name>[；<Name>=<value>]*：issue property条目授权域名持有人<Issuer Domain Name>或在该域名持有人明确授权下行事的一方为发布该财产的域颁发证书。
issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue wildcard certificates for the domain in which the property is published.
issuewild<Issuer Domain Name>[；<Name>=<value>]*：issuewild属性条目授权域名持有人<Issuer Domain Name>或在该域名持有人明确授权下行事的一方为发布该属性的域颁发通配符证书。
iodef <URL> : Specifies a URL to which an issuer MAY report certificate issue requests that are inconsistent with the issuer's Certification Practices or Certificate Policy, or that a Certificate Evaluator may use to report observation of a possible policy violation. The Incident Object Description Exchange Format (IODEF) format is used [RFC5070].
iodef<URL>：指定一个URL，颁发者可以向该URL报告与颁发者的认证实践或证书策略不一致的证书颁发请求，或者证书评估者可以使用该URL报告可能违反策略的观察结果。使用事件对象描述交换格式（IODEF）格式[RFC5070]。
The following example is a DNS zone file (see [RFC1035]) that informs CAs that certificates are not to be issued except by the holder of the domain name 'ca.example.net' or an authorized agent thereof. This policy applies to all subordinate domains under example.com.
以下示例是一个DNS区域文件（请参见[RFC1035]），该文件通知CAs，除非由域名“ca.example.net”的持有人或其授权代理，否则不得颁发证书。此策略适用于example.com下的所有从属域。
$ORIGIN example.com . CAA 0 issue "ca.example.net"
$originexample.com。CAA 0问题“ca.example.net”
If the domain name holder specifies one or more iodef properties, a certificate issuer MAY report invalid certificate requests to that address. In the following example, the domain name holder specifies that reports may be made by means of email with the IODEF data as an attachment, a Web service [RFC6546], or both:
如果域名持有者指定了一个或多个iodef属性，证书颁发者可能会向该地址报告无效的证书请求。在下面的示例中，域名持有人指定可以通过电子邮件（将IODEF数据作为附件）、Web服务[RFC6546]或两者结合的方式进行报告：
$ORIGIN example.com
. CAA 0 issue "ca.example.net"
. CAA 0 iodef "mailto:security@example.com"
. CAA 0 iodef "http://iodef.example.com/"
$ORIGIN example.com
. CAA 0 issue "ca.example.net"
. CAA 0 iodef "mailto:security@example.com"
. CAA 0 iodef "http://iodef.example.com/"
A certificate issuer MAY specify additional parameters that allow customers to specify additional parameters governing certificate issuance. This might be the Certificate Policy under which the certificate is to be issued, the authentication process to be used might be specified, or an account number specified by the CA to enable these parameters to be retrieved.
证书颁发者可以指定其他参数，以允许客户指定管理证书颁发的其他参数。这可能是要在其中颁发证书的证书策略，可能指定要使用的身份验证过程，或者是CA指定的帐户号，以便能够检索这些参数。
For example, the CA 'ca.example.net' has requested its customer 'example.com' to specify the CA's account number '230123' in each of the customer's CAA records.
例如，CA“CA.example.net”已请求其客户“example.com”在每个客户的CAA记录中指定CA的账号“230123”。
$ORIGIN example.com . CAA 0 issue "ca.example.net; account=230123"
$originexample.com。CAA 0发布“ca.example.net；账户=230123”
The syntax of additional parameters is a sequence of name-value pairs as defined in Section 5.2. The semantics of such parameters is left to site policy and is outside the scope of this document.
附加参数的语法是第5.2节中定义的名称-值对序列。此类参数的语义由站点策略决定，不在本文档范围内。
The critical flag is intended to permit future versions CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated domains.
临界标志旨在允许未来版本的CAA引入新的语义，这些语义必须为记录的正确处理所理解，防止不识别新语义的合格CA为指定域颁发证书。
In the following example, the property 'tbs' is flagged as critical. Neither the example.net CA nor any other issuer is authorized to issue under either policy unless the processing rules for the 'tbs' property tag are understood.
在以下示例中，属性“tbs”被标记为关键。除非了解“tbs”属性标签的处理规则，否则example.net CA或任何其他发行人均无权根据任一策略发行。
$ORIGIN example.com . CAA 0 issue "ca.example.net; policy=ev" . CAA 128 tbs "Unknown"
$originexample.com。CAA 0发布“ca.example.net；policy=ev”。CAA 128 tbs“未知”
Note that the above restrictions only apply at certificate issue. Since the validity of an end entity certificate is typically a year or more, it is quite possible that the CAA records published at a domain will change between the time a certificate was issued and validation by a relying party.
请注意，上述限制仅适用于证书颁发。由于最终实体证书的有效期通常为一年或一年以上，因此在颁发证书和依赖方验证期间，在域中发布的CAA记录很可能会发生变化。
Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies.
在颁发证书之前，合规CA必须检查相关CAA资源记录集的发布情况。如果存在此类记录集，CA不得颁发证书，除非CA确定（1）证书请求与适用的CAA资源记录集一致，或（2）相关证书政策或认证实践声明中规定的例外适用。
A certificate request MAY specify more than one domain name and MAY specify wildcard domains. Issuers MUST verify authorization for all the domains and wildcard domains specified in the request.
证书请求可以指定多个域名，也可以指定通配符域。发卡机构必须验证请求中指定的所有域和通配符域的授权。
The search for a CAA record climbs the DNS name tree from the specified label up to but not including the DNS root '.'.
搜索CAA记录会将DNS名称树从指定的标签爬升到但不包括DNS根“.”。
Given a request for a specific domain X, or a request for a wildcard domain *.X, the relevant record set R(X) is determined as follows:
给定对特定域X的请求或对通配符域*.X的请求，相关记录集R（X）的确定如下：
Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X.
让CAA（X）为响应对标签X执行CAA记录查询而返回的记录集，P（X）为DNS层次结构中X正上方的DNS标签，a（X）为在标签X处指定的CNAME或DNAME别名记录的目标。
o If CAA(X) is not empty, R(X) = CAA (X), otherwise
o 如果CAA（X）不是空的，则R（X）=CAA（X），否则
o If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise
o 如果A（X）不为null，且R（A（X））不为空，则R（X）=R（A（X）），否则
o If X is not a top-level domain, then R(X) = R(P(X)), otherwise
o 如果X不是顶级域，则R（X）=R（P（X）），否则
o R(X) is empty.
o R（X）是空的。
For example, if a certificate is requested for X.Y.Z the issuer will search for the relevant CAA record set in the following order:
例如，如果为X.Y.Z申请证书，发卡机构将按以下顺序搜索相关CAA记录集：
X.Y.Z
X.Y.Z
Alias (X.Y.Z)
别名（X.Y.Z）
Y.Z
Y.Z
Alias (Y.Z)
别名（Y.Z）
Z
Z
Alias (Z)
别名（Z）
Return Empty
返回空
Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required. An issuer MUST NOT issue certificates if doing so would conflict with the relevant CAA Resource Record set, irrespective of whether the corresponding DNS records are signed.
强烈建议使用DNSSEC认证CAA RRs，但不是必需的。如果颁发者这样做会与相关CAA资源记录集冲突，则无论相应的DNS记录是否已签名，颁发者都不得颁发证书。
DNSSEC provides a proof of non-existence for both DNS domains and RR set within domains. DNSSEC verification thus enables an issuer to determine if the answer to a CAA record query is empty because the RR set is empty or if it is non-empty but the response has been suppressed.
DNSSEC为DNS域和域内的RR集提供不存在的证明。因此，DNSSEC验证使发卡机构能够确定CAA记录查询的答案是否为空，是因为RR集为空，还是因为RR集为非空，但响应已被抑制。
Use of DNSSEC allows an issuer to acquire and archive a proof that they were authorized to issue certificates for the domain. Verification of such archives MAY be an audit requirement to verify CAA record processing compliance. Publication of such archives MAY be a transparency requirement to verify CAA record processing compliance.
使用DNSSEC允许发卡机构获取并存档证明其已被授权为域颁发证书的证据。验证此类档案可能是验证CAA记录处理合规性的审计要求。公布此类档案可能是验证CAA记录处理合规性的透明度要求。
A CAA RR contains a single property entry consisting of a tag-value pair. Each tag represents a property of the CAA record. The value of a CAA property is that specified in the corresponding value field.
CAA RR包含由标记值对组成的单个属性条目。每个标记表示CAA记录的一个属性。CAA属性的值是在相应的值字段中指定的值。
A domain name MAY have multiple CAA RRs associated with it and a given property MAY be specified more than once.
一个域名可能有多个与之关联的CAA RRs，并且一个给定的属性可能被指定多次。
The CAA data field contains one property entry. A property entry consists of the following data fields:
CAA数据字段包含一个属性条目。属性条目由以下数据字段组成：
+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags | Tag Length = n |
+----------------+----------------+...+---------------+
| Tag char 0 | Tag char 1 |...| Tag char n-1 |
+----------------+----------------+...+---------------+
+----------------+----------------+.....+----------------+
| Value byte 0 | Value byte 1 |.....| Value byte m-1 |
+----------------+----------------+.....+----------------+
+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags | Tag Length = n |
+----------------+----------------+...+---------------+
| Tag char 0 | Tag char 1 |...| Tag char n-1 |
+----------------+----------------+...+---------------+
+----------------+----------------+.....+----------------+
| Value byte 0 | Value byte 1 |.....| Value byte m-1 |
+----------------+----------------+.....+----------------+
Where n is the length specified in the Tag length field and m is the remaining octets in the Value field (m = d - n - 2) where d is the length of the RDATA section.
其中n是标记长度字段中指定的长度，m是值字段中剩余的八位字节（m=d-n-2），其中d是RDATA部分的长度。
The data fields are defined as follows:
数据字段定义如下：
Flags: One octet containing the following fields:
标志：一个八位字节，包含以下字段：
Bit 0, Issuer Critical Flag: If the value is set to '1', the critical flag is asserted and the property MUST be understood if the CAA record is to be correctly processed by a certificate issuer.
位0，颁发者关键标志：如果该值设置为“1”，则断言关键标志，并且如果证书颁发者要正确处理CAA记录，则必须理解该属性。
A Certification Authority MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property tag that for which the issuer critical flag is set.
对于设置了颁发者关键标志的未知或不受支持的属性标记，证书颁发机构不得为包含CAA关键属性的任何域颁发证书。
Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. Thus, the Flags value 1 means that bit 7 is set while a value of 128 means that bit 0 is set according to this convention.
注意，根据[RFC1035]中规定的约定，位0为最高有效位，位7为最低有效位。因此，标志值1表示设置了位7，而值128表示根据该约定设置了位0。
All other bit positions are reserved for future use.
所有其他位位置保留供将来使用。
To ensure compatibility with future extensions to CAA, DNS records compliant with this version of the CAA specification MUST clear (set to "0") all reserved flags bits. Applications that interpret CAA records MUST ignore the value of all reserved flag bits.
为确保与CAA的未来扩展兼容，符合此版本CAA规范的DNS记录必须清除（设置为“0”）所有保留标志位。解释CAA记录的应用程序必须忽略所有保留标志位的值。
Tag Length: A single octet containing an unsigned integer specifying the tag length in octets. The tag length MUST be at least 1 and SHOULD be no more than 15.
标记长度：单个八位字节，包含一个无符号整数，以八位字节为单位指定标记长度。标签长度必须至少为1，且不得超过15。
Tag: The property identifier, a sequence of US-ASCII characters.
标记：属性标识符，一个US-ASCII字符序列。
Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT contain any other characters. Matching of tag values is case insensitive.
标记值可能包含US-ASCII字符“a”到“z”、“a”到“z”以及数字0到9。标记值不应包含任何其他字符。标记值的匹配不区分大小写。
Tag values submitted for registration by IANA MUST NOT contain any characters other than the (lowercase) US-ASCII characters 'a' through 'z' and the numbers 0 through 9.
IANA提交注册的标记值不得包含除（小写）US-ASCII字符“a”到“z”以及数字0到9以外的任何字符。
Value: A sequence of octets representing the property value. Property values are encoded as binary values and MAY employ sub-formats.
值：表示属性值的八位字节序列。特性值被编码为二进制值，并且可以使用子格式。
The length of the value field is specified implicitly as the remaining length of the enclosing Resource Record data field.
值字段的长度隐式指定为封闭资源记录数据字段的剩余长度。
The canonical presentation format of the CAA record is:
CAA记录的规范表示格式为：
CAA <flags> <tag> <value>
CAA <flags> <tag> <value>
Where:
哪里：
Flags: Is an unsigned integer between 0 and 255.
标志：是介于0和255之间的无符号整数。
Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case.
标记：是一个非零序的US-ASCII字母和小写数字。
Value: Is the <character-string> encoding of the value field as specified in [RFC1035], Section 5.1.
值：是[RFC1035]第5.1节中规定的值字段的<character string>编码。
The issue property tag is used to request that certificate issuers perform CAA issue restriction processing for the domain and to grant authorization to specific certificate issuers.
issue属性标记用于请求证书颁发者对域执行CAA颁发限制处理，并向特定证书颁发者授予授权。
The CAA issue property value has the following sub-syntax (specified in ABNF as per [RFC5234]).
CAA问题属性值具有以下子语法（根据[RFC5234]在ABNF中指定）。
issuevalue = space [domain] space [";" *(space parameter) space]
issuevalue = space [domain] space [";" *(space parameter) space]
domain = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
domain = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
space = *(SP / HTAB)
space = *(SP / HTAB)
parameter = tag "=" value
参数=标记“=”值
tag = 1*(ALPHA / DIGIT)
tag = 1*(ALPHA / DIGIT)
value = *VCHAR
value = *VCHAR
For consistency with other aspects of DNS administration, domain name values are specified in letter-digit-hyphen Label (LDH-Label) form.
为了与DNS管理的其他方面保持一致，域名值在字母数字连字符标签（LDH标签）表单中指定。
A CAA record with an issue parameter tag that does not specify a domain name is a request that certificate issuers perform CAA issue restriction processing for the corresponding domain without granting authorization to any certificate issuer.
带有未指定域名的问题参数标记的CAA记录是指证书颁发者在未向任何证书颁发者授予授权的情况下对相应域执行CAA问题限制处理的请求。
This form of issue restriction would be appropriate to specify that no certificates are to be issued for the domain in question.
这种形式的颁发限制适用于指定不为相关域颁发证书。
For example, the following CAA record set requests that no certificates be issued for the domain 'nocerts.example.com' by any certificate issuer.
例如，以下CAA记录集要求任何证书颁发者都不要为域“nocerts.example.com”颁发任何证书。
nocerts.example.com CAA 0 issue ";"
nocerts.example.com CAA 0版“
A CAA record with an issue parameter tag that specifies a domain name is a request that certificate issuers perform CAA issue restriction processing for the corresponding domain and grants authorization to the certificate issuer specified by the domain name.
具有指定域名的问题参数标记的CAA记录是证书颁发者对相应域执行CAA问题限制处理并向域名指定的证书颁发者授予授权的请求。
For example, the following CAA record set requests that no certificates be issued for the domain 'certs.example.com' by any certificate issuer other than the example.net certificate issuer.
例如，以下CAA记录集要求除example.net证书颁发者之外的任何证书颁发者均不得为域“certs.example.com”颁发任何证书。
certs.example.com CAA 0 issue "example.net"
certs.example.com CAA 0发布“example.net”
CAA authorizations are additive; thus, the result of specifying both the empty issuer and a specified issuer is the same as specifying just the specified issuer alone.
CAA授权是附加的；因此，指定空颁发者和指定颁发者的结果与仅指定指定的颁发者的结果相同。
An issuer MAY choose to specify issuer-parameters that further constrain the issue of certificates by that issuer, for example, specifying that certificates are to be subject to specific validation polices, billed to certain accounts, or issued under specific trust anchors.
发卡机构可以选择指定进一步约束该发卡机构颁发证书的发卡机构参数，例如，指定证书要遵守特定的验证策略、向特定账户计费或在特定的信任锚下颁发。
The semantics of issuer-parameters are determined by the issuer alone.
发卡机构参数的语义仅由发卡机构确定。
The issuewild property has the same syntax and semantics as the issue property except that issuewild properties only grant authorization to issue certificates that specify a wildcard domain and issuewild properties take precedence over issue properties when specified. Specifically:
issuewild属性与issue属性具有相同的语法和语义，不同之处在于issuewild属性仅授予颁发指定通配符域的证书的授权，并且issuewild属性在指定时优先于issue属性。明确地：
issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain.
处理非通配符域的域请求时，必须忽略issuewild属性。
If at least one issuewild property is specified in the relevant CAA record set, all issue properties MUST be ignored when processing a request for a domain that is a wildcard domain.
如果相关CAA记录集中至少指定了一个issuewild属性，则在处理通配符域的请求时，必须忽略所有issue属性。
The iodef property specifies a means of reporting certificate issue requests or cases of certificate issue for the corresponding domain that violate the security policy of the issuer or the domain name holder.
iodef属性指定了一种方法，用于报告违反颁发者或域名持有人安全策略的相应域的证书颁发请求或证书颁发案例。
The Incident Object Description Exchange Format (IODEF) [RFC5070] is used to present the incident report in machine-readable form.
事件对象描述交换格式（IODEF）[RFC5070]用于以机器可读的形式呈现事件报告。
The iodef property takes a URL as its parameter. The URL scheme type determines the method used for reporting:
iodef属性将URL作为其参数。URL方案类型确定用于报告的方法：
mailto: The IODEF incident report is reported as a MIME email attachment to an SMTP email that is submitted to the mail address specified. The mail message sent SHOULD contain a brief text message to alert the recipient to the nature of the attachment.
mailto:IODEF事件报告报告为提交到指定邮件地址的SMTP电子邮件的MIME电子邮件附件。发送的邮件信息应包含简短的文本信息，以提醒收件人附件的性质。
http or https: The IODEF report is submitted as a Web service request to the HTTP address specified using the protocol specified in [RFC6546].
http或https：IODEF报告作为Web服务请求提交到使用[RFC6546]中指定的协议指定的http地址。
CAA records assert a security policy that the holder of a domain name wishes to be observed by certificate issuers. The effectiveness of CAA records as an access control mechanism is thus dependent on observance of CAA constraints by issuers.
CAA记录声明了域名持有人希望证书颁发者遵守的安全策略。因此，CAA记录作为访问控制机制的有效性取决于发行人是否遵守CAA约束。
The objective of the CAA record properties described in this document is to reduce the risk of certificate mis-issue rather than avoid reliance on a certificate that has been mis-issued. DANE [RFC6698] describes a mechanism for avoiding reliance on mis-issued certificates.
本文档中描述的CAA记录属性的目的是降低证书错误颁发的风险，而不是避免依赖错误颁发的证书。DANE[RFC6698]描述了一种避免依赖错误颁发的证书的机制。
CAA records offer CAs a cost-effective means of mitigating the risk of certificate mis-issue: the cost of implementing CAA checks is very small and the potential costs of a mis-issue event include the removal of an embedded trust anchor.
CAA记录为CAs提供了一种降低证书错误颁发风险的经济有效的方法：实施CAA检查的成本非常小，错误颁发事件的潜在成本包括移除嵌入式信任锚。
Use of CAA records does not prevent mis-issue by an authorized Certification Authority, i.e., a CA that is authorized to issue certificates for the domain in question by CAA records.
使用CAA记录不会阻止授权证书颁发机构（即，CAA记录授权为相关域颁发证书的CA）错误颁发证书。
Domain name holders SHOULD verify that the CAs they authorize to issue certificates for their domains employ appropriate controls to ensure that certificates are issued only to authorized parties within their organization.
域名持有人应验证其授权为其域颁发证书的CA是否采用了适当的控制措施，以确保仅向其组织内的授权方颁发证书。
Such controls are most appropriately determined by the domain name holder and the authorized CA(s) directly and are thus out of scope of this document.
此类控制由域名持有人和授权CA直接确定，因此不在本文件范围内。
Suppression of the CAA record or insertion of a bogus CAA record could enable an attacker to obtain a certificate from an issuer that was not authorized to issue for that domain name.
禁止CAA记录或插入伪造的CAA记录可使攻击者从未经授权为该域名颁发证书的颁发者处获取证书。
Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets.
在可能的情况下，发行人应执行DNSSEC验证，以检测丢失或修改的CAA记录集。
In cases where DNSSEC is not deployed in a corresponding domain, an issuer SHOULD attempt to mitigate this risk by employing appropriate DNS security controls. For example, all portions of the DNS lookup
如果DNSSEC未部署在相应的域中，则发卡机构应尝试通过采用适当的DNS安全控制来降低此风险。例如，DNS查找的所有部分
process SHOULD be performed against the authoritative name server. Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls.
应针对权威名称服务器执行此过程。第三方缓存的数据不得依赖，但可用于支持额外的反欺骗或反抑制控制。
Introduction of a malformed or malicious CAA RR could in theory enable a Denial-of-Service (DoS) attack.
引入格式错误或恶意的CAA RR理论上可能导致拒绝服务（DoS）攻击。
This specific threat is not considered to add significantly to the risk of running an insecure DNS service.
此特定威胁不会显著增加运行不安全DNS服务的风险。
An attacker could, in principle, perform a DoS attack against an issuer by requesting a certificate with a maliciously long DNS name. In practice, the DNS protocol imposes a maximum name length and CAA processing does not exacerbate the existing need to mitigate DoS attacks to any meaningful degree.
原则上，攻击者可以通过请求具有恶意长DNS名称的证书来对颁发者执行DoS攻击。在实践中，DNS协议规定了最大名称长度，CAA处理不会加剧现有的需要，以在任何有意义的程度上缓解DoS攻击。
A Certification Authority could make use of the critical flag to trick customers into publishing records that prevent competing Certification Authorities from issuing certificates even though the customer intends to authorize multiple providers.
证书颁发机构可以利用临界标志欺骗客户发布记录，从而阻止竞争的证书颁发机构颁发证书，即使客户打算授权多个提供商。
In practice, such an attack would be of minimal effect since any competent competitor that found itself unable to issue certificates due to lack of support for a property marked critical SHOULD investigate the cause and report the reason to the customer. The customer will thus discover that they had been deceived.
在实践中，这种攻击的影响最小，因为任何有能力的竞争对手如果发现自己由于缺少对标记为关键的财产的支持而无法颁发证书，则应调查原因并向客户报告原因。因此，客户会发现他们被欺骗了。
IANA has assigned Resource Record Type 257 for the CAA Resource Record Type and added the line depicted below to the registry named "Resource Record (RR) TYPEs" and QTYPEs as defined in BCP 42 [RFC6195] and located at http://www.iana.org/assignments/dns-parameters.
IANA已为CAA资源记录类型分配了资源记录类型257，并将下面描述的行添加到名为“资源记录（RR）类型”的注册表中，以及BCP 42[RFC6195]中定义的QTYPEs，并位于http://www.iana.org/assignments/dns-parameters.
RR Name Value and meaning Reference
----------- --------------------------------------------- ---------
CAA 257 Certification Authority Restriction [RFC6844]
RR Name Value and meaning Reference
----------- --------------------------------------------- ---------
CAA 257 Certification Authority Restriction [RFC6844]
IANA has created the "Certification Authority Restriction Properties" registry with the following initial values:
IANA已创建具有以下初始值的“证书颁发机构限制属性”注册表：
Tag Meaning Reference
----------- -------------------------------------- ---------
issue Authorization Entry by Domain [RFC6844]
issuewild Authorization Entry by Wildcard Domain [RFC6844]
iodef Report incident by IODEF report [RFC6844]
auth Reserved [HB2011]
path Reserved [HB2011]
policy Reserved [HB2011]
Tag Meaning Reference
----------- -------------------------------------- ---------
issue Authorization Entry by Domain [RFC6844]
issuewild Authorization Entry by Wildcard Domain [RFC6844]
iodef Report incident by IODEF report [RFC6844]
auth Reserved [HB2011]
path Reserved [HB2011]
policy Reserved [HB2011]
Although [HB2011] has expired, deployed clients implement the CAA properties specified in the document and reuse of these property tags for a different purpose could cause unexpected behavior.
尽管[HB2011]已过期，但部署的客户端实现了文档中指定的CAA属性，并且将这些属性标记重新用于其他目的可能会导致意外行为。
Addition of tag identifiers requires a public specification and Expert Review as set out in [RFC6195], Section 3.1.1.
如[RFC6195]第3.1.1节所述，添加标签标识符需要公共规范和专家审查。
The tag space is designed to be sufficiently large that exhausting the possible tag space need not be a concern. The scope of Expert Review SHOULD be limited to the question of whether the specification provided is sufficiently clear to permit implementation and to avoid unnecessary duplication of functionality.
标签空间被设计为足够大，从而不必担心耗尽可能的标签空间。专家审查的范围应限于提供的规范是否足够清晰，以允许实施和避免不必要的功能重复。
IANA has created the "Certification Authority Restriction Flags" registry with the following initial values:
IANA已创建具有以下初始值的“证书颁发机构限制标志”注册表：
Flag Meaning Reference
----------- ---------------------------------- ---------
0 Issuer Critical Flag [RFC6844]
1-7 Reserved> [RFC6844]
Flag Meaning Reference
----------- ---------------------------------- ---------
0 Issuer Critical Flag [RFC6844]
1-7 Reserved> [RFC6844]
Assignment of new flags follows the RFC Required policy set out in [RFC5226], Section 4.1.
新标志的分配遵循[RFC5226]第4.1节规定的RFC要求政策。
The authors would like to thank the following people who contributed to the design and documentation of this work item: Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson.
作者要感谢以下为本工作项目的设计和文档编制做出贡献的人：克里斯·埃文斯、斯蒂芬·法雷尔、杰夫·霍奇斯、保罗·霍夫曼、斯蒂芬·肯特、亚当·兰利、本·劳里、詹姆斯·马歇尔、克里斯·帕尔默、斯科特·施密特、肖恩·特纳和本·威尔逊。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070]Danyliw，R.，Meijer，J.，和Y.Demchenko，“事件对象描述交换格式”，RFC 50702007年12月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[RFC6195]Eastlake，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 61952011年3月。
[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012.
[RFC6546]Trammell，B.，“通过HTTP/TLS传输实时网络间防御（RID）消息”，RFC 6546，2012年4月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月。
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[X.509] International Telecommunication Union, "ITU-T Recommendation X.509 (11/2008): Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, November 2008.
[X.509]国际电信联盟，“ITU-T建议X.509（11/2008）：信息技术-开放系统互连-目录：公钥和属性证书框架”，ITU-T建议X.509，2008年11月。
[HB2011] Hallam-Baker, P., Stradling, R., and B. Laurie, "DNS Certification Authority Authorization (CAA) Resource Record", Work in Progress, May 2011.
[HB2011]Hallam Baker，P.，Stradling，R.和B.Laurie，“DNS认证机构授权（CAA）资源记录”，正在进行的工作，2011年5月。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647]Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
Authors' Addresses
作者地址
Phillip Hallam-Baker Comodo Group, Inc.
菲利普·哈拉姆·贝克·科莫多集团公司。
EMail: philliph@comodo.com
EMail: philliph@comodo.com
Rob Stradling Comodo CA, Ltd.
Rob Stradling Comodo CA有限公司。
EMail: rob.stradling@comodo.com
EMail: rob.stradling@comodo.com