DigiCert, Inc.

corey.bonnell@digicert.com

sec lamps caa certification authority authorization email 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. 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.

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 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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.

Table of Contents

• .  Introduction
• .  Conventions and Definitions
• .  Syntax of the "issuemail" Property Tag
• .  Processing of the "issuemail" Property Tag
• .  Examples of the "issuemail" Property Tag
  • .  No "issuemail" Property
  • .  Single "issuemail" Property
  • .  Single "issuemail" Property with Parameters
  • .  Multiple "issuemail" Properties
  • .  Malformed "issuemail" Property
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Author's Address

Introduction 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. contains the core CAA specification, where Property Tags that restrict the issuance of certificates that certify domain names are defined. 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. 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 .

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.

Syntax of the "issuemail" Property Tag This document defines the "issuemail" Property Tag.  The presence of one or more "issuemail" Properties in the Relevant Resource Record Set (RRSet) 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 ): 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 . Readers who are familiar with the sub-syntax of the "issue" and "issuewild" Property Tags will recognize that this sub-syntax is identical. 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

"label":

A single domain label that consists solely of ASCII letters, digits, and the hyphen (known as an "LDH label")

"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

Processing of the "issuemail" Property Tag 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 . 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 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. 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 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. 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 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.

Examples of the "issuemail" Property Tag 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".

No "issuemail" Property 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: mail.client.example CAA 0 issue "authority.example" mail.client.example CAA 0 issue "other-authority.example"

Single "issuemail" Property 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: mail.client.example CAA 0 issuemail ";"

Single "issuemail" Property with Parameters 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: mail.client.example CAA 0 issuemail "authority.example; account=123456"

Multiple "issuemail" Properties 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. mail.client.example CAA 0 issuemail ";" mail.client.example CAA 0 issuemail "authority.example"

Malformed "issuemail" Property The following RRSet contains a single "issuemail" Property whose sub-syntax does not conform to the ABNF as specified in . 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. malformed.client.example CAA 0 issuemail "%%%%%"

Security Considerations The security considerations that are expressed in are relevant to this specification. 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 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. 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. For example, assume that an RRSet contains the following Properties: 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".

IANA Considerations 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:

Tag	Meaning	Reference
issuemail	Authorization Entry by Email Address	RFC 9495

References Normative References 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. 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 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] 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] 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. 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. 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 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 , , , , , , , , , , , , , , and for their official reviews and suggestions, which greatly improved the quality of this document.

Author's Address DigiCert, Inc.

corey.bonnell@digicert.com