rfc9495.original.xml   rfc9495.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- [CS] updated by Chris 09/06/23 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2. 2) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2. 2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-lamps-caa-issuemail-07" category="std" consensus="true" submissionType="IE <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
TF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> -ietf-lamps-caa-issuemail-07" number="9495" submissionType="IETF" category="std"
consensus="true" tocInclude="true" sortRefs="true" symRefs="true"
updates="" obsoletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.17.5 --> <!-- xml2rfc v2v3 conversion 3.17.5 -->
<front> <front>
<title abbrev="CAA for Email Addresses">Certification Authority Authorizatio n (CAA) Processing for Email Addresses</title> <title abbrev="CAA for Email Addresses">Certification Authority Authorizatio n (CAA) Processing for Email Addresses</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-caa-issuemail-07"/ > <seriesInfo name="RFC" value="9495"/>
<author fullname="Corey Bonnell"> <author fullname="Corey Bonnell">
<organization>DigiCert, Inc.</organization> <organization>DigiCert, Inc.</organization>
<address> <address>
<email>corey.bonnell@digicert.com</email> <email>corey.bonnell@digicert.com</email>
</address> </address>
</author> </author>
<date year="2023" month="August" day="10"/> <date year="2023" month="October"/>
<area>Security</area> <area>sec</area>
<workgroup>lamps</workgroup>
<keyword>caa</keyword> <keyword>caa</keyword>
<keyword>certification authority authorization</keyword> <keyword>certification authority authorization</keyword>
<keyword>email address</keyword> <keyword>email address</keyword>
<abstract> <abstract>
<?line 42?>
<t>The Certification Authority Authorization (CAA) DNS resource record (RR) <t>The Certification Authority Authorization (CAA) DNS resource record (RR)
provides a mechanism for domains to express the allowed set of provides a mechanism for domains to express the allowed set of
Certification Authorities (CAs) that are authorized to issue Certification Authorities that are authorized to issue
certificates for the domain. RFC 8659 contains the core CAA certificates for the domain. RFC 8659 contains the core CAA
specification, where Property Tags that restrict the issuance of specification, where Property Tags that restrict the issuance of
certificates which certify domain names are defined. This specification certificates that certify domain names are defined. This specification
defines a Property Tag that grants authorization to CAs to issue defines a Property Tag that grants authorization to Certification Authorities to
certificates which contain the <tt>id-kp-emailProtection</tt> key purpose in issue
the <tt>extendedKeyUsage</tt> extension and one or more <tt>rfc822Name</tt> or certificates that contain the <tt>id-kp-emailProtection</tt> key purpose in
<tt>otherName</tt> of type <tt>id-on-SmtpUTF8Mailbox</tt> that include the domai the <tt>extendedKeyUsage</tt> extension and at least one <tt>rfc822Name</tt> val
n name ue or
<tt>otherName</tt> value of type <tt>id-on-SmtpUTF8Mailbox</tt> that includes th
e domain name
in the <tt>subjectAltName</tt> extension.</t> in the <tt>subjectAltName</tt> extension.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
CBonnell.github.io/caa-issuemail/draft-ietf-lamps-caa-issuemail.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-lamps-caa-issuemail/"/>.
</t>
<t>
Discussion of this document takes place on the
Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group m
ailing list (<eref target="mailto:spasm@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/spasm/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/"
/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/CBonnell/caa-issuemail"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 56?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Certification Authority Authorization (CAA) DNS resource record (RR ) <t>The Certification Authority Authorization (CAA) DNS resource record (RR )
provides a mechanism for domains to express the allowed set of provides a mechanism for domains to express the allowed set of
Certification Authorities (CAs) that are authorized to issue Certification Authorities that are authorized to issue
certificates for the domain. <xref target="RFC8659"/> contains the core CAA certificates for the domain. <xref target="RFC8659"/> contains the core CAA
specification, where Property Tags that restrict the issuance of specification, where Property Tags that restrict the issuance of
certificates which certify domain names are defined. <xref target="RFC8659"/> do certificates that certify domain names are defined. <xref target="RFC8659"/> doe
es not s not
define a mechanism to restrict the issuance of certificates which define a mechanism to restrict the issuance of certificates that
certify email addresses. For the purposes of this document, a certify email addresses. For the purposes of this document, a
certificate "certifies" an email address if the certificate contains the certificate "certifies" an email address if the certificate contains the
<tt>id-kp-emailProtection</tt> key purpose in the <tt>extendedKeyUsage</tt> exte <tt>id-kp-emailProtection</tt> key purpose in
nsion the <tt>extendedKeyUsage</tt> extension and at least one <tt>rfc822Name</tt> val
and the email address is included as a <tt>rfc822Name</tt> or <tt>otherName</tt> ue or
of <tt>otherName</tt> value of type <tt>id-on-SmtpUTF8Mailbox</tt> that includes th
type <tt>id-on-SmtpUTF8Mailbox</tt> in the <tt>subjectAltName</tt> extension.</t e domain name
> in the <tt>subjectAltName</tt> extension.</t>
<t>This document defines a CAA Property Tag which restricts the allowed se <t>This document defines a CAA Property Tag that restricts the allowed set
t of issuers of certificates that certify email addresses. Its
of issuers of certificates which certify email addresses. Its
syntax and processing are similar to the "issue" Property Tag as defined syntax and processing are similar to the "issue" Property Tag as defined
in section 4.2 of <xref target="RFC8659"/>.</t> in <xref target="RFC8659" sectionFormat="of" section="4.2"/>.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<?line -18?>
</section> </section>
<section anchor="syntax"> <section anchor="syntax">
<name>Syntax of the "issuemail" Property Tag</name> <name>Syntax of the "issuemail" Property Tag</name>
<t>This document defines the "issuemail" Property Tag. The presence of <t>This document defines the "issuemail" Property Tag. &nbsp;The presence of
one or more "issuemail" Properties in the Relevant Resource Record one or more "issuemail" Properties in the Relevant Resource Record
Set (<xref target="RFC8659"/>) indicates that the domain is requesting that Set (RRSet) <xref target="RFC8659"/> indicates that the domain is requesting tha t
Certification Authorities restrict the issuance of certificates that Certification Authorities restrict the issuance of certificates that
certify email addresses.</t> certify email addresses.</t>
<t>The CAA "issuemail" Property Value has the following sub-syntax <t>The CAA "issuemail" Property Value has the following sub-syntax
(specified in ABNF as per <xref target="RFC5234"/>):</t> (specified in ABNF as per <xref target="RFC5234"/>):</t>
<artwork><![CDATA[
<sourcecode name="" type="abnf"><![CDATA[
issuemail-value = *WSP [issuer-domain-name *WSP] issuemail-value = *WSP [issuer-domain-name *WSP]
[";" *WSP [parameters *WSP]] [";" *WSP [parameters *WSP]]
issuer-domain-name = label *("." label) issuer-domain-name = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
parameters = (parameter *WSP ";" *WSP parameters) / parameter parameters = (parameter *WSP ";" *WSP parameters) / parameter
parameter = tag *WSP "=" *WSP value parameter = tag *WSP "=" *WSP value
tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
value = *(%x21-3A / %x3C-7E) value = *(%x21-3A / %x3C-7E)
]]></artwork> ]]></sourcecode>
<t>The production rules for "WSP", "ALPHA", and "DIGIT" are defined in <t>The production rules for "WSP", "ALPHA", and "DIGIT" are defined in
Appendix B.1 of <xref target="RFC5234"/>. Readers who are familiar with the sub- syntax <xref target="RFC5234" sectionFormat="of" section="B.1"/>. Readers who are famil iar with the sub-syntax
of the "issue" and "issuewild" Property Tags will recognize that this of the "issue" and "issuewild" Property Tags will recognize that this
sub-syntax is identical.</t> sub-syntax is identical.</t>
<t>The meanings of each production rule within "issuemail-value" are as <t>The meanings of each production rule within "issuemail-value" are as
follows:</t> follows:</t>
<ul spacing="normal"> <dl spacing="normal" newline="true">
<li>"issuer-domain-name": A domain name of the CA comprised of one or <dt>"issuer-domain-name":</dt><dd>A domain name of the Certification Aut
more labels</li> hority comprised of one or
<li>"label": A single domain label which consists solely of ASCII letter more labels</dd>
s, <dt>"label":</dt><dd>A single domain label that consists solely of ASCII
digits, and the hyphen (known as an "LDH label")</li> letters,
<li>"parameters": A semicolon-separated list of parameters</li> digits, and the hyphen (known as an "LDH label")</dd>
<li>"parameter": A tag and a value, separated by an equals sign ("=")</l <dt>"parameters":</dt><dd>A semicolon-separated list of parameters</dd>
i> <dt>"parameter":</dt><dd>A tag and a value, separated by an equals sign
<li>"tag": A keyword which identifies the type of parameter</li> ("=")</dd>
<li>"value": The string value for a parameter</li> <dt>"tag":</dt><dd>A keyword that identifies the type of parameter</dd>
</ul> <dt>"value":</dt><dd>The string value for a parameter</dd>
</dl>
</section> </section>
<section anchor="processing-of-the-issuemail-property-tag"> <section anchor="processing-of-the-issuemail-property-tag">
<name>Processing of the "issuemail" Property Tag</name> <name>Processing of the "issuemail" Property Tag</name>
<t>Prior to issuing a certificate that certifies an email address, the <t>Prior to issuing a certificate that certifies an email address, the
Certification Authority <bcp14>MUST</bcp14> check for publication of a Relevant Certification Authority <bcp14>MUST</bcp14> check for publication of a Relevant
Resource Record Set (RRSet). The discovery of such a Relevant RRSet <bcp14>MUST< RRSet. The discovery of such a Relevant RRSet <bcp14>MUST</bcp14>
/bcp14> be performed using the algorithm specified in <xref target="RFC8659" sectionForm
be performed using the algorithm specified in section 3 of <xref target="RFC8659 at="of" section="3"/>.
"/>.
The input domain to the discovery algorithm <bcp14>SHALL</bcp14> be the domain " part" The input domain to the discovery algorithm <bcp14>SHALL</bcp14> be the domain " part"
(<xref target="RFC5322"/>) of the email address that is being certified. If the domain <xref target="RFC5322"/> of the email address that is being certified. If the do main
"part" of the email address being certified is an Internationalized "part" of the email address being certified is an Internationalized
Domain Name (<xref target="RFC5890"/>) that contains one or more U-Labels, then Domain Name <xref target="RFC5890"/> that contains one or more U-Labels, then al
all l
U-Labels <bcp14>MUST</bcp14> be converted to their A-Label representation (<xref U-Labels <bcp14>MUST</bcp14> be converted to their A-Label representation <xref
target="RFC5891"/>) target="RFC5891"/>
for the purpose of discovering the Relevant RRSet for that email for the purpose of discovering the Relevant RRSet for that email
address.</t> address.</t>
<t>If the Relevant RRSet is empty, or the Relevant RRSet does not contain <t>If the Relevant RRSet is empty or if it does not contain
any "issuemail" Properties, then the domain has not requested any any "issuemail" Properties, then the domain has not requested any
restrictions on the issuance of certificates for email addresses. The restrictions on the issuance of certificates for email addresses. The
presence of other Property Tags, such as "issue" or "issuewild", does presence of other Property Tags, such as "issue" or "issuewild", does
not restrict the issuance of certificates which certify email addresses.</t> not restrict the issuance of certificates that certify email addresses.</t>
<t>For each "issuemail" Property in the Relevant RRSet, the <t>For each "issuemail" Property in the Relevant RRSet, the
Certification Authority <bcp14>SHALL</bcp14> compare its issuer-domain-name with the Certification Authority <bcp14>SHALL</bcp14> compare its issuer-domain-name with the
issuer-domain-name as expressed in the Property Value. If there is not issuer-domain-name as expressed in the Property Value. If there is not
any "issuemail" record whose issuer-domain-name (as expressed in the any "issuemail" record whose issuer-domain-name (as expressed in the
Property Value) matches the Certification Authority's Property Value) matches the Certification Authority's
issuer-domain-name, then the Certification Authority <bcp14>MUST NOT</bcp14> iss ue issuer-domain-name, then the Certification Authority <bcp14>MUST NOT</bcp14> iss ue
the certificate. If the Relevant RRSet contains any "issuemail" the certificate. If the Relevant RRSet contains any "issuemail"
Property whose issuemail-value does not conform to the ABNF syntax as Property whose issuemail-value does not conform to the ABNF syntax as
defined in <xref target="syntax"/> of this document, then those records <bcp14>S HALL</bcp14> be defined in <xref target="syntax"/> of this document, then those records <bcp14>S HALL</bcp14> be
treated as if the issuer-domain-name in the issuemail-value is the empty treated as if the issuer-domain-name in the issuemail-value is the empty
string.</t> string.</t>
<t>If the certificate certifies more than one email address, then the <t>If the certificate certifies more than one email address, then the
Certification Authority <bcp14>MUST</bcp14> perform the above procedure for each Certification Authority <bcp14>MUST</bcp14> perform the above procedure for each
email address being certified.</t> email address being certified.</t>
<t>The assignment of issuer-domain-names to Certification Authorities is <t>The assignment of issuer-domain-names to Certification Authorities is
beyond the scope of this document.</t> beyond the scope of this document.</t>
<t>Parameters may be defined by a Certification Authority as a means <t>Parameters may be defined by a Certification Authority as a means
for domains to further restrict the issuance of certificates. For for domains to further restrict the issuance of certificates. For
example, a Certification Authority may define a parameter which contains example, a Certification Authority may define a parameter that contains
an account identifier. If the domain elects to add this parameter in an an account identifier. If the domain elects to add this parameter in an
issuemail Property, the Certification Authority will verify that the "issuemail" Property, the Certification Authority will verify that the
account that is requesting the certificate matches the account specified account that is requesting the certificate matches the account specified
in the Property and will refuse to issue the certificate if they do not in the Property and will refuse to issue the certificate if they do not
match.</t> match.</t>
<t>The processing of parameters in the issuemail-value are specific to eac <t>The processing of parameters in the issuemail-value is specific to each
h Certification Authority and is beyond the scope of this document. In
Certification Authority and are beyond the scope of this document. In
particular, this document does not define any parameters and does not particular, this document does not define any parameters and does not
specify any processing rules for when parameters must be acknowledged by specify any processing rules for when parameters must be acknowledged by
a Certification Authority. However, parameters that do not conform to a Certification Authority. However, parameters that do not conform to
the ABNF syntax as defined in <xref target="syntax"/> will result in the the ABNF syntax as defined in <xref target="syntax"/> will result in the
issuemail-value being not conformant with the ABNF syntax. As stated issuemail-value being not conformant with the ABNF syntax. As stated
above, a Property whose issuemail-value is malformed <bcp14>SHALL</bcp14> be tre ated as above, a Property whose issuemail-value is malformed <bcp14>SHALL</bcp14> be tre ated as
if the issuer-domain-name in the issuemail-value is the empty string.</t> if the issuer-domain-name in the issuemail-value is the empty string.</t>
</section> </section>
<section anchor="examples-of-the-issuemail-property-tag"> <section anchor="examples-of-the-issuemail-property-tag">
<name>Examples of the "issuemail" Property Tag</name> <name>Examples of the "issuemail" Property Tag</name>
<t>Several illustrative examples of Relevant RRSets and their expected <t>Several illustrative examples of Relevant RRSets and their expected
processing semantics follow. All examples assume that the processing semantics follow. All examples assume that the
issuer-domain-name for the Certification Authority is issuer-domain-name for the Certification Authority is
"authority.example".</t> "authority.example".</t>
<section anchor="no-issuemail-property"> <section anchor="no-issuemail-property">
<name>No issuemail Property</name> <name>No "issuemail" Property</name>
<t>The following RRSet does not contain any "issuemail" Properties, <t>The following RRSet does not contain any "issuemail" Properties,
so there are no restrictions on the issuance of certificates which so there are no restrictions on the issuance of certificates that
certify email addresses for that domain:</t> certify email addresses for that domain:</t>
<artwork><![CDATA[ <artwork><![CDATA[
mail.client.example CAA 0 issue "authority.example" mail.client.example CAA 0 issue "authority.example"
mail.client.example CAA 0 issue "other-authority.example" mail.client.example CAA 0 issue "other-authority.example"
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="single-issuemail-property"> <section anchor="single-issuemail-property">
<name>Single issuemail Property</name> <name>Single "issuemail" Property</name>
<t>The following RRSet contains a single "issuemail" Property where the <t>The following RRSet contains a single "issuemail" Property where the
issuer-domain-name is the empty string, so the issuance of certificates issuer-domain-name is the empty string, so the issuance of certificates
certifying email addresses for the domain is prohibited:</t> certifying email addresses for the domain is prohibited:</t>
<artwork><![CDATA[ <artwork><![CDATA[
mail.client.example CAA 0 issuemail ";" mail.client.example CAA 0 issuemail ";"
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="single-issuemail-property-with-parameters"> <section anchor="single-issuemail-property-with-parameters">
<name>Single issuemail Property with Parameters</name> <name>Single "issuemail" Property with Parameters</name>
<t>The following RRSet contains a single "issuemail" Property where the <t>The following RRSet contains a single "issuemail" Property where the
issuer-domain-name is "authority.example" and contains a single issuer-domain-name is "authority.example" and contains a single
"account" parameter of "123456". In this case, the Certification "account" parameter of "123456". In this case, the Certification
Authority <bcp14>MAY</bcp14> issue the certificate, or it <bcp14>MAY</bcp14> ref use to issue the Authority <bcp14>MAY</bcp14> issue the certificate, or it <bcp14>MAY</bcp14> ref use to issue the
certificate depending on its practices for processing the "account" certificate, depending on its practices for processing the "account"
parameter:</t> parameter:</t>
<artwork><![CDATA[ <artwork><![CDATA[
mail.client.example mail.client.example
CAA 0 issuemail "authority.example; account=123456" CAA 0 issuemail "authority.example; account=123456"
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="multiple-issuemail-properties"> <section anchor="multiple-issuemail-properties">
<name>Multiple issuemail Properties</name> <name>Multiple "issuemail" Properties</name>
<t>The following RRSet contains multiple "issuemail" Properties, <t>The following RRSet contains multiple "issuemail" Properties,
one of which matches the issuer-domain-name of the example Certification where one Property matches the issuer-domain-name of the example Certification
Authority ("authority.example") and one Property which does not match. Authority ("authority.example") and one Property does not match.
Although this example is contrived, this example demonstrates that since Although this example is contrived, it demonstrates that since
there is at least one record whose issuer-domain-name matches the there is at least one record whose issuer-domain-name matches the
Certification Authority's issuer-domain-name, issuance is permitted.</t> Certification Authority's issuer-domain-name, issuance is permitted.</t>
<artwork><![CDATA[ <artwork><![CDATA[
mail.client.example CAA 0 issuemail ";" mail.client.example CAA 0 issuemail ";"
mail.client.example CAA 0 issuemail "authority.example" mail.client.example CAA 0 issuemail "authority.example"
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="malformed-issuemail-property"> <section anchor="malformed-issuemail-property">
<name>Malformed issuemail Property</name> <name>Malformed "issuemail" Property</name>
<t>The following RRSet contains a single "issuemail" Property whose <t>The following RRSet contains a single "issuemail" Property whose
sub-syntax does not conform to the ABNF as specified in <xref target="syntax"/>. sub-syntax does not conform to the ABNF as specified in <xref target="syntax"/>.
Given that "issuemail" Properties with malformed syntax are treated the Given that "issuemail" Properties with malformed syntax are treated the
same as "issuemail" Properties whose issuer-domain-name is the empty same as "issuemail" Properties whose issuer-domain-name is the empty
string, issuance is prohibited.</t> string, issuance is prohibited.</t>
<artwork><![CDATA[ <artwork><![CDATA[
malformed.client.example CAA 0 issuemail "%%%%%" malformed.client.example CAA 0 issuemail "%%%%%"
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations that are expressed in <xref target="RFC8659 "/> are relevant <t>The security considerations that are expressed in <xref target="RFC8659 "/> are relevant
to this specification.</t> to this specification.</t>
<t>The processing of "issuemail" Properties as specified in this document <t>The processing of "issuemail" Properties as specified in this document
is a supplement to the Certification Authority's validation process. is a supplement to the Certification Authority's validation process.
The Certification Authority <bcp14>MUST NOT</bcp14> treat solely the presence of an The Certification Authority <bcp14>MUST NOT</bcp14> treat solely the presence of an
"issuemail" Property with its issuer-domain-name specified within the "issuemail" Property with its issuer-domain-name specified within the
relevant CAA RRSet as sufficient validation of the email address. The Relevant CAA RRSet as sufficient validation of the email address. The
Certification Authority <bcp14>MUST</bcp14> validate the email address according to the Certification Authority <bcp14>MUST</bcp14> validate the email address according to the
relevant policy documents and practice statements.</t> relevant policy documents and practice statements.</t>
<t>CAA Properties may have the "critical" flag asserted, which specifies <t>CAA Properties may have the "critical" flag asserted, which specifies
that the Property is critical and must be processed by conforming that a given Property is critical and must be processed by conforming
Certification Authorities. If a Certification Authority does not Certification Authorities. If a Certification Authority does not
understand the Property, then it <bcp14>MUST NOT</bcp14> issue the certificate i n understand the Property, then it <bcp14>MUST NOT</bcp14> issue the certificate i n
question.</t> question.</t>
<t>If a single CAA RRSet is processed by multiple Certification Authoritie s <t>If a single CAA RRSet is processed by multiple Certification Authoritie s
for the issuance of multiple certificate types, then a Certification for the issuance of multiple certificate types, then a Certification
Authority's lack of support for a critical CAA Property in the RRSet Authority's lack of support for a critical CAA Property in the RRSet
will prevent the Certification Authority from issuing any certificates will prevent the Certification Authority from issuing any certificates
for that domain.</t> for that domain.</t>
<t>For example, assume that an RRSet contains the following Properties:</t > <t>For example, assume that an RRSet contains the following Properties:</t >
<artwork><![CDATA[ <artwork><![CDATA[
client.example CAA 128 issue "other-authority.example" client.example CAA 128 issue "other-authority.example"
client.example CAA 0 issuemail "authority.example" client.example CAA 0 issuemail "authority.example"
]]></artwork> ]]></artwork>
<t>In this case, if the Certification Authority whose issuer-domain-name <t>In this case, if the Certification Authority whose issuer-domain-name
matches "authority.example" does not recognize the "issue" Property Tag, matches "authority.example" does not recognize the "issue" Property Tag,
then that Certification Authority will not be able to issue S/MIME then that Certification Authority will not be able to issue S&wj;/MIME
certificates that certify email addresses for "client.example".</t> certificates that certify email addresses for "client.example".</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The author requests the registration of the following "Certification <t>IANA has registered the following entry in the "Certification Authority
Authority Restriction Properties" in the registry group "Public Key Restriction Properties" subregistry of the "Public Key
Infrastructure using X.509 (PKIX) Parameters":</t> Infrastructure using X.509 (PKIX) Parameters" registry group:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Tag</th> <th align="left">Tag</th>
<th align="left">Meaning</th> <th align="left">Meaning</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">issuemail</td> <td align="left">issuemail</td>
<td align="left">Authorization Entry by Email Address</td> <td align="left">Authorization Entry by Email Address</td>
<td align="left">[This document]</td> <td align="left">RFC 9495</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC5322">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"
<title>Internet Message Format</title> />
<author fullname="P. Resnick" initials="P." role="editor" surname="R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
esnick"/> />
<date month="October" year="2008"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5891.xml"
<abstract> />
<t>This document specifies the Internet Message Format (IMF), a sy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8659.xml"
ntax for text messages that are sent between computer users, within the framewor />
k of "electronic mail" messages. This specification is a revision of Request For <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "S />
tandard for the Format of ARPA Internet Text Messages", updating it to reflect c <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
urrent practice and incorporating incremental changes that were specified in oth />
er RFCs. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5322"/>
<seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
gmented BNF (ABNF), has been popular among many Internet specifications. The cur
rent specification documents ABNF. It balances compactness and simplicity with r
easonable representational power. The differences between standard BNF and ABNF
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC5891">
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protoc
ol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="August" year="2010"/>
<abstract>
<t>This document is the revised protocol definition for Internatio
nalized 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 do
main names, not free text. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5891"/>
<seriesInfo name="DOI" value="10.17487/RFC5891"/>
</reference>
<reference anchor="RFC8659">
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Reco
rd</title>
<author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Bak
er"/>
<author fullname="R. Stradling" initials="R." surname="Stradling"/>
<author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman
-Andrews"/>
<date month="November" year="2019"/>
<abstract>
<t>The Certification Authority Authorization (CAA) DNS Resource Re
cord allows a DNS domain name holder to specify one or more Certification Author
ities (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 r
ecord and rules for processing CAA records by CAs.</t>
<t>This document obsoletes RFC 6844.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8659"/>
<seriesInfo name="DOI" value="10.17487/RFC8659"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5890">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"
<title>Internationalized Domain Names for Applications (IDNA): Defin />
itions and Document Framework</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="August" year="2010"/>
<abstract>
<t>This document is one of a collection that, together, describe t
he protocol and usage context for a revision of Internationalized Domain Names f
or Applications (IDNA), superseding the earlier version. It describes the docume
nt collection and provides definitions and other material that are common to the
set. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890"/>
<seriesInfo name="DOI" value="10.17487/RFC5890"/>
</reference>
</references> </references>
</references> </references>
<?line 316?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The author would like to thank the participants on the LAMPS Working <t>The author would like to thank the participants on the LAMPS Working
Group mailing list for their insightful feedback and comments. In Group mailing list for their insightful feedback and comments. In
particular, the author extends sincere appreciation to Alexey Melnikov, particular, the author extends sincere appreciation to <contact fullname="Alexey
Christer Holmberg, Éric Vyncke, John Levine, Lars Eggert, Melnikov"/>,
Michael Richardson, Murray Kucherawy, Paul Wouters, <contact fullname="Christer Holmberg"/>, <contact fullname="Éric Vyncke"/>, <con
Phillip Hallam-Baker, Roman Danyliw, Russ Housley, Sean Turner, tact fullname="John Levine"/>, <contact fullname="Lars Eggert"/>,
Seo Suchan, Tim Chown, and Tim Wicinski for their official reviews and <contact fullname="Michael Richardson"/>, <contact fullname="Murray Kucherawy"/>
suggestions which greatly improved the quality of this document.</t> , <contact fullname="Paul Wouters"/>,
<contact fullname="Phillip Hallam-Baker"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Russ Housley"/>, <contact fullname="Sean Turner"/>,
<contact fullname="Seo Suchan"/>, <contact fullname="Tim Chown"/>, and <contact
fullname="Tim Wicinski"/> for their official reviews and
suggestions, which greatly improved the quality of this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+Va73IbtxH/jqdAz5OJmCGpSLYTW4mT0pIcq5ZsVZTjZDye
MXgHkqjuXw53ktjE+d636LO0L9bdBXCHI+9opWlnOlN9sI93AHaxf3+7wGg0
YqUqY3nAg0NZlGquQlGqLOWTqlxmhSpX7umv5v3O4WQy4OdFFkqtVbrg86zg
x4lQMZ9EUQEvpQ6YmM0KeY2LTibdI4CMXGTF6oDrMmIsysJUJMBGVIh5OVKy
nI9ikeR6FAoxUlpXElcYff4l09UsgRfATLnKYcbJ8eUzzu9xEesMKKo0krmE
f9IyGPLgZPIU/gMOgpOLy2cBS6tkJosDFgH9AxZmqZaprvQBL4tKMmD5PhOF
FAd8KsMK98/u8ZusuFoUWZUf8Dff8TfwCzf+Hb5hV3IFn6MDxkccWKX/WoIU
tSCFL0gcSFviwgiFXcu0ApY4t6SCU5WoUkYoNYVTRMzPZLgUqdKJJqmevzj5
gYs04tOzk7NjvkMSGwSwhhFN0OIV3yNFeK9zoZM/opTHWbHAD6IIl/BhWZa5
PtjdxXH4Sl3LsRu2iy92Z0V2o+UurbCLMxeqXFYz1PXTLE1lHO+2VIZDYhC2
Lr3l3dCxmTxWWXvS7nYzGC/LBBZmRqIoeyDC+byKY2NFh1khV9wSoW/APwjO
yP6AH6mFQnsf8pM0HNMAaUQT4szxzMz8YwTjUJ3jMEsYS7MigQWuSUsXzw4f
3t/fd4/79x+4x0eP9+zjoy8ePj5gTKXz9ZmPHn8OH9hoNOJipstChCVjl0vJ
f4sXHr2ccjCdrCpCCQ/AesR3Li4GLC+yaxVJzQVPnMWQwUQZ7DLVvMy4vM3R
7HgJREUcZzdgaVqWPJuzbh4UrAd09QCmiBIMRtYWDVNhRVIPa6xfGiNFAobu
GLfOUSgg5rQ0nMBXlDmHHTGdy7AmPOQ3SwkfINbksOaKX4qFNrSB8bJQYUmz
kaxIQQLAeYv4zVKFS+uNK8sCR/vQxHwk5yqV0ZhfLpXmLdLMfEP5+dQN8UUh
0lK3vRm3D6LpkYJlxGyZeH6votFVPiKbAwqlDHGV9xyiCc+rIs807CtlNFTe
lhjOohdy9VqLhXzP6Y2m4AK+n6US41uCQnxfzMNH+/svYZPv4SV7n8EShf05
p6hAtLN0NE3K/PXls0dnwMIsu31vNqfSMK4i6SmNJMYc3xB8/wLMTuLSLFqz
MjbGnKgoiiWDoHmSlkUWVbSx/wfTfmv9/d3/lG03XEUZfEuz0tp2S36wwz6y
fJMsc2Rb+UvqMX9mZWJNWJPNoXdBeq8SyMhDLvx98MD+AEQAttxekKu5kaA3
3hctu5sT8Y85EUMnwkFr1LVzhogLNLc13+Jt32Jbfesu7nPpC4o3EQghVCsK
Gd07hW2YOQOhk70Wult/vFd/J6VmegUivqXIkjcoD41KAx4BUIDWgiQDIhK0
eQNJWdvDkKGNSviD8T6yUhvjGAPEYZYC5MHvmqgd4TwCOtrEC9QjYivNg7PX
00tEc/g/f/mKni+O//z65OL4CJ+nzyenp/UDsyOmz1+9Pj1qnpqZh6/Ozo5f
HpnJ8Ja3XrHgbPIjfEGuglfnlyevXk5OA6NEX0coFBDGDM2slAUEnZKMBVxM
h4WawQ+Y8/Tw/B9/33vAf/75D7D//b29xx8+2B+P9r58AD8gFqRDG8vjlf0J
Il4xkecSJA6rgIIBX+aqBJg7RDHrZXaTcowiIM3P3qJk3h3wr2dhvvfgG/sC
N9x66WTWekky23yzMdkIseNVB5lamq33a5Ju8zv5sfXbyd17+fW3MUau0d6j
b79haEJTY6vZ3DNIwpxto/z5njHqD31Otm024gOIaOAi0gZiP+F2zMJkYv39
QsbyGtACPNhUdkGpjE0hG+3U7jCA8ZH1UMoBXvYFdgv5UwXOjm6IX7fksLsF
cVqkLwbYVA0xp1Mg34u4knwpjMzmGYYdZAwC28gIme3YTGesf/L05TM0V5hO
/o9A+d0AsO+vv/4KWLip7K5p5Sf8szfTc/7WBLCREcIIExt9eEdQ/W3wVWDH
5aKAbyXGOvr+jrlF25OfQA0ykzH/bCcYB+Z5QIUJvnzCdyan588nfJcfnXx3
cjmAYThyFAzWvwxwfY8oTK1/GZZq3ppRA5he//Lnw/QS7NPMe2LnkSCwhIMv
v4kzzmsZ7nxyu783uo9fP7m9fzj68nhAAmfGlh0u40UVWygTAGkMhrSoi320
cuAjCkSlkxzra3XLn473XFgntQK+lyJCsdwsM5o1F5AyFESwG6jzyGQ8Q2m5
bWAo0vONiqNgDRvBu5iA4AKqOOncRGnWLEgpG+t+sPPYGnIiAeGkC8qEUkDu
W9s8MQZmGqwZotk0hHJj4hoM9jM7qGVYwQGf+PDLxaLDCWCVJC+UBpnBOxMz
sADHqEFmp3FFeqJFMM3Gtdsbw6wLB600JHqdxRLyAyw3mR6enPBYlmheQ1gW
C9VSG7Uh/eUqhyzCd65SzBKIX2CPp0fPzcLBAGk3BmoYkIkKsxjgi5b4CXNZ
DHSRXjO0NZHmoZ0iWWHMb8ib6bMVobqfKkhasMEFMARmTsRhFs22/RO7VaM+
xIO0C8JUPnmcafRzQGEZwx1EH2P3aMbCGwsJwutTfSRJMHZeqKxwYJ8wTwt6
ksXVcHUDrVLC7gnNK07JOFzK8Iq4zKtZ7AYBX6JOFGwtUXBKFBcX8N/AJKJI
6TC7lgWZga5AZsJLMziQiDEAJbA37DuAHiptkgfixAVytEx4K0o7oHZ/DaYh
RZXmVens0mK/hotmQQMaZq3aEU2lDBilOuyWQKqzemiDbVN7apiNjDopQ/1y
MveWY2a57iXWpuJqoKMTBGapMO0zrObYkeEM8bdJwdiLeWcrv7q+8HP869Ep
+SupmJAYc6+MYmdUmIA4SlMtwjBV8IkZA0HLgIfS1reW5t67AZu36yXcmJOs
U9iabs0M4JQ2z+zmIdhZQa0NByHIJC9X1AHt+O6KQrdxqIVWPZjG7t5TLqIA
nGvxCULfdMUcBiFcn6XboQhuZ6MKAaNjHt7iVGe108HQmr6uswemsCZ5DGln
zHB358K2tzBiDCtbyh+d8WMD7qFwt0cE4y2YIzDRQOzuQi0ua7KOb7B32+cw
LowMtGGa8x5c35T+69q1jRXI1lp20d/pIMLaRAY8ESVENhOwe3b7qe7YgWdQ
W8MmFg2m/7LWDaijw5pR1068tt2Gc2/DHvb0nQEDpwt2BGFdWaxZg4SgirOF
xYeOTofdHVIyctZ1iGRlIYWpFV2Xo0P6qnEen02lbfQDv2YmATb+32qW1MmK
whiEjZTi2mbeSj+evGwyMUlkBhHKdAeiqjCJF52DbY3IFpEJjUCAyq+6UeFv
mzp4/SUOIL6ZXGUW5kCszOWG7IHSeQPRE7HCCO3Uhpik1+CE6SuKVLO1nuK8
KigM3SmcUCeMyVuR5DHYeT895K3uxzVlQathrMFtuQjDrAKR1QCpGPN2cuTg
BNQNylABRiDNithBSFltSnWkGG71PwLdmIwgJrrClDlWXM5uladtC/RDg5tW
4w62HrQQRFqYP6+0rPuuG8sal8G2J0U1ojKuaxsP8HmFWo8zUV/LdmapdYxm
3GsdiHJhwscNEHAHQ6yiwioWxXCtb1QHGqd6iFMeq0im7tYa5lZmTLO5pnDD
bpE/O6kAss9Q3oj9YxktyOhZrxGO+fPsRoKWh/4ypF0jYC8ess14yLvjoVWk
ruLSJY512Zv44BHAEF4Xih6VMZ9A+VBixGQUe4b+wUx3MFfo+LHFvw00reMu
+11xl9dx9x4/Nm6uP15hTFHKIuYgmgrP/PBAkEtvejuRaVfNAZiELAzeDfv3
bAAKNoHFrrZ9GBATyLxeDwItmFvjtx07dfizz+Ah2Ab1+fXYrhzgru/xlxnf
DCfGCZu2UDfKXE/MPspkOrOYBT0tbQ4m7oQnt55PNODZyMA2oehAOYwV+q3d
Ind/2Af73EahDkncfS5h2FHHCtSVAXFOTfl/V5E2GMc1DjrNzpwy9Wi/w6AB
V2dbJexki5x0i9fvXIKxLtUMLzH8NlnTwsFXd5COiRdNtv+vSqvDAshFN5YH
rzHZLvBSMEgy2Nu//+DhFwHmB5MTQqFlRw5mHvqa/NidBqmmUyUN6MiYrXM2
cyWGsmJKxUaONw5UaLXmBRWKYI57VnPfrz/Wq78NaX3lQMATK4dav2eQJlTe
pWGICR/RaeLm9kUUquXnFlT5kKRDy661YG2zTyk7HaYwqE/jPYNCknX4s0Bl
EsPUarE0FuBIoTHAlgrICdGw/SmSCQQ/TBjugABUFVI9ZGo7eBNLga26VH60
qPMk0Id0Pu2qRodNUFDUz09UWRKs/3c8+zeN3xI3z+ok/x8PnSA/v7u8tTwU
ut1Qa5DQmH0HKk2N3nqOiyiINXDFYauiASyoLG3L/r5F+hTeUTCu6bIO07Uy
LStdGtrQzif45zRS35vD810N5UohvCNd7T6GrY+8vnbR6jY0lxfwU+F6pCT3
9Ss7nfi/R1Lrymqhc6bIMqoc9kto3aq531UAHqrIvLbkx1vvu9RdDVKu6+qX
7VNGLNe67RJtpadf1OzKHmug2Ti5keKMC6AAqjmwhsr1+e/qrJqG3NbN2BVk
R1sWI35BmcfIsWEnz2IVrmq5a3vlwOQlA/fpPWjWuwJB7Qyompfi2pALQuwM
hAJkNI/pBoKmRuzQRl8nE83qo9Wmbwcx184m6q52smo03QLr7rCF/pNXakX1
l/l1NVeleDxWulOaVhWeUjJvdbw2K9+UmWKbDJ5o2hjWKNc4dMN/nR97ua/7
0D7qq6e1DkFWed0JFn3ZEVwihurTHFDkeVaU9mimlnXrSotrniLzjMpGcINr
8rwtTjQvsqQ5qYF6ooVS15C+a+DWDRmvNBLpel5on2w3dmcx0Jaktbf/6KOA
//fmvDZytFVsbwOnJycwBwK6IG2d6Pzj1u77PkNmu4cgyK1NJFwOmxKz2EOp
0128tty+2OYds3UXcEFbgFiN4m3DyctJZ8Yx+3NNKqPcQi6Uqb+bkNcoPOgD
fRdNJepZReAM2K66Mve3eXBOh3z8hVyBzuYFwLOiCkvsl5rjuB/GDz9/zHfw
DvfAq2ACMLNf6NqK+fuFn5kzbL717xdgbw5wEL3XvoFlRu6Pe89b/jaH0TKN
Wf6ydlvzOMUdQ5RpXfCHYW9bN23ewTLmgugMIgMqbFK3pyjIs58PzM18GT0J
5iLWMvjQUuBNVsV4Hn0lTSIR6ZVJmdRlUzndybXtgdPJ2fnU3dNndPedLr6j
EOlE28Y7hX1RrRbLcl7FfC5lhNzZki4xyWezk1ezZO4UagPGsWGRQ+AKVX0h
eBLLWwkZUsapusquh+xwWQB1KAWfZzHuFWDYP/8GFsW/X6XhFXjzn7Jlyk/l
tUrhx6koND9eLPCaOjuDVCZkzC/w/yLSeIX0rCoKyIQvKvDkQtxAFjkXsI83
WWVuBZwvwfNUzp+LOBbJ6Km4wh7fBUSBlB9ByIzVDfysQF3Ps0rHEhaYgqnx
y6pIYSSbyoxPK7wjOuSXKuGHeOPMXDHAn29A7Km+Up40M8IUAht/10reUEoH
CA170AbnmZS8QNwDkEcleJvXoFuOlwTQyzab+f8CXGCpXqUyAAA=
</rfc> </rfc>
 End of changes. 47 change blocks. 
351 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.48.