]> DigiCert, Inc.

corey.bonnell@digicert.com

caa certification authority authorization email address The Certificate Authority Authorization (CAA) DNS resource record type provides a mechanism for domains to express the allowed set of Certificate Authorities that may issue certificates for the domain. The core CAA specification () solely defines Property Tags that restrict the issuance of certificates that certify domain names; it does not define a mechanism for domains to restrict the issuance of certificates that include email addresses. This specification defines a Property Tag that grants authorization to Certificate Authorities to issue certificates which certify email addresses. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines a CAA Property Tag which restricts the allowed set of issuers for electronic email addresses. Its syntax and processing are similar to the "issue" Property Tag as defined in section 4.2 of .

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

The "issuemail" Property Tag Syntax This document defines the "issuemail" Property Tag. The presence of one or more "issuemail" Properties in the Relevant Resource Record Set () indicates that the domain is requesting that Certification Authorities restrict the issuance of certificates that certify email addresses. The CAA "issuemail" Property Value has the following sub-syntax (specified in ABNF as per ): Readers who are familiar with the sub-syntax of the "issue" and "issuewild" Property Tags will recognize that this sub-syntax is identical.

"issuemail" Property Tag Processing Prior to issuing a certificate that certifies an email address, the Certification Authority MUST check for publication of a Relevant Resource Record Set (RRSet). The discovery of such a Relevant RRSet MUST be performed using the algorithm specified in section 3 of . The input domain to the discovery algorithm SHALL be the domain "part" () of the email address that is being certified. If the domain "part" of the email address being certified is an Internationalized Domain Name () that contains one or more U-Labels, then all U-Labels MUST be converted to their A-Label representation () for the purpose of discovering the Relevant RRSet for that email address. If the Relevant RRSet is empty, or the Relevant RRSet 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 which certify email addresses. 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 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. 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. The processing of parameters in the issuemail-value are beyond the scope of this document.

"issuemail" Property Tag Examples 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 "ca.example.com". The following RRSet does not contain any "issuemail" Properties, so there are no restrictions on the issuance of certificates which certify email addresses for that domain: 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: The following RRSet contains multiple "issuemail" Properties, one of which matches the issuer-domain-name of the example Certification Authority ("ca.example.com") and one Property which does not match. Given that there is at least one record whose issuer-domain-name matches the Certification Authority's issuer-domain-name, issuance is permitted. 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.

Security Considerations TODO: verify that this is correct This document introduces no security considerations beyond those expressed in .

IANA Considerations The author(s) request the registration of the following "Certification Authority Restriction Properties":

Tag	Meaning	Reference
issuemail	Authorization Entry by Email Address	[This document]

References Normative References This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK] 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 name. CAA Resource Records allow a public CA 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 CAs. This document obsoletes RFC 6844. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.