Movatterモバイル変換


[0]ホーム

URL:


RFC 9495CAA for Email AddressesOctober 2023
BonnellStandards Track[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9495
Category:
Standards Track
Published:
ISSN:
2070-1721
Author:
C. Bonnell
DigiCert, Inc.

RFC 9495

Certification Authority Authorization (CAA) Processing for Email Addresses

Abstract

The Certification Authority Authorization (CAA) DNS resource record (RR)provides a mechanism for domains to express the allowed set ofCertification Authorities that are authorized to issuecertificates for the domain. RFC 8659 contains the core CAAspecification, where Property Tags that restrict the issuance ofcertificates that certify domain names are defined. This specificationdefines a Property Tag that grants authorization to Certification Authorities to issuecertificates that contain theid-kp-emailProtection key purpose intheextendedKeyUsage extension and at least onerfc822Name value orotherName value of typeid-on-SmtpUTF8Mailbox that includes the domain namein thesubjectAltName 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 athttps://www.rfc-editor.org/info/rfc9495.

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 (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.

Table of Contents

1.Introduction

The Certification Authority Authorization (CAA) DNS resource record (RR)provides a mechanism for domains to express the allowed set ofCertification Authorities that are authorized to issuecertificates for the domain.[RFC8659] contains the core CAAspecification, where Property Tags that restrict the issuance ofcertificates that certify domain names are defined.[RFC8659] does notdefine a mechanism to restrict the issuance of certificates thatcertify email addresses. For the purposes of this document, acertificate "certifies" an email address if the certificate contains theid-kp-emailProtection key purpose intheextendedKeyUsage extension and at least onerfc822Name value orotherName value of typeid-on-SmtpUTF8Mailbox that includes the domain namein thesubjectAltName extension.

This document defines a CAA Property Tag that restricts the allowed setof issuers of certificates that certify email addresses. Itssyntax and processing are similar to the "issue" Property Tag as definedinSection 4.2 of [RFC8659].

2.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[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.  The presence ofone or more "issuemail" Properties in the Relevant Resource RecordSet (RRSet)[RFC8659] indicates that the domain is requesting thatCertification Authorities restrict the issuance of certificates thatcertify 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" are defined inAppendix B.1 of [RFC5234]. Readers who are familiar with the sub-syntaxof the "issue" and "issuewild" Property Tags will recognize that thissub-syntax is identical.

The meanings of each production rule within "issuemail-value" are asfollows:

"issuer-domain-name":
A domain name of the Certification Authority comprised of one ormore 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, theCertification AuthorityMUST check for publication of a RelevantRRSet. The discovery of such a Relevant RRSetMUSTbe performed using the algorithm specified inSection 3 of [RFC8659].The input domain to the discovery algorithmSHALL 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 InternationalizedDomain Name[RFC5890] that contains one or more U-Labels, then allU-LabelsMUST be converted to their A-Label representation[RFC5891]for the purpose of discovering the Relevant RRSet for that emailaddress.

If the Relevant RRSet is empty or if it does not containany "issuemail" Properties, then the domain has not requested anyrestrictions on the issuance of certificates for email addresses. Thepresence of other Property Tags, such as "issue" or "issuewild", doesnot restrict the issuance of certificates that certify email addresses.

For each "issuemail" Property in the Relevant RRSet, theCertification AuthoritySHALL compare its issuer-domain-name with theissuer-domain-name as expressed in the Property Value. If there is notany "issuemail" record whose issuer-domain-name (as expressed in theProperty Value) matches the Certification Authority'sissuer-domain-name, then the Certification AuthorityMUST NOT issuethe certificate. If the Relevant RRSet contains any "issuemail"Property whose issuemail-value does not conform to the ABNF syntax asdefined inSection 3 of this document, then those recordsSHALL betreated as if the issuer-domain-name in the issuemail-value is the emptystring.

If the certificate certifies more than one email address, then theCertification AuthorityMUST perform the above procedure for eachemail address being certified.

The assignment of issuer-domain-names to Certification Authorities isbeyond the scope of this document.

Parameters may be defined by a Certification Authority as a meansfor domains to further restrict the issuance of certificates. Forexample, a Certification Authority may define a parameter that containsan account identifier. If the domain elects to add this parameter in an"issuemail" Property, the Certification Authority will verify that theaccount that is requesting the certificate matches the account specifiedin the Property and will refuse to issue the certificate if they do notmatch.

The processing of parameters in the issuemail-value is specific to eachCertification Authority and is beyond the scope of this document. Inparticular, this document does not define any parameters and does notspecify any processing rules for when parameters must be acknowledged bya Certification Authority. However, parameters that do not conform tothe ABNF syntax as defined inSection 3 will result in theissuemail-value being not conformant with the ABNF syntax. As statedabove, a Property whose issuemail-value is malformedSHALL be treated asif the issuer-domain-name in the issuemail-value is the empty string.

5.Examples of the "issuemail" Property Tag

Several illustrative examples of Relevant RRSets and their expectedprocessing semantics follow. All examples assume that theissuer-domain-name for the Certification Authority is"authority.example".

5.1.No "issuemail" Property

The following RRSet does not contain any "issuemail" Properties,so there are no restrictions on the issuance of certificates thatcertify 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

The following RRSet contains a single "issuemail" Property where theissuer-domain-name is the empty string, so the issuance of certificatescertifying email addresses for the domain is prohibited:

mail.client.example         CAA 0 issuemail ";"

5.3.Single "issuemail" Property with Parameters

The following RRSet contains a single "issuemail" Property where theissuer-domain-name is "authority.example" and contains a single"account" parameter of "123456". In this case, the CertificationAuthorityMAY issue the certificate, or itMAY refuse to issue thecertificate, depending on its practices for processing the "account"parameter:

mail.client.example        CAA 0 issuemail "authority.example; account=123456"

5.4.Multiple "issuemail" Properties

The following RRSet contains multiple "issuemail" Properties,where one Property matches the issuer-domain-name of the example CertificationAuthority ("authority.example") and one Property does not match.Although this example is contrived, it demonstrates that sincethere is at least one record whose issuer-domain-name matches theCertification 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

The following RRSet contains a single "issuemail" Property whosesub-syntax does not conform to the ABNF as specified inSection 3.Given that "issuemail" Properties with malformed syntax are treated thesame as "issuemail" Properties whose issuer-domain-name is the emptystring, issuance is prohibited.

malformed.client.example     CAA 0 issuemail "%%%%%"

6.Security Considerations

The security considerations that are expressed in[RFC8659] are relevantto this specification.

The processing of "issuemail" Properties as specified in this documentis a supplement to the Certification Authority's validation process.The Certification AuthorityMUST NOT treat solely the presence of an"issuemail" Property with its issuer-domain-name specified within theRelevant CAA RRSet as sufficient validation of the email address. TheCertification AuthorityMUST validate the email address according to therelevant policy documents and practice statements.

CAA Properties may have the "critical" flag asserted, which specifiesthat a given Property is critical and must be processed by conformingCertification Authorities. If a Certification Authority does notunderstand the Property, then itMUST NOT issue the certificate inquestion.

If a single CAA RRSet is processed by multiple Certification Authoritiesfor the issuance of multiple certificate types, then a CertificationAuthority's lack of support for a critical CAA Property in the RRSetwill prevent the Certification Authority from issuing any certificatesfor 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-namematches "authority.example" does not recognize the "issue" Property Tag,then that Certification Authority will not be able to issue S⁠/MIMEcertificates that certify email addresses for "client.example".

7.IANA Considerations

IANA has registered the following entry in the "Certification Authority Restriction Properties" subregistry of the "Public KeyInfrastructure using X.509 (PKIX) Parameters" registry group:

Table 1
TagMeaningReference
issuemailAuthorization Entry by Email AddressRFC 9495

8.References

8.1.Normative References

[RFC2119]
Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119,DOI 10.17487/RFC2119,,<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234]
Crocker, D., Ed. andP. Overell,"Augmented BNF for Syntax Specifications: ABNF",STD 68,RFC 5234,DOI 10.17487/RFC5234,,<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322]
Resnick, P., Ed.,"Internet Message Format",RFC 5322,DOI 10.17487/RFC5322,,<https://www.rfc-editor.org/info/rfc5322>.
[RFC5891]
Klensin, J.,"Internationalized Domain Names in Applications (IDNA): Protocol",RFC 5891,DOI 10.17487/RFC5891,,<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,,<https://www.rfc-editor.org/info/rfc8174>.
[RFC8659]
Hallam-Baker, P.,Stradling, R., andJ. Hoffman-Andrews,"DNS Certification Authority Authorization (CAA) Resource Record",RFC 8659,DOI 10.17487/RFC8659,,<https://www.rfc-editor.org/info/rfc8659>.

8.2.Informative References

[RFC5890]
Klensin, J.,"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework",RFC 5890,DOI 10.17487/RFC5890,,<https://www.rfc-editor.org/info/rfc5890>.

Acknowledgments

The author would like to thank the participants on the LAMPS WorkingGroup mailing list for their insightful feedback and comments. Inparticular, the author extends sincere appreciation toAlexey 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, andTim Wicinski for their official reviews andsuggestions, which greatly improved the quality of this document.

Author's Address

Corey Bonnell
DigiCert, Inc.
Email:corey.bonnell@digicert.com

[8]ページ先頭

©2009-2025 Movatter.jp