[要約] RFC 6844は、DNS Certification Authority Authorization（CAA）リソースレコードに関する標準仕様です。CAAレコードは、ドメイン所有者が証明書発行者を制限するために使用されます。このRFCの目的は、CAAレコードの使用方法と実装の一貫性を確保することです。
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ドメイン名の所有者は、そのドメインの証明書を発行することを承認された1つ以上の証明機関（CA）を指定できます。 CAAリソースレコードを使用すると、公的な認証局が追加の制御を実装して、意図しない証明書の誤発行のリスクを軽減できます。このドキュメントでは、CAAレコードの構文と、証明書発行者がCAAレコードを処理するためのルールを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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証明書データをチェックするメカニズムの一部として使用されます。 2つの仕様の違いは、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の場合、証明書は通常、1つ以上の関連する依拠アプリケーションに埋め込まれたパブリックトラストアンカー証明書の下で発行されます。
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.
組み込みトラストアンカー証明書をアプリケーションに含める基準は、このドキュメントの範囲外です。通常、このような基準では、証明書ポリシー（CP）の要件がどのように達成されるかを指定する証明書実務声明（CPS）をCAが発行する必要があります。 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ドメインの証明書を発行する権限の現在の付与のみが記述されています。証明書は通常、少なくとも1年間有効であるため、現在発行されている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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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].
証明書：[RFC5280]で指定されているX.509証明書。
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）：[RFC4033]、[RFC4034]、[RFC4035]、[RFC5155]、およびリビジョンで指定されている認証サービスを提供するDNSの拡張。
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）：[RFC5280]および関連ドキュメントで指定されているように、ITUによって指定された[X.509]証明書標準をインターネットアプリケーションに適用する、IETFによって発行された標準および仕様。
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）：[STD13]および[RFC2181]で定義されている、所有者名、クラス、タイプ、存続時間、およびデータを含むDNSの特定のエントリ。
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を持つすべてのRRでの存続時間は常に同じですが、データはRRSet内のRR間で異なる場合があります。
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 RRを公開することにより、複数のプロパティを同じドメイン名に関連付けることができます。次のフラグが定義されています。
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.
発行者の重要：「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リソースレコードセットに含まれている場合、発行者はドメインの証明書を発行してはなりません（MUST NOT）。
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.
問題<発行者のドメイン名> [; <name> = <value>] *：問題プロパティエントリは、ドメイン名の所有者<発行元ドメイン名>またはそのドメイン名の所有者の明示的な権限の下で活動する当事者が、ドメインの証明書を発行することを承認しますプロパティが公開されています。
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 <発行元のドメイン名> [; <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を指定します。この要求は、発行者の認証慣行または証明書ポリシーと一致しないか、証明書評価者がポリシー違反の可能性の観察を報告するために使用できます。 Incident Object Description Exchange Format（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]を参照）であり、ドメイン名 'ca.example.net'の所有者またはその承認されたエージェント以外は証明書を発行しないことをCAに通知します。このポリシーは、example.comの下のすべての下位ドメインに適用されます。
$ORIGIN example.com . CAA 0 issue "ca.example.net"
$ ORIGIN example.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:
ドメイン名の所有者が1つ以上のiodefプロパティを指定している場合、証明書発行者はそのアドレスへの無効な証明書要求を報告できます（MAY）。次の例では、ドメイン名所有者は、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/"
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.
証明書発行者は、顧客が証明書の発行を管理する追加のパラメーターを指定できるようにする追加のパラメーターを指定してもよい（MAY）。これは、証明書が発行される証明書ポリシー、使用する認証プロセスの指定、またはこれらのパラメーターの取得を可能にするために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"
$ ORIGIN example.com。 CAA 0の問題「ca.example.net; account = 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」に重要なフラグが設定されています。 example.net CAも他の発行者も、 'tbs'プロパティタグの処理ルールが理解されていない限り、どちらのポリシーにも基づいて発行することはできません。
$ORIGIN example.com . CAA 0 issue "ca.example.net; policy=ev" . CAA 128 tbs "Unknown" 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.
$ ORIGIN example.com。 CAA 0は「ca.example.net; policy = ev」を発行します。 CAA 128 tbs "不明"上記の制限は証明書の発行時にのみ適用されることに注意してください。エンドエンティティ証明書の有効期間は通常1年以上であるため、ドメインで発行された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は、（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.
証明書リクエストは複数のドメイン名を指定してもよいし（MAY）、ワイルドカードドメインを指定してもよい（MAY）。発行者は、リクエストで指定されたすべてのドメインとワイルドカードドメインの承認を確認する必要があります。
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）をCNAMEのターゲットとします。または、ラベルXで指定された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 Alias (Y.Z)
Y.Zエイリアス（Y.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 RRを認証することを強くお勧めしますが、必須ではありません。対応するDNSレコードが署名されているかどうかに関係なく、関連するCAAリソースレコードセットと競合する場合、発行者は証明書を発行してはなりません。
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検証により、発行者は、RRセットが空であるためにCAAレコードクエリへの回答が空であるか、それとも空ではないが応答が抑制されているかを判断できます。
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 RRが関連付けられている場合があり（MAY）、特定のプロパティが複数回指定される場合があります。
The CAA data field contains one property entry. A property entry consists of the following data fields:
CAAデータフィールドには、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:
フラグ：次のフィールドを含む1つのオクテット：
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の数字を含めることができます（MAY）。タグ値には、他の文字を含めないでください。タグ値のマッチングでは、大文字と小文字は区別されません。
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>
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で指定されている値フィールドの<文字列>エンコーディングです。
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.
発行プロパティタグは、証明書発行者がドメインに対して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]
domain = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
space = *(SP / HTAB)
parameter = tag "=" value
パラメータ=タグ "="値
tag = 1*(ALPHA / DIGIT)
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プロパティの構文とセマンティクスは、issuewildプロパティと同じです。ただし、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レコードセットで少なくとも1つの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電子メール添付ファイルとして報告されます。送信されるメールメッセージには、添付ファイルの性質を受信者に警告する簡単なテキストメッセージを含める必要があります（SHOULD）。
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レポートは、[RFC6546]で指定されたプロトコルを使用して指定されたHTTPアドレスにWebサービス要求として送信されます。
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レコードは、CAに証明書の誤発行のリスクを軽減する費用効果の高い手段を提供します。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が適切な制御を採用して、証明書が組織内の承認された関係者にのみ発行されることを確認する必要があります（SHOULD）。
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レコードセットを検出する必要があります（SHOULD）。
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 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.
DNSSECが対応するドメインに展開されていない場合、発行者は、適切なDNSセキュリティコントロールを採用することにより、このリスクを軽減しようとする必要があります（SHOULD）。たとえば、DNSルックアッププロセスのすべての部分は、信頼できるネームサーバーに対して実行する必要があります（SHOULD）。サードパーティによってキャッシュされたデータに依存することはできませんが、追加のスプーフィング防止または抑制抑制制御をサポートするために使用できます。
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を割り当て、以下に示す行を、BCP 42 [RFC6195]で定義され、http：// wwwにある「リソースレコード（RR）タイプ」およびQTYPEsという名前のレジストリに追加しました。 iana.org/assignments/dns-parameters。
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]
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]
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、「Clarifications to the DNS Specification」、RFC 2181、1997年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 Security Extensionsのリソースレコード」、RFC 4034、2005年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 Security Extensionsのプロトコル変更」、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、「The Incident Object Description Exchange Format」、RFC 5070、2007年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 Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、2008年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、「RFCで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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[RFC6195] Eastlake、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6195、2011年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 1035、1987年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 Certification Authority Authorization（CAA）Resource Record」、Work in Progress、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.、and S. Wu、 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework"、RFC 3647、November 2003。
Authors' Addresses
著者のアドレス
Phillip Hallam-Baker Comodo Group, Inc.
Phillip Hallam-Baker Comodo Group、Inc.
EMail: philliph@comodo.com
Rob Stradling Comodo CA, Ltd.
Rob Stradling Comodo CA、Ltd.
EMail: rob.stradling@comodo.com