[要約] RFC 9495 は、ドメインが許可された認証局を表現するためのCAA DNSリソースレコードを提供し、証明書の発行を制限するProperty Tagsを定義します。その目的は、認証局に電子メール保護キーを含む証明書を発行する権限を与えることです。
Internet Engineering Task Force (IETF) C. Bonnell
Request for Comments: 9495 DigiCert, Inc.
Category: Standards Track October 2023
ISSN: 2070-1721
The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities that are authorized to issue certificates for the domain. RFC 8659 contains the core CAA specification, where Property Tags that restrict the issuance of certificates that certify domain names are defined. This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension.
認定機関認証（CAA）DNSリソースレコード（RR）は、ドメインがドメインの証明書を発行する権限を与えられた許可された認定当局のセットを表現するメカニズムを提供します。RFC 8659には、ドメイン名が定義されている証明書の発行を制限するプロパティタグが定義されているコアCAA仕様が含まれています。この仕様では、拡張キーセージ拡張にID-KP-EMAILPROTECTIONの重要な目的を含む証明書と、ドメイン名を含むタイプID-on-SMTputF8Mailboxの少なくとも1つのRFC822NAME値またはその他の値を含む証明書を認証当局に付与するプロパティタグを定義します。subjectaltname拡張機能で。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9495.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9495で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Syntax of the "issuemail" Property Tag
4. Processing of the "issuemail" Property Tag
5. Examples of the "issuemail" Property Tag
5.1. No "issuemail" Property
5.2. Single "issuemail" Property
5.3. Single "issuemail" Property with Parameters
5.4. Multiple "issuemail" Properties
5.5. Malformed "issuemail" Property
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Author's Address
The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities that are authorized to issue certificates for the domain. [RFC8659] contains the core CAA specification, where Property Tags that restrict the issuance of certificates that certify domain names are defined. [RFC8659] does not define a mechanism to restrict the issuance of certificates that certify email addresses. For the purposes of this document, a certificate "certifies" an email address if the certificate contains the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension.
認定機関認証（CAA）DNSリソースレコード（RR）は、ドメインがドメインの証明書を発行する権限を与えられた許可された認定当局のセットを表現するメカニズムを提供します。[RFC8659]には、ドメイン名が定義されている証明書の発行を制限するプロパティタグが定義されているコアCAA仕様が含まれています。[RFC8659]は、電子メールアドレスを証明する証明書の発行を制限するメカニズムを定義していません。このドキュメントの目的のために、証明書に証明書に拡張キーセージ拡張におけるID-KP-Emailprotectionの重要な目的が含まれている場合、証明書は電子メールアドレスを「証明」します。subjectaltname拡張機能のドメイン名。
This document defines a CAA Property Tag that restricts the allowed set of issuers of certificates that certify email addresses. Its syntax and processing are similar to the "issue" Property Tag as defined in Section 4.2 of [RFC8659].
このドキュメントでは、電子メールアドレスを証明する証明書の発行者の許可セットを制限するCAAプロパティタグを定義します。その構文と処理は、[RFC8659]のセクション4.2で定義されている「問題」プロパティタグに似ています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document defines the "issuemail" Property Tag. The presence of one or more "issuemail" Properties in the Relevant Resource Record Set (RRSet) [RFC8659] indicates that the domain is requesting that Certification Authorities restrict the issuance of certificates that certify email addresses.
このドキュメントでは、「発行メール」プロパティタグを定義します。関連するリソースレコードセット（RRSET）[RFC8659]に1つ以上の「発行メール」プロパティが存在することは、ドメインが認証当局が電子メールアドレスを証明する証明書の発行を制限することを要求していることを示しています。
The CAA "issuemail" Property Value has the following sub-syntax (specified in ABNF as per [RFC5234]):
CAAの「発行メール」プロパティ値には、次のサブシンタックスがあります（[RFC5234]に従ってABNFで指定されています）：
issuemail-value = *WSP [issuer-domain-name *WSP]
[";" *WSP [parameters *WSP]]
issuer-domain-name = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
parameters = (parameter *WSP ";" *WSP parameters) / parameter
parameter = tag *WSP "=" *WSP value
tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
value = *(%x21-3A / %x3C-7E)
The production rules for "WSP", "ALPHA", and "DIGIT" are defined in Appendix B.1 of [RFC5234]. Readers who are familiar with the sub-syntax of the "issue" and "issuewild" Property Tags will recognize that this sub-syntax is identical.
「WSP」、「アルファ」、および「桁」の生産ルールは、[RFC5234]の付録B.1で定義されています。「問題」と「IssueWild」プロパティタグのサブシナタックスに精通している読者は、このサブシンタックスが同一であることを認識します。
The meanings of each production rule within "issuemail-value" are as follows:
「発行メール価値」内の各生産ルールの意味は次のとおりです。
"issuer-domain-name":
「発行者ドメインネーム」：
A domain name of the Certification Authority comprised of one or more labels
1つ以上のラベルで構成される認証機関のドメイン名
"label":
"ラベル"：
A single domain label that consists solely of ASCII letters, digits, and the hyphen (known as an "LDH label")
ASCII文字、数字、およびハイフン（「LDHラベル」として知られている）のみで構成される単一のドメインラベル
"parameters":
"パラメーター"：
A semicolon-separated list of parameters
パラメーターのセミコロン分離リスト
"parameter":
「パラメーター」：
A tag and a value, separated by an equals sign ("=")
等しい記号で区切られたタグと値（ "="）
"tag":
"鬼ごっこ"：
A keyword that identifies the type of parameter
パラメーターのタイプを識別するキーワード
"value":
"価値"：
The string value for a parameter
パラメーターの文字列値
Prior to issuing a certificate that certifies an email address, the Certification Authority MUST check for publication of a Relevant RRSet. The discovery of such a Relevant RRSet MUST be performed using the algorithm specified in Section 3 of [RFC8659]. The input domain to the discovery algorithm SHALL be the domain "part" [RFC5322] of the email address that is being certified. If the domain "part" of the email address being certified is an Internationalized Domain Name [RFC5890] that contains one or more U-Labels, then all U-Labels MUST be converted to their A-Label representation [RFC5891] for the purpose of discovering the Relevant RRSet for that email address.
電子メールアドレスを証明する証明書を発行する前に、認定機関は、関連するRRSetの公開を確認する必要があります。このような関連するRRSETの発見は、[RFC8659]のセクション3で指定されたアルゴリズムを使用して実行する必要があります。発見アルゴリズムへの入力ドメインは、認定されている電子メールアドレスのドメイン「パート」[RFC5322]でなければなりません。認定されている電子メールアドレスのドメイン「部分」が1つ以上のUラベルを含む国際化ドメイン名[RFC5890]である場合、すべてのUラベルをA-Label表現[RFC5891]に変換する必要があります。そのメールアドレスに関連するRRSETを発見します。
If the Relevant RRSet is empty or if it does not contain any "issuemail" Properties, then the domain has not requested any restrictions on the issuance of certificates for email addresses. The presence of other Property Tags, such as "issue" or "issuewild", does not restrict the issuance of certificates that certify email addresses.
関連するRRSTが空である場合、または「発行メール」プロパティが含まれていない場合、ドメインは電子メールアドレスの証明書の発行に関する制限を要求していません。「問題」や「IssueWild」などの他のプロパティタグの存在は、電子メールアドレスを証明する証明書の発行を制限しません。
For each "issuemail" Property in the Relevant RRSet, the Certification Authority SHALL compare its issuer-domain-name with the issuer-domain-name as expressed in the Property Value. If there is not any "issuemail" record whose issuer-domain-name (as expressed in the Property Value) matches the Certification Authority's issuer-domain-name, then the Certification Authority MUST NOT issue the certificate. If the Relevant RRSet contains any "issuemail" Property whose issuemail-value does not conform to the ABNF syntax as defined in Section 3 of this document, then those records SHALL be treated as if the issuer-domain-name in the issuemail-value is the empty string.
関連するRRSETの各「発行」プロパティについて、認証機関は、その発行者ドメイン名とプロパティ値で表現されているように発行者ドメイン名と比較するものとします。（資産価値で表現されている）発行者ドメイン名が認証機関の発行者ドメイン名と一致する「発行メール」レコードがない場合、認定機関は証明書を発行してはなりません。関連するRRSETに、このドキュメントのセクション3で定義されているように発行メール価値がABNF構文に準拠していない「発行メール」プロパティが含まれている場合、それらの記録は発行者の価値の発行者ドメイン名が扱われるものとします。空の文字列。
If the certificate certifies more than one email address, then the Certification Authority MUST perform the above procedure for each email address being certified.
証明書が複数の電子メールアドレスを証明する場合、認定機関は認定されている各メールアドレスの上記の手順を実行する必要があります。
The assignment of issuer-domain-names to Certification Authorities is beyond the scope of this document.
認証当局への発行者ドメイン名の割り当ては、この文書の範囲を超えています。
Parameters may be defined by a Certification Authority as a means for domains to further restrict the issuance of certificates. For example, a Certification Authority may define a parameter that contains an account identifier. If the domain elects to add this parameter in an "issuemail" Property, the Certification Authority will verify that the account that is requesting the certificate matches the account specified in the Property and will refuse to issue the certificate if they do not match.
パラメーターは、ドメインが証明書の発行をさらに制限する手段として、認証機関によって定義される場合があります。たとえば、認証機関は、アカウント識別子を含むパラメーターを定義できます。ドメインがこのパラメーターを「発行メール」プロパティに追加することを選択した場合、認証機関は、証明書を要求しているアカウントがプロパティで指定されたアカウントと一致し、一致しない場合は証明書の発行を拒否することを確認します。
The processing of parameters in the issuemail-value is specific to each Certification Authority and is beyond the scope of this document. In particular, this document does not define any parameters and does not specify any processing rules for when parameters must be acknowledged by a Certification Authority. However, parameters that do not conform to the ABNF syntax as defined in Section 3 will result in the issuemail-value being not conformant with the ABNF syntax. As stated above, a Property whose issuemail-value is malformed SHALL be treated as if the issuer-domain-name in the issuemail-value is the empty string.
IssueMail-Valueでのパラメーターの処理は、各認証機関に固有であり、このドキュメントの範囲を超えています。特に、このドキュメントはパラメーターを定義せず、パラメーターを認定機関によって確認する必要がある場合の処理ルールを指定しません。ただし、セクション3で定義されているようにABNF構文に準拠していないパラメーターは、発行値値がABNF構文に適合しないようになります。上記のように、発行メール価値が奇形であるプロパティは、発行者の価値の発行者ドメイン名が空の文字列であるかのように扱われるものとします。
Several illustrative examples of Relevant RRSets and their expected processing semantics follow. All examples assume that the issuer-domain-name for the Certification Authority is "authority.example".
関連するrrsetのいくつかの例と、その予想処理セマンティクスが続きます。すべての例は、認証機関の発行者ドメイン名が「Authority.example」であることを前提としています。
The following RRSet does not contain any "issuemail" Properties, so there are no restrictions on the issuance of certificates that certify email addresses for that domain:
次のRRSTには「発行メール」プロパティは含まれていないため、そのドメインの電子メールアドレスを証明する証明書の発行に制限はありません。
mail.client.example CAA 0 issue "authority.example"
mail.client.example CAA 0 issue "other-authority.example"
The following RRSet contains a single "issuemail" Property where the issuer-domain-name is the empty string, so the issuance of certificates certifying email addresses for the domain is prohibited:
次のRRSetには、発行者ドメイン名が空の文字列である単一の「発行メール」プロパティが含まれているため、ドメインの電子メールアドレスを証明する証明書の発行は禁止されています。
mail.client.example CAA 0 issuemail ";"
The following RRSet contains a single "issuemail" Property where the issuer-domain-name is "authority.example" and contains a single "account" parameter of "123456". In this case, the Certification Authority MAY issue the certificate, or it MAY refuse to issue the certificate, depending on its practices for processing the "account" parameter:
次のRRSETには、発行者ドメイン名が「authorid.example」であり、「123456」の単一の「アカウント」パラメーターが含まれる単一の「発行メール」プロパティが含まれています。この場合、認定機関は証明書を発行するか、「アカウント」パラメーターを処理する慣行に応じて、証明書の発行を拒否する場合があります。
mail.client.example
CAA 0 issuemail "authority.example; account=123456"
The following RRSet contains multiple "issuemail" Properties, where one Property matches the issuer-domain-name of the example Certification Authority ("authority.example") and one Property does not match. Although this example is contrived, it demonstrates that since there is at least one record whose issuer-domain-name matches the Certification Authority's issuer-domain-name, issuance is permitted.
次のRRSETには複数の「発行メール」プロパティが含まれています。ここでは、1つのプロパティが実証認定機関（「Authority.example」）の発行者ドメイン名と一致し、1つのプロパティが一致しません。この例は反論されていますが、発行者ドメイン名が認証局の発行者ドメイン名と一致する少なくとも1つのレコードがあるため、発行が許可されていることを示しています。
mail.client.example CAA 0 issuemail ";"
mail.client.example CAA 0 issuemail "authority.example"
The following RRSet contains a single "issuemail" Property whose sub-syntax does not conform to the ABNF as specified in Section 3. Given that "issuemail" Properties with malformed syntax are treated the same as "issuemail" Properties whose issuer-domain-name is the empty string, issuance is prohibited.
次のRRSETには、セクション3で指定されているように、サブシンタックスがABNFに適合しない単一の「発行メール」プロパティが含まれています。空の文字列は、発行は禁止されています。
malformed.client.example CAA 0 issuemail "%%%%%"
The security considerations that are expressed in [RFC8659] are relevant to this specification.
[RFC8659]で表現されているセキュリティ上の考慮事項は、この仕様に関連しています。
The processing of "issuemail" Properties as specified in this document is a supplement to the Certification Authority's validation process. The Certification Authority MUST NOT treat solely the presence of an "issuemail" Property with its issuer-domain-name specified within the Relevant CAA RRSet as sufficient validation of the email address. The Certification Authority MUST validate the email address according to the relevant policy documents and practice statements.
このドキュメントで指定されている「発行メール」プロパティの処理は、認証機関の検証プロセスの補足です。認証当局は、関連するCAA RRSET内で指定された発行者ドメイン名を使用して、「発行メール」プロパティの存在だけを、電子メールアドレスの十分な検証として扱ってはなりません。認証機関は、関連するポリシー文書と実践ステートメントに従って、電子メールアドレスを検証する必要があります。
CAA Properties may have the "critical" flag asserted, which specifies that a given Property is critical and must be processed by conforming Certification Authorities. If a Certification Authority does not understand the Property, then it MUST NOT issue the certificate in question.
CAAプロパティには、「重要な」フラグが主張されている場合があります。これは、特定のプロパティが重要であり、認証当局に適合して処理する必要があることを指定しています。認証当局が不動産を理解していない場合、問題の証明書を発行してはなりません。
If a single CAA RRSet is processed by multiple Certification Authorities for the issuance of multiple certificate types, then a Certification Authority's lack of support for a critical CAA Property in the RRSet will prevent the Certification Authority from issuing any certificates for that domain.
単一のCAA RRSETが複数の証明書タイプの発行のために複数の認証当局によって処理された場合、RRSETの重要なCAAプロパティに対する認定機関のサポートの欠如により、認証機関がそのドメインの証明書を発行することができません。
For example, assume that an RRSet contains the following Properties:
たとえば、RRSetに次のプロパティが含まれていると仮定します。
client.example CAA 128 issue "other-authority.example"
client.example CAA 0 issuemail "authority.example"
In this case, if the Certification Authority whose issuer-domain-name matches "authority.example" does not recognize the "issue" Property Tag, then that Certification Authority will not be able to issue S/MIME certificates that certify email addresses for "client.example".
この場合、発行者ドメイン名が「Authority.example」と一致する認定機関が「問題」プロパティタグを認識しない場合、その認証機関は、電子メールアドレスを証明するS/MIME証明書を発行できません。client.example "。
IANA has registered the following entry in the "Certification Authority Restriction Properties" subregistry of the "Public Key Infrastructure using X.509 (PKIX) Parameters" registry group:
IANAは、「X.509（PKIX）パラメーターを使用した「公開キーインフラストラクチャ」の「認証機関制限プロパティ」に次のエントリを登録しました。
+===========+======================================+===========+
| Tag | Meaning | Reference |
+===========+======================================+===========+
| issuemail | Authorization Entry by Email Address | RFC 9495 |
+-----------+--------------------------------------+-----------+
Table 1
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
The author would like to thank the participants on the LAMPS Working Group mailing list for their insightful feedback and comments. In particular, the author extends sincere appreciation to Alexey Melnikov, Christer Holmberg, Éric Vyncke, John Levine, Lars Eggert, Michael Richardson, Murray Kucherawy, Paul Wouters, Phillip Hallam-Baker, Roman Danyliw, Russ Housley, Sean Turner, Seo Suchan, Tim Chown, and Tim Wicinski for their official reviews and suggestions, which greatly improved the quality of this document.
著者は、洞察に満ちたフィードバックとコメントについて、Lamps Working Groupメーリングリストの参加者に感謝したいと思います。特に、著者は、Alexey Melnikov、Christer Holmberg、Eric Vyncke、John Levine、Lars Eggert、Michael Richardson、Murray Kuchcherawy、Paul Wouters、Phillip Hallam-Baker、Roman Danyliw、Russ Housley、Russ Housley、Sean Turn、Seo Suchan、Seo Suchan、Tim Chown、およびTim Wicinskiの公式レビューと提案については、このドキュメントの品質を大幅に向上させました。
Corey Bonnell
DigiCert, Inc.
Email: corey.bonnell@digicert.com