doc: Add RFC documents

1 files changed, 377 insertions, 0 deletions

diff --git a/doc/rfc/rfc9495.txt b/doc/rfc/rfc9495.txt
new file mode 100644
index 0000000..4edfb41
--- /dev/null
+++ b/doc/rfc/rfc9495.txt
@@ -0,0 +1,377 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        C. Bonnell
+Request for Comments: 9495                                DigiCert, Inc.
+Category: Standards Track                                   October 2023
+ISSN: 2070-1721
+
+
+    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 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
+   https://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
+   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 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.
+
+   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
+
+   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 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.
+
+   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 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.
+
+   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
+
+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.  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.
+
+   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 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 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.
+
+5.  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".
+
+5.1.  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"
+
+5.2.  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 ";"
+
+5.3.  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"
+
+5.4.  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"
+
+5.5.  Malformed "issuemail" Property
+
+   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.
+
+   malformed.client.example     CAA 0 issuemail "%%%%%"
+
+6.  Security Considerations
+
+   The security considerations that are expressed in [RFC8659] 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".
+
+7.  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  |
+     +-----------+--------------------------------------+-----------+
+
+                                 Table 1
+
+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, 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>.
+
+8.2.  Informative References
+
+   [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>.
+
+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.
+
+Author's Address
+
+   Corey Bonnell
+   DigiCert, Inc.
+   Email: corey.bonnell@digicert.com