rfc9549.original.xml   rfc9549.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!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.7.2 (Ruby 2.6.1 <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
0) --> ipr="pre5378Trust200902"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName docName="draft-ietf-lamps-rfc8399bis-05"
="draft-ietf-lamps-rfc8399bis-05" category="std" consensus="true" submissionType number="9549"
="IETF" obsoletes="8399" updates="5280" tocInclude="true" sortRefs="true" symRef category="std"
s="true" version="3"> consensus="true"
<!-- xml2rfc v2v3 conversion 3.19.1 --> submissionType="IETF"
obsoletes="8399"
updates="5280"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3"
xml:lang="en">
<front> <front>
<title abbrev="I18n Updates to RFC 5280">Internationalization Updates to RFC 5280</title> <title abbrev="I18n Updates to RFC 5280">Internationalization Updates to RFC 5280</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc8399bis-05"/> <seriesInfo name="RFC" value="9549"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<city>Herndon, VA</city> <city>Herndon</city>
<country>US</country> <region>VA</region>
<country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2024" month="January" day="18"/> <date year="2024" month="March"/>
<area>Security</area>
<keyword>Internet-Draft</keyword> <area>SEC</area>
<workgroup>lamps</workgroup>
<keyword>Internationalized Email Address</keyword>
<abstract> <abstract>
<?line 81?>
<t>The updates to RFC 5280 described in this document provide alignment <t>The updates to RFC 5280 described in this document provide alignment
with the 2008 specification for Internationalized Domain Names (IDNs) with the 2008 specification for Internationalized Domain Names (IDNs)
and includes support for internationalized email addresses in X.509 and includes support for internationalized email addresses in X.509
certificates. The update ensures that name constraints for traditional certificates. The updates ensure that name constraints for
email addresses and internationalized email addresses are handled in email addresses that contain only ASCII characters and internationalized email a
the same manner. This document (once approved) obsoletes RFC 8399.</t> ddresses are handled in
the same manner. This document obsoletes RFC 8399.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 90?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>This document updates the Introduction in Section 1, the Name Constrain <t>This document updates the Introduction in Section <xref target="RFC5280
ts " section="1" sectionFormat="bare"/>, the Name Constraints
certificate extension discussion in Section 4.2.1.10, and the Processing Rules certificate extension discussion in Section <xref target="RFC5280" section="4.2.
for Internationalized Names in Section 7 of RFC 5280 <xref target="RFC5280"/> to 1.10" sectionFormat="bare"/>, and the Processing Rules
provide for Internationalized Names in Section <xref target="RFC5280" section="7" sectio
nFormat="bare"/> of RFC 5280 <xref target="RFC5280"/> to provide
alignment with the 2008 specification for Internationalized Domain Names (IDNs) alignment with the 2008 specification for Internationalized Domain Names (IDNs)
and includes support for internationalized email addresses in X.509 certificates .</t> and includes support for internationalized email addresses in X.509 certificates .</t>
<t>An IDN in Unicode (native character) form contains at least one <t>An IDN in Unicode (native character) form contains at least one
U-label <xref target="RFC5890"/>. IDNs are carried in certificates in ACE-encod ed U-label <xref target="RFC5890"/>. IDNs are carried in certificates in ACE-encod ed
form. That is, all U-labels within an IDN are converted to A-labels. Conversio n form. That is, all U-labels within an IDN are converted to A-labels. Conversio n
of a U-label to an A-label is described in <xref target="RFC5891"/>.</t> of a U-label to an A-label is described in <xref target="RFC5891"/>.</t>
<t>The GeneralName structure supports many different name forms, including <t>The GeneralName structure supports many different name forms, including
otherName for extensibility. RFC 8398 <xref target="RFC8398"/> specifies the otherName for extensibility. RFC 8398 <xref target="RFC8398"/> specifies the
SmtpUTF8Mailbox for internationalized email addresses.</t> SmtpUTF8Mailbox for internationalized email addresses.</t>
<t>Note that Internationalized Domain Names in Applications specifications <t>Note that Internationalized Domain Names in Applications specifications
published in 2003 (IDNA2003) <xref target="RFC3490"/> and 2008 (IDNA2008) <xref target="RFC5890"/> both published in 2003 (IDNA2003) <xref target="RFC3490"/> and 2008 (IDNA2008) <xref target="RFC5890"/> both
refer to the Punycode algorithm for conversion <xref target="RFC3492"/>.</t> refer to the Punycode algorithm for conversion <xref target="RFC3492"/>.</t>
<t>Note that characters in the Unicode Category “Symbol, Other” (So) are
<t>Note that characters in the Unicode Category "Symbol, Other" (So) are
specifically not included in IDNA2003 <xref target="RFC3490"/> or IDNA2008 <xref target="RFC5890"/>; specifically not included in IDNA2003 <xref target="RFC3490"/> or IDNA2008 <xref target="RFC5890"/>;
the derived property values for character in this category are calculated as the derived property values for characters in this category are calculated as
DISALLOWED. Thus, some characters that are allowed under the Unicode IDNA DISALLOWED. Thus, some characters that are allowed under the Unicode IDNA
Compatibility Processing <xref target="UTS46"/> are not allowed under this speci Compatibility Processing <xref target="UTS46"/> are not allowed under this speci
fication. For fication.
instance, ☕.example results in in a failure under this specification, but it For instance, ♚.example,
becomes xn--53h.example under <xref target="UTS46"/>.</t> which contains the Unicode character U+1F0A1 (BLACK CHESS KING),
results in a failure under this specification, but it becomes
xn&nbhy;&nbhy;45h.example under <xref target="UTS46"/>.</t>
<section anchor="terms"> <section anchor="terms">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="changes-since-rfc-8399"> <section anchor="changes-since-rfc-8399">
<name>Changes since RFC 8399</name> <name>Changes since RFC 8399</name>
<t>In some cases, <xref target="RFC8399"/> required conversion of A-labe ls to U-labels <t>In some cases, <xref target="RFC8399"/> required conversion of A-labe ls to U-labels
in order to process name constraints for internationalized email in order to process name constraints for internationalized email
addresses. This lead to implementation complexity and at least two addresses. This led to implementation complexity and at least two
security vulnerabilities. One summary of the vulnerabilities an be security vulnerabilities. One summary of the vulnerabilities can be
found in <xref target="DDHQ"/>. Now, all Internationalized Domain Names (IDNs) found in <xref target="DDHQ"/>. Now, all IDNs
are carried and processed as A-labels.</t> are carried and processed as A-labels.</t>
<t>The Introduction provides a warning to implementers about the handlin g of <t>The Introduction provides a warning to implementers about the handlin g of
characters in the Unicode Category “Symbol, Other” (So), which includes characters in the Unicode Category "Symbol, Other" (So), which includes
emoji characters.</t> emoji characters.</t>
</section> </section>
</section> </section>
<section anchor="updates-to-rfc-5280"> <section anchor="updates-to-rfc-5280">
<name>Updates to RFC 5280</name> <name>Updates to RFC 5280</name>
<t>This section provides updates to several paragraphs of <xref target="RF C5280"/>. For <t>This section provides updates to several paragraphs of <xref target="RF C5280"/>. For
clarity, if the entire section is not replaced, then the original text and clarity, if the entire section is not replaced, then the original text and
the replacement text are shown.</t> the replacement text are shown.</t>
<section anchor="update-in-the-introduction-section-1"> <section anchor="update-in-the-introduction-section-1">
<name>Update in the Introduction (Section 1)</name> <name>Update in the Introduction (Section 1)</name>
<t>This update provides references for IDNA2008.</t> <t>This update provides references for IDNA2008.</t>
<t>OLD</t> <t>OLD</t>
<artwork><![CDATA[ <blockquote>
* Enhanced support for internationalized names is specified in <ul><li>
Enhanced support for internationalized names is specified in
Section 7, with rules for encoding and comparing Section 7, with rules for encoding and comparing
Internationalized Domain Names, Internationalized Resource Internationalized Domain Names, Internationalized Resource
Identifiers (IRIs), and distinguished names. These rules are Identifiers (IRIs), and distinguished names. These rules are
aligned with comparison rules established in current RFCs, aligned with comparison rules established in current RFCs,
including [RFC3490], [RFC3987], and [RFC4518]. including <xref target="RFC3490"/>, <xref target="RFC3987"/>, and <xref targ
]]></artwork> et="RFC4518"/>.
</li></ul>
</blockquote>
<t>NEW</t> <t>NEW</t>
<artwork><![CDATA[ <blockquote>
* Enhanced support for internationalized names is specified in <ul><li>
Enhanced support for internationalized names is specified in
Section 7, with rules for encoding and comparing Section 7, with rules for encoding and comparing
Internationalized Domain Names, Internationalized Resource Internationalized Domain Names, Internationalized Resource
Identifiers (IRIs), and distinguished names. These rules are Identifiers (IRIs), and distinguished names. These rules are
aligned with comparison rules established in current RFCs, aligned with comparison rules established in current RFCs,
including [RFC3987], [RFC4518], [RFC5890], and [RFC5891]. including <xref target="RFC3987"/>, <xref target="RFC4518"/>, <xref target="
]]></artwork> RFC5890"/>, and <xref target="RFC5891"/>.
</li> </ul>
</blockquote>
</section> </section>
<section anchor="update-in-name-constraints-section-42110"> <section anchor="update-in-name-constraints-section-42110">
<name>Update in Name Constraints (Section 4.2.1.10)</name> <name>Update in Name Constraints (Section 4.2.1.10)</name>
<t>This update removes the ability to include constraints for a <t>This update removes the ability to include constraints for a
particular mailbox. This capability was not used, and removing it particular mailbox. This capability was not used, and removing it
allows name constraints to apply to email addresses in rfc822Name and allows name constraints to apply to email addresses in rfc822Name and
SmtpUTF8Mailbox <xref target="RFC8398"/> within otherName.</t> SmtpUTF8Mailbox <xref target="RFC8398"/> within otherName.</t>
<t>OLD</t> <t>OLD</t>
<artwork><![CDATA[ <blockquote>
A name constraint for Internet mail addresses MAY specify a A name constraint for Internet mail addresses <bcp14>MAY</bcp14> specify a
particular mailbox, all addresses at a particular host, or all particular mailbox, all addresses at a particular host, or all
mailboxes in a domain. To indicate a particular mailbox, the mailboxes in a domain. To indicate a particular mailbox, the
constraint is the complete mail address. For example, constraint is the complete mail address. For example,
"root@example.com" indicates the root mailbox on the host "root@example.com" indicates the root mailbox on the host
"example.com". To indicate all Internet mail addresses on a "example.com". To indicate all Internet mail addresses on a
particular host, the constraint is specified as the host name. For particular host, the constraint is specified as the host name. For
example, the constraint "example.com" is satisfied by any mail example, the constraint "example.com" is satisfied by any mail
address at the host "example.com". To specify any address within a address at the host "example.com". To specify any address within a
domain, the constraint is specified with a leading period (as with domain, the constraint is specified with a leading period (as with
URIs). For example, ".example.com" indicates all the Internet mail URIs). For example, ".example.com" indicates all the Internet mail
addresses in the domain "example.com", but not Internet mail addresses in the domain "example.com", but not Internet mail
addresses on the host "example.com". addresses on the host "example.com".
]]></artwork> </blockquote>
<t>NEW</t> <t>NEW</t>
<artwork><![CDATA[ <blockquote>
A name constraint for Internet mail addresses MAY specify all A name constraint for Internet mail addresses <bcp14>MAY</bcp14> specify all
addresses at a particular host or all mailboxes in a domain. To addresses at a particular host or all mailboxes in a domain. To
indicate all Internet mail addresses on a particular host, the indicate all Internet mail addresses on a particular host, the
constraint is specified as the host name. For example, the constraint is specified as the host name. For example, the
constraint "example.com" is satisfied by any mail address at the constraint "example.com" is satisfied by any mail address at the
host "example.com". To specify any address within a domain, the host "example.com". To specify any address within a domain, the
constraint is specified with a leading period (as with URIs). For constraint is specified with a leading period (as with URIs). For
example, ".example.com" indicates all the Internet mail addresses example, ".example.com" indicates all the Internet mail addresses
in the domain "example.com" but not Internet mail addresses on in the domain "example.com" but not Internet mail addresses on
the host "example.com". the host "example.com".
]]></artwork> </blockquote>
</section> </section>
<section anchor="update-in-idns-in-generalname-section-72"> <section anchor="update-in-idns-in-generalname-section-72">
<name>Update in IDNs in GeneralName (Section 7.2)</name> <name>Update in IDNs in GeneralName (Section 7.2)</name>
<t>This update aligns with IDNA2008. Since all of Section 7.2 is <t>This update aligns with IDNA2008. Since all of <xref target="RFC5280 " section="7.2" sectionFormat="of"/> is
replaced, the OLD text is not provided.</t> replaced, the OLD text is not provided.</t>
<t>NEW</t> <t>NEW</t>
<artwork><![CDATA[ <blockquote>
<t>
Internationalized Domain Names (IDNs) may be included in certificates Internationalized Domain Names (IDNs) may be included in certificates
and CRLs in the subjectAltName and issuerAltName extensions, name and CRLs in the subjectAltName and issuerAltName extensions, name
constraints extension, authority information access extension, constraints extension, authority information access extension,
subject information access extension, CRL distribution points subject information access extension, CRL distribution points
extension, and issuing distribution point extension. Each of these extension, and issuing distribution point extension. Each of these
extensions uses the GeneralName type; one choice in GeneralName is extensions uses the GeneralName type; one choice in GeneralName is
the dNSName field, which is defined as type IA5String. the dNSName field, which is defined as type IA5String.</t>
<t>
IA5String is limited to the set of ASCII characters. To accommodate IA5String is limited to the set of ASCII characters. To accommodate
IDNs, U-labels are converted to A-labels. The A-label is the IDNs, U-labels are converted to A-labels. The A-label is the
encoding of the U-label according to the Punycode algorithm [RFC3492] encoding of the U-label according to the Punycode algorithm <xref target="RFC
with the ACE prefix "xn--" added at the beginning of the string. 3492"/>
with the ACE prefix "xn--" added at the beginning of the string.</t>
<t>
When comparing DNS names for equality, conforming implementations When comparing DNS names for equality, conforming implementations
MUST perform a case-insensitive exact match on the entire DNS name. <bcp14>MUST</bcp14> perform a case-insensitive exact match on the entire DNS
When evaluating name constraints, conforming implementations MUST name.
When evaluating name constraints, conforming implementations <bcp14>MUST</bcp
14>
perform a case-insensitive exact match on a label-by-label basis. As perform a case-insensitive exact match on a label-by-label basis. As
noted in Section 4.2.1.10, any DNS name that may be constructed by noted in Section <xref target="RFC5280" section="4.2.1.10" sectionFormat="bar e"/>, any DNS name that may be constructed by
adding labels to the left-hand side of the domain name given as the adding labels to the left-hand side of the domain name given as the
constraint is considered to fall within the indicated subtree. constraint is considered to fall within the indicated subtree.</t>
Implementations that have a user interface SHOULD convert IDNs to <t> Implementations that have a user interface <bcp14>SHOULD</bcp14> convert I DNs to
Unicode for display. Specifically, conforming implementations Unicode for display. Specifically, conforming implementations
convert A-labels to U-labels for display purposes. convert A-labels to U-labels for display purposes.</t>
Implementation consideration: There are increased memory requirements <t> Implementation consideration: There are increased memory requirements
for IDNs. An IDN ACE label will begin with the four additional for IDNs. An IDN ACE label will begin with the four additional
characters "xn--", and an IDN can require as many as five ASCII characters "xn--", and an IDN can require as many as five ASCII
characters to specify a single international character. characters to specify a single international character.</t>
]]></artwork> </blockquote>
</section> </section>
<section anchor="update-in-idns-in-distinguished-names-section-73"> <section anchor="update-in-idns-in-distinguished-names-section-73">
<name>Update in IDNs in Distinguished Names (Section 7.3)</name> <name>Update in IDNs in Distinguished Names (Section 7.3)</name>
<t>This update aligns with IDNA2008.</t> <t>This update aligns with IDNA2008.</t>
<t>OLD</t> <t>OLD</t>
<artwork><![CDATA[ <blockquote>
Domain Names may also be represented as distinguished names using Domain Names may also be represented as distinguished names using
domain components in the subject field, the issuer field, the domain components in the subject field, the issuer field, the
subjectAltName extension, or the issuerAltName extension. As with subjectAltName extension, or the issuerAltName extension. As with
the dNSName in the GeneralName type, the value of this attribute is the dNSName in the GeneralName type, the value of this attribute is
defined as an IA5String. Each domainComponent attribute represents a defined as an IA5String. Each domainComponent attribute represents a
single label. To represent a label from an IDN in the distinguished single label. To represent a label from an IDN in the distinguished
name, the implementation MUST perform the "ToASCII" label conversion name, the implementation <bcp14>MUST</bcp14> perform the "ToASCII" label conv
specified in Section 4.1 of RFC 3490. The label SHALL be considered ersion
a "stored string". That is, the AllowUnassigned flag SHALL NOT be specified in Section 4.1 of RFC 3490. The label <bcp14>SHALL</bcp14> be cons
idered
a "stored string". That is, the AllowUnassigned flag <bcp14>SHALL NOT</bcp14
> be
set. set.
]]></artwork> </blockquote>
<t>NEW</t> <t>NEW</t>
<artwork><![CDATA[ <blockquote>
Domain names may also be represented as distinguished names using Domain names may also be represented as distinguished names using
domain components in the subject field, the issuer field, the domain components in the subject field, the issuer field, the
subjectAltName extension, or the issuerAltName extension. As with subjectAltName extension, or the issuerAltName extension. As with
the dNSName in the GeneralName type, the value of this attribute is the dNSName in the GeneralName type, the value of this attribute is
defined as an IA5String. Each domainComponent attribute represents a defined as an IA5String. Each domainComponent attribute represents a
single label. To represent a label from an IDN in the distinguished single label. To represent a label from an IDN in the distinguished
name, the implementation MUST convert all U-labels to A-labels. name, the implementation <bcp14>MUST</bcp14> convert all U-labels to A-labels
]]></artwork> .
</blockquote>
</section> </section>
<section anchor="update-in-internationalized-electronic-mail-addresses-sec tion-75"> <section anchor="update-in-internationalized-electronic-mail-addresses-sec tion-75">
<name>Update in Internationalized Electronic Mail Addresses (Section 7.5 )</name> <name>Update in Internationalized Electronic Mail Addresses (Section 7.5 )</name>
<t>This update aligns with IDNA2008 and <xref target="RFC8398"/>. Since all <t>This update aligns with IDNA2008 and <xref target="RFC8398"/>. Since all
of Section 7.5 is replaced, the OLD text is not provided.</t> of <xref target="RFC5280" section="7.5" sectionFormat="of"/> is replaced, the OL D text is not provided.</t>
<t>NEW</t> <t>NEW</t>
<artwork><![CDATA[ <blockquote>
<t>
Electronic Mail addresses may be included in certificates and CRLs in Electronic Mail addresses may be included in certificates and CRLs in
the subjectAltName and issuerAltName extensions, name constraints the subjectAltName and issuerAltName extensions, name constraints
extension, authority information access extension, subject extension, authority information access extension, subject
information access extension, issuing distribution point extension, information access extension, issuing distribution point extension,
or CRL distribution points extension. Each of these extensions uses or CRL distribution points extension. Each of these extensions uses
the GeneralName construct. If the email address includes an IDN but the GeneralName construct. If the email address includes an IDN but
the local-part of the email address can be represented in ASCII, then the local-part of the email address can be represented in ASCII, then
the email address is placed in the rfc822Name choice of GeneralName, the email address is placed in the rfc822Name choice of GeneralName,
which is defined as type IA5String. If the local-part of the which is defined as type IA5String. If the local-part of the
internationalized email address cannot be represented in ASCII, then internationalized email address cannot be represented in ASCII, then
the internationalized email address is placed in the otherName choice the internationalized email address is placed in the otherName choice
of GeneralName using the conventions in RFC 8398 [RFC8398]. of GeneralName using the conventions in RFC 8398 <xref target="RFC8398"/>.
</t>
When the host-part contains an IDN, conforming implementations MUST <t>
When the host-part contains an IDN, conforming implementations <bcp14>MUST</b
cp14>
convert all U-labels to A-labels. convert all U-labels to A-labels.
</t>
7.5.1. Local-Part Contains Only ASCII Characters <t>7.5.1. Local-Part Contains Only ASCII Characters</t>
Two email addresses are considered to match if:
1) The local-part of each name is an exact match, AND <t> Two email addresses are considered to match if:</t>
2) The host-part of each name matches using a case-insensitive <ol type="%d)"><li>The local-part of each name is an exact match, AND</li>
ASCII comparison. <li>The host-part of each name matches using a case-insensitive
ASCII comparison.</li>
</ol>
Implementations that have a user interface SHOULD convert the <t>
Implementations that have a user interface <bcp14>SHOULD</bcp14> convert the
host-part of internationalized email addresses specified in these host-part of internationalized email addresses specified in these
extensions to Unicode before display. Specifically, conforming extensions to Unicode before display. Specifically, conforming
implementations convert A-labels to U-labels for display purposes. implementations convert A-labels to U-labels for display purposes.</t>
7.5.2. Local-Part Contains Non-ASCII Characters <t> 7.5.2. Local-Part Contains Non-ASCII Characters</t>
When the local-part contains non-ASCII characters, conforming <t> When the local-part contains non-ASCII characters, conforming
implementations MUST place the internationalized email address in the implementations <bcp14>MUST</bcp14> place the internationalized email address
in the
SmtpUTF8Mailbox within the otherName choice of GeneralName as SmtpUTF8Mailbox within the otherName choice of GeneralName as
specified in Section 3 of RFC 8398 [RFC8398]. Note that the UTF8 specified in Section <xref target="RFC8398" section="3" sectionFormat="bare"/
encoding of the internationalized email address MUST NOT contain a > of RFC 8398 <xref target="RFC8398"/>. Note that the UTF8
Byte-Order-Mark (BOM) [RFC3629] to aid comparison. The email address encoding of the internationalized email address <bcp14>MUST NOT</bcp14> conta
local-part within the SmtpUTF8Mailbox MUST conform to the in a
requirements of [RFC6530] and [RFC6531]. Byte-Order-Mark (BOM) <xref target="RFC3629"/> to aid comparison. The email
address
Two email addresses are considered to match if: local-part within the SmtpUTF8Mailbox <bcp14>MUST</bcp14> conform to the
requirements of <xref target="RFC6530"/> and <xref target="RFC6531"/>.</t>
1) The local-part of each name is an exact match, AND
2) The host-part of each name matches using a case-insensitive <t> Two email addresses are considered to match if:</t>
ASCII comparison.
Implementations that have a user interface SHOULD convert the <ol type="%d)"><li>The local-part of each name is an exact match, AND</li>
<li>The host-part of each name matches using a case-insensitive
ASCII comparison.</li>
</ol>
<t>
Implementations that have a user interface <bcp14>SHOULD</bcp14> convert the
host-part of internationalized email addresses specified in these host-part of internationalized email addresses specified in these
extensions to Unicode before display. Specifically, conforming extensions to Unicode before display. Specifically, conforming
implementations convert A-labels to U-labels for display purposes. implementations convert A-labels to U-labels for display purposes.
]]></artwork> </t>
</blockquote>
</section> </section>
</section> </section>
<section anchor="sec-cons"> <section anchor="sec-cons">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Consideration related to IDNA2008 in <xref section="4" sec
tionFormat="of" target="RFC5890"/> <t>The Security Considerations related to internationalized names in
are relevant to this specification.</t> <xref section="4" sectionFormat="of" target="RFC5890"/> are relevant to this spe
<t>Conforming CAs <bcp14>SHOULD</bcp14> ensure that IDNs are valid accordi cification.
ng to IDNA2008, which </t>
<t>Conforming Certification Authorities (CAs) <bcp14>SHOULD</bcp14> ensure
that IDNs are valid according to IDNA2008, which
is defined in <xref target="RFC5890"/>, <xref target="RFC5891"/>, <xref target=" RFC5892"/>, <xref target="RFC5893"/>, <xref target="RFC5894"/>, is defined in <xref target="RFC5890"/>, <xref target="RFC5891"/>, <xref target=" RFC5892"/>, <xref target="RFC5893"/>, <xref target="RFC5894"/>,
and the updates to these documents. Failure to use valid A-labels may yield a and the updates to these documents. Failure to use valid A-labels may yield a
domain name that cannot be correctly represented in the Domain Name System domain name that cannot be correctly represented in the Domain Name System
(DNS). In addition, the CA/Browser Forum offers some (DNS). In addition, the CA/Browser Forum offers some
guidance regarding internal server names in certificates <xref target="CABF"/>.< /t> guidance regarding internal server names in certificates <xref target="CABF"/>.< /t>
<t>An earlier version of this specification <xref target="RFC8399"/> requi red conversion <t>An earlier version of this specification <xref target="RFC8399"/> requi red conversion
of A-labels to U-labels in order to process name constraints for of A-labels to U-labels in order to process name constraints for
internationalized email addresses in SmtpUTF8Mailbox other names. This internationalized email addresses in SmtpUTF8Mailbox other names. This
lead to implementation complexity and at least two security vulnerabilities. lead to implementation complexity and at least two security vulnerabilities.
Now, all Internationalized Domain Names (IDNs) are carried and processed Now, all IDNs are carried and processed
as A-labels.</t> as A-labels.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name>
<t>Thanks to David Benjamin and Wei Chuang for identifying the issue and a
solution.</t>
<t>Thanks to Takahiro Nemoto, John Klensin, Mike Ounsworth, and Orie Steel
e for their
careful review and thoughtful comments.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 19.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.34
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 92.xml"/>
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36
<abstract> 29.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
nify the requirements in the specification. These words are often capitalized. T 87.xml"/>
his document defines these words as they should be interpreted in IETF documents <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.45
. This document specifies an Internet Best Current Practices for the Internet Co 18.xml"/>
mmunity, and requests discussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
</abstract> 80.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<seriesInfo name="BCP" value="14"/> 90.xml"/>
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<seriesInfo name="DOI" value="10.17487/RFC2119"/> 91.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<reference anchor="RFC3492"> 92.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<title>Punycode: A Bootstring encoding of Unicode for Internationali 93.xml"/>
zed Domain Names in Applications (IDNA)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
<author fullname="A. Costello" initials="A." surname="Costello"/> 30.xml"/>
<date month="March" year="2003"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
<abstract> 31.xml"/>
<t>Punycode is a simple and efficient transfer encoding syntax des <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
igned for use with Internationalized Domain Names in Applications (IDNA). It uni 74.xml"/>
quely and reversibly transforms a Unicode string into an ASCII string. ASCII cha <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
racters in the Unicode string are represented literally, and non-ASCII character 98.xml"/>
s are represented by ASCII characters that are allowed in host name labels (lett
ers, digits, and hyphens). This document defines a general algorithm called Boot
string that allows a string of basic code points to uniquely represent any strin
g of code points drawn from a larger set. Punycode is an instance of Bootstring
that uses particular parameter values specified by this document, appropriate fo
r IDNA. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3492"/>
<seriesInfo name="DOI" value="10.17487/RFC3492"/>
</reference>
<reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
<date month="November" year="2003"/>
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Univer
sal Character Set (UCS) which encompasses most of the world's writing systems. T
he originally proposed encodings of the UCS, however, were not compatible with m
any current applications and protocols, and this has led to the development of U
TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu
ll US-ASCII range, providing compatibility with file systems, parsers and other
software that rely on US-ASCII values but are transparent to other values. This
memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC3987">
<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author fullname="M. Duerst" initials="M." surname="Duerst"/>
<author fullname="M. Suignard" initials="M." surname="Suignard"/>
<date month="January" year="2005"/>
<abstract>
<t>This document defines a new protocol element, the International
ized Resource Identifier (IRI), as a complement of the Uniform Resource Identifi
er (URI). An IRI is a sequence of characters from the Universal Character Set (U
nicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs
can be used instead of URIs, where appropriate, to identify resources.</t>
<t>The approach of defining a new protocol element was chosen inst
ead of extending or changing the definition of URIs. This was done in order to a
llow a clear distinction and to avoid incompatibilities with existing software.
Guidelines are provided for the use and deployment of IRIs in various protocols,
formats, and software components that currently deal with URIs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3987"/>
<seriesInfo name="DOI" value="10.17487/RFC3987"/>
</reference>
<reference anchor="RFC4518">
<front>
<title>Lightweight Directory Access Protocol (LDAP): Internationaliz
ed String Preparation</title>
<author fullname="K. Zeilenga" initials="K." surname="Zeilenga"/>
<date month="June" year="2006"/>
<abstract>
<t>The previous Lightweight Directory Access Protocol (LDAP) techn
ical specifications did not precisely define how character string matching is to
be performed. This led to a number of usability and interoperability problems.
This document defines string preparation algorithms for character-based matching
rules defined for use in LDAP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4518"/>
<seriesInfo name="DOI" value="10.17487/RFC4518"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC5890">
<front>
<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>
<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="RFC5892">
<front>
<title>The Unicode Code Points and Internationalized Domain Names fo
r Applications (IDNA)</title>
<author fullname="P. Faltstrom" initials="P." role="editor" surname=
"Faltstrom"/>
<date month="August" year="2010"/>
<abstract>
<t>This document specifies rules for deciding whether a code point
, considered in isolation or in context, is a candidate for inclusion in an Inte
rnationalized Domain Name (IDN).</t>
<t>It is part of the specification of Internationalizing Domain Na
mes in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5892"/>
<seriesInfo name="DOI" value="10.17487/RFC5892"/>
</reference>
<reference anchor="RFC5893">
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for
Applications (IDNA)</title>
<author fullname="H. Alvestrand" initials="H." role="editor" surname
="Alvestrand"/>
<author fullname="C. Karp" initials="C." surname="Karp"/>
<date month="August" year="2010"/>
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Na
mes (IDNs) has presented several challenges. This memo provides a new Bidi rule
for Internationalized Domain Names for Applications (IDNA) labels, based on the
encountered problems with some scripts and some shortcomings in the 2003 IDNA Bi
di criterion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5893"/>
<seriesInfo name="DOI" value="10.17487/RFC5893"/>
</reference>
<reference anchor="RFC6530">
<front>
<title>Overview and Framework for Internationalized Email</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<author fullname="Y. Ko" initials="Y." surname="Ko"/>
<date month="February" year="2012"/>
<abstract>
<t>Full use of electronic mail throughout the world requires that
(subject to other constraints) people be able to use close variations on their o
wn names (written correctly in their own languages and scripts) as mailbox names
in email addresses. This document introduces a series of specifications that de
fine mechanisms and protocol extensions needed to fully support internationalize
d email addresses. These changes include an SMTP extension and extension of emai
l header syntax to accommodate UTF-8 data. The document set also includes discus
sion of key assumptions and issues in deploying fully internationalized email. T
his document is a replacement for RFC 4952; it reflects additional issues identi
fied since that document was published. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6530"/>
<seriesInfo name="DOI" value="10.17487/RFC6530"/>
</reference>
<reference anchor="RFC6531">
<front>
<title>SMTP Extension for Internationalized Email</title>
<author fullname="J. Yao" initials="J." surname="Yao"/>
<author fullname="W. Mao" initials="W." surname="Mao"/>
<date month="February" year="2012"/>
<abstract>
<t>This document specifies an SMTP extension for transport and del
ivery of email messages with internationalized email addresses or header informa
tion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6531"/>
<seriesInfo name="DOI" value="10.17487/RFC6531"/>
</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>
<reference anchor="RFC8398">
<front>
<title>Internationalized Email Addresses in X.509 Certificates</titl
e>
<author fullname="A. Melnikov" initials="A." role="editor" surname="
Melnikov"/>
<author fullname="W. Chuang" initials="W." role="editor" surname="Ch
uang"/>
<date month="May" year="2018"/>
<abstract>
<t>This document defines a new name form for inclusion in the othe
rName field of an X.509 Subject Alternative Name and Issuer Alternative Name ext
ension that allows a certificate subject to be associated with an internationali
zed email address.</t>
<t>This document updates RFC 5280.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8398"/>
<seriesInfo name="DOI" value="10.17487/RFC8398"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3490">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.34
<title>Internationalizing Domain Names in Applications (IDNA)</title 90.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<author fullname="P. Faltstrom" initials="P." surname="Faltstrom"/> 94.xml"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<author fullname="A. Costello" initials="A." surname="Costello"/> 99.xml"/>
<date month="March" year="2003"/>
<abstract>
<t>Until now, there has been no standard method for domain names t
o use characters outside the ASCII repertoire. This document defines internation
alized domain names (IDNs) and a mechanism called Internationalizing Domain Name
s in Applications (IDNA) for handling them in a standard fashion. IDNs use chara
cters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII cha
racters to be represented using only the ASCII characters already allowed in so-
called host names today. This backward-compatible representation is required in
existing protocols like DNS, so that IDNs can be introduced with no changes to t
he existing infrastructure. IDNA is only meant for processing domain names, not
free text. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3490"/>
<seriesInfo name="DOI" value="10.17487/RFC3490"/>
</reference>
<reference anchor="RFC5894">
<front>
<title>Internationalized Domain Names for Applications (IDNA): Backg
round, Explanation, and Rationale</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="August" year="2010"/>
<abstract>
<t>Several years have passed since the original protocol for Inter
nationalized Domain Names (IDNs) was completed and deployed. During that time, a
number of issues have arisen, including the need to update the system to deal w
ith newer versions of Unicode. Some of these issues require tuning of the existi
ng protocols and the tables on which they depend. This document provides an over
view of a revised system and provides explanatory material for its components. T
his document is not an Internet Standards Track specification; it is published f
or informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5894"/>
<seriesInfo name="DOI" value="10.17487/RFC5894"/>
</reference>
<reference anchor="RFC8399">
<front>
<title>Internationalization Updates to RFC 5280</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="May" year="2018"/>
<abstract>
<t>The updates to RFC 5280 described in this document provide alig
nment with the 2008 specification for Internationalized Domain Names (IDNs) and
add support for internationalized email addresses in X.509 certificates.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8399"/>
<seriesInfo name="DOI" value="10.17487/RFC8399"/>
</reference>
<reference anchor="CABF" target="https://cabforum.org/internal-names/"> <reference anchor="CABF" target="https://cabforum.org/internal-names/">
<front> <front>
<title>Internal Server Names and IP Address Requirements for SSL: Gu idance on the Deprecation of Internal Server Names and Reserved IP Addresses pro vided by the CA/Browser Forum</title> <title>Internal Server Names and IP Address Requirements for SSL: Gu idance on the Deprecation of Internal Server Names and Reserved IP Addresses pro vided by the CA/Browser Forum</title>
<author> <author>
<organization>CA/Browser Forum</organization> <organization>CA/Browser Forum</organization>
</author> </author>
<date year="2012" month="June"/> <date year="2012" month="June"/>
</front> </front>
<seriesInfo name="Version" value="1.0"/> <refcontent>Version 1.0</refcontent>
</reference> </reference>
<reference anchor="DDHQ" target="https://securitylabs.datadoghq.com/arti cles/openssl-november-1-vulnerabilities/"> <reference anchor="DDHQ" target="https://securitylabs.datadoghq.com/arti cles/openssl-november-1-vulnerabilities/">
<front> <front>
<title>The OpenSSL punycode vulnerability (CVE-2022-3602): Overview, detection, exploitation, and remediation</title> <title>The OpenSSL punycode vulnerability (CVE-2022-3602): Overview, detection, exploitation, and remediation</title>
<author> <author>
<organization>Datadog Security Labs</organization> <organization>Datadog Security Labs</organization>
</author> </author>
<date year="2022" month="November" day="01"/> <date year="2022" month="November" day="01"/>
</front> </front>
</reference> </reference>
<reference anchor="UTS46" target="https://www.unicode.org/reports/tr46"> <reference anchor="UTS46" target="https://www.unicode.org/reports/tr46">
<front> <front>
<title>Unicode Technical Standard #46: Unicode IDNA Compatibility Pr ocessing</title> <title>Unicode Technical Standard #46: Unicode IDNA Compatibility Pr ocessing</title>
<author initials="M." surname="Davis" fullname="Mark Davis"> <author initials="M." surname="Davis" fullname="Mark Davis">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Suignard" fullname="Michel Suignard"> <author initials="M." surname="Suignard" fullname="Michel Suignard">
<organization/> <organization/>
</author> </author>
<date year="2023" month="September"/> <date year="2023" month="September"/>
</front> </front>
<refcontent>Revision 31, The Unicode Consortium, Mountain View</refcon tent> <refcontent>Revision 31, The Unicode Consortium, Mountain View</refcon tent>
</reference> </reference>
</references> </references>
</references> </references>
</back>
<!-- ##markdown-source:
H4sIAOp4qWUAA+1b23IbuZm+x1Ng6QtLKZIWKcmWmOwkNCXH2tXBEaWZTblc
KbAbJDFuNjiNbtFcl6fyEluVi6Qqz7KPMk+y//8D6EY3qYMzudjdmiv2AYf/
8P3HBjudDjO5SOM/iUSncsDzrJBMLbMBX2bycP/V0U1WmLy/t3e812exjlKx
gFFxJqZ5R8l82knEYmk62TQ62j8+nijT2TtkemJ0InNpBhyfsmIZC7o77B/t
sUjkA27ymEU6NTI1Bbx4jvs+Z0s1YJznOoIna2mew43RWZ7JqQmerBfhg1zl
CZD0/CzNZZaKXOlUJOo/6YLf2p1hSX79ZkT7P2diMsnkHU7pHd0zxBSThTIG
lrhZL2H1s9ObN0xkUgz4WEZFpvI1+7iC57SpzDsnKBGGKw14f69/0NnrdXpH
jIkin+tswDrcSu66MIa/1YVJ5Bp40dlswL9VM5WU67b5+fkIXnkq62/hRQQ/
A/4W9o112ubfDvGZLtI8g8e3Y7iTC6GSAZ/bbX53hysYGXUjvWBMpVOdLUA8
dxKFDTzvHxzvucvDo+MDd4maw8vR8PUb/AW9iGwmQXfzPF+awYsXkZjAUsWi
C1y8UFb8SQf5NC/sBKuab+iGO2EJZCa7kxm/xJEcwMfP3vFhHGfSGDf0Wv5Q
qEwuZJobDpvw8fh8wH9fqFikkeSg2Xwu+YkEkEZW03r66C7X0uCjcDt4s8z0
nYpl7KZP1rT0aPjidaZXMIG/QR7prVcmXnes7raO8zDo9Tt7L+kJvFfSoOgH
bp9vZYbwGvBedw8enZy8/cN2KRun+URMTBdWFrGezX9AXb4QWa6iBKStl2BH
BmSv7+RiIrNOr3NXJKnMxEQlKlf3KOQGGL2CqSBcvizSdaRjycOJa74z+va0
A4Dud/Zf7vV3PfVXINk7JVdtHoOdR6iBNpeflolWubB3KHHUYKzowX0CPLEc
lQDn58BnTYqwd68H9gQPb2/GBy+3i2m1WnWLVCELhMdMLsFzmBd5dvAy5L11
awfxGxnN4RKBgg5QZDF/Botz//7s5HLIR3qxBPKdMN5lOgLQqHTW2mTHSUal
4JkuusDXnfJotqZ/IbKPwePmhHGhZilQUZ+jorlM6u9Kuex39o7pCbhD8KU5
GAvwdy1hB7SI/V6bNOwZGoG7BZGoYtHmF+gvhErBu8hVi7G04RL6vd5x5R36
/vJlv3x6fPTKXR4c9o68+wDnWXmS4LJXXfary313+fJwf6+69GOPeq8CXwRb
sE6nA27R5JmIcsaQt2LTeQMiTZSpCdi5QjehDIe4VaAr8bbOIUDMUnzCViqf
k8FDiDviZikjNVXOpaDfaUQVWPREL1Bw1q3sAErMLkOsqzRKCtibm2KJ0KPp
amM6+WYuSvcDS/1H9xAUGUnQDe0tTdfapuWOY4zMkMm5yAkXHCMnSEF57wjX
sbKbsOYGlrbHyIDYxucwNCGxMZSIwZ0WIgVvQPSEgtzR6IbFEgUq411eRnxS
A4aOrlXXQsWwJmPPUJKZjgvyFfzzM4W3X1CL4bqlPmH/2gQQ09j6GQ6wxteo
AMK0E0QoQHBFYA1kBbEyUUGRPFzjoNvv9rq9PeumcLnKtiFGg09l27Vv1R6s
9AoiT4W9z5+dFXz5gph0eGMl3vj/GrzxGt4YG6bo8fC19xc7KXkEHs0FGpzM
dnGLBYIPXQdgJueJFCaHcCzZLWSCE3BVVgJg/F++AGqQXMJWJDKIgGSS4cZ4
PxyddmSKW8Yo9AWBDdZWBrSTJNytbEh2MF5YSmlVnUIgymFdEPbQjYP5I3qO
SmegHeGXwFEw2w3kCLzQV3jSe0C6dS+/lxgKE4Ia4AywCIboBW7QONYAsOlU
ZqhbMk3kAAi32gE0MQ3azi7dKw9MG1C63JvLkd0crwA5DhbWDth4kS9vb94c
XYAiJ/rT0/QMDFxqMATyGY+ACnWwXCYOhqaOSsOWxSRRZm5lBLDdJxQO8WrX
ko0JJJCNqCRY+/dHuyEc+AREwSBWQa4EiiCj80mHSGYaov98QdxFpfrK9fuk
k4qlEpTGevkgzAGuYLE1/+nPfx2vFxOdtPkV6uCnP/+N74z1LiKHlTwmyZqn
OvfmREx69mrcoXE6tkKufk2+Mob8DjNLMPglAHLN70RSSOucS1LLeBR5Eq1l
JFGRCASxMOzkbDw8P7/67vSEzKAAKBm9kCG/xD/OBNr1CqYVaYwiDWSAhLL7
chegnvIo1Bisgsw3V1INEAAtkN1C6YC1YiTb/Ke//FdXfoLSL5GQfZgiyUkP
aJ18CkBEM7lvsTafFCDvnE0kJLEgpE9pp3O4Py8XtBNLKkHvz55BupYtVKoT
PVtD9ABBLMwXa6Qf5ZqvdBYb3rq4Hd+02vaXX17R9fXpH27Prk9P8Hr8FoRb
XjA3Yvz26vb8pLqqZo6uLi5OL0/sZHjKa49Y62L4x5YNIa2rdzdnV5fD89Zm
1oFSBsBPpDVbqFmcsmve5/Xo3X//vXcAfP+LS8BAQfYGMyG4Wc2ly6t1Cqi1
t6D2NYNALAXhCx1mJJaQhSfoPkH0c71KOcBfghx/9R4l82HAfzOJlr2Db9wD
ZLj20Mus9pBktvlkY7IV4pZHW7YppVl73pB0nd7hH2v3Xu7Bw9/8NlGp5FB/
//YbRuAZQWozw1CpMG3xKQpjZ6mzLgEus136YJR8ZivQOHRGEEt8kEGF+sAE
dgHeIbZubWntbHuedo/bZpXbdokWxFWKaQoNAkFkMwSwF7j/hPaMMCgDcL7S
zNeJvFH5wZJXKQatxUKAywEe0FM0BmFYnEgIv0XqQiEWpBTCL/XKxuEnpiZB
sEcanTwI8FWItpZby/BcrgSk8JXIUnRUoQDQ84mJBs+B5FOqikOg7P8ZoaAN
RgQVVplLQfKsv1eBs0Xfs61D5PJWIxu0B/WIkXeYO/AlrDXLxHJuUPZBguic
apQI2/ZRVjPAq8Ikwy0Nu6CHhnI2EZGMyeAtlxAwZwobHTkkFShrikRuIDke
+wIXQyfQxVoRrcHy44VVU8JOmWTvOhZdDVJySPEb0jUX3HxIBEFdnZ8w9uOP
P8I2v+Kn6RwjRfxIdpraBKSMELb6wJq2zK/bNmfOMCm3KRTmiqh7hBdaBMgP
8qyg93MPRNtb3l9Lo4ssknZ6jMIHKjKE8/WZ2bXuFmqIHLYobBZENNsKzUhH
F6YU1BHARB/GEMmONgNc2FESwmeQS4G9Ut4IiDBtZnsBLmvk713i8aFtL6Hc
/mCJee9K7g9dEja7PP3uF7H/U8VuZV3K2V5ithdoAMsEr4GaSTXL0sqkfM3Z
sKwMfM6dK3l91w0dn3VJGyFEsCW1/SBlzPjClgQ+akDg9yushPUbhUGf4Xpx
YMLAI2RelO9tiVFYH0ElQARsKRyxy9/vE4fobpqFSVjCuFqtLH7q/oEPm3sH
xa/MeWNriPkOqRD3cPqmCGyICvoZ4PjCYXNt8jbm8DAMV3DTLF8CcjXEK8oR
JR/bJoLYug+WZJyHpCurPBucc1mj3jp57lJbglsr0zr/nXuCfdxWuaVdCN/7
/XyrG+mnyeG8Jr1lkN4UISzTlJwViaU85KXyCcKUe5O+XMSCZTw/zemtOluw
GFi9ocUmmLOsiS5cwZGGiir32MJcqXaY6qf4PgAuYxX3MBvkFQTlVIh/KNCU
jvmOsCvhKrfodBqq4q3uPTpCObvIWck64EmWiYilrs6XLX/QNh+YH2i9IZUN
p/9zbClpbLvNapzRPGAxjFzoE0G4FYGbBvUYCGsIbEx/GggbCMQ1/hEQhgh8
iI2HQRgisGZfXwfCStZWJ/eCcDsGa6rCFR7EYC3sUaMPfsOOWRn5XnX7jaBH
AduxXqaQkH1QfYasQaoczAZRsloGzCGY2PTW5cf+K163bhtPqlmA97WtzqsW
UNikJBuBCDq6Pi8t2xST74G+YZL7cAiUmEJm/knZgYb8B2Fbx4ap3rfdZySM
2uW3WbSUiOrIahyu4LZ9eCASSslTpkDNVJ9o6pATsKptHc0Ix83R1UjQy6mA
IslWjkbWljGYYVgLDVWfr5fy19gXhlpKq0g2oWG/gRE6L8e2OapkEpf1GHZm
pyp15g+L8bPh4TjHjBM0jIr1tzg2UQvlmsCkG4Azlurj0dlZWMuRLYO09GKh
EYW0DgCgXbWYH2oqY8UatI6dvZdpsSusfasZ98liV8Xe0+t0SX7/Ay5UfhkY
jk7x8MVUfeItbI210Cxl7CPlRELVlwY7mkAs32FxWCbn/ORy7HJ9yuB/KERC
pSawiPgh8dU6DKQWagmBg6Juv6DmSEfRUQ1FHwTAF0ToMHIERRoWrX6/bkmL
xEaowDR+I9t8iAyigfKVJ5MBvhUF35msnQYmwijU25CYAidhLXvbJ6B1Sbnt
rjqHYImF0pgihwuVSG3VA0LmEznNO9iR4AY/Ljq1OLdLi86A3tRFss0ggXcw
MbOIm6L7c9EF1/EuH2u6SZ5J6QygITCiey7uMG0tjHRV3xQ8JnfdN4dr66pz
itq+UYLoABcADha/SYyD3vhjWPGLbuuLhcvyZZEttf0wsUF9KQG6G6ClYXs7
I5ecSYHdowWUL9nat+XoYAgu5HoQpGf7XQjNxwJgpUCSZC6VcU2h7CQtuq+l
yELVP7L2Zl2j+8wUwa/bFBVIn3zgd4oIJA/TWCIP0gXsN84SWS/Aq8EUR/k9
gfSkVvy6cFWFxP2nBNR6zVWLfIhwkRjqSmd4jMZgj43c7ZayGxDlan2HanQx
4N3TvBkQvR8n5FJADJ4EEWwjTFJxVs3aeE+GXCbsYeRwBDTDj6WBvsNYk1SY
6tko5wNQEGRQ3WWIcRHPMjvyvAbTS5EZW4Y4RRPubJwpR3jHxKeZXnhU+dQs
FDVzpz6c8OoWUvPJ+L51owl+Lbd61aYmeoK+TuDxev5jNbaWXEiz020r3/k8
64zI3/GWyTV6JhtlWuHHWQpW2Em4TYUxtgMzTcSMl98FsKeM1Mh8S91yUjnI
X/D4fxKP3vnXvtKHSdO2QmEjIz9NQP6ZhlDEsZMUHM0L/N3hE/wdue2gCRUW
FKxWUBxi2P3qgoJQ26S2KpkeqSLCEsJD5quriDB/aqbzT6si/J62QHxo4FNq
AypKwFDuqTjuLyKaFYSXSGg1ZfqFB0ncx5Fa5V4egXEohr39OomG9KWDvQaf
j9WnRvTBq+Zq8BgEelT7icUv1NjRcAsabzFBS9RVOrBdwAQJ6AlFTcnhBuFW
UQ8e90BuELNPYuixtTZYrA6wWA5J5TUmrTv2Pbg7LAZQrzC/PN7y3lnlh6BO
8d0Fy211rIiU+aTq4HEHhKPA3iHT5/ycRPsONxv5za7wS7qtFEdlEkezblab
PXBXHgbZui0/1HTA3LnN3q6NqjU1SoR+agtf5C8oXdp8eHniJ/ft5Eootbk0
3ge/LRWRWwRbgrb0LT+E/NySIeiPlXQ9ftSsloRsax1greAqkIkEXcsnFCFk
Dg1G/sEiBHHRvwcXlzrtbIVFidxAwyV003JWVRE8RrzN7NDinmaeqddG8/NL
UDM2TbZpr8LcmyTu+xSxYbZ4EMAfvqI+B+y8rf/xGP3+vIkXms1XXq9z2bnC
MxQdOia98/rqYtf2R172jz/QhykVh4i2yWttbVwo0Eogj6aofPZis2ntJRoW
l8jPe3c2+UP52Q+PJzsX9ot/+P/sH360mWv1t4RR2KIw/PMzI6MO6tqdQts+
ECBlj/bBjmWaSudryqLM2Zs9TUjHZ2COvBN4fkNvO4vH2KiKjCMoQpwy7DFx
d+LTn7uFegPsptaM9HS4ZisL8pLgECwQ0w5PxFY3/fBmP7w5gBvmD1QHR2Fs
xufPw9E3UXdGEF4CshyVpXowk15jlQbOIWyj2ZOfZa4DPGUgxWTdzHpw+6Db
wcdrk8sF2zm5HOM3lrO07AC1t/7ZB1QyxV4Ong1jM/+no0zOhBWi/68TN/Yv
Rqk/RlvL9z9/xr9O0fnFIZi0yBIFY4OzZJu6fewEGrvnBBp/6gk09qQD4k13
SeEkOIABxerXH1Dj9x5QY193xIzfe8SM1Y6YcTztBCk2/Y2nYbxKpGLjzwdz
OjNhZwiyTnv+axh9TPUqkfHM9R0/D3ha4P+sZPyvrVS3aCWRfiSd4D98Yv5a
pt+LBZ1Wj/l3UkEaUQiADp3Hsedd1j5nppLPygsglxTOyqslb8RHMVeZ5pdy
oXPd5v+m5yn/9wT9JED4Qn2E+rVIzUpn+dx2L69AOnycS3Al9h8ic6kyBlKT
0yIBaOGft9x/H3Qxm+f4FD+MkH3av25MRPSR/Q/fzawMIToAAA==
<section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="David Benjamin"/> and <contact fullname="W
ei Chuang"/>
for identifying the issue and a solution.</t>
<t>Thanks to <contact fullname="Takahiro Nemoto"/>,
<contact fullname="John Klensin"/>, <contact fullname="Mike Ounsworth"/>, and <c
ontact fullname="Orie Steele"/> for their
careful review and thoughtful comments.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 65 change blocks. 
565 lines changed or deleted 215 lines changed or added

This html diff was produced by rfcdiff 1.48.