RFC 9495

Certification Authority Authorization (CAA) Processing for Email Addresses

📅 published October 2023, from ietf

RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses 💅

Okay bestie, let's start with the basics 🎀 RFC 9495 comes from the IETF (Internet Engineering Task Force) and was written by C. Bonnell at DigiCert, Inc. It's on the Standards Track and was published in October 2023. Its ISSN is 2070-1721. The title block doesn't mention obsoleting or updating any other RFCs 🦋

Abstract ✨

Okay so the CAA DNS resource record (RR) is basically how a domain says which Certification Authorities are allowed to issue certificates for it 🔐 The core CAA spec is in RFC 8659, which defines the Property Tags that restrict issuing certificates for domain names. This spec adds a new Property Tag that gives Certification Authorities the green light to issue certificates that include the id-kp-emailProtection key purpose in the extendedKeyUsage extension, plus at least one rfc822Name value or an 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 IETF, and it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status, any errata, and a way to send feedback, head to https://www.rfc-editor.org/info/rfc9495 🔗

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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 🧾 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License.

Table of Contents 🗂️

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

1. Introduction 🌸

The CAA DNS resource record (RR) is how a domain tells the world which Certification Authorities are allowed to issue certificates for it 🙌 [RFC8659] contains the core CAA spec, where the Property Tags that restrict issuing certificates for 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.

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] 🦋

2. Conventions and Definitions 📖

Here's the keyword rule 🧠 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.

3. Syntax of the "issuemail" Property Tag 🎀

This document defines the "issuemail" Property Tag. If one or more "issuemail" Properties show up in the Relevant Resource Record Set (RRSet) [RFC8659], that means the domain is asking Certification Authorities to restrict the issuance of certificates that certify email addresses 💌

The CAA "issuemail" Property Value has the following sub-syntax (specified in ABNF as per [RFC5234]):

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" come from Appendix B.1 of [RFC5234]. If you already know the sub-syntax of the "issue" and "issuewild" Property Tags, you'll spot that this one is identical 👀

The meanings of each production rule within "issuemail-value" go like this:

  • 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

4. 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. Finding that Relevant RRSet MUST be done with the algorithm from Section 3 of [RFC8659]. The input domain for that discovery algorithm SHALL be the domain "part" [RFC5322] of the email address 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 🔄

If the Relevant RRSet is empty, or if it doesn't contain any "issuemail" Properties, then the domain hasn't requested any restrictions on issuing certificates for email addresses 🙅‍♀️ Other Property Tags, like "issue" or "issuewild", don't 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 isn't 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 doesn't conform to the ABNF syntax 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.

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 way for domains to restrict issuance even further. For example, a Certification Authority may define a parameter that contains an account identifier. If the domain adds this parameter to an "issuemail" Property, the Certification Authority will verify that the account requesting the certificate matches the account specified in the Property, and it will refuse to issue the certificate if they don't 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 doesn't define any parameters, and it doesn't specify any processing rules for when parameters must be acknowledged by a Certification Authority. However, parameters that don't conform to the ABNF syntax defined in Section 3 will make the issuemail-value non-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 🙈

5. Examples of the "issuemail" Property Tag 🍓

Here come some illustrative examples of Relevant RRSets and how they're expected to be processed 🌈 Every example assumes that the issuer-domain-name for the Certification Authority is "authority.example".

5.1. No "issuemail" Property

This RRSet doesn't contain any "issuemail" Properties, so there are no restrictions on issuing 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"

5.2. Single "issuemail" Property

This RRSet has a single "issuemail" Property where the issuer-domain-name is the empty string, so issuing certificates that certify email addresses for the domain is prohibited 🛑

mail.client.example         CAA 0 issuemail ";"

5.3. Single "issuemail" Property with Parameters

This RRSet has a single "issuemail" Property where the issuer-domain-name is "authority.example" and it includes 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"

5.4. Multiple "issuemail" Properties

This RRSet has multiple "issuemail" Properties. One of them matches the issuer-domain-name of the example Certification Authority ("authority.example") and one doesn't. It's a bit contrived, sure 😅 but it shows that because at least one record's 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"

5.5. Malformed "issuemail" Property

This RRSet has a single "issuemail" Property whose sub-syntax doesn't conform to the ABNF in Section 3. Since "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 "%%%%%"

6. Security Considerations 🔐

Okay bestie, this section is serious, so let's go! 💅 It starts by pointing you to the security considerations already written in [RFC8659], because they apply here too 🫶

The issuemail processing in this document is a supplement to the Certification Authority's validation process, not a replacement for it 🌸 A 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. Seeing the property is NOT enough! 🙈 The Certification Authority MUST validate the email address according to the relevant policy documents and practice statements.

Next, CAA Properties may have the "critical" flag asserted 🚩 That means the Property is critical and must be processed by conforming Certification Authorities. If a Certification Authority doesn't understand the Property, then it MUST NOT issue the certificate in question. No cert for you! 💀

If a single CAA RRSet is processed by multiple Certification Authorities for issuing multiple certificate types, then one Certification Authority's lack of support for a critical CAA Property in the RRSet will stop that Certification Authority from issuing any certificates for that domain 😭 One unsupported critical property and the whole thing is blocked, it's giving domino effect 🍓

Here's an example RRSet with these 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" doesn't recognize the "issue" Property Tag, then that Certification Authority won't be able to issue S/MIME certificates that certify email addresses for "client.example". Main character energy for the critical flag, honestly 👑✨

7. IANA Considerations 🦋

IANA has registered a new entry in the "Certification Authority Restriction Properties" subregistry of the "Public Key Infrastructure using X.509 (PKIX) Parameters" registry group 🎀 Here's the entry:

+===========+======================================+===========+
| Tag       | Meaning                              | Reference |
+===========+======================================+===========+
| issuemail | Authorization Entry by Email Address | RFC 9495  |
+-----------+--------------------------------------+-----------+

                             Table 1

8. References 📚

8.1. Normative References

8.2. Informative References

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 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 ✨ Everyone who helped make this better, you're iconic 🌈

Author's Address 🧚

Corey Bonnell

DigiCert, Inc.

Email: corey.bonnell@digicert.com

📦 where this page comes from