rfc9525.original.xml   rfc9525.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.6.39 (Ruby 2.6. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
10) --> -ietf-uta-rfc6125bis-15" number="9525" submissionType="IETF" category="std" cons
<?rfc compact="yes"?> ensus="true" obsoletes="6125" updates="" tocDepth="4" tocInclude="true" sortRefs
<?rfc subcompact="no"?> ="true" symRefs="true" xml:lang="en" version="3">
<?rfc rfcedstyle="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-uta-rfc6125bis-15" category="std" consensus="true" submissionType="IETF" o
bsoletes="6125" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" ve
rsion="3">
<!-- xml2rfc v2v3 conversion 3.17.5 --> <!-- xml2rfc v2v3 conversion 3.17.5 -->
<front> <front>
<title abbrev="Service Identity">Service Identity in TLS</title> <title abbrev="Service Identity in TLS">Service Identity in TLS</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-rfc6125bis-15"/> <seriesInfo name="RFC" value="9525"/>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre"> <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>independent</organization> <organization>Independent</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>stpeter@stpeter.im</email> <email>stpeter@stpeter.im</email>
</address> </address>
</author> </author>
<author initials="R." surname="Salz" fullname="Rich Salz"> <author initials="R." surname="Salz" fullname="Rich Salz">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>rsalz@akamai.com</email> <email>rsalz@akamai.com</email>
</address> </address>
</author> </author>
<date year="2023" month="August" day="10"/> <date year="2023" month="November"/>
<area>Applications</area> <area>art</area>
<keyword>Internet-Draft</keyword> <workgroup>uta</workgroup>
<abstract>
<?line 197?> <keyword>TLS</keyword>
<keyword>server</keyword>
<keyword>X509</keyword>
<keyword>identity</keyword>
<keyword>naming</keyword>
<keyword>verifying</keyword>
<keyword>representing</keyword>
<keyword>PKIX</keyword>
<keyword>certificates</keyword>
<keyword>validation</keyword>
<abstract>
<t>Many application technologies enable secure communication between two entitie s <t>Many application technologies enable secure communication between two entitie s
by means of Transport Layer Security (TLS) with by means of Transport Layer Security (TLS) with
Internet Public Key Infrastructure Using X.509 (PKIX) certificates. Internet Public Key Infrastructure using X.509 (PKIX) certificates.
This document specifies This document specifies
procedures for representing and verifying the identity of application services procedures for representing and verifying the identity of application services
in such interactions.</t> in such interactions.</t>
<t>This document obsoletes RFC 6125.</t> <t>This document obsoletes RFC 6125.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Using TLS in Applications Working Group mailing list (uta@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ut
a/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/richsalz/draft-ietf-uta-rfc6125bis"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 208?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<section anchor="motivation"> <section anchor="motivation">
<name>Motivation</name> <name>Motivation</name>
<t>The visible face of the Internet largely consists of services that em ploy a <t>The visible face of the Internet largely consists of services that em ploy a
client-server architecture in which a client client-server architecture in which a client
communicates with an application service. When a client communicates with an communicates with an application service. When a client communicates with an
application service using <xref target="TLS"/>, <xref target="DTLS"/>, or a prot application service using <xref target="RFC8446"/>, <xref target="RFC9147"/>, or
ocol built on those a protocol built on those
(<xref target="QUIC"/> being a notable example), (<xref target="RFC9001"/> being a notable example),
it has some notion of the server's it has some notion of the server's
identity (e.g., "the website at bigcompany.example") while attempting to establi sh identity (e.g., "the website at bigcompany.example") while attempting to establi sh
secure communication. Likewise, during TLS negotiation, the server presents secure communication. Likewise, during TLS negotiation, the server presents
its notion of the service's identity in the form of a public-key certificate its notion of the service's identity in the form of a public key certificate
that was issued by a certificate authority (CA) in the context of the that was issued by a certification authority (CA) in the context of the
Internet Public Key Infrastructure using X.509 <xref target="PKIX"/>. Informall Internet Public Key Infrastructure using X.509 <xref target="RFC5280"/>. Inform
y, we can ally, we can
think of these identities as the client's "reference identity" and the think of these identities as the client's "reference identity" and the
server's "presented identity"; more formal definitions are given later. A server's "presented identity"; more formal definitions are given later. A
client needs to verify that the server's presented identity matches its client needs to verify that the server's presented identity matches its
reference identity so it can deterministically and automatically authenticate th e communication.</t> reference identity so it can deterministically and automatically authenticate th e communication.</t>
<t>This document defines procedures for how clients do this verification <t>This document defines procedures for how clients perform this verific
. ation.
It therefore also defines requirements on other parties, such as It therefore defines requirements on other parties, such as
the certificate authorities that issue certificates, the service administrators the certification authorities that issue certificates, the service administrator
requesting s requesting
them, and the protocol designers defining how things are named.</t> them, and the protocol designers defining interactions between clients an
<t>This document obsoletes RFC 6125. Changes from RFC 6125 are described d servers.</t>
under <xref target="changes"/>.</t> <t>This document obsoletes RFC 6125 <xref target="RFC6125"/>. Changes fr
om RFC 6125 <xref target="RFC6125"/> are described under <xref target="changes"/
>.</t>
</section> </section>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability</name> <name>Applicability</name>
<t>This document does not supersede the rules for certificate issuance o r <t>This document does not supersede the rules for certificate issuance o r
validation specified by <xref target="PKIX"/>. That document also governs any validation specified by <xref target="RFC5280"/>. That document also governs an y
certificate-related topic on which this document is silent. This includes certificate-related topic on which this document is silent. This includes
certificate syntax, extensions such as name constraints or certificate syntax, extensions such as name constraints or
extended key usage, and handling of certification paths.</t> extended key usage, and handling of certification paths.</t>
<t>This document addresses only name forms in the leaf "end entity" serv er <t>This document addresses only name forms in the leaf "end entity" serv er
certificate. It does not address the name forms in the chain of certificates certificate. It does not address the name forms in the chain of certificates
used to validate a certificate, let alone creating or checking the validity used to validate a certificate, nor does it create or check the validity
of such a chain. In order to ensure proper authentication, applications need of such a chain. In order to ensure proper authentication, applications need
to verify the entire certification path.</t> to verify the entire certification path.</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview of Recommendations</name> <name>Overview of Recommendations</name>
<t>The previous version of this specification, <xref target="VERIFY"/>, surveyed the then-current <t>The previous version of this specification, <xref target="RFC6125"/>, surveyed the then-current
practice from many IETF standards and tried to generalize best practices practice from many IETF standards and tried to generalize best practices
(see Appendix A of <xref target="VERIFY"/> for details).</t> (see Appendix A of <xref target="RFC6125"/> for details).</t>
<t>This document takes the lessons learned since then and codifies them. <t>This document takes the lessons learned since then and codifies them.
The following is a summary of the rules, which are described at greater The following is a summary of the rules, which are described at greater
length in the remainder of this document:</t> length in the remainder of this document:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Only check DNS domain names via the subjectAltName <li>Only check DNS domain names via the subjectAltName
extension designed for that purpose: dNSName.</li> extension designed for that purpose: dNSName.</li>
<li>Allow use of even more specific <li>Allow use of even more specific
subjectAltName extensions where appropriate such as subjectAltName extensions where appropriate such as
uniformResourceIdentifier, iPAddress, and the otherName form SRVName.</li> uniformResourceIdentifier, iPAddress, and the otherName form SRVName.</li>
<li>Wildcard support is now the default in certificates. <li>Wildcard support is now the default in certificates.
skipping to change at line 131 skipping to change at line 130
<section anchor="scope"> <section anchor="scope">
<name>Scope</name> <name>Scope</name>
<section anchor="in-scope"> <section anchor="in-scope">
<name>In Scope</name> <name>In Scope</name>
<t>This document applies only to service identities that are used in T LS or DTLS <t>This document applies only to service identities that are used in T LS or DTLS
and that are included in PKIX certificates.</t> and that are included in PKIX certificates.</t>
<t>With regard to TLS and DTLS, these security protocols are used to <t>With regard to TLS and DTLS, these security protocols are used to
protect data exchanged over a wide variety of application protocols, protect data exchanged over a wide variety of application protocols,
which use both the TLS or DTLS handshake protocol and the TLS or which use both the TLS or DTLS handshake protocol and the TLS or
DTLS record layer, either directly or through a profile as in Network DTLS record layer, either directly or through a profile as in Network
Time Security <xref target="NTS"/>. The TLS handshake protocol can also be used Time Security <xref target="RFC8915"/>. The TLS handshake protocol can also be used
with different record layers to define secure transport protocols; with different record layers to define secure transport protocols;
at present the most prominent example is QUIC <xref target="RFC9000"/>. The at present, the most prominent example is QUIC <xref target="RFC9000"/>. The
rules specified here are intended to apply to all protocols in this rules specified here are intended to apply to all protocols in this
extended TLS "family".</t> extended TLS "family".</t>
<t>With regard to PKIX certificates, the primary usage is in the <t>With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in <xref target="PKIX"/>. context of the public key infrastructure described in <xref target="RFC5280"/>.
In addition, technologies such as DNS-Based Authentication In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) <xref target="DANE"/> sometimes use certificates based of Named Entities (DANE) <xref target="RFC6698"/> sometimes use certificates bas ed
on PKIX (more precisely, certificates structured via <xref target="X.509"/> or on PKIX (more precisely, certificates structured via <xref target="X.509"/> or
specific encodings thereof such as <xref target="X.690"/>), at least in certain specific encodings thereof such as <xref target="X.690"/>), at least in certain
modes. Alternatively, a TLS peer could issue delegated credentials modes. Alternatively, a TLS peer could issue delegated credentials
that are based on a CA-issued certificate, as in <xref target="TLS-SUBCERTS"/>. that are based on a CA-issued certificate, as in <xref target="RFC9345"/>.
In both cases, a TLS client could learn of a service identity In both cases, a TLS client could learn of a service identity
through its inclusion in the relevant certificate. The rules specified through its inclusion in the relevant certificate. The rules specified
here are intended to apply whenever service identities are included in here are intended to apply whenever service identities are included in
X.509 certificates or credentials that are derived from such certificates.</t> X.509 certificates or credentials that are derived from such certificates.</t>
</section> </section>
<section anchor="out-of-scope"> <section anchor="out-of-scope">
<name>Out of Scope</name> <name>Out of Scope</name>
<t>The following topics are out of scope for this specification:</t> <t>The following topics are out of scope for this specification:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Security protocols other than those <li>Security protocols other than those
described above.</li> described above.</li>
<li>Keys or certificates employed outside the context of PKIX-based systems.</li> <li>Keys or certificates employed outside the context of PKIX-based systems.</li>
<li>Client or end-user identities. <li>Client or end-user identities.
Other than as described above, certificates representing client identities Other than as described above, certificates representing client identities
(e.g., rfc822Name) are beyond the scope of this document.</li> (e.g., rfc822Name) are beyond the scope of this document.</li>
<li>Identification of servers using other than a domain name, IP add <li>Identification of servers using other than a domain name, an IP
ress, or SRV service name. address, or an SRV service name.
This document discusses Uniform Resource Identifiers <xref target="URI"/> only t This document discusses Uniform Resource Identifiers <xref target="RFC3986"/> on
o the ly to the
extent that they are expressed in certificates. Other aspects of a service extent that they are expressed in certificates. Other aspects of a service
such as a specific resource (the URI "path" component) or parameters (the URI such as a specific resource (the URI "path" component) or parameters (the URI
"query" component) are the responsibility of specific protocols or URI "query" component) are the responsibility of specific protocols or URI
schemes.</li> schemes.</li>
<li> <li>
<t>Certification authority policies. <t>Certification authority policies.
This includes items such as the following: </t> This includes items such as the following: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>How to certify or validate fully-qualified domain names (FQD <li>How to certify or validate fully qualified domain names (FQD
Ns) and application Ns) and application
service types (see <xref target="ACME"/> for some definition of this).</li> service types (see <xref target="RFC8555"/>).</li>
<li>Types or "classes" of certificates to issue and whether to a <li>What types or "classes" of certificates to issue and whether
pply different to apply different
policies for them.</li> policies for them.</li>
<li>How to certify or validate other kinds of information that m ight be <li>How to certify or validate other kinds of information that m ight be
included in a certificate (e.g., organization name).</li> included in a certificate (e.g., organization name).</li>
</ul> </ul>
</li> </li>
<li>Resolution of DNS domain names. <li>Resolution of DNS domain names.
Although the process whereby a client resolves the DNS domain name of an Although the process whereby a client resolves the DNS domain name of an
application service can involve several steps, for the purposes of this application service can involve several steps, for the purposes of this
specification the only relevant consideration is that the client needs to specification, the only relevant consideration is that the client needs to
verify the identity of the entity with which it will communicate once the verify the identity of the entity with which it will communicate once the
resolution process is complete. Thus, the resolution process itself is resolution process is complete. Thus, the resolution process itself is
out of scope for this specification.</li> out of scope for this specification.</li>
<li>User interface issues. <li>User interface issues.
In general, such issues are properly the responsibility of client In general, such issues are properly the responsibility of client
software developers and standards development organizations software developers and standards development organizations
dedicated to particular application technologies (see, for example, dedicated to particular application technologies (for example, see
<xref target="WSC-UI"/>).</li> <xref target="WSC-UI"/>).</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>Because many concepts related to "identity" are often too vague to be <t>Because many concepts related to "identity" are often too vague to be
actionable in application protocols, we define a set of more concrete terms actionable in application protocols, we define a set of more concrete terms
for use in this specification.</t> for use in this specification.</t>
<dl> <dl>
skipping to change at line 212 skipping to change at line 211
entities, or connecting to a broader network of services.</t> entities, or connecting to a broader network of services.</t>
</dd> </dd>
<dt>application service provider:</dt> <dt>application service provider:</dt>
<dd> <dd>
<t>An entity that hosts or deploys an application service.</t> <t>An entity that hosts or deploys an application service.</t>
</dd> </dd>
<dt>application service type:</dt> <dt>application service type:</dt>
<dd> <dd>
<t>A formal identifier for the application protocol used to provide a <t>A formal identifier for the application protocol used to provide a
particular kind of application service at a domain. This often appears as particular kind of application service at a domain. This often appears as
a URI scheme <xref target="URI"/>, DNS SRV Service <xref target="DNS-SRV"/>, or an ALPN <xref target="ALPN"/> a URI scheme <xref target="RFC3986"/>, a DNS SRV Service <xref target="RFC2782"/ >, or an Application-Layer Protocol Negotiation (ALPN) <xref target="RFC7301"/>
identifier.</t> identifier.</t>
</dd> </dd>
<dt>identifier:</dt> <dt>identifier:</dt>
<dd> <dd>
<t>A particular instance of an identifier type that is either presen ted by a <t>A particular instance of an identifier type that is either presen ted by a
server in a certificate or referenced by a client for matching purposes.</t> server in a certificate or referenced by a client for matching purposes.</t>
</dd> </dd>
<dt>identifier type:</dt> <dt>identifier type:</dt>
<dd> <dd>
<t>A formally defined category of identifier that can be included in a <t>A formally defined category of identifier that can be included in a
certificate and therefore that can also be used for matching purposes. For certificate and therefore be used for matching purposes. For
conciseness and convenience, we define the following identifier types of conciseness and convenience, we define the following identifier types of
interest: interest:
</t> </t>
<ul spacing="normal"> <dl spacing="normal">
<li>DNS-ID: a subjectAltName entry of type dNSName as defined in < <dt>DNS-ID:</dt><dd> A subjectAltName entry of type dNSName as def
xref target="PKIX"/>.</li> ined in <xref target="RFC5280"/>.</dd>
<li>IP-ID: a subjectAltName entry of type iPAddress as defined in <dt>IP-ID:</dt><dd> A subjectAltName entry of type iPAddress as de
<xref target="PKIX"/>.</li> fined in <xref target="RFC5280"/>.</dd>
<li>SRV-ID: a subjectAltName entry of type otherName whose name fo <dt>SRV-ID:</dt><dd> A subjectAltName entry of type otherName whos
rm is e name form is
SRVName, as defined in <xref target="SRVNAME"/>.</li> SRVName as defined in <xref target="RFC4985"/>.</dd>
<li>URI-ID: a subjectAltName entry of type uniformResourceIdentifi <dt>URI-ID:</dt><dd> A subjectAltName entry of type uniformResourc
er eIdentifier
as defined in <xref target="PKIX"/>. See further discussion in <xref target="sec as defined in <xref target="RFC5280"/>. See further discussion in <xref target="
urity-uri"/>.</li> security-uri"/>.</dd>
</ul> </dl>
</dd> </dd>
<dt>PKIX:</dt> <dt>PKIX:</dt>
<dd> <dd>
<t>The short name for the Internet Public Key Infrastructure using X .509 <t>The short name for the Internet Public Key Infrastructure using X .509
defined in <xref target="PKIX"/>. That document provides a profile of the X.509 v3 defined in <xref target="RFC5280"/>. That document provides a profile of the X. 509v3
certificate specifications and X.509v2 certificate revocation list (CRL) certificate specifications and X.509v2 certificate revocation list (CRL)
specifications for use on the Internet.</t> specifications for use on the Internet.</t>
</dd> </dd>
<dt>presented identifier:</dt> <dt>presented identifier:</dt>
<dd> <dd>
<t>An identifier presented by a server to a client within a PKIX cer tificate <t>An identifier presented by a server to a client within a PKIX cer tificate
when the client attempts to establish secure communication with the server. when the client attempts to establish secure communication with the server.
The certificate can include one or more presented identifiers of different The certificate can include one or more presented identifiers of different
types, and if the server hosts more than one domain then the certificate types, and if the server hosts more than one domain, then the certificate
might present distinct identifiers for each domain.</t> might present distinct identifiers for each domain.</t>
</dd> </dd>
<dt>reference identifier:</dt> <dt>reference identifier:</dt>
<dd> <dd>
<t>An identifier used by the client when examining presented identif <t>An identifier expected by the client when examining presented ide
iers. ntifiers.
It is constructed from the source domain, and optionally an application It is constructed from the source domain and, optionally, an application
service type.</t> service type.</t>
</dd> </dd>
<dt>Relative Distinguished Name (RDN):</dt> <dt>Relative Distinguished Name (RDN):</dt>
<dd> <dd>
<t>An ASN.1-based construction which itself is a building-block comp <t>An ASN.1-based construction that is itself a building-block compo
onent of nent of
Distinguished Names. See <xref section="2" sectionFormat="comma" target="LDAP-DN Distinguished Names. See <xref section="2" sectionFormat="comma" target="RFC4514
"/>.</t> "/>.</t>
</dd> </dd>
<dt>source domain:</dt> <dt>source domain:</dt>
<dd> <dd>
<t>The fully qualified domain name (FQDN) that a client expects an a pplication <t>The FQDN that a client expects an application
service to present in the certificate. This is typically input by service to present in the certificate. This is typically input by
a human user, configured into a client, or provided by reference such as a human user, configured into a client, or provided by reference such as
a URL. The combination of a source domain and, optionally, an application a URL. The combination of a source domain and, optionally, an application
service type enables a client to construct one or more reference service type enables a client to construct one or more reference
identifiers. This specification covers FQDNs. Use of any names that identifiers. This specification covers FQDNs. Use of any names that
are not fully qualified is out of scope and may result in unexpected are not fully qualified is out of scope and may result in unexpected
or undefined behavior.</t> or undefined behavior.</t>
</dd> </dd>
<dt>subjectAltName entry:</dt> <dt>subjectAltName entry:</dt>
<dd> <dd>
<t>An identifier placed in a subjectAltName extension.</t> <t>An identifier placed in a subjectAltName extension.</t>
</dd> </dd>
<dt>subjectAltName extension:</dt> <dt>subjectAltName extension:</dt>
<dd> <dd>
<t>A standard PKIX extension enabling identifiers of various types t o be <t>A standard PKIX extension enabling identifiers of various types t o be
bound to the certificate subject.</t> bound to the certificate subject.</t>
</dd> </dd>
<dt>subjectName:</dt> <dt>subjectName:</dt>
<dd> <dd>
<t>The name of a PKIX certificate's subject, encoded in a certificat e's <t>The name of a PKIX certificate's subject, encoded in a certificat e's
subject field (see <xref section="4.1.2.6" sectionFormat="comma" target="PKIX"/> ).</t> subject field (see <xref section="4.1.2.6" sectionFormat="comma" target="RFC5280 "/>).</t>
</dd> </dd>
</dl> </dl>
<t>TLS uses the words "client" and "server," where the client is the ent ity <t>TLS uses the words "client" and "server", where the client is the ent ity
that initiates the connection. In many cases, this is consistent with common pr actice, that initiates the connection. In many cases, this is consistent with common pr actice,
such as a browser connecting to a Web origin. such as a browser connecting to a web origin.
For the sake of clarity, and to follow the usage in <xref target="TLS"/> and rel For the sake of clarity, and to follow the usage in <xref target="RFC8446"/> and
ated related
specifications, we will continue specifications, we will continue
to use the terms client and server in this document. to use the terms client and server in this document.
However, these are TLS-layer roles, and the application protocol However, these are TLS-layer roles, and the application protocol
could support the TLS server making requests to the TLS client after the could support the TLS server making requests to the TLS client after the
TLS handshake; there is no requirement that the roles at the application TLS handshake; there is no requirement that the roles at the application
layer match the TLS layer.</t> layer match the TLS layer.</t>
<t>Security-related terms used in this document, but not defined here or in <t>Security-related terms used in this document, but not defined here or in
<xref target="PKIX"/> should be understood in the sense defined in <xref target= "SECTERMS"/>. Such <xref target="RFC5280"/>, should be understood in the sense defined in <xref tar get="RFC4949"/>. Such
terms include "attack", "authentication", "identity", "trust", "validate", terms include "attack", "authentication", "identity", "trust", "validate",
and "verify".</t> and "verify".</t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<?line -18?>
</section> </section>
</section> </section>
<section anchor="names"> <section anchor="names">
<name>Identifying Application Services</name> <name>Identifying Application Services</name>
<t>This document assumes that an application service is identified by a DN S domain <t>This document assumes that an application service is identified by a DN S domain
name (e.g., <tt>bigcompany.example</tt>), an IP address (IPv4 or IPv6), or by an identifier name (e.g., <tt>bigcompany.example</tt>), an IP address (IPv4 or IPv6), or an id entifier
that contains additional supplementary information. Supplementary information that contains additional supplementary information. Supplementary information
is limited to the application service type as expressed in a DNS SRV record is limited to the application service type as expressed in a DNS SRV record
(e.g., "the IMAP server at isp.example" for "_imap.isp.example") or a URI.</t> (e.g., "the IMAP server at isp.example" for "_imap.isp.example") or a URI.</t>
<t>In a DNS-ID - and in the DNS domain name portion of an SRV-ID or URI-ID <t>In a DNS-ID -- and in the DNS domain name portion of an SRV-ID or URI-I
- any D -- any
characters outside the <xref target="US-ASCII"/> range are prohibited and intern characters outside the range described in <xref target="US-ASCII"/> are prohibit
ationalized ed, and internationalized
domain labels are represented as A-labels <xref target="IDNA-DEFS"/>.</t> domain labels are represented as A-labels <xref target="RFC5890"/>.</t>
<t>An IP address is either a 4-octet IPv4 address <xref target="IPv4"/> or <t>An IP address is either a 4-octet IPv4 address <xref target="RFC0791"/>
a 16-octet or a 16-octet
IPv6 address <xref target="IPv6"/>. The identifier might need to be converted f IPv6 address <xref target="RFC4291"/>. The identifier might need to be converte
rom a d from a
textual representation to obtain this value.</t> textual representation to obtain this value.</t>
<t>From the perspective of the application client or user, some identifier s are <t>From the perspective of the application client or user, some identifier s are
<em>direct</em> because they are provided directly by a human user. This includ es <em>direct</em> because they are provided directly by a human user. This includ es
runtime input, prior configuration, or explicit acceptance of a client runtime input, prior configuration, or explicit acceptance of a client
communication attempt. Other names are <em>indirect</em> because they are communication attempt. Other names are <em>indirect</em> because they are
automatically resolved by the application based on user input, such as a automatically resolved by the application based on user input, such as a
target name resolved from a source name using DNS SRV or <xref target="NAPTR"/> records. target name resolved from a source name using DNS SRV or the records described i n <xref target="RFC3403"/>.
The distinction matters most for certificate consumption, specifically The distinction matters most for certificate consumption, specifically
verification as discussed in this document.</t> verification as discussed in this document.</t>
<t>From the perspective of the application service, some identifiers are <t>From the perspective of the application service, some identifiers are
<em>unrestricted</em> because they can be used in any type of service, such as a <em>unrestricted</em> because they can be used in any type of service, such as a
single certificate being used for both the HTTP and IMAP services at the host single certificate being used for both the HTTP and IMAP services at the host
"bigcompany.example". Other identifiers are <em>restricted</em> because they ca n only be used for "bigcompany.example". Other identifiers are <em>restricted</em> because they ca n only be used for
one type of service, such as a special-purpose certificate that can only be one type of service, such as a special-purpose certificate that can only be
used for an IMAP service. This distinction matters most for certificate used for an IMAP service. This distinction matters most for certificate
issuance.</t> issuance.</t>
<t>We can categorize the four identifier types as follows:</t> <t>The four identifier types can be categorized as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A DNS-ID is direct and unrestricted.</li> <li>A DNS-ID is direct and unrestricted.</li>
<li>An IP-ID is direct and unrestricted.</li> <li>An IP-ID is direct and unrestricted.</li>
<li>An SRV-ID is typically indirect but can be direct, and is restricted .</li> <li>An SRV-ID is typically indirect but can be direct, and it is restric ted.</li>
<li>A URI-ID is direct and restricted.</li> <li>A URI-ID is direct and restricted.</li>
</ul> </ul>
<t>It is important to keep these distinctions in mind, because best practi ces <t>It is important to keep these distinctions in mind because best practic es
for the deployment and use of the identifiers differ. for the deployment and use of the identifiers differ.
Note that cross-protocol attacks such as <xref target="ALPACA"/> Note that cross-protocol attacks such as those described in <xref target="ALPACA "/>
are possible when two are possible when two
different protocol services use the same certificate. different protocol services use the same certificate.
This can be addressed by using restricted identifiers or deploying This can be addressed by using restricted identifiers or deploying
services so that they do not share certificates. services so that they do not share certificates.
Protocol specifications <bcp14>MUST</bcp14> specify which identifiers are Protocol specifications <bcp14>MUST</bcp14> specify which identifiers are
mandatory-to-implement and <bcp14>SHOULD</bcp14> provide operational guidance wh en necessary.</t> mandatory to implement and <bcp14>SHOULD</bcp14> provide operational guidance wh en necessary.</t>
<t>The Common Name RDN <bcp14>MUST NOT</bcp14> be used to identify a servi ce because <t>The Common Name RDN <bcp14>MUST NOT</bcp14> be used to identify a servi ce because
it is not strongly typed (essentially free-form text) and therefore it is not strongly typed (it is essentially free-form text) and therefore
suffers from ambiguities in interpretation.</t> suffers from ambiguities in interpretation.</t>
<t>For similar reasons, other RDNs within the subjectName <bcp14>MUST NOT< /bcp14> be used to <t>For similar reasons, other RDNs within the subjectName <bcp14>MUST NOT< /bcp14> be used to
identify a service.</t> identify a service.</t>
<t>An IP address that is the result of a DNS query is not direct. Use of I <t>An IP address that is the result of a DNS query is indirect. Use of IP-
P-IDs IDs
that are not direct is out of scope for this document.</t> that are indirect is out of scope for this document.</t>
<t>The IETF continues to define methods for looking up information needed <t>The IETF continues to define methods for looking up information needed
to make connections to network services. One recent example is service to make connections to network services. One recent example is service
binding via the "SVCB" and "HTTPS" DNS resource record (RR) types. This binding via the "SVCB" and "HTTPS" DNS resource record (RR) types. This
document does not define any identity representation or verification procedures document does not define any identity representation or verification procedures
that are specific to SVCB-compatible records, because the use of such records du ring that are specific to SVCB-compatible records, because the use of such records du ring
connection establishment does not currently alter any of the PKIX validation connection establishment does not currently alter any of the PKIX validation
requirements specified herein or in any other relevant specification. For exampl requirements specified herein or in any other relevant specification.
e, For example,
the PKIX validation rules for <xref target="HTTP-OVER-TLS"/> and <xref target="D the PKIX validation rules for <xref target="RFC9110"/> and <xref target="RFC7858
NS-OVER-TLS"/> do not change "/> do not change
when the client uses <xref target="SVCB-FOR-HTTPS"/> or <xref target="SVCB-FOR-D when the client uses the DNS resource records defined in <xref target="RFC9460"/
NS"/>. However, it is possible > or <xref target="RFC9461"/> to look up connection information. However, it is
possible
that future SVCB mapping documents could specify altered PKIX rules for new use cases.</t> that future SVCB mapping documents could specify altered PKIX rules for new use cases.</t>
</section> </section>
<section anchor="design"> <section anchor="design">
<name>Designing Application Protocols</name> <name>Designing Application Protocols</name>
<t>This section defines how protocol designers should reference this docum ent, <t>This section defines how protocol designers should reference this docum ent,
which would typically be a normative reference in their specification. which would typically be a normative reference in their specification.</t>
Its specification <t>A specification
<bcp14>MAY</bcp14> choose to allow only one of the identifier types defined here .</t> <bcp14>MAY</bcp14> choose to allow only one of the identifier types defined here .</t>
<t>If the technology does not use DNS SRV records to resolve the DNS domai n <t>If the technology does not use DNS SRV records to resolve the DNS domai n
names of application services, then its specification <bcp14>MUST</bcp14> state that SRV-ID names of application services, then the specification <bcp14>MUST</bcp14> state that SRV-ID
as defined in this document is not supported. Note that many existing as defined in this document is not supported. Note that many existing
application technologies use DNS SRV records to resolve the DNS domain names application technologies use DNS SRV records to resolve the DNS domain names
of application services, but do not rely on representations of those records of application services, but they do not rely on representations of those record
in PKIX certificates by means of SRV-IDs as defined in <xref target="SRVNAME"/>. s
</t> in PKIX certificates by means of SRV-IDs as defined in <xref target="RFC4985"/>.
</t>
<t>If the technology does not use URIs to identify application services, t hen <t>If the technology does not use URIs to identify application services, t hen
its specification <bcp14>MUST</bcp14> state that URI-ID as defined in this docum ent is not the specification <bcp14>MUST</bcp14> state that URI-ID as defined in this docum ent is not
supported. Note that many existing application technologies use URIs to supported. Note that many existing application technologies use URIs to
identify application services, but do not rely on representation of those identify application services, but they do not rely on representation of those
URIs in PKIX certificates by means of URI-IDs.</t> URIs in PKIX certificates by means of URI-IDs.</t>
<t>A technology <bcp14>MAY</bcp14> disallow the use of the wildcard charac ter in presented identifiers. If <t>A technology <bcp14>MAY</bcp14> disallow the use of the wildcard charac ter in presented identifiers. If
it does so, then the specification <bcp14>MUST</bcp14> state that wildcard certi ficates as it does so, then the specification <bcp14>MUST</bcp14> state that wildcard certi ficates as
defined in this document are not supported.</t> defined in this document are not supported.</t>
<t>A protocol can allow the use of an IP address in place of a DNS name. This <t>A protocol can allow the use of an IP address in place of a DNS name. This
might use the same field without distinguishing the type of identifier, as for might use the same field without distinguishing the type of identifier as, for
example in the "host" components of a URI. In this case, applications need to b example, in the "host" components of a URI. In this case, applications need to
e aware that the textual be aware that the textual
representation of an IPv4 address is a valid DNS name. The two representation of an IPv4 address is a valid DNS name. The two
types can be distinguished by first testing if the identifier is a valid IPv4 types can be distinguished by first testing if the identifier is a valid IPv4
address, as is done by the "first-match-wins" algorithm in <xref section="3.2.2" sectionFormat="of" target="URI"/>.</t> address, as is done by the "first-match-wins" algorithm in <xref section="3.2.2" sectionFormat="of" target="RFC3986"/>.</t>
</section> </section>
<section anchor="represent"> <section anchor="represent">
<name>Representing Server Identity</name> <name>Representing Server Identity</name>
<t>This section provides instructions for issuers of <t>This section provides instructions for issuers of
certificates.</t> certificates.</t>
<section anchor="represent-rules"> <section anchor="represent-rules">
<name>Rules</name> <name>Rules</name>
<t>When a certificate authority issues a certificate based on the FQDN <t>When a certification authority issues a certificate based on the FQDN
at which the application service provider at which the application service provider
will provide the relevant application, the following rules apply to will provide the relevant application, the following rules apply to
the representation of application service identities. the representation of application service identities.
Note that some of these rules are cumulative Note that some of these rules are cumulative
and can interact in important ways that are illustrated later in this and can interact in important ways that are illustrated later in this
document.</t> document.</t>
<ol spacing="normal" type="1"><li>The certificate <bcp14>MUST</bcp14> in clude at least one identifier.</li> <ol spacing="normal" type="1"><li>The certificate <bcp14>MUST</bcp14> in clude at least one identifier.</li>
<li>The certificate <bcp14>SHOULD</bcp14> include a DNS-ID as a baseli ne <li>The certificate <bcp14>SHOULD</bcp14> include a DNS-ID as a baseli ne
for interoperability. This is not mandatory because for interoperability. This is not mandatory because
it is legitimate for a certificate to include only an SRV-ID or it is legitimate for a certificate to include only an SRV-ID or
URI-ID so as to scope its use to a particular application type.</li> URI-ID so as to scope its use to a particular application type.</li>
<li>If the service using the certificate deploys a technology for whic
h <li>If the service using the certificate deploys a technology for which
the relevant specification stipulates that certificates should the relevant specification stipulates that certificates should
include identifiers of type "SRV-ID" (e.g., this is true of <xref target="XMPP"/ >), include identifiers of type SRV-ID (e.g., this is true of the Extensible Messagi ng and Presence Protocol (XMPP) as described in <xref target="RFC6120"/>),
then the certificate <bcp14>SHOULD</bcp14> include an SRV-ID. This then the certificate <bcp14>SHOULD</bcp14> include an SRV-ID. This
identifier type could supplement the DNS-ID, unless the certificate identifier type could supplement the DNS-ID, unless the certificate
is meant to be scoped to only the protocol in question.</li> is meant to be scoped to only the protocol in question.</li>
<li>If the service using the certificate deploys a technology for whic h <li>If the service using the certificate deploys a technology for whic h
the relevant specification stipulates that certificates should include the relevant specification stipulates that certificates should include
identifiers of type URI-ID (e.g., this is true of <xref target="SIP"/> as specif identifiers of type URI-ID (e.g., this is true of the Session Initiation Protoco
ied by l <xref target="RFC3261"/> as specified by
<xref target="SIP-CERTS"/>), then the certificate <bcp14>SHOULD</bcp14> include <xref target="RFC5922"/>), then the certificate <bcp14>SHOULD</bcp14> include a
a URI-ID. The scheme URI-ID. The scheme
<bcp14>MUST</bcp14> be that of the protocol associated with the application serv <bcp14>MUST</bcp14> be that of the protocol associated with the application serv
ice type ice type,
and the "host" component <bcp14>MUST</bcp14> be the FQDN and the "host" component <bcp14>MUST</bcp14> be the FQDN
of the service. The application protocol specification of the service. The application protocol specification
<bcp14>MUST</bcp14> specify which URI schemes are acceptable in URI-IDs containe d in PKIX <bcp14>MUST</bcp14> specify which URI schemes are acceptable in URI-IDs containe d in PKIX
certificates used for the application protocol (e.g., <tt>sip</tt> but not <tt>s ips</tt> certificates used for the application protocol (e.g., <tt>sip</tt> but not <tt>s ips</tt>
or <tt>tel</tt> for SIP as described in <xref target="SIP-SIPS"/>). Typically, t his or <tt>tel</tt> for SIP as described in <xref target="RFC5630"/>). Typically, th is
identifier type would supplement the DNS-ID, unless the certificate identifier type would supplement the DNS-ID, unless the certificate
is meant to be scoped to only the protocol in question.</li> is meant to be scoped to only the protocol in question.</li>
<li>The certificate <bcp14>MAY</bcp14> contain more than one DNS-ID, S RV-ID, URI-ID, or IP-ID <li>The certificate <bcp14>MAY</bcp14> contain more than one DNS-ID, S RV-ID, URI-ID, or IP-ID
as further explained under <xref target="security-multi"/>.</li> as further explained in <xref target="security-multi"/>.</li>
<li>The certificate <bcp14>MAY</bcp14> include other application-speci fic identifiers <li>The certificate <bcp14>MAY</bcp14> include other application-speci fic identifiers
for compatibility with a deployed base, especially identifiers for for compatibility with a deployed base, especially identifiers for
types that were defined before publication of <xref target="SRVNAME"/> or for wh ich types that were defined before publication of <xref target="RFC4985"/> or for wh ich
SRV service names or URI schemes do not exist. Such identifiers are out SRV service names or URI schemes do not exist. Such identifiers are out
of scope for this specification.</li> of scope for this specification.</li>
</ol> </ol>
</section> </section>
<section anchor="represent-examples"> <section anchor="represent-examples">
<name>Examples</name> <name>Examples</name>
<t>Consider a simple website at <tt>www.bigcompany.example</tt>, which i s not discoverable via <t>Consider a simple website at <tt>&lt;www.bigcompany.example&gt;</tt>, which is not discoverable via
DNS SRV lookups. Because HTTP does not specify the use of URIs in server DNS SRV lookups. Because HTTP does not specify the use of URIs in server
certificates, a certificate for this service might include only a DNS-ID of certificates, a certificate for this service might include only a DNS-ID of
<tt>www.bigcompany.example</tt>.</t> <tt>&lt;www.bigcompany.example&gt;</tt>.</t>
<t>Consider another website, which is reachable by a fixed IP address of <t>Consider another website, which is reachable by a fixed IP address of
<tt>2001:db8::5c</tt>. If the two sites refer to the same web service, then <tt>2001:db8::5c</tt>. If the two sites refer to the same web service, then
the certificate might also include this value in an IP-ID to allow the certificate might also include this value in an IP-ID to allow
clients to use the fixed IP address as a reference identity.</t> clients to use the fixed IP address as a reference identity.</t>
<t>Consider an IMAP-accessible email server at the host <tt>mail.isp.exa mple</tt> <t>Consider an IMAP-accessible email server at the host <tt>mail.isp.exa mple</tt>
servicing email addresses of the form <tt>user@isp.example</tt> and discoverable via servicing email addresses of the form <tt>user@isp.example</tt> and discoverable via
DNS SRV lookups on the application service name of <tt>isp.example</tt>. A DNS SRV lookups on the application service name of <tt>isp.example</tt>. A
certificate for this service might include SRV-IDs of <tt>_imap.isp.example</tt> and certificate for this service might include SRV-IDs of <tt>_imap.isp.example</tt> and
<tt>_imaps.isp.example</tt> (see <xref target="EMAIL-SRV"/>) along with DNS-IDs <tt>_imaps.isp.example</tt> (see <xref target="RFC6186"/>) along with DNS-IDs of
of <tt>isp.example</tt> <tt>isp.example</tt>
and <tt>mail.isp.example</tt>.</t> and <tt>mail.isp.example</tt>.</t>
<t>Consider a SIP-accessible voice-over-IP (VoIP) server at the host <t>Consider a SIP-accessible voice-over-IP (VoIP) server at the host
<tt>voice.college.example</tt> servicing SIP addresses of the form <tt>voice.college.example</tt> servicing SIP addresses of the form
<tt>user@voice.college.example</tt> and identified by a URI of &lt;sip:voice.col lege.example&gt;. <tt>user@voice.college.example</tt> and identified by a URI of &lt;sip:voice.col lege.example&gt;.
A certificate for this service would include a URI-ID of A certificate for this service would include a URI-ID of
<tt>sip:voice.college.example</tt> (see <xref target="SIP-CERTS"/>) along with a <tt>&lt;sip:voice.college.example&gt;</tt> (see <xref target="RFC5922"/>) along
DNS-ID of with a DNS-ID of
<tt>voice.college.example</tt>.</t> <tt>voice.college.example</tt>.</t>
<t>Consider an XMPP-compatible instant messaging (IM) server at the host <t>Consider an XMPP-compatible instant messaging (IM) server at the host
<tt>messenger.example</tt> servicing IM addresses of the form <tt>user@messenger .example</tt> and <tt>messenger.example</tt> that services IM addresses of the form <tt>user@messe nger.example</tt> and that is
discoverable via DNS SRV lookups on the <tt>messenger.example</tt> domain. A discoverable via DNS SRV lookups on the <tt>messenger.example</tt> domain. A
certificate for this service might include SRV-IDs of certificate for this service might include SRV-IDs of
<tt>_xmpp-client.messenger.example</tt> and <tt>_xmpp-server.messenger.example</ tt> (see <tt>_xmpp-client.messenger.example</tt> and <tt>_xmpp-server.messenger.example</ tt> (see
<xref target="XMPP"/>), as well as a DNS-ID of <tt>messenger.example</tt>.</t> <xref target="RFC6120"/>), as well as a DNS-ID of <tt>messenger.example</tt>.</t >
</section> </section>
</section> </section>
<section anchor="request"> <section anchor="request">
<name>Requesting Server Certificates</name> <name>Requesting Server Certificates</name>
<t>This section provides instructions for service providers regarding <t>This section provides instructions for service providers regarding
the information to include in certificate signing requests (CSRs). the information to include in certificate signing requests (CSRs).
In general, service providers <bcp14>SHOULD</bcp14> request certificates that In general, service providers <bcp14>SHOULD</bcp14> request certificates that
include all the identifier types that are required or recommended for include all the identifier types that are required or recommended for
the application service type that will be secured using the certificate to the application service type that will be secured using the certificate to
be issued.</t> be issued.</t>
<t>A service provider <bcp14>SHOULD</bcp14> request certificates with as f ew identifiers as <t>A service provider <bcp14>SHOULD</bcp14> request certificates with as f ew identifiers as
necessary to identify a single service; see <xref target="security-multi"/>.</t> necessary to identify a single service; see <xref target="security-multi"/>.</t>
<t>If the certificate will be used for only a single type of application <t>If the certificate will be used for only a single type of application
service, the service provider <bcp14>SHOULD</bcp14> request a certificate that i ncludes service, the service provider <bcp14>SHOULD</bcp14> request a certificate that i ncludes
DNS-ID or IP-ID values that identify that service or, DNS-ID or IP-ID values that identify that service or,
if appropriate for the application service type, SRV-ID or if appropriate for the application service type, SRV-ID or
URI-ID values that limit the deployment scope of the certificate to only the URI-ID values that limit the deployment scope of the certificate to only the
defined application service type.</t> defined application service type.</t>
<t>If the certificate might be used for any type of application service, t hen <t>If the certificate might be used for any type of application service,
the service provider <bcp14>SHOULD</bcp14> request a certificate that includes the service provider <bcp14>SHOULD</bcp14> request a certificate that includes
only DNS-IDs or IP-IDs. Again, because of multiprotocol attacks this practice is only DNS-IDs or IP-IDs. Again, because of multiprotocol attacks, this practice i
discouraged; this can be mitigated by deploying only one service on s
discouraged; it can be mitigated by deploying only one service on
a host.</t> a host.</t>
<t>If a service provider offers multiple application service types and wis hes to <t>If a service provider offers multiple application service types and wis hes to
limit the applicability of certificates using SRV-IDs or URI-IDs, they <bcp14>SH limit the applicability of certificates using SRV-IDs or URI-IDs, it <bcp14>SHOU
OULD</bcp14> LD</bcp14>
request multiple certificates, rather than a single certificate containing request that multiple certificates rather than a single certificate containing
multiple SRV-IDs or URI-IDs each identifying a different application service multiple SRV-IDs or URI-IDs each identify a different application service
type. This rule does not apply to application service type "bundles" that type. This rule does not apply to application service type "bundles" that
identify distinct access methods to the same underlying application such as identify distinct access methods to the same underlying application such as
an email application with access methods denoted by the application service an email application with access methods denoted by the application service
types of <tt>imap</tt>, <tt>imaps</tt>, <tt>pop3</tt>, <tt>pop3s</tt>, and <tt>s ubmission</tt> as described in types of <tt>imap</tt>, <tt>imaps</tt>, <tt>pop3</tt>, <tt>pop3s</tt>, and <tt>s ubmission</tt> as described in
<xref target="EMAIL-SRV"/>.</t> <xref target="RFC6186"/>.</t>
</section> </section>
<section anchor="verify"> <section anchor="verify">
<name>Verifying Service Identity</name> <name>Verifying Service Identity</name>
<t>At a high level, the client verifies the application service's <t>At a high level, the client verifies the application service's
identity by performing the following actions:</t> identity by performing the following actions:</t>
<ol spacing="normal" type="1"><li>The client constructs a list of referenc e identifiers it would find acceptable <ol spacing="normal" type="1"><li>The client constructs a list of referenc e identifiers it would find acceptable
based on the source domain and, if applicable, the type of service to based on the source domain and, if applicable, the type of service to
which the client is connecting.</li> which the client is connecting.</li>
<li>The server provides its identifiers in the form of a PKIX <li>The server provides its presented identifiers in the form of a PKIX
certificate.</li> certificate.</li>
<li>The client checks each of its reference identifiers against the <li>The client checks each of its reference identifiers against the
presented identifiers for the purpose of finding a match. When checking a server's presented identifiers for the purpose of finding a match. When checking a
reference identifier against a presented identifier, the client matches the reference identifier against a presented identifier, the client matches the
source domain of the identifiers and, optionally, their application service source domain of the identifiers and, optionally, their application service
type.</li> type.</li>
</ol> </ol>
<t>Naturally, in addition to checking identifiers, a client should perform <t>Naturally, in addition to checking identifiers, a client should perform
further checks, such as expiration and revocation, to ensure that the server further checks, such as expiration and revocation, to ensure that the server
is authorized to provide the requested service. Because such checking is not a is authorized to provide the requested service. Because such checking is not a
matter of verifying the application service identity presented in a matter of verifying the application service identity presented in a
certificate, methods for doing so are out of scope for certificate, methods for doing so are out of scope for
this document.</t> this document.</t>
<section anchor="verify-reference"> <section anchor="verify-reference">
<name>Constructing a List of Reference Identifiers</name> <name>Constructing a List of Reference Identifiers</name>
<section anchor="verify-reference-rules"> <section anchor="verify-reference-rules">
<name>Rules</name> <name>Rules</name>
<t>The client <bcp14>MUST</bcp14> construct a list of acceptable refer ence identifiers, <t>The client <bcp14>MUST</bcp14> construct a list of acceptable refer ence identifiers
and <bcp14>MUST</bcp14> do so independently of the identifiers presented by the and <bcp14>MUST</bcp14> do so independently of the identifiers presented by the
service.</t> server.</t>
<t>The inputs used by the client to construct its list of reference id entifiers <t>The inputs used by the client to construct its list of reference id entifiers
might be a URI that a user has typed into an interface (e.g., an HTTPS URL might be a URI that a user has typed into an interface (e.g., an HTTPS URL
for a website), configured account information (e.g., the domain name of a for a website), configured account information (e.g., the domain name of a
host for retrieving email, which might be different from the DNS domain name host for retrieving email, which might be different from the DNS domain name
portion of a username), a hyperlink in a web page that triggers a browser to portion of a username), a hyperlink in a web page that triggers a browser to
retrieve a media object or script, or some other combination of information retrieve a media object or script, or some other combination of information
that can yield a source domain and an application service type.</t> that can yield a source domain and an application service type.</t>
<t>This document does not precisely define how reference identifiers a re generated. <t>This document does not precisely define how reference identifiers a re generated.
Defining reference identifiers is the responsibility of applications or protocol s that use this Defining reference identifiers is the responsibility of applications or protocol s that use this
document. Because the security of a system that uses this document will depend document. Because the security of a system that uses this document will depend
on how reference identifiers are generated, great care should be taken in this on how reference identifiers are generated, great care should be taken in this
process. For example, a protocol or application could specify that the applicati on process. For example, a protocol or application could specify that the applicati on
service type is obtained through a one-to-one mapping of URI schemes to service service type is obtained through a one-to-one mapping of URI schemes to service
types or support only a restricted set of URI schemes. Similarly, it could types or that the protocol or application supports only a restricted set of URI
insist that a domain name or IP address taken as input to the reference schemes.
Similarly, it could
specify that a domain name or an IP address taken as input to the reference
identifier must be obtained in a secure context such as a hyperlink embedded in identifier must be obtained in a secure context such as a hyperlink embedded in
a web page that was delivered over an authenticated and encrypted channel a web page that was delivered over an authenticated and encrypted channel
(see for instance <xref target="SECURE-CONTEXTS"/> with regard to the web platfo rm).</t> (for instance, see <xref target="SECURE-CONTEXTS"/> with regard to the web platf orm).</t>
<t>Naturally, if the inputs themselves are invalid or corrupt (e.g., a user has <t>Naturally, if the inputs themselves are invalid or corrupt (e.g., a user has
clicked a hyperlink provided by a malicious entity in a phishing attack), clicked a hyperlink provided by a malicious entity in a phishing attack),
then the client might end up communicating with an unexpected application then the client might end up communicating with an unexpected application
service.</t> service.</t>
<t>During the course of processing, a client might be exposed to ident ifiers that <t>During the course of processing, a client might be exposed to ident ifiers that
look like, but are not, reference identifiers. For example, DNS resolution that look like, but are not, reference identifiers. For example, DNS resolution that
starts at a DNS-ID reference identifier might produce intermediate domain names starts at a DNS-ID reference identifier might produce intermediate domain names
that need to be further resolved. Unless an application defines a process that need to be further resolved. Unless an application defines a process
for authenticating intermediate identifiers in a way that then allows for authenticating intermediate identifiers in a way that then allows
them to be used as a reference identifier (see for example <xref target="SMTP-TL S"/>), them to be used as a reference identifier (for example, see <xref target="RFC868 9"/>),
any intermediate values are not reference any intermediate values are not reference
identifiers and <bcp14>MUST NOT</bcp14> be treated as such. identifiers and <bcp14>MUST NOT</bcp14> be treated as such.
In the DNS case, not treating intermediate domain names as reference identifiers In the DNS case, not treating intermediate domain names as reference identifiers
removes DNS and DNS resolution from the attack surface.</t> removes DNS and DNS resolution from the attack surface.</t>
<t>As one example of the process of generating a reference identifier, <t>As one example of the process of generating a reference identifier,
from user from the user
input of the URI &lt;sip:alice@college.example&gt; a client could derive the app input of the URI &lt;sip:alice@voice.college.example&gt;, a client could derive
lication the application
service type <tt>sip</tt> from the URI scheme and parse the domain name <tt>coll ege.example</tt> service type <tt>sip</tt> from the URI scheme and parse the domain name <tt>coll ege.example</tt>
from the host component.</t> from the "host" component.</t>
<t>Using the combination of FQDN(s) or IP address(es), plus optionally <t>Using the combination of one or more FQDNs or IP addresses, plus op
an application service type, the client tionally an application service type, the client
<bcp14>MUST</bcp14> construct its list of reference identifiers in accordance wi th the <bcp14>MUST</bcp14> construct its list of reference identifiers in accordance wi th the
following rules:</t> following rules:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If a server for the application service type is typically associ ated <li>If a server for the application service type is typically associ ated
with a URI for security purposes (i.e., a formal protocol document with a URI for security purposes (i.e., a formal protocol document
specifies the use of URIs in server certificates), then the reference identifier specifies the use of URIs in server certificates), the reference identifier
<bcp14>SHOULD</bcp14> be a URI-ID.</li> <bcp14>SHOULD</bcp14> be a URI-ID.</li>
<li>If a server for the application service type is typically discov ered <li>If a server for the application service type is typically discov ered
by means of DNS SRV records, then the reference identifier <bcp14>SHOULD</bcp14> be an SRV-ID.</li> by means of DNS SRV records, the reference identifier <bcp14>SHOULD</bcp14> be a n SRV-ID.</li>
<li>If the reference identifier is an IP address, the reference iden tifier is an <li>If the reference identifier is an IP address, the reference iden tifier is an
IP-ID.</li> IP-ID.</li>
<li>In the absence of more specific identifiers, the reference ident ifier is a DNS-ID. <li>In the absence of more specific identifiers, the reference ident ifier is a DNS-ID.
A reference identifier of type DNS-ID can be directly constructed from a A reference identifier of type DNS-ID can be directly constructed from an
FQDN that is (a) contained in or securely derived from the inputs, or FQDN that is (a) contained in or securely derived from the inputs or
(b) explicitly associated with the source domain by means of user (b) explicitly associated with the source domain by means of user
configuration.</li> configuration.</li>
</ul> </ul>
<t>Which identifier types a client includes in its list of reference <t>Which identifier types a client includes in its list of reference
identifiers, and their priority, is a matter of local policy. For example, a identifiers, and their priority, is a matter of local policy. For example, a
client that is built to connect only to a particular kind of service might be client that is built to connect only to a particular kind of service might be
configured to accept as valid only certificates that include an SRV-ID for configured to accept as valid only certificates that include an SRV-ID for
that application service type. By contrast, a more lenient client, even if that application service type. By contrast, a more lenient client, even if
built to connect only to a particular kind of service, might include built to connect only to a particular kind of service, might include
SRV-IDs, DNS-IDs, and IP-IDs in its list of reference identifiers.</t> SRV-IDs, DNS-IDs, and IP-IDs in its list of reference identifiers.</t>
</section> </section>
<section anchor="verify-reference-examples"> <section anchor="verify-reference-examples">
<name>Examples</name> <name>Examples</name>
<t>The following examples are for illustrative purposes only and are n ot <t>The following examples are for illustrative purposes only and are n ot
intended to be comprehensive.</t> intended to be comprehensive.</t>
<ol spacing="normal" type="1"><li>A web browser that is connecting via HTTPS to the website at <ol spacing="normal" type="1"><li>A web browser that is connecting via HTTPS to the website at
<tt>https://www.bigcompany.example/</tt> would have a single reference identifie r: <tt>&lt;https://www.bigcompany.example/&gt;</tt> would have a single reference i dentifier:
a DNS-ID of <tt>www.bigcompany.example</tt>.</li> a DNS-ID of <tt>www.bigcompany.example</tt>.</li>
<li>A web browser connecting to <tt>https://192.0.2.107/</tt> would have a single <li>A web browser connecting to <tt>&lt;https://192.0.2.107/&gt;</tt > would have a single
IP-ID reference identifier of <tt>192.0.2.107</tt>. Likewise, if connecting IP-ID reference identifier of <tt>192.0.2.107</tt>. Likewise, if connecting
to <tt>https://[2001:db8::abcd]</tt> , it would have a single IP-ID to <tt>&lt;https://[2001:db8::abcd]&gt;</tt>, it would have a single IP-ID
reference identifier of <tt>2001:db8::abcd</tt>.</li> reference identifier of <tt>2001:db8::abcd</tt>.</li>
<li>A mail user agent that is connecting via IMAPS to the email serv ice at <li>A mail user agent that is connecting via IMAPS to the email serv ice at
<tt>isp.example</tt> (resolved as <tt>mail.isp.example</tt>) might have three re ference <tt>isp.example</tt> (resolved as <tt>mail.isp.example</tt>) might have three re ference
identifiers: an SRV-ID of <tt>_imaps.isp.example</tt> (see <xref target="EMAIL-S RV"/>), and identifiers: an SRV-ID of <tt>_imaps.isp.example</tt> (see <xref target="RFC6186 "/>) and
DNS-IDs of <tt>isp.example</tt> and <tt>mail.isp.example</tt>. An email user ag ent that DNS-IDs of <tt>isp.example</tt> and <tt>mail.isp.example</tt>. An email user ag ent that
does not support <xref target="EMAIL-SRV"/> would probably be explicitly configu red to does not support <xref target="RFC6186"/> would probably be explicitly configure d to
connect to <tt>mail.isp.example</tt>, whereas an SRV-aware user agent would deri ve connect to <tt>mail.isp.example</tt>, whereas an SRV-aware user agent would deri ve
<tt>isp.example</tt> from an email address of the form <tt>user@isp.example</tt> but might <tt>isp.example</tt> from an email address of the form <tt>user@isp.example</tt> but might
also accept <tt>mail.isp.example</tt> as the DNS domain name portion of referenc e also accept <tt>mail.isp.example</tt> as the DNS domain name portion of referenc e
identifiers for the service.</li> identifiers for the service.</li>
<li>A voice-over-IP (VoIP) user agent that is connecting via SIP to the voice <li>A VoIP user agent that is connecting via SIP to the voice
service at <tt>voice.college.example</tt> might have only one reference identifi er: service at <tt>voice.college.example</tt> might have only one reference identifi er:
a URI-ID of <tt>sip:voice.college.example</tt> (see <xref target="SIP-CERTS"/>). a URI-ID of <tt>sip:voice.college.example</tt> (see <xref target="RFC5922"/>).</
</li> li>
<li>An instant messaging (IM) client that is connecting via XMPP to <li>An IM client that is connecting via XMPP to the IM
the IM
service at <tt>messenger.example</tt> might have three reference identifiers: an service at <tt>messenger.example</tt> might have three reference identifiers: an
SRV-ID of <tt>_xmpp-client.messenger.example</tt> (see <xref target="XMPP"/>), a DNS-ID of SRV-ID of <tt>_xmpp-client.messenger.example</tt> (see <xref target="RFC6120"/>) , a DNS-ID of
<tt>messenger.example</tt>, and an XMPP-specific <tt>XmppAddr</tt> of <tt>messen ger.example</tt> <tt>messenger.example</tt>, and an XMPP-specific <tt>XmppAddr</tt> of <tt>messen ger.example</tt>
(see <xref target="XMPP"/>).</li> (see <xref target="RFC6120"/>).</li>
</ol> </ol>
<t>In all these cases, presented identifiers that do not match the ref erence <t>In all these cases, presented identifiers that do not match the ref erence
identifier(s) would be rejected; for instance:</t> identifier(s) would be rejected; for instance:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>With regard to the first example a DNS-ID of "web.bigcompany.exa mple" would <li>With regard to the first example, a DNS-ID of <tt>web.bigcompany .example</tt> would
be rejected because the DNS domain name portion does not match be rejected because the DNS domain name portion does not match
"www.bigcompany.example".</li> <tt>www.bigcompany.example</tt>.</li>
<li>With regard to the third example, a URI-ID of "sip:www.college.e <li>With regard to the third example, a URI-ID of &lt;sip:www.colleg
xample" e.example&gt;
would be rejected because the DNS domain name portion does not match would be rejected because the DNS domain name portion does not match
"voice.college.example" and a DNS-ID of "voice.college.example" would be "voice.college.example", and a DNS-ID of "voice.college.example" would be
rejected because it lacks the appropriate application service type rejected because it lacks the appropriate application service type
portion (i.e., it does not specify a "sip:" URI).</li> portion (i.e., it does not specify a "sip:" URI).</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="verify-seek"> <section anchor="verify-seek">
<name>Preparing to Seek a Match</name> <name>Preparing to Seek a Match</name>
<t>Once the client has constructed its list of reference identifiers and has <t>Once the client has constructed its list of reference identifiers and has
received the server's presented identifiers, received the server's presented identifiers,
the client checks its reference identifiers against the presented identifiers the client checks its reference identifiers against the presented identifiers
skipping to change at line 656 skipping to change at line 657
its list of reference identifiers without finding a match. The search succeeds its list of reference identifiers without finding a match. The search succeeds
if any presented identifier matches one of the reference identifiers, at if any presented identifier matches one of the reference identifiers, at
which point the client <bcp14>SHOULD</bcp14> stop the search.</t> which point the client <bcp14>SHOULD</bcp14> stop the search.</t>
<t>Before applying the comparison rules provided in the following <t>Before applying the comparison rules provided in the following
sections, the client might need to split the reference identifier into sections, the client might need to split the reference identifier into
components. components.
Each reference identifier produces either a domain name or an IP address and Each reference identifier produces either a domain name or an IP address and
optionally an application service type as follows:</t> optionally an application service type as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A DNS-ID reference identifier <bcp14>MUST</bcp14> be used directly as the DNS domain <li>A DNS-ID reference identifier <bcp14>MUST</bcp14> be used directly as the DNS domain
name and there is no application service type.</li> name, and there is no application service type.</li>
<li>An IP-ID reference identifier <bcp14>MUST</bcp14> be exactly equal <li>An IP-ID reference identifier <bcp14>MUST</bcp14> exactly match th
to the value of a e value of an
iPAddress entry in subjectAltName, with no partial (e.g., network-level) matchin g. There is no application service type.</li> iPAddress entry in subjectAltName, with no partial (e.g., network-level) matchin g. There is no application service type.</li>
<li>For an SRV-ID reference identifier, the DNS domain name portion is <li>For an SRV-ID reference identifier, the DNS domain name portion is
the Name and the application service type portion is the Service. For the Name and the application service type portion is the Service. For
example, an SRV-ID of <tt>_imaps.isp.example</tt> has a DNS domain name portion example, an SRV-ID of <tt>_imaps.isp.example</tt> has a DNS domain name portion
of <tt>isp.example</tt> and an application service type portion of of <tt>isp.example</tt> and an application service type portion of
<tt>imaps</tt>, which maps to the IMAP application protocol as explained in <tt>imaps</tt>, which maps to the IMAP application protocol as explained in
<xref target="EMAIL-SRV"/>.</li> <xref target="RFC6186"/>.</li>
<li>For a reference identifier of type URI-ID, the DNS domain name <li>For a reference identifier of type URI-ID, the DNS domain name
portion is the "reg-name" part of the "host" component and the application portion is the "reg-name" part of the "host" component and the application
service type portion is the scheme, as defined above. Matching only the service type portion is the scheme, as defined above. Matching only the
"reg-name" rule from <xref target="URI"/> limits the additional domain name vali dation "reg-name" rule from <xref target="RFC3986"/> limits the additional domain name validation
(<xref target="verify-domain"/>) to DNS domain names or non-IP hostnames. (<xref target="verify-domain"/>) to DNS domain names or non-IP hostnames.
A URI that contains an IP address might be matched against an IP-ID in place A URI that contains an IP address might be matched against an IP-ID in place
of a URI-ID by some lenient clients. This document does not describe how a of a URI-ID by some lenient clients. This document does not describe how a
URI that contains no "host" component can be matched. Note that extraction of t he URI that contains no "host" component can be matched. Note that extraction of t he
"reg-name" might necessitate normalization of the URI (as explained in "reg-name" might necessitate normalization of the URI (as explained in
<xref section="6" sectionFormat="of" target="URI"/>). For example, a URI-ID of <tt>sip:voice.college.example</tt> would be split <xref section="6" sectionFormat="of" target="RFC3986"/>). For example, a URI-ID of <tt>&lt;sip:voice.college.example&gt;</tt> would be split
into a DNS domain name portion of <tt>voice.college.example</tt> and an applicat ion into a DNS domain name portion of <tt>voice.college.example</tt> and an applicat ion
service type of <tt>sip</tt> (associated with an application protocol of SIP as service type of <tt>sip</tt> (associated with an application protocol of SIP as
explained in <xref target="SIP-CERTS"/>).</li> explained in <xref target="RFC5922"/>).</li>
</ul> </ul>
<t>If the reference identifier produces a domain name, the client <bcp14 >MUST</bcp14> match the <t>If the reference identifier produces a domain name, the client <bcp14 >MUST</bcp14> match the
DNS name; see <xref target="verify-domain"/>. DNS name; see <xref target="verify-domain"/>.
If the reference identifier produces an IP address, the client <bcp14>MUST</bcp1 4> match the IP If the reference identifier produces an IP address, the client <bcp14>MUST</bcp1 4> match the IP
address; see <xref target="verify-ip"/>. address; see <xref target="verify-ip"/>.
If an application service type is present it <bcp14>MUST</bcp14> also match the If an application service type is present, it <bcp14>MUST</bcp14> also match the
service type as well; see <xref target="verify-app"/>.</t> service type; see <xref target="verify-app"/>.</t>
</section> </section>
<section anchor="verify-domain"> <section anchor="verify-domain">
<name>Matching the DNS Domain Name Portion</name> <name>Matching the DNS Domain Name Portion</name>
<t>This section describes how the client must determine if the presented DNS <t>This section describes how the client must determine if the presented DNS
name matches the reference DNS name. The rules differ depending on whether name matches the reference DNS name. The rules differ depending on whether
the domain to be checked is an the domain to be checked is an
internationalized domain name, as defined in <xref target="names"/>, or not. internationalized domain name, as defined in <xref target="names"/>, or not.
For clients For clients
that support presented identifiers containing the wildcard character "*", this s ection that support presented identifiers containing the wildcard character "*", this s ection
also specifies a supplemental rule for such "wildcard certificates". also specifies a supplemental rule for such "wildcard certificates".
This section uses the description of labels and domain names in This section uses the description of labels and domain names in
<xref target="DNS-CONCEPTS"/>.</t> <xref target="RFC1034"/>.</t>
<t>If the DNS domain name portion of a reference identifier is a "tradit <t>If the DNS domain name portion of a reference identifier
ional is not an internationalized domain name
domain name" (i.e., a FQDN that conforms to "preferred name syntax" as (i.e., an FQDN that conforms to "preferred name syntax" as
described in <xref section="3.5" sectionFormat="of" target="DNS-CONCEPTS"/>), described in <xref section="3.5" sectionFormat="of" target="RFC1034"/>),
then matching of the reference identifier against the presented then the matching of the reference identifier against the presented
identifier <bcp14>MUST</bcp14> be performed by comparing the set of domain name labels using identifier <bcp14>MUST</bcp14> be performed by comparing the set of domain name labels using
a case-insensitive ASCII comparison, as clarified by <xref target="DNS-CASE"/>. For a case-insensitive ASCII comparison, as clarified by <xref target="RFC4343"/>. For
example, <tt>WWW.BigCompany.Example</tt> would be lower-cased to <tt>www.bigcomp any.example</tt> for example, <tt>WWW.BigCompany.Example</tt> would be lower-cased to <tt>www.bigcomp any.example</tt> for
comparison purposes. Each label <bcp14>MUST</bcp14> match in order for the name s to be comparison purposes. Each label <bcp14>MUST</bcp14> match in order for the name s to be
considered to match, except as supplemented by the rule about checking of considered a match, except as supplemented by the rule about checking
wildcard labels in presented identifiers given below.</t> wildcard labels in presented identifiers given below.</t>
<t>If the DNS domain name portion of a reference identifier is an <t>If the DNS domain name portion of a reference identifier is an
internationalized domain name, then the client <bcp14>MUST</bcp14> convert any U -labels internationalized domain name, then the client <bcp14>MUST</bcp14> convert any U -labels
<xref target="IDNA-DEFS"/> in the domain name to A-labels before checking the do <xref target="RFC5890"/> in the domain name to A-labels before checking the doma
main name in name
or comparing it with others. In accordance with <xref target="IDNA-PROTO"/>, A- or comparing it with others. In accordance with <xref target="RFC5891"/>, A-lab
labels els
<bcp14>MUST</bcp14> be compared as case-insensitive ASCII. Each label <bcp14>MU ST</bcp14> match in order <bcp14>MUST</bcp14> be compared as case-insensitive ASCII. Each label <bcp14>MU ST</bcp14> match in order
for the domain names to be considered to match, except as supplemented by for the domain names to be considered to match, except as supplemented by
the rule about checking of wildcard labels in presented identifiers given below. </t> the rule about checking wildcard labels in presented identifiers given below.</t >
<t>If the technology specification supports wildcards in presented ident ifiers, then the client <bcp14>MUST</bcp14> <t>If the technology specification supports wildcards in presented ident ifiers, then the client <bcp14>MUST</bcp14>
match the reference identifier against a presented identifier whose DNS match the reference identifier against a presented identifier whose DNS
domain name portion contains the wildcard character "*" in a label provided domain name portion contains the wildcard character "*" in a label, provided
these requirements are met:</t> these requirements are met:</t>
<ol spacing="normal" type="1"><li>There is only one wildcard character.< /li> <ol spacing="normal" type="1"><li>There is only one wildcard character.< /li>
<li>The wildcard character appears only as the complete content of the left-most label.</li> <li>The wildcard character appears only as the complete content of the left-most label.</li>
</ol> </ol>
<t>If the requirements are not met, the presented identifier is invalid and <bcp14>MUST</bcp14> <t>If the requirements are not met, the presented identifier is invalid and <bcp14>MUST</bcp14>
be ignored.</t> be ignored.</t>
<t>A wildcard in a presented identifier can only match exactly one label in a <t>A wildcard in a presented identifier can only match one label in a
reference identifier. This specification covers only wildcard characters in reference identifier. This specification covers only wildcard characters in
presented identifiers, not wildcard characters in reference identifiers or in presented identifiers, not wildcard characters in reference identifiers or in
DNS domain names more generally. Therefore, the use of wildcard characters DNS domain names more generally. Therefore, the use of wildcard characters
as described herein is not to be confused with DNS wildcard as described herein is not to be confused with DNS wildcard
matching, where the "*" label always matches at least one whole label and matching, where the "*" label always matches at least one whole label and
sometimes more; see <xref section="4.3.3" sectionFormat="comma" target="DNS-CONC sometimes more; see <xref section="4.3.3" sectionFormat="comma" target="RFC1034"
EPTS"/> and <xref target="DNS-WILDCARDS"/>. /> and <xref target="RFC4592"/>.
In particular, it also deviates from <xref section="2.1.3" sectionFormat="comma" In particular, it also deviates from <xref section="2.1.3" sectionFormat="comma"
target="DNS-WILDCARDS"/>.</t> target="RFC4592"/>.</t>
<t>For information regarding the security characteristics of wildcard <t>For information regarding the security characteristics of wildcard
certificates, see <xref target="security-wildcards"/>.</t> certificates, see <xref target="security-wildcards"/>.</t>
</section> </section>
<section anchor="verify-ip"> <section anchor="verify-ip">
<name>Matching an IP Address Portion</name> <name>Matching an IP Address Portion</name>
<t>An IP-ID matches based on an octet-for-octet comparison of the bytes of the <t>Matching of an IP-ID is based on an octet-for-octet comparison of the bytes of the
reference identity with the bytes contained in the iPAddress subjectAltName.</t> reference identity with the bytes contained in the iPAddress subjectAltName.</t>
<t>For an IP address that appears in a URI-ID, the "host" component of b oth the <t>For an IP address that appears in a URI-ID, the "host" component of b oth the
reference identity and the presented identifier must match. These are parsed as either reference identity and the presented identifier must match. These are parsed as either
an "IPv6address" (following <xref section="3.2.2" sectionFormat="comma" target=" RFC3986"/>) or an "IPv4address" (following <xref target="IPv4"/>). an "IPv6address" (following <xref section="3.2.2" sectionFormat="comma" target=" RFC3986"/>) or an "IPv4address" (following <xref target="RFC0791"/>).
If the resulting octets are equal, the IP address matches.</t> If the resulting octets are equal, the IP address matches.</t>
<t>This document does not specify how an SRV-ID reference identity can i nclude an <t>This document does not specify how an SRV-ID reference identity can i nclude an
IP address, as <xref target="SRVNAME"/> only defines string names, not octet ide ntifiers IP address, as <xref target="RFC4985"/> only defines string names, not octet ide ntifiers
such as an IP address.</t> such as an IP address.</t>
</section> </section>
<section anchor="verify-app"> <section anchor="verify-app">
<name>Matching the Application Service Type Portion</name> <name>Matching the Application Service Type Portion</name>
<t>The rules for matching the application service type depend on whether <t>The rules for matching the application service type depend on whether
the identifier is an SRV-ID or a URI-ID.</t> the identifier is an SRV-ID or a URI-ID.</t>
<t>These identifiers provide an application service type portion to be c hecked, <t>These identifiers provide an application service type portion to be c hecked,
but that portion is combined only with the DNS domain name portion of the but that portion is combined only with the DNS domain name portion of the
SRV-ID or URI-ID itself. For example, if a client's list of reference SRV-ID or URI-ID itself. Consider the example of a messaging client that has tw
identifiers includes an SRV-ID of <tt>_xmpp-client.messenger.example</tt> and a o reference
DNS-ID identifiers: (1) an SRV-ID of <tt>_xmpp-client.messenger.example</tt> and (2) a
of <tt>app.example</tt>, the client <bcp14>MUST</bcp14> check both the combinati DNS-ID
on of an of <tt>app.example</tt>. The client <bcp14>MUST</bcp14> check (1) the combinati
application service type of <tt>xmpp-client</tt> and a DNS domain name of on of (a) an
<tt>messenger.example</tt> and, separately, application service type of <tt>xmpp-client</tt> and (b) a DNS domain name of
<tt>messenger.example</tt> as well as (2)
a DNS domain name of <tt>app.example</tt>. However, the a DNS domain name of <tt>app.example</tt>. However, the
client <bcp14>MUST NOT</bcp14> check the combination of an application service t ype of client <bcp14>MUST NOT</bcp14> check the combination of an application service t ype of
<tt>xmpp-client</tt> and a DNS domain name of <tt>app.example</tt> because it do es not <tt>xmpp-client</tt> and a DNS domain name of <tt>app.example</tt> because it do es not
have an SRV-ID of <tt>_xmpp-client.app.example</tt> in its list of reference have an SRV-ID of <tt>_xmpp-client.app.example</tt> in its list of reference
identifiers.</t> identifiers.</t>
<t>If the identifier is an SRV-ID, then the application service name <bc p14>MUST</bcp14> <t>If the identifier is an SRV-ID, then the application service name <bc p14>MUST</bcp14>
be matched in a case-insensitive manner, in accordance with <xref target="DNS-SR be matched in a case-insensitive manner, in accordance with <xref target="RFC278
V"/>. 2"/>.
Note that, per <xref target="SRVNAME"/>, the <tt>_</tt> character is part of the Note that per <xref target="RFC4985"/>, the underscore "_" is part of the servic
service name in e name in
DNS SRV records and in SRV-IDs.</t> DNS SRV records and in SRV-IDs.</t>
<t>If the identifier is a URI-ID, then the scheme name portion <bcp14>MU ST</bcp14> be <t>If the identifier is a URI-ID, then the scheme name portion <bcp14>MU ST</bcp14> be
matched in a case-insensitive manner, in accordance with <xref target="URI"/>. matched in a case-insensitive manner, in accordance with <xref target="RFC3986"/
Note that the <tt>:</tt> character is a separator between the scheme name >.
and the rest of the URI, and thus does not need to be included in any Note that the colon ":" is a separator between the scheme name
and the rest of the URI and thus does not need to be included in any
comparison.</t> comparison.</t>
</section> </section>
<section anchor="outcome"> <section anchor="outcome">
<name>Outcome</name> <name>Outcome</name>
<t>If the client has found a presented identifier that matches a referen ce <t>If the client has found a presented identifier that matches a referen ce
identifier, then the service identity check has succeeded. In this case, the identifier, then the service identity check has succeeded. In this case, the
client <bcp14>MUST</bcp14> use the matched reference identifier as the validated identity of client <bcp14>MUST</bcp14> use the matched reference identifier as the validated identity of
the application service.</t> the application service.</t>
<t>If the client does not find a presented identifier matching any of th e <t>If the client does not find a presented identifier matching any of th e
reference identifiers, then the client <bcp14>MUST</bcp14> proceed as described as follows.</t> reference identifiers, then the client <bcp14>MUST</bcp14> proceed as follows.</ t>
<t>If the client is an automated application, <t>If the client is an automated application,
then it <bcp14>SHOULD</bcp14> terminate the communication attempt with a bad then it <bcp14>SHOULD</bcp14> terminate the communication attempt with a bad
certificate error and log the error appropriately. The application <bcp14>MAY</ bcp14> certificate error and log the error appropriately. The application <bcp14>MAY</ bcp14>
provide a configuration setting to disable this behavior, but it <bcp14>MUST NOT </bcp14> provide a configuration setting to disable this behavior, but it <bcp14>MUST NOT </bcp14>
disable this security control by default.</t> disable this security control by default.</t>
<t>If the client is one that is directly controlled by a human <t>If the client is one that is directly controlled by a human
user, then it <bcp14>SHOULD</bcp14> inform the user of the identity mismatch and user, then it <bcp14>SHOULD</bcp14> inform the user of the identity mismatch and
automatically terminate the communication attempt with a bad certificate automatically terminate the communication attempt with a bad certificate
error in order to prevent users from inadvertently bypassing security error in order to prevent users from inadvertently bypassing security
protections in hostile situations. protections in hostile situations.
Such clients <bcp14>MAY</bcp14> give advanced users the option of proceeding Such clients <bcp14>MAY</bcp14> give advanced users the option of proceeding
with acceptance despite the identity mismatch. Although this behavior can be with acceptance despite the identity mismatch. Although this behavior can be
appropriate in certain specialized circumstances, it needs to be handled with appropriate in certain specialized circumstances, it needs to be handled with
extreme caution, for example by first encouraging even an advanced user to extreme caution, for example by first encouraging even an advanced user to
terminate the communication attempt and, if they choose to proceed anyway, by terminate the communication attempt and, if they choose to proceed anyway, by
forcing the user to view the entire certification path before proceeding.</t> forcing the user to view the entire certification path before proceeding.</t>
<t>The application <bcp14>MAY</bcp14> also present the user with the abi lity to accept the <t>The application <bcp14>MAY</bcp14> also present the user with the abi lity to accept the
presented certificate as valid for subsequent connections. Such ad-hoc presented certificate as valid for subsequent connections. Such ad hoc
"pinning" <bcp14>SHOULD NOT</bcp14> restrict future connections to just the pinn ed "pinning" <bcp14>SHOULD NOT</bcp14> restrict future connections to just the pinn ed
certificate. Local policy that statically enforces a given certificate for a certificate. Local policy that statically enforces a given certificate for a
given peer <bcp14>SHOULD</bcp14> be made available only as prior configuration, rather than a given peer <bcp14>SHOULD</bcp14> be made available only as prior configuration r ather than a
just-in-time override for a failed connection.</t> just-in-time override for a failed connection.</t>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="security-wildcards"> <section anchor="security-wildcards">
<name>Wildcard Certificates</name> <name>Wildcard Certificates</name>
<t>Wildcard certificates automatically vouch for any single-label host n ames <t>Wildcard certificates automatically vouch for any single-label hostna mes
within their domain, but not multiple levels of domains. This can be within their domain, but not multiple levels of domains. This can be
convenient for administrators but also poses the risk of vouching for rogue convenient for administrators but also poses the risk of vouching for rogue
or buggy hosts. See for example <xref target="Defeating-SSL"/> (beginning at sli de 91) and or buggy hosts. For example, see <xref target="Defeating-SSL"/> (beginning at sl ide 91) and
<xref target="HTTPSbytes"/> (slides 38-40).</t> <xref target="HTTPSbytes"/> (slides 38-40).</t>
<t>As specified in <xref target="verify-domain"/>, restricting the prese nted identifiers in certificates to only one <t>As specified in <xref target="verify-domain"/>, restricting the prese nted identifiers in certificates to only one
wildcard character (e.g., "*.bigcompany.example" but not "*.*.bigcompany.example ") and wildcard character (e.g., "*.bigcompany.example" but not "*.*.bigcompany.example ") and
restricting the use of wildcards to only the left-most domain label can restricting the use of wildcards to only the left-most domain label can
help to mitigate certain aspects of the attack described in <xref target="Defeat ing-SSL"/>.</t> help to mitigate certain aspects of the attack described in <xref target="Defeat ing-SSL"/>.</t>
<t>That same attack also relies on the initial use of a cleartext HTTP c onnection, <t>That same attack also relies on the initial use of a cleartext HTTP c onnection,
which is hijacked by an active on-path attacker and subsequently upgraded to which is hijacked by an active on-path attacker and subsequently upgraded to
HTTPS. In order to mitigate such an attack, administrators and software HTTPS. In order to mitigate such an attack, administrators and software
developers are advised to follow the strict TLS guidelines provided in developers are advised to follow the strict TLS guidelines provided in
<xref section="3.2" sectionFormat="comma" target="TLS-REC"/>.</t> <xref section="3.2" sectionFormat="comma" target="RFC9325"/>.</t>
<t>Because the attack described in <xref target="HTTPSbytes"/> relies on an underlying <t>Because the attack described in <xref target="HTTPSbytes"/> relies on an underlying
cross-site scripting (XSS) attack, web browsers and applications are advised cross-site scripting (XSS) attack, web browsers and applications are advised
to follow best practices to prevent XSS attacks; see for example <xref target="X SS"/> to follow best practices to prevent XSS attacks; for example, see <xref target=" XSS"/>, which was
published by the Open Web Application Security Project (OWASP).</t> published by the Open Web Application Security Project (OWASP).</t>
<t>Protection against a wildcard that identifies a public suffix <t>Protection against a wildcard that identifies a public suffix
<xref target="Public-Suffix"/>, such as <tt>*.co.uk</tt> or <tt>*.com</tt>, is b eyond the scope of this <xref target="Public-Suffix"/>, such as <tt>*.co.uk</tt> or <tt>*.com</tt>, is b eyond the scope of this
document.</t> document.</t>
<t>As noted in <xref target="design"/>, application protocols can disall ow the use of <t>As noted in <xref target="design"/>, application protocols can disall ow the use of
wildcard certificates entirely as a more foolproof mitigation.</t> wildcard certificates entirely as a more foolproof mitigation.</t>
</section> </section>
<section anchor="security-uri"> <section anchor="security-uri">
<name>Uniform Resource Identifiers</name> <name>Uniform Resource Identifiers</name>
<t>The URI-ID type is a subjectAltName entry of type uniformResourceIden tifier <t>The URI-ID type is a subjectAltName entry of type uniformResourceIden tifier
as defined in <xref target="PKIX"/>. For the purposes of this specification, th e URI-ID as defined in <xref target="RFC5280"/>. For the purposes of this specification, the URI-ID
<bcp14>MUST</bcp14> include both a "scheme" and a "host" component that matches the "reg-name" <bcp14>MUST</bcp14> include both a "scheme" and a "host" component that matches the "reg-name"
rule; if the entry does not include both, it is not a valid URI-ID and <bcp14>MU ST</bcp14> be rule; if the entry does not include both, it is not a valid URI-ID and <bcp14>MU ST</bcp14> be
ignored. Any other components are ignored, because only the "scheme" and "host" ignored. Any other components are ignored because only the "scheme" and "host"
components are used for certificate matching as specified under <xref target="ve rify"/>.</t> components are used for certificate matching as specified under <xref target="ve rify"/>.</t>
<t>The quoted component names in the previous paragraph represent the as sociated <t>The quoted component names in the previous paragraph represent the as sociated
<xref target="ABNF"/> productions from the IETF standard for Uniform Resource Id <xref target="RFC5234"/> productions from the IETF Proposed Standard for Uniform
entifiers Resource Identifiers
<xref target="URI"/>. Although the reader should be aware that some application <xref target="RFC3986"/>. Although the reader should be aware that some applica
s (e.g., tions (e.g.,
web browsers) might instead conform to the Uniform Resource Locator (URL) web browsers) might instead conform to the Uniform Resource Locator (URL)
specification maintained by the WHATWG <xref target="URL"/>, it is not expected that specification maintained by the WHATWG <xref target="URL"/>, it is not expected that
differences between the URI and URL specifications would manifest themselves differences between the URI and URL specifications would manifest themselves
in certificate matching.</t> in certificate matching.</t>
</section> </section>
<section anchor="security-idn"> <section anchor="security-idn">
<name>Internationalized Domain Names</name> <name>Internationalized Domain Names</name>
<t>This document specifies only matching between reference identifiers a nd <t>This document specifies only matching between reference identifiers a nd
presented identifiers, not the visual presentation of domain names. More presented identifiers, not the visual presentation of domain names.
specifically, matching of internationalized domain names is performed on Specifically, the matching of internationalized domain names is performed on
A-labels only <xref target="verify"/>. The limited scope of this specification l A-labels only (<xref target="verify-domain"/>). The limited scope of this specif
ikely ication likely
mitigates potential confusion caused by the use of visually similar characters mitigates potential confusion caused by the use of visually similar characters
in domain names (as described for example in <xref section="4.4" sectionFormat=" comma" target="IDNA-DEFS"/>, in domain names (for example, as described in <xref section="4.4" sectionFormat= "of" target="RFC5890"/>,
<xref target="UTS-36"/>, and <xref target="UTS-39"/>); in any case, such concern s are a matter for <xref target="UTS-36"/>, and <xref target="UTS-39"/>); in any case, such concern s are a matter for
application-level protocols and user interfaces, not the matching of certificate s.</t> application-level protocols and user interfaces, not the matching of certificate s.</t>
</section> </section>
<section anchor="ip-addresses"> <section anchor="ip-addresses">
<name>IP Addresses</name> <name>IP Addresses</name>
<t>The TLS Server Name Indication (SNI) extension only conveys domain na mes. <t>The TLS Server Name Indication (SNI) extension only conveys domain na mes.
Therefore, a client with an IP-ID reference identity cannot present any Therefore, a client with an IP-ID reference identity cannot present any
information about its reference identity when connecting to a server. Servers information about its reference identity when connecting to a server. Servers
that wish to present an IP-ID therefore need to present this identity when a that wish to present an IP-ID therefore need to present this identity when a
connection is made without SNI.</t> connection is made without SNI.</t>
<t>The textual representation of an IPv4 address might be misinterpreted <t>The textual representation of an IPv4 address might be misinterpreted
as a valid as a valid FQDN in some contexts. This can result in different
FQDN in some contexts. This can result in different security treatment that migh security treatment that might cause different components of a system
t cause to classify the value differently, which might lead to
different components of a system to classify the value differently, which might vulnerabilities. Consider a system in which one component enforces a
lead security rule that is conditional on the type of identifier but
to vulnerabilities. For example, one system component enforces a security rule misclassifies an IP address as an FQDN, whereas a second component
that is conditional on the type of identifier. This component misclassifies an correctly classifies the identifier but incorrectly assumes that
IP address as an FQDN. A different component correctly classifies the rules regarding IP addresses have been enforced by the first
identifier but might incorrectly assume that rules regarding IP addresses have component. As a result, the system as a whole might behave in an
been enforced. Consistent classification of identifiers avoids this problem.</t insecure manner. Consistent classification of identifiers avoids
> this problem.</t>
<t>See also <xref target="design"/>, particularly the last paragraph.</t > <t>See also <xref target="design"/>, particularly the last paragraph.</t >
</section> </section>
<section anchor="security-multi"> <section anchor="security-multi">
<name>Multiple Presented Identifiers</name> <name>Multiple Presented Identifiers</name>
<t>A given application service might be addressed by multiple DNS domain names <t>A given application service might be addressed by multiple DNS domain names
for a variety of reasons, and a given deployment might service multiple for a variety of reasons, and a given deployment might service multiple
domains or protocols. TLS Extensions such as TLS Server Name Indication domains or protocols.
(SNI), discussed in <xref section="4.4.2.2" sectionFormat="comma" target="TLS"/> TLS extensions such as the Server Name Indication (SNI), as discussed in <xref s
, and Application Layer Protocol ection="3" sectionFormat="comma" target="RFC6066"/>, and ALPN, as discussed in <
Negotiation (ALPN), discussed in <xref target="ALPN"/>, provide a way for the ap xref target="RFC7301"/>, provide a way for the application
plication
to indicate the desired identifier and protocol to the server, which it to indicate the desired identifier and protocol to the server, which it
can then use to select the most appropriate certificate.</t> can then use to select the most appropriate certificate.</t>
<t>This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI-I Ds in a <t>This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI-I Ds in a
certificate. As a result, an application service can use the same certificate. As a result, an application service can use the same
certificate for multiple hostnames, such as when a client does not support certificate for multiple hostnames, such as when a client does not support
the TLS SNI extension, or for multiple protocols, such as SMTP and HTTP, on a the TLS SNI extension, or for multiple protocols, such as SMTP and HTTP, on a
single hostname. Note that the set of names in a certificate is the set of single hostname. Note that the set of names in a certificate is the set of
names that could be affected by a compromise of any other server named in names that could be affected by a compromise of any other server named in
the set: the strength of any server in the set of names is determined by the the set: the strength of any server in the set of names is determined by the
weakest of those servers that offer the names.</t> weakest of those servers that offer the names.</t>
<t>The way to mitigate this risk is to limit the number of names that <t>The way to mitigate this risk is to limit the number of names that
any server can speak for, and to ensure that all servers in the set any server can speak for and to ensure that all servers in the set
have a strong minimum configuration as described in Section 3.9 of <xref target= have a strong minimum configuration as described in <xref target="RFC9325" secti
"TLS-REC"/>.</t> onFormat="comma" section="3.9"/>.</t>
</section> </section>
<section anchor="multiple-reference-identifiers"> <section anchor="multiple-reference-identifiers">
<name>Multiple Reference Identifiers</name> <name>Multiple Reference Identifiers</name>
<t>This specification describes how a client may construct multiple acce ptable <t>This specification describes how a client may construct multiple acce ptable
reference identifiers and may match any of those reference identifiers with reference identifiers and may match any of those reference identifiers with
the set of presented identifiers. <xref section="4.2.1.10" sectionFormat="comma" target="PKIX"/> describes a the set of presented identifiers. <xref section="4.2.1.10" sectionFormat="comma" target="RFC5280"/> describes a
mechanism to allow CA certificates to be constrained in the set of presented mechanism to allow CA certificates to be constrained in the set of presented
identifiers that they may include within server certificates. However, these identifiers that they may include within server certificates. However, these
constraints only apply to the explicitly enumerated name forms. For example, constraints only apply to the explicitly enumerated name forms. For example,
a CA that is only name constrained for DNS-IDs is not constrained for SRV-IDs a CA that is only name-constrained for DNS-IDs is not constrained for SRV-IDs
and URI-IDs, unless those name forms are also explicitly included within the and URI-IDs, unless those name forms are also explicitly included within the
name constraints extension.</t> name constraints extension.</t>
<t>A client that constructs multiple reference identifiers of different types, <t>A client that constructs multiple reference identifiers of different types,
such as both DNS-ID and SRV-IDs, as described in <xref target="verify-reference- rules"/>, such as both DNS-IDs and SRV-IDs as described in <xref target="verify-reference- rules"/>,
<bcp14>SHOULD</bcp14> take care to ensure that CAs issuing such certificates are <bcp14>SHOULD</bcp14> take care to ensure that CAs issuing such certificates are
appropriately constrained. This <bcp14>MAY</bcp14> take the form of local policy through appropriately constrained. This <bcp14>MAY</bcp14> take the form of local policy through
agreement with the issuing CA, or <bcp14>MAY</bcp14> be enforced by the client r equiring agreement with the issuing CA or <bcp14>MAY</bcp14> be enforced by the client re quiring
that if one form of presented identifier is constrained, such as a dNSName that if one form of presented identifier is constrained, such as a dNSName
name constraint for DNS-IDs, then all other forms of acceptable reference name constraint for DNS-IDs, then all other forms of acceptable reference
identities are also constrained, such as requiring a uniformResourceIndicator identities are also constrained, such as requiring a uniformResourceIndicator
name constraint for URI-IDs.</t> name constraint for URI-IDs.</t>
</section> </section>
<section anchor="certificate-trust"> <section anchor="certificate-trust">
<name>Certificate Trust</name> <name>Certificate Trust</name>
<t>This document assumes that, if a client trusts a given CA, it trusts all <t>This document assumes that if a client trusts a given CA, it trusts a ll
certificates issued by that CA. The certificate checking process does not certificates issued by that CA. The certificate checking process does not
include additional checks for bad behavior by the hosts identified with include additional checks for bad behavior by the hosts identified with
such certificates, for instance rogue servers or buggy applications. Any such certificates, for instance, rogue servers or buggy applications. Any
additional checks (e.g., checking the server name against trusted block additional checks (e.g., checking the server name against trusted block
lists) are the responsibility of the application protocol or the client lists) are the responsibility of the application protocol or the client
itself.</t> itself.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no actions for IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC1034" to="DNS-CONCEPTS"/>
<displayreference target="RFC2782" to="DNS-SRV"/>
<displayreference target="RFC4592" to="DNS-WILDCARDS"/>
<displayreference target="RFC5890" to="IDNA-DEFS"/>
<displayreference target="RFC5891" to="IDNA-PROTO"/>
<displayreference target="RFC4514" to="LDAP-DN"/>
<displayreference target="RFC5280" to="PKIX"/>
<displayreference target="RFC4985" to="SRVNAME"/>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC9325" to="TLS-REC"/>
<displayreference target="RFC0791" to="IPv4"/>
<displayreference target="RFC4291" to="IPv6"/>
<displayreference target="RFC5234" to="ABNF"/>
<displayreference target="RFC8555" to="ACME"/>
<displayreference target="RFC7301" to="ALPN"/>
<displayreference target="RFC6698" to="DANE"/>
<displayreference target="RFC4343" to="DNS-CASE"/>
<displayreference target="RFC7858" to="DNS-OVER-TLS"/>
<displayreference target="RFC9147" to="DTLS"/>
<displayreference target="RFC6186" to="EMAIL-SRV"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC3403" to="NAPTR"/>
<displayreference target="RFC8915" to="NTS"/>
<displayreference target="RFC9001" to="QUIC"/>
<displayreference target="RFC4949" to="SECTERMS"/>
<displayreference target="RFC3261" to="SIP"/>
<displayreference target="RFC5922" to="SIP-CERTS"/>
<displayreference target="RFC5630" to="SIP-SIPS"/>
<displayreference target="RFC8689" to="SMTP-TLS"/>
<displayreference target="RFC8446" to="TLS"/>
<displayreference target="RFC9345" to="TLS-SUBCERTS"/>
<displayreference target="RFC9461" to="SVCB-FOR-DNS"/>
<displayreference target="RFC9460" to="SVCB-FOR-HTTPS"/>
<displayreference target="RFC6125" to="VERIFY"/>
<displayreference target="RFC6120" to="XMPP"/>
<displayreference target="RFC6066" to ="TLS-EXT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="DNS-CONCEPTS">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"
<title>Domain names - concepts and facilities</title> />
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"
"/> />
<date month="November" year="1987"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4592.xml"
<abstract> />
<t>This RFC is the revised basic definition of The Domain Name Sys <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"
tem. It obsoletes RFC-882. This memo describes the domain style names and their />
used for host address look up and electronic mail forwarding. It discusses the c <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5891.xml"
lients and servers in the domain name system and the protocol used between them. />
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4514.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"
<seriesInfo name="STD" value="13"/> />
<seriesInfo name="RFC" value="1034"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4985.xml"
<seriesInfo name="DOI" value="10.17487/RFC1034"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"
<reference anchor="DNS-SRV"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
<title>A DNS RR for specifying the location of services (DNS SRV)</t />
itle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen />
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"
<author fullname="P. Vixie" initials="P." surname="Vixie"/> />
<author fullname="L. Esibov" initials="L." surname="Esibov"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"
<date month="February" year="2000"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
<t>This document describes a DNS RR which specifies the location o />
f the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>
<reference anchor="DNS-WILDCARDS">
<front>
<title>The Role of Wildcards in the Domain Name System</title>
<author fullname="E. Lewis" initials="E." surname="Lewis"/>
<date month="July" year="2006"/>
<abstract>
<t>This is an update to the wildcard definition of RFC 1034. The i
nteraction with wildcards and CNAME is changed, an error condition is removed, a
nd the words defining some concepts central to wildcards are changed. The overal
l goal is not to change wildcards, but to refine the definition of RFC 1034. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4592"/>
<seriesInfo name="DOI" value="10.17487/RFC4592"/>
</reference>
<reference anchor="IDNA-DEFS">
<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="IDNA-PROTO">
<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="LDAP-DN">
<front>
<title>Lightweight Directory Access Protocol (LDAP): String Represen
tation of Distinguished Names</title>
<author fullname="K. Zeilenga" initials="K." role="editor" surname="
Zeilenga"/>
<date month="June" year="2006"/>
<abstract>
<t>The X.500 Directory uses distinguished names (DNs) as primary k
eys to entries in the directory. This document defines the string representation
used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguis
hed names. The string representation is designed to give a clean representation
of commonly used distinguished names, while being able to represent any distingu
ished name. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4514"/>
<seriesInfo name="DOI" value="10.17487/RFC4514"/>
</reference>
<reference anchor="PKIX">
<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="SRVNAME">
<front>
<title>Internet X.509 Public Key Infrastructure Subject Alternative
Name for Expression of Service Name</title>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<date month="August" year="2007"/>
<abstract>
<t>This document defines a new name form for inclusion in the othe
rName field of an X.509 Subject Alternative Name extension that allows a certifi
cate subject to be associated with the service name and domain name components o
f a DNS Service Resource Record. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4985"/>
<seriesInfo name="DOI" value="10.17487/RFC4985"/>
</reference>
<reference anchor="URI">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="TLS-REC">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are used to protect data exchanged over a wide range of application
protocols and can also form the basis for secure transport protocols. Over the
years, the industry has witnessed several serious attacks on TLS and DTLS, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion is largely complete, and TLS 1.3 is widely available. This document updates
the guidance given the new environment and obsoletes RFC 7525. In addition, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</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>
<reference anchor="IPv4">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="IPv6">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, te
xt representations of IPv6 addresses, definition of IPv6 unicast addresses, anyc
ast addresses, and multicast addresses, and an IPv6 node's required addresses.</
t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="ABNF">
<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="ACME">
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/>
<author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman
-Andrews"/>
<author fullname="D. McCarney" initials="D." surname="McCarney"/>
<author fullname="J. Kasten" initials="J." surname="Kasten"/>
<date month="March" year="2019"/>
<abstract>
<t>Public Key Infrastructure using X.509 (PKIX) certificates are u
sed for a number of purposes, the most significant of which is the authenticatio
n of domain names. Thus, certification authorities (CAs) in the Web PKI are trus
ted to verify that an applicant for a certificate legitimately represents the do
main name(s) in the certificate. As of this writing, this verification is done t
hrough a collection of ad hoc mechanisms. This document describes a protocol tha
t a CA and an applicant can use to automate the process of verification and cert
ificate issuance. The protocol also provides facilities for other certificate ma
nagement functions, such as certificate revocation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8555"/>
<seriesInfo name="DOI" value="10.17487/RFC8555"/>
</reference>
<reference anchor="ALPN">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl"/>
<author fullname="A. Popov" initials="A." surname="Popov"/>
<author fullname="A. Langley" initials="A." surname="Langley"/>
<author fullname="E. Stephan" initials="E." surname="Stephan"/>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
<reference anchor="DANE">
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transpo
rt Layer Security (TLS) Protocol: TLSA</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="J. Schlyter" initials="J." surname="Schlyter"/>
<date month="August" year="2012"/>
<abstract>
<t>Encrypted communication on the Internet often uses Transport La
yer Security (TLS), which depends on third parties to certify the keys used. Thi
s document improves on that situation by enabling the administrators of domain n
ames to specify the keys used in that domain's TLS servers. This requires matchi
ng improvements in TLS client software, but no change in TLS server software. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6698"/>
<seriesInfo name="DOI" value="10.17487/RFC6698"/>
</reference>
<reference anchor="DNS-CASE">
<front>
<title>Domain Name System (DNS) Case Insensitivity Clarification</ti
tle>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<date month="January" year="2006"/>
<abstract>
<t>Domain Name System (DNS) names are "case insensitive". This doc
ument explains exactly what that means and provides a clear specification of the
rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="4343"/>
<seriesInfo name="DOI" value="10.17487/RFC4343"/>
</reference>
<reference anchor="DNS-OVER-TLS">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</ti
tle>
<author fullname="Z. Hu" initials="Z." surname="Hu"/>
<author fullname="L. Zhu" initials="L." surname="Zhu"/>
<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="D. Wessels" initials="D." surname="Wessels"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="May" year="2016"/>
<abstract>
<t>This document describes the use of Transport Layer Security (TL
S) to provide privacy for DNS. Encryption provided by TLS eliminates opportuniti
es for eavesdropping and on-path tampering with DNS queries in the network, such
as discussed in RFC 7626. In addition, this document specifies two usage profil
es for DNS over TLS and provides advice on performance considerations to minimiz
e overhead from using TCP and TLS with DNS.</t>
<t>This document focuses on securing stub-to-recursive traffic, as
per the charter of the DPRIVE Working Group. It does not prevent future applica
tions of the protocol to recursive-to-authoritative traffic.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7858"/>
<seriesInfo name="DOI" value="10.17487/RFC7858"/>
</reference>
<reference anchor="DTLS">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="EMAIL-SRV">
<front>
<title>Use of SRV Records for Locating Email Submission/Access Servi
ces</title>
<author fullname="C. Daboo" initials="C." surname="Daboo"/>
<date month="March" year="2011"/>
<abstract>
<t>This specification describes how SRV records can be used to loc
ate email services. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6186"/>
<seriesInfo name="DOI" value="10.17487/RFC6186"/>
</reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="HTTP-OVER-TLS">
<front>
<title>HTTP Over TLS</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="May" year="2000"/>
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) t
o secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2818"/>
<seriesInfo name="DOI" value="10.17487/RFC2818"/>
</reference>
<reference anchor="NAPTR">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Three: The Do
main Name System (DNS) Database</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="October" year="2002"/>
<abstract>
<t>This document describes a Dynamic Delegation Discovery System (
DDDS) Database using the Domain Name System (DNS) as a distributed database of R
ules. The Keys are domain-names and the Rules are encoded using the Naming Autho
rity Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 291
5, it is the official specification for the NAPTR DNS Resource Record. It is als
o part of a series that is completely specified in "Dynamic Delegation Discovery
System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very importan
t to note that it is impossible to read and understand any document in this seri
es without reading the others. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3403"/>
<seriesInfo name="DOI" value="10.17487/RFC3403"/>
</reference>
<reference anchor="NTS">
<front>
<title>Network Time Security for the Network Time Protocol</title>
<author fullname="D. Franke" initials="D." surname="Franke"/>
<author fullname="D. Sibold" initials="D." surname="Sibold"/>
<author fullname="K. Teichel" initials="K." surname="Teichel"/>
<author fullname="M. Dansarie" initials="M." surname="Dansarie"/>
<author fullname="R. Sundblad" initials="R." surname="Sundblad"/>
<date month="September" year="2020"/>
<abstract>
<t>This memo specifies Network Time Security (NTS), a mechanism fo
r using Transport Layer Security (TLS) and Authenticated Encryption with Associa
ted Data (AEAD) to provide cryptographic security for the client-server mode of
the Network Time Protocol (NTP).</t>
<t>NTS is structured as a suite of two loosely coupled sub-protoco
ls. The first (NTS Key Establishment (NTS-KE)) handles initial authentication an
d key establishment over TLS. The second (NTS Extension Fields for NTPv4) handle
s encryption and authentication during NTP time synchronization via extension fi
elds in the NTP packets, and holds all required state only on the client via opa
que cookies.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8915"/>
<seriesInfo name="DOI" value="10.17487/RFC8915"/>
</reference>
<reference anchor="QUIC">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu
rner"/>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="SECTERMS">
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname="R. Shirey" initials="R." surname="Shirey"/>
<date month="August" year="2007"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanat
ions of terminology for information system security. The 334 pages of entries of
fer recommendations to improve the comprehensibility of written material that is
generated in the Internet Standards Process (RFC 2026). The recommendations fol
low the principles that such writing should (a) use the same term or definition
whenever the same concept is mentioned; (b) use terms in their plainest, diction
ary sense; (c) use terms that are already well-established in open publications;
and (d) avoid terms that either favor a particular vendor or favor a particular
technology or mechanism over other, competing techniques that already exist or
could be developed. This memo provides information for the Internet community.</
t>
</abstract>
</front>
<seriesInfo name="FYI" value="36"/>
<seriesInfo name="RFC" value="4949"/>
<seriesInfo name="DOI" value="10.17487/RFC4949"/>
</reference>
<reference anchor="SIP">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
<author fullname="A. Johnston" initials="A." surname="Johnston"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="R. Sparks" initials="R." surname="Sparks"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="E. Schooler" initials="E." surname="Schooler"/>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an a
pplication-layer control (signaling) protocol for creating, modifying, and termi
nating sessions with one or more participants. These sessions include Internet t
elephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="SIP-CERTS">
<front>
<title>Domain Certificates in the Session Initiation Protocol (SIP)<
/title>
<author fullname="V. Gurbani" initials="V." surname="Gurbani"/>
<author fullname="S. Lawrence" initials="S." surname="Lawrence"/>
<author fullname="A. Jeffrey" initials="A." surname="Jeffrey"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes how to construct and interpret certain
information in a PKIX-compliant (Public Key Infrastructure using X.509) certific
ate for use in a Session Initiation Protocol (SIP) over Transport Layer Security
(TLS) connection. More specifically, this document describes how to encode and
extract the identity of a SIP domain in a certificate and how to use that identi
ty for SIP domain authentication. As such, this document is relevant both to imp
lementors of SIP and to issuers of certificates. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5922"/>
<seriesInfo name="DOI" value="10.17487/RFC5922"/>
</reference>
<reference anchor="SIP-SIPS">
<front>
<title>The Use of the SIPS URI Scheme in the Session Initiation Prot
ocol (SIP)</title>
<author fullname="F. Audet" initials="F." surname="Audet"/>
<date month="October" year="2009"/>
<abstract>
<t>This document provides clarifications and guidelines concerning
the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It als
o makes normative changes to SIP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5630"/>
<seriesInfo name="DOI" value="10.17487/RFC5630"/>
</reference>
<reference anchor="SMTP-TLS">
<front>
<title>SMTP Require TLS Option</title>
<author fullname="J. Fenton" initials="J." surname="Fenton"/>
<date month="November" year="2019"/>
<abstract>
<t>The SMTP STARTTLS option, used in negotiating transport-level e
ncryption of SMTP connections, is not as useful from a security standpoint as it
might be because of its opportunistic nature; message delivery is, by default,
prioritized over security. This document describes an SMTP service extension, RE
QUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or
TLS-Required message header field is used when sending a message, it asserts a r
equest on the part of the message sender to override the default negotiation of
TLS, either by requiring that TLS be negotiated when the message is relayed or b
y requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based
Authentication of Named Entities (DANE) be ignored when relaying a message for
which security is unimportant.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8689"/>
<seriesInfo name="DOI" value="10.17487/RFC8689"/>
</reference>
<reference anchor="TLS">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="TLS-SUBCERTS">
<front>
<title>Delegated Credentials for TLS and DTLS</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/>
<author fullname="S. Iyengar" initials="S." surname="Iyengar"/>
<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="July" year="2023"/>
<abstract>
<t>The organizational separation between operators of TLS and DTLS
endpoints and the certification authority can create limitations. For example,
the lifetime of certificates, how they may be used, and the algorithms they supp
ort are ultimately determined by the Certification Authority (CA). This document
describes a mechanism to overcome some of these limitations by enabling operato
rs to delegate their own credentials for use in TLS and DTLS without breaking co
mpatibility with peers that do not support this specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9345"/>
<seriesInfo name="DOI" value="10.17487/RFC9345"/>
</reference>
<reference anchor="SVCB-FOR-DNS">
<front>
<title>Service Binding Mapping for DNS Servers</title>
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc
hwartz">
<organization>Meta Platforms, Inc.</organization>
</author>
<date day="26" month="June" year="2023"/>
<abstract>
<t> The SVCB DNS resource record type expresses a bound collecti
on of
endpoint metadata, for use when establishing a connection to a named
service. DNS itself can be such a service, when the server is
identified by a domain name. This document provides the SVCB mapping
for named DNS servers, allowing them to indicate support for
encrypted transport protocols.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
<seriesInfo name="Internet-Draft" value="draft-ietf-add-svcb-dns-09"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"
<reference anchor="SVCB-FOR-HTTPS"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"
<title>Service binding and parameter specification via the DNS (DNS />
SVCB and HTTPS RRs)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml"
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc />
hwartz"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4343.xml"
<organization>Google</organization> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"
<author fullname="Mike Bishop" initials="M." surname="Bishop"> />
<organization>Akamai Technologies</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"
</author> />
<author fullname="Erik Nygren" initials="E." surname="Nygren"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6186.xml"
<organization>Akamai Technologies</organization> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
<date day="11" month="March" year="2023"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3403.xml"
<t> This document specifies the "SVCB" and "HTTPS" DNS resource />
record <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"
(RR) types to facilitate the lookup of information needed to make />
connections to network services, such as for HTTP origins. SVCB <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"
records allow a service to be provided from multiple alternative />
endpoints, each with associated parameters (such as transport <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"
protocol configuration), and are extensible to support future uses />
(such as keys for encrypting the TLS ClientHello). They also enable <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"
aliasing of apex domains, which is not possible with CNAME. The />
HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5922.xml"
providing more information to the client before it attempts to />
establish a connection, these records offer potential benefits to <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5630.xml"
both performance and privacy. />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8689.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9345.xml"
/>
TO BE REMOVED: This document is being collaborated on in Github at: <!-- [SVCB-FOR-DNS] [I-D.ietf-add-svcb-dns] is now RFC 9461 -->
https://github.com/MikeBishop/dns-alt-svc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9461.xml"
(https://github.com/MikeBishop/dns-alt-svc). The most recent working />
version of the document, open issues, etc. should all be available
there. The authors (gratefully) accept pull requests. <!-- [SVCB-FOR-HTTPS] [I-D.ietf-dnsop-svcb-https] is now RFC 9460 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"
/>
<!--<reference anchor="I-D.ietf-dnsop-svcb-https" target="https://datatracker.ie
tf.org/doc/html/draft-ietf-dnsop-svcb-https-12">
<front>
<title>Service binding and parameter specification via the DNS (DNS SVCB and
HTTPS RRs)</title>
<author fullname="Benjamin M. Schwartz" initials="B." surname="Schwartz">
<organization>Google</organization>
</author>
<author fullname="Mike Bishop" initials="M." surname="Bishop">
<organization>Akamai Technologies</organization>
</author>
<author fullname="Erik Nygren" initials="E." surname="Nygren">
<organization>Akamai Technologies</organization>
</author>
<date day="11" month="March" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-12"/>
</reference>
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"
/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-1
2"/>
</reference>
<reference anchor="VERIFY">
<front>
<title>Representation and Verification of Domain-Based Application S
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
tificates in the Context of Transport Layer Security (TLS)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="J. Hodges" initials="J." surname="Hodges"/>
<date month="March" year="2011"/>
<abstract>
<t>Many application technologies enable secure communication betwe
en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX
) certificates in the context of Transport Layer Security (TLS). This document s
pecifies procedures for representing and verifying the identity of application s
ervices in such interactions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
</reference>
<reference anchor="XMPP">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</titl
e>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="March" year="2011"/>
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an app
lication profile of the Extensible Markup Language (XML) that enables the near-r
eal-time exchange of structured yet extensible data between any two or more netw
ork entities. This document defines XMPP's core protocol methods: setup and tear
down of XML streams, channel encryption, authentication, error handling, and com
munication primitives for messaging, network availability ("presence"), and requ
est-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6120"/>
<seriesInfo name="DOI" value="10.17487/RFC6120"/>
</reference>
<reference anchor="ALPACA" target="https://alpaca-attack.com/ALPACA.pdf" > <reference anchor="ALPACA" target="https://alpaca-attack.com/ALPACA.pdf" >
<front> <front>
<title>ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication</title> <title>ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication</title>
<author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann "> <author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann ">
<organization>Ruhr University Bochum</organization> <organization>Ruhr University Bochum</organization>
</author> </author>
<author initials="C." surname="Dresen" fullname="Christian Dresen"> <author initials="C." surname="Dresen" fullname="Christian Dresen">
<organization>Münster University of Applied Sciences</organization > <organization>Münster University of Applied Sciences</organization >
</author> </author>
<author initials="R." surname="Merget" fullname="Robert Merget"> <author initials="R." surname="Merget" fullname="Robert Merget">
<organization>Ruhr University Bochum</organization> <organization>Ruhr University Bochum</organization>
</author> </author>
<author initials="D." surname="Poddebniak" fullname="Damian Poddebni ak"> <author initials="D." surname="Poddebniak" fullname="Damian Poddebni ak">
<organization>Münster University of Applied Sciences</organization > <organization>Münster University of Applied Sciences</organization >
</author> </author>
<author initials="J." surname="Müller" fullname="Jens Müler"> <author initials="J." surname="Müller" fullname="Jens Müller">
<organization>Ruhr University Bochum</organization> <organization>Ruhr University Bochum</organization>
</author> </author>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y"> <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk y">
<organization>Paderborn University</organization> <organization>Paderborn University</organization>
</author> </author>
<author initials="J." surname="Schwenk" fullname="Jörg Schwek"> <author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
<organization>Ruhr University Bochum</organization> <organization>Ruhr University Bochum</organization>
</author> </author>
<author initials="S." surname="Schinzel" fullname="Sebastian Schinze l"> <author initials="S." surname="Schinzel" fullname="Sebastian Schinze l">
<organization>Ruhr University Bochum</organization> <organization>Ruhr University Bochum</organization>
</author> </author>
<date year="2021" month="September"/> <date year="2021" month="September"/>
</front> </front>
<refcontent>30th USENIX Security Symposium (USENIX Security 21)</refcon tent>
</reference> </reference>
<reference anchor="HTTPSbytes" target="https://media.blackhat.com/bh-ad- 10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf"> <reference anchor="HTTPSbytes" target="https://media.blackhat.com/bh-ad- 10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf">
<front> <front>
<title>HTTPS Can Byte Me</title> <title>HTTPS Can Byte Me</title>
<author initials="J." surname="Sokol" fullname="Josh Sokol"> <author initials="J." surname="Sokol" fullname="Josh Sokol">
<organization>SecTheory Ltd.</organization> <organization>SecTheory Ltd.</organization>
</author> </author>
<author initials="R." surname="Hansen" fullname="Robert Hansen"> <author initials="R." surname="Hansen" fullname="Robert Hansen">
<organization>SecTheory Ltd.</organization> <organization>SecTheory Ltd.</organization>
</author> </author>
<date year="2010" month="November"/> <date year="2010" month="November"/>
</front> </front>
<seriesInfo name="BlackHat" value="Abu Dhabi"/> <refcontent>Black Hat Briefings</refcontent>
</reference> </reference>
<reference anchor="Defeating-SSL" target="https://www.blackhat.com/prese ntations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf"> <reference anchor="Defeating-SSL" target="https://www.blackhat.com/prese ntations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf">
<front> <front>
<title>New Tricks for Defeating SSL in Practice</title> <title>New Tricks for Defeating SSL in Practice</title>
<author initials="M." surname="Marlinspike" fullname="Moxie Marlinsp ike"> <author initials="M." surname="Marlinspike" fullname="Moxie Marlinsp ike">
<organization/> <organization/>
</author> </author>
<date year="2009" month="February"/> <date year="2009" month="February"/>
</front> </front>
<seriesInfo name="BlackHat" value="DC"/> <refcontent>Black Hat DC</refcontent>
</reference> </reference>
<reference anchor="Public-Suffix" target="https://publicsuffix.org"> <reference anchor="Public-Suffix" target="https://publicsuffix.org">
<front> <front>
<title>Public Suffix List</title> <title>Public Suffix List</title>
<author> <author>
<organization/> <organization>Mozilla Foundation</organization>
</author> </author>
<date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="SECURE-CONTEXTS" target="https://www.w3.org/TR/secure -contexts/"> <reference anchor="SECURE-CONTEXTS" target="https://www.w3.org/TR/secure -contexts/">
<front> <front>
<title>Secure Contexts</title> <title>Secure Contexts</title>
<author initials="M." surname="West" fullname="Mike West"> <author initials="M." surname="West" fullname="Mike West">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date month="September" year="2021"/>
</front> </front>
<refcontent>W3C Candidate Recommendation Draft</refcontent>
</reference> </reference>
<reference anchor="US-ASCII"> <reference anchor="US-ASCII">
<front> <front>
<title>Coded Character Set - 7-bit American Standard Code for Inform ation Interchange</title> <title>Coded Character Sets - 7-bit American Standard Code for Infor mation Interchange (7-Bit ASCII)</title>
<author> <author>
<organization>American National Standards Institute</organization> <organization>American National Standards Institute</organization>
</author> </author>
<date year="1986"/> <date year="2007" month="June"/>
</front> </front>
<seriesInfo name="ANSI" value="X3.4"/> <seriesInfo name="ANSI INCITS" value="4-1986 (R2007)"/>
</reference> </reference>
<reference anchor="URL" target="https://url.spec.whatwg.org/"> <reference anchor="URL" target="https://url.spec.whatwg.org/">
<front> <front>
<title>URL</title> <title>URL</title>
<author initials="A." surname="van Kesteren" fullname="Anne van Kest eren"> <author initials="A." surname="van Kesteren" fullname="Anne van Kest eren">
<organization/> <organization/>
</author> </author>
<date year="2023"/> <date month="September" year="2023"/>
</front> </front>
<refcontent>WHATWG Living Standard</refcontent>
</reference> </reference>
<reference anchor="UTS-36" target="https://unicode.org/reports/tr36/"> <reference anchor="UTS-36" target="https://unicode.org/reports/tr36/">
<front> <front>
<title>Unicode Security Considerations</title> <title>Unicode Security Considerations</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="2014"/> <date month= "September" year="2014"/>
</front> </front>
<seriesInfo name="Unicode Technical Report" value="#36"/>
<refcontent>Revision 15</refcontent>
</reference> </reference>
<reference anchor="UTS-39" target="https://unicode.org/reports/tr39/"> <reference anchor="UTS-39" target="https://unicode.org/reports/tr39/">
<front> <front>
<title>Unicode Security Mechanisms</title> <title>Unicode Security Mechanisms</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="2022"/> <date month="September" year="2023"/>
</front> </front>
<seriesInfo name="Unicode Technical Standard" value="#39"/>
<refcontent>Version 15.1.0, Revision 28</refcontent>
</reference> </reference>
<reference anchor="X.509"> <reference anchor="X.509">
<front> <front>
<title>Information Technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title> <title>Information Technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title>
<author> <author>
<organization>International Telecommunications Union</organization > <organization>ITU-T</organization>
</author> </author>
<date year="2005"/> <date month="October" year="2019"/>
</front> </front>
<seriesInfo name="ITU-T" value="X.520"/> <seriesInfo name="ISO/IEC" value="9594-8"/>
<seriesInfo name="ITU-T Recommendation" value="X.509"/>
</reference> </reference>
<reference anchor="X.690"> <reference anchor="X.690">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>International Telecommunications Union</organization > <organization>ITU-T</organization>
</author> </author>
<date year="2008"/> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="ITU-T" value="X.690"/> <seriesInfo name="ISO/IEC" value="8825-1:2021 (E)"/>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference> </reference>
<reference anchor="WSC-UI" target="https://www.w3.org/TR/2010/REC-wsc-ui -20100812/"> <reference anchor="WSC-UI" target="https://www.w3.org/TR/2010/REC-wsc-ui -20100812/">
<front> <front>
<title>Web Security Context: User Interface Guidelines</title> <title>Web Security Context: User Interface Guidelines</title>
<author initials="A." surname="Saldhana" fullname="Anil Saldhana"> <author initials="A." surname="Saldhana" fullname="Anil Saldhana">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Roessler" fullname="Thomas Roessler"> <author initials="T." surname="Roessler" fullname="Thomas Roessler">
<organization/> <organization/>
</author> </author>
<date year="2010" month="August"/> <date year="2010" month="August"/>
</front> </front>
<seriesInfo name="W3C Recommendation" value="REC-wsc-ui-20100812"/>
</reference> </reference>
<reference anchor="XSS" target="https://owasp.org/www-community/attacks/ xss/"> <reference anchor="XSS" target="https://owasp.org/www-community/attacks/ xss/">
<front> <front>
<title>Cross Site Scripting (XSS)</title> <title>Cross Site Scripting (XSS)</title>
<author> <author>
<organization>OWASP</organization> <organization>Kirsten, S., et al.</organization>
</author> </author>
<date year="2022"/> <date year="2020"/>
</front>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9000"/> <refcontent>OWASP Foundation</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"
/>
</references> </references>
</references> </references>
<?line 1173?>
<section anchor="changes"> <section anchor="changes">
<name>Changes from RFC 6125</name> <name>Changes from RFC 6125</name>
<t>This document revises and obsoletes <xref target="VERIFY"/> based <t>This document revises and obsoletes <xref target="RFC6125"/> based
on the decade of experience and changes since it was published. on the decade of experience and changes since it was published.
The major changes, in no particular order, include:</t> The major changes, in no particular order, include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The only legal place for a certificate wildcard is as the complete l eft-most <li>The only legal place for a certificate wildcard is as the complete l eft-most
label in a domain name.</li> label in a domain name.</li>
<li>The server identity can only be expressed in the subjectAltNames <li>The server identity can only be expressed in the subjectAltNames
extension; it is no longer valid to use the commonName RDN, extension; it is no longer valid to use the commonName RDN,
known as <tt>CN-ID</tt> in <xref target="VERIFY"/>.</li> known as <tt>CN-ID</tt> in <xref target="RFC6125"/>.</li>
<li>Detailed discussion of pinning (configuring use of a certificate tha t <li>Detailed discussion of pinning (configuring use of a certificate tha t
doesn't match the criteria in this document) has been removed and replaced doesn't match the criteria in this document) has been removed and replaced
with two paragraphs in <xref target="outcome"/>.</li> with two paragraphs in <xref target="outcome"/>.</li>
<li>The sections detailing different target audiences and which sections <li>The sections detailing different target audiences and which sections
to read (first) have been removed.</li> to read (first) have been removed.</li>
<li>References to the X.500 directory, the survey of prior art, and the <li>References to the X.500 directory, the survey of prior art, and the
sample text in Appendix A have been removed.</li> sample text in Appendix A have been removed.</li>
<li>All references have been updated to the current latest version.</li> <li>All references have been updated to the latest versions.</li>
<li>The TLS SNI extension is no longer new, it is commonplace.</li> <li>The TLS SNI extension is no longer new; it is commonplace.</li>
<li>Additional text on multiple identifiers, and their security consider ations, <li>Additional text on multiple identifiers, and their security consider ations,
has been added.</li> has been added.</li>
<li>IP-ID reference identifiers are added. This builds on the definitio <li>IP-ID reference identifiers have been added. This builds on the def
n in <xref section="4.3.5" sectionFormat="of" target="HTTP"/>.</li> inition in <xref section="4.3.5" sectionFormat="comma" target="RFC9110"/>.</li>
<li>Shortened the document title because the previous title was difficul <li>The document title has been shortened because the previous title was
t to cite.</li> difficult to cite.</li>
</ul> </ul>
</section> </section>
<section anchor="contributors">
<name>Contributors</name>
<t>Jeff Hodges co-authored the previous version of these recommendations,
<xref target="VERIFY"/>.
The authors gratefully acknowledge his essential contributions to this work.</t>
<t>Martin Thomson contributed the text on handling of IP-IDs.</t>
</section>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>We gratefully acknowledge everyone who contributed to the previous <t>We gratefully acknowledge everyone who contributed to the previous
version of these recommendations, <xref target="VERIFY"/>. version of this specification <xref target="RFC6125"/>.
Thanks also to Carsten Bormann for converting the previous document Thanks also to <contact fullname="Carsten Bormann"/> for converting the previous
to Markdown so that we could more easily use Martin Thomson's <tt>i-d-template</ version of this specification to Markdown so that we could more easily use <con
tt> tact fullname="Martin Thomson's"/> <tt>i-d-template</tt>
software.</t> software.</t>
<t>In addition to discussion on the mailing list, the following people <t>In addition to discussions within the UTA Working Group, the following people
provided official reviews or especially significant feedback: provided official reviews or especially significant feedback:
Corey Bonnell, <contact fullname="Corey Bonnell"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Viktor Dukhovni, <contact fullname="Viktor Dukhovni"/>,
Lars Eggert, <contact fullname="Lars Eggert"/>,
Patrik Fältström, <contact fullname="Patrik Fältström"/>,
Jim Fenton, <contact fullname="Jim Fenton"/>,
Olle Johansson, <contact fullname="Olle Johansson"/>,
John Klensin, <contact fullname="John Klensin"/>,
Murray Kucherawy, <contact fullname="Murray Kucherawy"/>,
Warren Kumari, <contact fullname="Warren Kumari"/>,
John Mattson, <contact fullname="John Mattson"/>,
Alexey Melnikov, <contact fullname="Alexey Melnikov"/>,
Derrell Piper, <contact fullname="Derrell Piper"/>,
Ines Robles, <contact fullname="Maria Ines Robles"/>,
Rob Sayre, <contact fullname="Rob Sayre"/>,
Yaron Sheffer, <contact fullname="Yaron Sheffer"/>,
Ryan Sleevi, <contact fullname="Ryan Sleevi"/>,
Brian Smith, <contact fullname="Brian Smith"/>,
Petr Špaček, <contact fullname="Petr Špaček"/>,
Orie Steele, <contact fullname="Orie Steele"/>,
Martin Thomson, <contact fullname="Martin Thomson"/>,
Joe Touch, <contact fullname="Joe Touch"/>,
Éric Vyncke, <contact fullname="Éric Vyncke"/>,
Paul Wouters, <contact fullname="Paul Wouters"/>,
and and
Qin Wu.</t> <contact fullname="Qin Wu"/>.</t>
<t>A few descriptive sentences were borrowed from <xref target="TLS-REC"/> <t>A few descriptive sentences were borrowed from <xref target="RFC9325"/>
.</t> .</t>
</section>
<section anchor="contributors" numbered="false">
<name>Contributors</name>
<t><contact fullname="Jeff Hodges"/> coauthored the previous version of th
is specification <xref target="RFC6125"/>.
The authors gratefully acknowledge his essential contributions to this work.</t>
<t><contact fullname="Martin Thomson"/> contributed the text on the handli
ng of IP-IDs.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIADlZ1WQAA81923bbWJbY+/kKRH4oqRbJkmSX21bN9DQt2VPqtmW1KJer
1/SsCCSPRLRAgAOAklla/oA85B/mId8wT3lKJ/+VfT0XAJRd3VlJHqosksC5
7LPPvl+Gw6G5O0qemmxVHSVNta6bw/39l/uHZl7OinRpj5J5lV43w8w218N1
kw6r69nzg8Pvp1k9zNPG1o0pp3WZW/jzKMFfzCxtjpK6mZu6qWy6PEpOX1++
MavsyCTJrFyu0hn8/s3G1t/AF/V66r8rSvpqs6zsdR08U1ZN/E1TzqIPc7tq
FvDNM/wMK7TzutnkVp9psgY/TGx1l81scjq3BXy1SbIiuXw7Mel0Wtm77u8m
hfUfJePVKs9gU1lZ1Ob2HvZTNLYqbDM8QdCYdN0syurIDGE8WOP5KJmkWdEM
x8W8srAeBuM5QKhq/VJWN0fwEqzeFjgnAWhdNNXmKPkwgU92mWY5AnOFb/9O
/h1lS53sAifLf3GzXGSzhX5Do49vUxgjubSzRVHm5U1m622zVDW897uUXhjB
oZiirJaw7TuLJ3dyNhkevz87fn1+OYF53hwf7D99Jt9PLn6irw5/8+JQvvp4
+vbkeHxxws8++/4l/nB6cjYenrx+w19+/+Llvn55fvH+8r1+ewDfvj0Znw9P
zuTtA5zp/A+nP/Mjhy/wRZj1bPzuNT/y8sX38NWHi1P6+PTli+fwEQ53ePH6
mL56+RRQMyuuwz2NX529kRFpL+NjGe7F99/jcOO357yC3zzdx0WdjM/49+fP
X75QmIwnsoSnz57Kd+9/en0xhMn53Rff07P6+eXBs9/A59fvxqdvHeSeH9CC
f7y8PJeHDvblczza4YsDHO1sfH55wVt9to/TnsmpAPRw5X/8cCrb3qeVT14f
X76+eCen8fLZS/zulOd6evj8gD8Oj19fyDhwYIfyJfwn3z1/SnB/B4vS9bx4
/uIlQ5o/PnumgJ98eOWHe/n0GS5r8tPxq+Gb9xdwsvD96fBkRHQlnc+H9d1s
OpwXdfgUbj98Dn4uV/zkomlW+CzA5vTNnwSGhzjHz+/Oz/XzPh/i+HiMxw2k
Iq1uLFAaevvou+/SHChPOkybJp3dIs5/x0+PVvNrfoEpx44MEtKC5G26gRt9
XpVAgMo8OS6L63WNPwyTcZHmm1+y4iZJi3nyLmuyG3gHPh5XMFEthCcZA+VA
UsMD7tCMSk3wb7nk70bJqyorbpdpUdD3etvfpdVsXXd+pIt/sV5UyYcCML2q
kda9KmeL9TIc9niUnFS2tvGYx4sqq5ssLeIfacx3f/3vRY1kLBi3vGag2Hky
mWW2mBGBcZMAgXpnEejRJBfl1FZN/MtXrvpklJyX87mdFll6Gw16ki5x2Z1f
/9al/36Eb+W5raJpfm+Lmn5w33/lymG8Sbksq/Kuvt3EQ66r9C/dH2nc83Ru
q2lZFcHg7VFni3tbxMD4/V//o7rhX25/3TInNGBW/GLzaMSJnaaMGK2fvzTu
HMSEo+Rw//Bg+FJo2mS6QXmh904u7TxLR9McLsoibehSThdAIoYH+9/9mBaA
kt+9kh+H45Ph4f7B/pC/H07K2zJnqjE8TovhK5hl+M4O6zyb27p9qem5BJ5L
8DlAxm33jw4ORo4BXNaL6GsCw8TOLhe2rDbJ22Y+al0EXmXfRYh+2TaQwhH2
e3BA39S2An6OTO1I3iXI/IgC2Hi6Tk4W6TRD3mOvLdGf4WTyth/q9/f3McxX
dPsbFnvwBOaz4f7L74Dk5LCfVXZrv9PJhifH8NMw+GkYzdgG/Jm9Ty6rDAkh
sGO/ugSeRdJ4DkQSiOLW8wB6GMwVU8TyU2Z7fiWYfvNNBEdY8v7hF+F4coyi
x3oKZH84WV9fZ5/6AbiiR2p6YgTTReyD30/4/eQtENid+GrsM4/+cPEahazL
1z8D39x6TvdPcYLvLi++q+1sXdnhrASJ9FNTfxdOOqHfkC3Rb48A8yNK8REU
AXD+W39/UcKaDMeT49PTo3Cq43IONPR4keLBoZRrGxj+N8Np1iTjJQB3hlSj
AV6YVnN6mg7+VKUx4JkkU88WaXHTd+wsyupIZ/RKmrsha3gdSFOzbmyw4gMW
AvuOd3w2AUHx56ejZyQ0brkT6yof1Ss7G93Dpbi/IaCH24YXt0F1PEruYKV/
sMhzWnd+XBS2+6uDMkpzHy4nw6fPt6yqyGYAQVpNZVegG9XfNdXT5/HS+CFG
AqTHgAY1EMFK1JjtyHCS3mV1W8q4Db72j07W2U0B4G/hzmxh8/g3R7me6d5e
/qq9vXx8b+8sIk5WL/9f7YtE5Z9H3++/jK7Fb3mAEM2dHraB+d6D2pdMNoAE
y1ouQAm4MaMnh/wyMIHkJKvgyxL1NSFEt3ZDkiUIrlU2BbRPZsBGsmuUJOFu
VbDi+7K67YMHXSXWYPUaXdrcAslfIvQZPxDGZYyX+99vuUunlx+Gl0e4faJi
P4+ev9zvA8N2OIwnZ6ODBOSvco5coFrnKhsAUYT7x/vC10Bie5XWQElf68MX
+HCy++r1xd4AeXmJe8hbv8tYu6CP7BHcTlDELW7WWb0AwtUe7AQe+z8JuRdf
gtxzUoQ/To6HH06/huyjDPAdKLbD+3o2XGckA+2/ODiMrsk3H+00uv/IBuD2
wDp4F9fpzCb/vAaqAMySTSnbaNkkzedwxdIWHcvy+Bd54XIEco2t67bkfLko
l2kd/8ZA+oakmv0Xw4NDXMbPky3cr7xP6xVBAQAyFMg3m+9Ygau/+1THPHDn
uCrrOplkcCsmsypbkZixC+Pv9WlbdMI77z+OJ+ct/nxozHA4TNJp3SCPM+Zd
WsAVDLTBJrCwAC6n09wmzJ6TCEOSqW3uLVz85r5MyM6EJpnpJllaEAIRwy8r
+ANpn2iY7gx3QWfcS+6zZmHUBCUEAVjJBu9XBRJ6tZ41OOuHGvdKVCnZRdvJ
Xkgk6pG5XGR1Mi9n6yUsI6n5osFaVlU5s3MYgsUzoMMsCqo6CyJ+dr3BT6C9
Jpka02DlITxqNqbVBgS6ej1bAGrAklMibjB5a3ZnQ0TFncyII4b4MpvPc2vM
E8TZqpyvmTo+PMnw42f44QkIfU12l8r3S/fhM04CnDarMzwMQndYJC7agS9H
BMs3cETAHuuG4K8rhyfTJrHLVV7CUZsZKIpFM8Rf4VBA814AVjGoYYv3C7S8
pQk/ZfyRwzh4YgC5PvCM4NovABn0xaTvRdPzYrKm4314AJz4/HkAf5zIX3Bk
abJSq8R0neUAXkC3RVlbs/vwgKahz58BDek8k6JsCFftpxR2avcGBoS2BVzT
ulxa/FXoLoKN9/4NnKke+q4d3YwGyQ7+em+nNV40ANo0uyGrbrEZybg7ewii
HH8Fdsf3sIELUOPsQIZN310B6LwFUfQ+q+0gAYzEl9BuUtgbWBc9MggWlgii
wvrgJLtLB7B9U3uEzQr6BZkSIW+y8sw1uCmG0AAIT5LV9RrYBdzVNOK3TEQI
HMfjPR1XhHJZwNfc2HVwYx8e8Mp+/jxyfDPPNwOAcQISMCwpK25l5NrdQaQ8
ac2TEzbBbncq0K4qtG24je/QLcY16XkmOwI52J176odkWVYMHuB0c3udAakl
FpfC1zeg6RcJegAqWOJYbgecjAVpHA6WiQRfoRB1ku5MCcgEIFsBfOHkussF
RIRfcNuwCJhuCeuo0WYGAGEhaN2UKFbIN96mZuUcQoxqEx7al8VlRURvUd4L
DPFZGAfeoS25cU5pX7BcBFKawyJ1qMr+2xoktiW9jBiIzyWrtMIDGjAxTGtD
a+vBokwpD6FbRLMHISon6ZxBATJ9WfG0lsQaHHo50FP2tGAO4sdNYeFZPk1A
NtwnItMNnyry6fnXEGdU9kBVA2BV5dJ9TWPALMBpp3DA6wIUDsBkVutqQGYi
12JDnWY5nu7DkzT8/LlzQCAt4F0GuK1g6XbOp0pCIh1VCEMEWYrIU1bmLs2z
udBM4W10d4ObdYlgdjPRId6UcMyI48XGBCMPK4u4DgAtV3B5SyX4TbRW+LsG
Glc0NHaGdt5ZvgaAhEMl9aZo0k8DoLiNLWq6UYITBH/iRXCoGaFPZegx1K+R
Lq3r9Mby0QJQ5zmeIZABPzxud5U2iy6LTedzwO7aIk7CPaGp8HLXSrBym14n
OzBXonSCL224eCRHwZnImPR6d0A496yIlwegWNcExkTOx8bEdADLwKMoQUee
VWIXwlNe2Nmtyhz0KtpBkVuvme/iXEQs4WlEO2QuRY1kFfB/hRw7MrYPQm5c
E90yIdmyBITK9oCWsfj9HV5De4/7uyAlACAnoz08KeVXkUGA6N1l5ZpoSO24
EqJLqN4gF2d/BvJxWPud3Vi+w7j0ITDICoWLldjH+PItURJFF2tSO3MIXf0q
Y0DfWLjzALFfLDD9ukn09drs1tbidYSVZ5+SMa7Kr4AuF1DcNMvrvQ42Nemt
rQVt6ho3DegD/G0ONwAvYENSDSwDVatrpml2OSJoXJd5Xt7jYcKIKWx0uUyr
jXJqutkDFagiggK39QZxAnASbtlNs1BMq9CFSdRGAasLPTLm2+Q9IjxhELrn
4Dd8mhAWTiRLmaqup38BcW6cN2fwPUj/7noq3ZwTRIg0r9bVCsSpo2R+NsHH
RzjLGHcFN5SkTIvskRioHrFJWnOEBOAeWQmiJOBqlRGVEDaRABnN8Fpd2Lpc
VzPL3mkAaTVIsvMx30BP7YnbnOldJCepLvBjls9naIEDUkr6RYa3+J5eA46Q
rkFSBLjEWkJCpiOiRyCPygDhI8ifHZv3TwC7RjoD708dH14hFwFEuW6Gy7JG
6Xtqc5a9gjOhtZ6URGCEgDoKADheEbeiGfOyvE1yNFaGRwpTCloIvEHqOIb7
WaLlkIaH6zuZAVGAi1rjv6RGoIbhvs6Kof7SoqLkMBIaCpdLmXEggtHSUpLn
UMphVx/auSnWgI5JHpDd0UPIlFqgNx9R/q/sDQIU5sJxyHoBfwxE9KtVOVQu
X/upmxJ1OVRSUJFNAd+YE8+TklQYOK05ElMgFF39zY03MHwVEbGngF0E2WBL
xIjqBdADL2koMvJjhh6rgEjCPnLUaYH5ZSQVzcm0BaCkm1WV65sFay/XpCsQ
KzkDhbmsbs1ltgyMfg8PZ5cT4eI8Uc86EAuJrU8ZJIY0KiBIJGQ20ZpIbGUZ
ThX3xmniDho/GLz+LMPSFgmR4WeQxfArUXfwaqGiBcv8J/bC7+taDYsuXibh
q0/oIJweFoJHQQgGQm1wtoTYWe2FAtz4znW6zPLNThdjOkg1EIkwI4pL0kSS
KcM2scoi+hDJHVmsqXiSDG86gQp0HJQIMtHLQoOICjgYHfEqReSMfd/IyfFy
ojFOrtEuRlvsoWIL/wI7Qn20yZBkIyZGFGiKI5pSLtEukV04oxnojag0xdRK
NzEn0v/wQPoWjA94qqTa2SJrlvGdmFHT889fwmHuDZAdAdOrHdEECmSWJXoa
QSPKxU54R0tI6aBWFlB+Vq7zuQj3c5vDWaFcCbIOURDAVuPoA+0Lhc00OR4P
Rf2MhCW+IWQFcAEXchJ0V2cwQq3TOxMDLoDYNdPeFg3bGL2JqEYTjSI26Hht
bu9SHCcSCy+dUO4w2zyC2cDwCotUqIeAtkijYY04OkXkBx5inqKCCAAQn7Nk
RGfWIqlE6N+vCceV2JfrZlheBwQ/FFFI4Oc1lfwaPSeyQFuEI3Fj0qXJrAPC
MtUQk4RizRToMXG9P9gN7y3cK1ugEBHWDfpw2tYFRPoho0rNzgQa65hPG0YD
0A/XaPb1MEa+/t6vKa3by2ndmsgIKHjkR4PBxBBUXc9eHB7iTd5jDLabUngB
g60tn9FSVaTxVn7WPGoxiQTQiySFQXJ6rjoIGb5A2nEIxaKEKGJenczq2Zq0
oA8sViUqVyVesMJr/uHiFImCsHmkjiISNk7a2dAW7acV6VXzjuykIE4RRdi2
6C4bSYNMUlKHQgBmWcsuQgyWkOygxrFDwlOJDGYPt7lK0cPT4EL1QRhvB/T/
ahM9i+vjOwtsDERN0bkRwDplgKOVDFSDqLW0gkWR+uMtXasSWIMgUqTqAtFA
d5ZurgkvE9yOJPk2+RFlzlJgRazf6YLX6zzfDP9tDZ+JN0ai+u6bP56c1ezB
CUQV9a7QqTebFT6Jis3DA8bziSJD1kxvxFI8RMUGl3RJr8FzO7M8RfTYaeut
uGIm2jg9kC/GSaVnTqag1Sh0hEqg4vOlnTOOg4o7J0TJAmcZ4dsyu1k0cJ9o
/FBwjG2Rcg/L6iYtsl/4fYTeHp0m4nq+VgC0dSE8S+BbC6L9YjmaoXpP2gmb
PfnqI57md6IAtoYhNMdD6bNao0CWFXf4Mnx3h3opcGS7gusroFLdqtYjQoSM
nICk5eC99JwodG6jPOP0kZZZEsYKNPzQdaEaP3wiGZFl3qxBjSYPrfIwNau3
MFblwamggslV0SGmuBaRq+/RBsQTOGnc4VewFjpA8t5lzntHCEnnBgxf9Hyx
MPJPRAHYAJJvtpACcVlgnPV1c89cFKQWfIctCd6uID+wVTBAsZr42ZwAREye
rJ2zdZ5W251keEn52EVoHsAoDw/sBgUBixW1S7L4sqv44UnjPwGnfmVnKQqD
ZAKZ4cGsGuRVaqpLdgKbNzLw6wYdbyUan27gJjeoGBj2SZETJCu26EBoeBfd
AEk4HRaJmThrhVotrqw2uBtckcjpnRPsuRNH5igZuwsi+O28BeyDotXVziKN
JIQjBfTWAOTk3uDKYEGg092J6WwN4kNK/u2AqAxCuzj8REhPNAj5nPB14qka
k8AOmzSZViWGJMKdIrUs9Jj1bxDBeIfXk3Za6DWjnYEsRFZOAC4KOfU2N1n/
wEjsGXzipcgcC3fkpO88VT3WlSXovg5QFqnwFn8mCv0qg6iVl9EKHgaRumab
TUrMmxmpChMDopQoomiiAeg2HD2vfruCQs6Rc8E/nz+jJcPtCGDgP/CugyVn
Bd7SmVDfEBAIJHUoqNrtnTBI1U2iDrQOOyH/r3hk1PPFJBXhS44bRAyl2dEa
O8eDbJLuEJqHGntTstEvfAOXiTxiGhtHcImRr4RlSvG+uLdCVX/LApM3JWI4
XlvQDgukw2ylLO5sQTHA4V2PpJc2UPHgydaEQVx1I8INnujpyRHZNWNrH2Zc
EKvBAxHDIUveDJNIlaaxTs+/ZihnBHx8MECzrxnN2w/vUVHxZv1E4qTEojjo
zCb5GG5CQPqvmXCreZMDNPq3BFcIhcVKjEgk04uO+vCgNrEh/J9WQ5kj5oh0
1HqB9hzdVUxsv8o1S6yuZ0Utb5KQljowZ4mYQaPcPW2hdMQpGCn5wcPoscre
lUKR8qxukt3ji7d7bRGJ5U6yRMfsBGDR9r86ahIRjZhAKHkg+i/3HxkGkYu2
jQkWg8p9KH6Jz7+OPP790THEh7zDmNWL2FHKMqTYhQuiUWrx6eyMpMhQNqeL
y9byLAxqEE60FHpS0Mgi1TZuO9EuWSJXW+CcQspmTTQ5CTcpSGPCMEzHv90P
fiJg000IQ4IpCkrsuO3dLAmCDcugBSOv2kJop6xb8loYBuWKI9nIld5SqkIu
Cyu/QLEqu7Ot4Dm60bsXJ2d7sg2K5hN7hFtG5jymTupFUWKd5SiYDKd5Obv1
iisT1u48Nd/7hwfJDhugqYXGPqR7Hm1QLzyplEmvSska5Z6YjxTSoNCTur4d
IKU79ayDGCNRh2uEm8QkZMUK5PvphgSDxRrEVTzhCmWw4jq7IWMksBF/u0ga
EApCiODRxvuFUMZ4O+LrUS6nWeGsJ2l81HjSg+CoB4+ftRM3HURY3uSTjK6c
W1YkqdQCg1htm5Vk0SEdfoSKDIsqG1Hu8QxwUxUFHXVODcWsUEdC5F2mCJha
3Fbrgg/OYmwukr9CyfTULtK7rEQJqo8T9VC/PJ2pcr3NZ9czmP4kEr3GuxOB
9N5Egm4sThCVQj8MuohZtGDVJEmm5bqYiwUq5hc8uV8GrkFx3unhHer8Ta1v
DtjK3WNE+Kb2vsoE1pfP1aCCo/lL92x0MDocPWdVDQ3M61pMAqAYgLa4w+jD
8UY7TGcHO+LrDEhbVgfqN1u/yUzDZhc2dkpYNHv4Wd9j03Yjt00i+JQ1EVsh
kZ+d3QPjzW2gwdzXtqvZYMBsWWU3SKjfiGxQoz+JlOQURQrxs5YiFdIj4kUp
NBiPHhEl1MR8mWRLsSigLXVtMegAGTU5+VGFdDwTFW8nlbdspj+W92g8UScg
Xhr0AJAfK6nK3AYO4T4FyLAPQP3A6qqT+ZYpRVpIQFGt2Be4ENLrxrLeGTne
fmChnP3KYRyUN8jQ4hL5ENIgXjsJ7G42+g5wSw3qPgqHIKX+1Qg4A+AqDZEQ
vf60pBLBaFRaQykQAYC6AoYN1E1Zzp3XGC6qbYm2kj5LkifgkeEFqBSyw/HH
OwP4K07pHAQmCAyTxAR7/EPNfjsD8gjvsFVqZ8TeB/S4yRV692FyiS/gv8nZ
e/r74vUfP5xevD7Bvyc/jt++dX8YeWLy4/sPb0/8X/7N4/fv3r0+O+GX4dsk
+srsvBv/aYdxZ+f9+eXp+7Px250OjNmuXLKWBqBYoQVkjlwpcgy+Oj7/H/9+
8Azg958wc/ngAN1s/OHFwW+ewQcUakQQKcQpRDi9MaxNE2nC25KusiZFOwwG
pi7K+4JOFU1i/4KQ+dej5B+ms9XBs9/KF7jh6EuFWfQlwaz7TedlBmLPVz3T
OGhG37cgHa93/Kfos8I9+PIf/glD9JPhwYt/+q2hYGjmHRSFHeYkTzR2+eEJ
sdVu/EJdr5XdbjG2kENYeZMoAN7Ga1hwYjPzVTfQ92qPxAvvmEl2T8/vnuEF
hH+f75FoM93ERgom+kgTYYbaOZHROAwkKicagg7rwIAFnGCy7TcDO8izZSZW
wDYVjIQdQKjIg5M6Kw0HB5gwxPn03fhcqSQZVFYuvplk/Z0//+dsma5G4Q97
HJEN2jCg66lMAIpxMmQtpOg1oiNdVmmuEN1dPDT67sbMNOOujnyDDw+apQdX
rMKIDzUDL7IpAYUnDjJZsl+AV8n8FJXDlmPn9qPbnYyH8tvDgyvlQIL3ODpw
b2dKk2fDEhbYJIQD+gDQAPz8j0AI9n/z8oCc7/DswXN+2CCitB5+jg8/O8SH
xdkcyGusiaGRX6gSmXMqp/ykBn2lIEv6DYk9ukzKaZMqfQOqvEai8kY1JjSB
o0yJao9o7yEizZyLlcV5cjKFYh3A0HzLMS7fwrrYWu08h07Ad1EwdNe8gtAJ
I63WBYZAsEIxwDgONtCSEiF2XbKn4xozuOAzNIk7u2A3O4GceqydO3cly+O4
wG+zYtviTRx1LQ4hp7SGUHJRDOyD5qU7acxwjg9jvRuGj03VGPqNTTB6OUsM
LKYqGIjjdFNrji5URRynXuLeqpqDdNrBwigxrpcrhpqT02A3Joz0JguUOI27
0savQBahOtuwZF2gEbHKUIFpgVsMoiruoPDLprrrYFAHTwRTHusKnOvhrKIu
igsz4IkWOLpGvEOkM7SImJ2eVA6HKa1NJN8+ugVi8YF11qAmuX0jfCRpPlTH
RrgjZ/KVQY3bHPKeYDd6hb4WK4yGkGMwFduaxFaN8bNsD15XXVNwWotKUFMI
yFiJPE2NV4jgHB4yx4wWbOT9iueEB7QMC/ISyryCJvyNmLjQGxYPpBwknjB6
ik1I2RJ5UMrq/621K1E2AkhS8NEyQ+uCnnYrwlhNrOzeWapiI0GyzSK+CGyo
G5mz0h0x5u8NfVwh5/kF0VhcmOXzZ0MEFR6mXC82QN6Xxof6uTEcmqvaVVPQ
fWDBYZFJwKlh80TamAZ5YMU6vHqxMAXDzRJEx24wlYRSGRZpZVuRSa6OTMuS
S9Isf7dRE1qLdizR0ID5wcOmHGZLkYkI0CKmqp8Lfbqau3qzBg0EOQMBCxRh
2CXIUaKCBAGzycXJWaJCtbvAGA4hQmgQQiZogDlkmaRtNFUJBIlJ1hwEx7rm
qC346rqydki+BeTPe7Fbx2AtBTKiEi9YAiFac3xYVni1Qx2rqK/XIPKhL6yy
aU3KNsdUwPJrNVcHUcG0tZ5tme62OhKOutPEoY4WKOKvyJ0oCkd3z1fMmbvo
rgcBfv6RjoHLBQEErAYPhiL91XoQxqwubbMo52xzxsBoIvmrKJAEJSTOc1ii
WcObVWgcdeg6b27yvsDtzVpxrRrBNEXqA5NoBP0O1m0SYw/VVtkheLiYJgm2
3b242GOiyWZC0031UU87MDoXo9GS3DB0JuTSPn/LQ9fFOMHmqKYUMbKGKISI
DIOQTSlZIuoiD0jaoQky850HI160ZGegJR1jP2n1QuPICOfzkUyUIRYHAmcF
myr4dcJfF+YSBxOgJ9NHTvRME+RIPTxElcTERsXu5+BLIU9ShqPtxSHr3sND
XJ2LZffgWxgSRXRnoWJKoJSZD+d6TU41fAcwcbVCLFIsqCU+VUkeAdOKFdXv
qLCcakFWQIwUSU4oS6OtEJ+78LaHJ5zHoSpxLcepaXuYCteTKieWIm+Aj61N
Ehx/Tw95xoyMI3H184K3mQZlVTsy5LRp2cvNu/Gf4CRKlHw4DBzWR9IOGeDb
zFPEkNDmhZz8WgyLrtqCQ1cEXqzpEhEQCbylkxrWCbakeA/YQ5a1tyC8q3EC
G4swJvbpdlLoJNkPpQ8QR5LESwNk97Wf2C9ktgYW/aqtSc7I1q2hZCX3orIE
/RYpkkA1PCeZzPSlcyRhij8DouuwD13oXzg7EOPqmAlvPRnz5ZMRofDLJ2O+
4mS2h3wFCzdfWPgX4e7AbmjEL8Kct4i0YhwCFa8ZiLRpYM5318tnM7nSRlmx
xfWanF6j1ENnVJcD7zR+HPD9KVVkSd1yDio3+IPAHbVSXlqbiQ1yuIc8VZsA
XgWKlWZNybAxJRKO2QeEIhSKKHPvl9WETNXiPEAGrBFh+qoIDgyNHdQqgxhl
iYpG6xi5dhoWvTHhv5OgKcad9D7VoB++IGTaMV3soF0HZifyORN/DDaNMhVq
Ckw/nQ4Vup4Bi66zCvSahvOrNXIgoL7B0DilcUHpVDYADg9otphGdmisIXk6
hvdZUYPIlKN+2SyWQgWEMz0dHY4OBXU5eTq5COPwJ2yIdOVsH544GLSZnItG
ybxDnhkpxYmSB9K0UiWePJGCOMG4Q+LAMLpWregtg6Cxp7ERQs1ACAT0AmMm
lWZR9xtoNXDQkMtMlZgmTEIJXhu0wrVYWNBEKsOvdXCkz/4dpEl4EkdmG1dy
QQZHNW69XHNkBLlyODqFS52QpuLU6Pt0E2SqwI7WlLtv51xGweV2BQL/wagT
/UIERB1PLgMJ8SsKFTzsvim6oHtXTRTsE4XTQR8DBl0RWuAWSF3kQGFnimQO
5FROp/FhVDoxidzeAOyWFM1PZt3IblMGoTscdOJs2ziE8CFQmlPibqwLIf9a
ixy0NbSYo1SeIiF2cT2+UErbfe7iTUNegOsljMSlRGgWE3GgAqt1Lu7ptIlp
NwuMxkfptx39RCx3eNs76klRNzZcTst52FjHFtPMZC2dQJPOeSoolZAnSVs+
TLzbN1e/rBU0GCTrItdc/jjQCdeFbLQRAkyHQtSY02MWQcYlIDGXoSCt/Nn/
J6ehQIph4k9D0G7rWUxOz1FnqqNKEjgY/TSUtLu9wdcdlEwnfgwOEsbB6GpP
hdxoDqYzfdV1OcuIXLgYuW1OLRxM3f9thhvMImQYHo6L5MjCeiOnYx1FFx3b
p3zoM1NI8UJIgL3IYert89nPOFp0ds6muy2Mwbkh62x15fz++Km+om1VyVVj
8ysaZIISUN1OXdUC1xjEgllArL8xDvTdoPv/yzfo+x4OgIohA68Vr6jrYDow
EFAP2PeKmhcH1GrcLLqJ+AS0UouLnAWW1nDs7PP+BTgqzn4+fzhDZ3UJLppy
FTXAcO4Jl7eSy49XisQ+K3b/fNMOpSQ6wNFRJDrbyodpTDkUnFOWHXcPNCoE
QkRR2rmCmgDnUFe0D9JqOOyj4/AAcViuzxcyd0CWes2CcCxOiXSMEpVW6ESz
Ixlxw4JaV1Sft+ts1zoZztxYU5gd3bW7LDWqBqNBcL3ClETNmSHfjy+uIxc4
0BlUq+oWgaGE4qjgpNu2wJN1iJjTq7gBgua23YxCKBSMWgKEYKMVRtTSDsld
ep19svNQvcEJDvf3D47m0xdHR9/PrlCzEGX6HkSKjBNarzmg2Sk5MJH3QpHa
3KbjvCtKMtCtebcx2+zEm6MGGxNk7KhG1VkvyV/dulcxMMipNURKKi4OatoQ
xCKoxy65wh/CCIQrcUYg4+W3glJA1yI0V8vkCv2zvwtfJCbyJZxSkb6PGWkc
4lU4KtcL+3r0UWMJjtMJr6A1Gv6+jn+QmEXXaAFIPBUWkmQnRse6szyS4rtA
jI6D+iIEh3FXwrKHCKUhHOzuT+Xp+V7P2ZgrenAEZB6kZOuX6g9o4hEjPh7D
x7NlAHL2tWJ2kJbBAH/+B+CHR73v/XZkxo9f5PtQenKSC12xraM6yIeiUQj5
iBT0D9FCfpSFQ+s9ZzuBGoI+qxuq6Xn6rh/iS3I43YBS1APt03eP3oWedxHb
2jci2XIj+uZ2mWN/4xUAVP+0XK2GTFhG/StM5CHJoeh5CE/IeB0DadC9zXOm
Re50+nYgZgitNadGiONQcEMORw98vRmirfLXUsVEytnF+dCe/sYp94l6AFzo
6u7x5AKTvKP02M5UIqDLW620b4xLdxcAQNRrd3dqvbh25pw5J2XBJN7h0Tg0
tQbmJB9Sasx8i7bUlGYqub9s/Gvv6NEN8RUEqNv7WJ6pjXMCt727HFIi0/yQ
8PXuERaFzYaL1S05YV6kARlTLYdhKHDIhb+4t7QbF+LCpRSRRfxlRq3eW90e
G3c0/bYamOw6KsTVp4CEJzcILBhCHsN5KA6xHQMR1MJoH63TCJwFeNvE/fDW
OgFJEBGz6QNzj7Dz98Calu14qkAcBM7xDSUbqZsV86YRXTohHUT9XGU7NIMh
lV1X6Y2d/6BmYTLOLrmdDrM5F3HhfWM+ldqkxAQYUGl3eyUHGPCC8u1HzOl4
92gNJteFP9OodmWnZARfX0e8NXqT3TIbga5R6LplxKJ2lTZB9ZOe6C7RBZFS
uiG6c3IemmI91/710TE9OyeLuGTyoLUzqProalNtI2Y7U9Aoc6yiweRT75pL
kmPZycUshHI46aL5pu1H0rwngIIIscGPTNPiMWHOsumPSAx3KAIgiI+gTNG/
Nf6xKldP9V/8grhqvZ4uM0o0vWqbEkwkaBKT/MnVye40nnt4wgH/wB/HeK0W
cGmTHIsrDEKPO0c4SBJMzwbCSsywzZWtkEkqy/CWcKm6feQNyloJStgwcn1K
J6XiAd0MxZoqYZAseI258d6ig+pvZNnvyTzLHN2BFwaRw8in1OFA3hvgM4N8
ko63artyzypNNHW82HZl5x7zEtuKQ2BgfUG5JujKauotoEiRotV0/3HM/rTT
VjUTHPFa4mVSznIZceVvV9iUSuj3zegmTHvnijBGSynL2uLD6Im462QGcnBC
32UR4wvA7SxtgC7T45mv+EZZgrqZYI6BzyMUY6zgqVE7FEPeh37aT6tMarlw
bKKmPA+Cqq6tytIY8i8OqF/i2g5sOSYSa+eBiVMNIVwlzC1cSJzhIFFKzIvq
3T/iMNqE54NFC6JSbWF81rzE4dDL0VNWzLTDvp48kRqca05WS6mDEBeeVXSJ
ilcJdRk6bJICl+rOa//svHrBdSC7rs/69PQhsOb23g/OaKLX5yUV7/YNLvNN
HxJGyeaN1CXnsLvLhQS713050VFeKl7YR2mYcaIR68aS9UtR6VjwngMUOQ+3
CIrsiJEZvuOOYdj2hz1bYpvaixJ5AT7YXTPSWJxjIapUStA0C41CDqq2EIdT
k5dbtmfXLqW7FcdiwrQR2hnVfsIruNhgDSAsG09JLmjtWmHeIt+jKru5IXrg
kiOBIsuCEF7UlC0pOSUU1TVqpkGWZfaL8kWO05DDjBwXsL2hWIKeDOVt2UhC
dLZUBXdlHjVoEMO4ttBtLFtPSiAFTZxoDfQtDM9Fd7bKJUVhCZymLRFmtEc2
84VuXEdpmFpJbUBO06Z6fe7FuhXqQboTXx6sbvmVWxtwkWSAdmWDREes2Fw4
J7MUoYqjCMPGEWXMBeKgPEd8e9Q2KUpSS2YNEmNX2BXEc4xRRild4/7Y0uyM
7r6krkpnlUtTFc0xCL+WSkzBAKNkwlHAxJ2k2CXo75gbrDc+uoJVFNdLMKKi
mpixL2Kpz3IPc47WNV1Kt0vOFteaFlyd0Scz+OtnlyAxSmXL9j28J6kyxy6K
rkpvEbU04NwtWEy1WVHdUFALCptzKW923EshIMpaDRvKYb5lXB6WYpxwAXna
4FXdazF3IdVMf+HPJVy0O1egk8NdyKtTVetV4wilI6lo/p7d4pqD/YdlDVAU
wkwlzHu3risHYOFCgotYO9yj+NYoGJWJIharX6/6SlmlYUGAPjSFrZ5wRxEa
FagRS2lyMeCHQHBxJBhGLOPod7p/pOW4atQcvCZxWoP+K9u6eBooLSXiaDw4
x6qpueCUWDJ6xUOtQ4LNcSQhl8h10yqLTRgWxFGp+KVJV6PkA/svW4RYA2RT
hQ1zvyDRmUqLBdO2ZPEUQ18czZDwNGqAsZSlEG/v9YPQDh1yazAZ4LY0IaYI
CQoUDxcgBhgNleu7wKzTh/H/DZWWp3XgvSWjofJYjkjDsRptSrAV0DhAvwBS
2WWJ9wdHpELe8ak7rs5Yjx0AUABBE19Nlg3dvo8NmLHDS4k/S4d9kw94dLyZ
hombDIK0k10EeBPt79ougrA1EbIArrD7OPFnf7zbTlAKDXe9SithhiEhvmq7
AIx7nyQkF8AA4PjgzaKxxIHxDLv1XkzVd20NEtAqBxqztdxNy6LnCY1pycFf
lDIJ4WcYB8zJNRKrYVpxaZQl5qxSW+rVtTmqjy/30SBYbomdKghmNqVr+WGt
pLmbjSwRZimT58PcRdLwBaTE2NDrA44MU2GwSx8gYEixHk6DkJe/b9fqeKFd
h7G9rWjvLywtXJgLmpKVbX0nq+Mo2sEXHsVSTOduYHGRTmsrubhRa4hYXX50
XOEEVKq1/ymNaRKWEWUFSqezqDIU2h3w3iSa1LSb7sXBOYpTLGUHBba9dDDg
+L3d6Z5LPo6wNKjrFcn94SESbUridGbMwmzlvKlF1tmIXOHhov92mtgYwXFR
WcXZ01TThQDrFf68xBaSVMMX4x5jCVk7XSm0uMFaUJFTS0anfRUlY/felEru
q+KI75BujQxEhCtqXNJ2R3VD/sRskPYaclmDSpJXdPgNlrVDWkAYmFPRw8aV
naK2Jdm1+Zt2NYi9lkaM0AN1CzDw2TGw9bTiemZktggiZzqWiyCA5jKyeeoP
JASQYKwBt8i+fJHhQruIsaxgwlL1U+5aUtkF1m6iGu0HI7h3KDM7PVnwICgm
hC5hNhV4GVsCedCKdhX13O5EwXx3JZbWRUqqt1j8+wvHYUBX6K/dHlhz2F54
XP3ILerg5eFof3Q4Otj/Tf9KcE52p20jP1fBGFejoIUfKBR+VjIoBhP/i4/Z
Saez+b9eJQNvdY5h4YLZtq4gHuuKjb3jhBwHpJ2AyhVc4tbhYayNOzwfaMPl
X+kI40ATV7YALm43cmRPrgXtAXRhG9dNCxH+KAyI1nCXL4e10MXCobbFtCRb
YloSqsfbBxUcLWy9Rgp4NKucDMgS03TKKW8B6Y/oGpnehZDgkXcWMuCiYGmt
++ccj2BN94Hw2T0BZmRFHN70peAmVNLoZOgWYVSXkN/u+rSS/SNVWrYdqRNx
vN75DFGxN2Toy6iJ8UGCmDSCCWrfY5zgloicAAOdn/QRiuLCfJJfGebDEatY
Ta8/QqfFPFubw3AU3d3pu/bWesJYtl+s9q2SiE93sb4QRCNb8/ExQcgSYl/3
lYHaMClWyUl2Vz/DRFif92pLPA0OF88mZYI41ERTXAdb/EwNF52VpAwtntYn
+6BedK/GwMr+hSwjP0Q2oyPuEtaxEXH2k2qfIcPZAY7Sw3B2eCZu/qVzRanW
226Sozm0Gexq0c/SdkZb1tosMvgQWDQ9Lu8gLuNwLUzGXs8dyPyNq+29KpwU
H8Fty3O6DGou0FpIhg3TOFQibhX3SBqALlQ0wKzphvymDJcdBJTU3D+vLEh5
IhlMrL2Fh94RcjkJDDD2FmSu99IMQS82+lFCDePL6jK3skTbyMySZuF9ej3d
YsXDFMwobtuvctf2D2e+wldr2O2MXZ+Ta+yIqMZRVzN2AWcknYcf37CmUXbc
wUkwR70GVmQxlZhrpPYt3Dl7g4Twfo8cSi3sS1qVWRF1xhBVuG7KlUAe5x9h
bwXubIuxHoG1BfGidrUFnC3XedxF/DYS8VfH3umoTlcNWNs8ou0WIDj4PNGR
eZ1SWYaeR8X2GZQda5n44/xXFJa+zhK0taxP7zI0s4asmU7h7ogOcC1pXa7a
idTLfMT5FRQKenRmoCM0p8XCuU5OoPB08jUmQbF4S1XY0bgTlbEdsKpeSA+P
1CXZSHmQIYWp7LnS+hRD8XV7eMMnIWy430r5GLWljBx84CwA3/az86/RcxPn
+ecWAJ5FfFHkXmhYbN+yTNIvbj+GVl5uNIkPOhJ3L3zwQtD4vD/zicMkcrXR
UOeUOABJ4P24kUgzhPp8yUkbgjvAaYf40w7hhtKcToZZz8m0S0y3RmbrcNRS
gJuiJcx3XHwfx7UEC6HINBL/tWUXBecJk/R1JMODCyqxgOz18CAsjR/BWHWA
fqdPLNYcKQuU1XG7vl+SDyXw5SsjauN8R0yu5z6cx9X+knx8xiQnsUw37FuP
bTT1qNPSzJfN4Xg0chTjZe8uDa5o57g0rJKXF5V1sJ+aioPH5LBj4Cs9J4cZ
1TSgkie5Np4KXAy7fQirie7PXZL7Xsfe9pW6iJPfiKtwW45y+6Wl4R7JpXi8
QLqs5Qp3FVs4W5fee9OvJf+QCI8HQ1d9eswG7fhcqwtewGKJEzhFwGidA43Z
bqH66Cun6xq+e6eDp7TyQWvCbCWTPUYVMyfvoaBKQ5Na7rfT5s2Ys9CaCUbX
RvOOdCh1O2GgEfs4F0RwEq3ApFMdiO8U1wcKZRn0/88tN6SyKg56OQ3m41K5
QUheAOao6oaWE+AAH4n4YJqnneZM4C8TyyQKvlwZH9TbTjXXGEPahWa4ODB3
HQLSwfXOhcCwIVltPv1qp485ZgNnt1DKzp+/3ZFUaoGlocP0fqY0LO6bCyWn
cA847Z3ewig7o/h0XMF5PqaVXm0tYVu0OghSnC6KcMfvz45fn3OvVL0Dj5Xg
fcQhswMkUtmMCd7f8W43715Bs1iJpcOxOdmKBkUTGc1XbwAOn3Y6ZbTDgiDf
i7cr2IAGR7heR4+oAv3KkOmRJCVGk8M0RO6Xw5agmxBUAm+KdzcpWSyGMA9a
zcncTsWIA/WBEJJK6mu6mhzLePKaCvy+8ZVjBsnVx48fR6+ym2MxAbzuEH0Q
0G01nKUSmrHNDE5ukkCJ8V2hElIuuB95QNPI+TUP/JTSq6IU1w0lqPGc9MIA
e2yLB8cjt49bJBwHyWbd+IhTkAEdrgsctxUZSm4y9M/AM+X934u3XyQZ7Ygb
dYRjYWXSST9INWgTVYNWVTBcEYDHlY6WRG23/dazRrPECd2yJmhMV3OFoLZz
XWY/v3h/+R4pms5kFJV5OLbO92PmF8/f1zENqYmrNf0r0MBsR4Pk70ODoHJG
qz4GU/Lajb995P5TNz2Gxa+PT5c+YsgP+7DUiaaP8BEOIuLTUZODYeNoVEoR
fQZL27g8B1ZLncG7O7pPKeiZWRv6sYtQO5Fwb0+O8CucDpTb62ZI9YRplaEc
11ofWQttM2iJC/Ht1OA6DVGifL8bEK4l4c+tlqPl+kZxxZH58NQygHBgQFKE
et95qoLR276H+zR0gEWsdQtK4Y7739hiIeNeHR0NjBzWksWZc0EiKRU7CGNW
eqYyUbKOlNmUSH93ia/JbKOp4W4Yo3x1EDSuIaRkMKY51XVSKS+qyASYnyu4
0ejkW9jjXlRwDdl52Fzn6ehpVKjz4+nbk+PxxYk2ePeOeDLsknQ1t3fcNkdU
4ui9oF3W6AAHl7q5YaS6y7oVVi+hRA6WmMA1q0M4typDtHJDHc3pCOWsVKg1
qiOOg8YgVXdR+1PwulQjxG7sFYDlg6XFQMDY5VZON43L6+6guhYg8Q9GQS8U
2+KMZbGNTOCWdmsCK82gexkaVzpaN6xK67D3LU1tKP2GX9Q9AquxtACiwDpi
c2wHxVy5HeydIEsEidTHR3AflqcvXzz3aEEF59AAwpvDd59teRd/IoXV0Tms
gkyMDA+DaR2ZIQeiGXqDCJ/l9ph+9UyQGWOrvbDZRJ0AQaAJdVQqDh4Ufylc
hkCNJalxoURVmDwxAoU+ARe5HZ5xj1rZ03yFmol3ERoVUw5S8VVsl+FQW/Vi
1gfbymAnNs03CQnC7Rg74mwb6Xn7FfbJSNMcGPSYE5oH5juOwLTawUdv1CNC
KWJ8p6EJtwVsW38y37Timy9Edvk4sJY99yvKJahnDqvAXgFQAqduRwBGWPgO
Cu3Ge8XWPsW0mGAtwcytnKDemhWUqFejWw7IbL4ZmL4348UDMMM+YSbcBoY8
81Z6d7EdM3B5X7WLeC2hE1PvueGgnu2nFQ3wNdF9XuzacjkC+XZruRqVt9Rc
y93x2nrDEtMuqkFftG/Q1TmoHzlAlTqkSYxbV//5KqwuW0eW9WhdIhKFRY2l
f5DE2W3dfciIisDeHt9MUZfM37FvqVPq7ce0w6PWDlPFY2xFYpt7212UUfaH
uT6BGVnDN9e15xZBRkPUMhr7IzmJgCn3+3UzQ4v6w5OS//rsSyh4//U1tVzc
IlZLtWMR9nrRMIRzO0GU79yCUwxmVI6/U/e2fVc1CEEPpl8Hq9XXR33l5n5K
uLFb8H3U3r2DKSd5P+J1ZgFus022ekSZ5KwFFlO8TO79rJ1F8f2VdkNxLo9Y
vjLnxmZrLBenaHcWljZHGi0/TSPJNbFVRVIPaN8l82P5xgdaqNIRwfLd+E/G
sdQ4eBktZRpfiSWmMWWWzlkbknKiUOZpsoke89I3hu2WOde7uE5B0OqDErXT
kcCqMNwbX80134qaSxluV9UCHqsBqkpVcaYurGKZ1axLoioTt3/6dXCPiiMy
lJ2hjXvr3lnuN6DdP2DsOTX0KrhL1iqlDC0HITyBxvqeNChsY8dtIFprztQc
GSrgp/XYsIQhWlFAsrtLqbc9z4bLL50ZWVAVjZquwoS00wLUXWWy3w6EMK4y
xyiPm0V84OJrM2H0jpQwQtYplQ/JFjfLKpCLOS6rJgUPCZ0anbDlZi7qqkEv
HVJO4LCcJR+mSrni1djtFcupUHA02o/wVoW7pyLJX3GQWtOhocZOrkOBu9fF
BjTiAdq6YB0zlW5lhuQus+xHQZhFXXDIYZYCmLWWo4O+JIK3rh1rvOoxcnP4
6qiSs+vj6pFUeZoW1a7WiHt2QExrLBjAFTK0RQo1HETsnw8X5czsrLIC/R87
iW8F6VJTtcNFq8PKX9Zqeod3bUR/RsnbIOuA7zGWiZcLZvFusuePjX/t4mGp
4e9XNspvWaZIlu7SLCeyoqas3sZxUaEZg2sFzj+kfnNo+6mQwnHeO0ZA2XnY
lhfrnWiX1kQrt0mO9MMTvaZUhiD5qAaaVs2wHpuBMR/76+NH1OeuxHPRUkcc
I85GYE4d4/RH3wEoq1wPdK0Z6wrnUHRL7f0bzt0uN5cM4OyPpwnn2I+d0grK
qua8T8LKUj1TIH7cUhUJXCReBkr1L2/WZOqerm9uNtx7nnubx1mOJ8BXKatv
OJm8BTV2d2pvGO3Q0FTneCQvD6hxkuEeLxMyZeCj9GudPH0xfLa/xzmEvnox
uZVazuCBQ1+9s/3W57jmWu1qVgH/MT1mVO2f+edvewNF9QTw9/5HeHvttbWs
fX4ZsTk27GmJZ2gWNl+RoV6qSDnim9bc9l3YnuRgtjxxrQMhwoQnQQFJ/Aad
f2XzzLpCgNzNOnfdGIANWRDzMUOcyrD6i6T9ZADhFtlfUnLwcrPUVBoLFkOi
kTyZZYnFEyzY/3p1U6WcwGIII1jAdOzVbZxNHIUMNWjjMg1cXjcYiW/meC2w
HLxUdJ7fZeJrCxphC+3Dzs3YXIzqyUcxgoY6ZA8vXh9HNieCY1gkoR/2EXp7
AFOmt5aMMtwwjrJtxCOMoec/TyZ7bp9BEgzvMqroEGzP+O3Fbe1CKQWG1hpm
bNCNbzD8/PmzobLE2ksCd/h+BbQa+43H9iMhoOdVSYU2dt9/HE/O8fKeO/km
8La4yxYWtGPPOtdBTrCFWvYJ217T5+GEPuNVV/vW1bejWTla315RsWz8sLyi
hLip3ZSihAXV6uL2BGPSFvR8pL3S50FvCAxT0J5OK6a/BQqLB8yuJFntuixz
GA6zJxmHmfMgT/lQZCS8XmizsbgejmMt8H8xwondSQNP0paJV8IjNU5uzePr
8H50046s4AbjYshqFmGq2XXSrQ09UNUWzU9RbweyMWFwNqnFGkLesSNHCmkT
RekZNDT+oKEpvCGn4oXTaJcuqnwkgpB2BNIkeeB96oHCrKGNL/mijVyoKgQ/
EtT7U5Ic7YN3YVovu4qFUT1Dp26G/EsLlksZtc8iIf7bmtDRQ0fDPpSd3VGp
CbQ+AJFcLXxDEKY7Pqv64WH86uwNEBoOgpJCpZr0Sk34UDafI97ikh9DQKOW
kUgtQONGirvwJVqCzjYU+RcRJuajJqReey7hsm5sOtfoEo0e7awJRUy0uux+
uHi7Z2L/HrJJ8X4Ijfr44/jy4z+TWect3mqPI66uBmWKaVkiJIyhPQfD/vCw
4fV2U0sO3ABNNLu2LBJLaRHTKujqooz5mp92QhaCkK7oomfzotP73Iceecco
YpYuemuCwmOeTbK6ZPWa0urj3jKh93KUvKOelkGb4UEUsvNoNAaVI/IhOWVh
XDwFbSW4CGSg0ObnEeVuOXSxUkm+MSoOYI8+1K9RTmFvKHl907DslsgvvN18
4xpuBp7WrIjXvRuZeULeSNTSBY6Ejs9ngG14Zy4nw6fPiZ+QD5Q+v/z8ee8H
se+JvYwLuJVwbpXyb03mxnifsDcBSfcBS5JetJWv9hWcang6rdZIhIvOeQlo
S9QHBR8ph0ws5LSYK7B3J2enmBrfoCG1FM886RKbOsYTE3i1XY67xpb2pwCw
J0yqYdUcgb0xoVeXY036cmTQC0plCKNsYK3PgDov/SFBgVgCVYQfmUcL3uui
nTnW09Wsbs2Vht00sTMGKqmaFgOAEmK+pWd72W3s5UOss9p1htWKMsTODIXg
oYkF6aqUZ5IGpCSYSBdXRF9XZc3Z36jmy9JzW5qO2x75p9stzbS2V4mBbnWt
3RU4G8O9hmQgLPMGigHJnXfrvNDmS9iIKvaLUZlbHt/zusBG4FaOEoAJsi1d
PLxoJt3GbU7fdeMCUGUHJFuGflbxkCJwkbklPdCg6lBii/SjoCUmsCm7VFwU
S9zz8PR6KfyQfaY+OiEqk4+OJDNFEi4wQBmFrBA1BenoxL4xSETg78ps7goQ
l9PcLgEDURknVS4UbH3IhSqaGOrhxAmhDO/UmHDu2MYWcZQrZ2NED1tv+pxS
vmph2InaGSw6nSzZRHOXVpnlMnOuHTJLkDxTUIyaJ3DTycASrBWXuBsRjXut
ZMw34t5O+gyRvgHVblnXtYrJ8EJE8jnygNcY6kRv0w2MqV1czZm9KYFFMU0d
vz0/646M39JZOaM8Vp/qKTRjqI78XItZk02XSreHbpVi7oP4tUox7dM1JGkM
0g+ypUuPMhBlKNMdeQjaIEJrb1yBtifOiotjRefLtTO4boZWG6eKK662c7va
KF5Gdk8hVRts8+jiwsNGj52WBG4VLufFa4730gGw5TqSaEPyORFWnJ16vjfQ
LjxuYIdafmAs7UWAR4V/QCq+kcIPuowoSaXxMclO3I8rlWuWET0kvWwlHFsl
b6Bbs0adJFT0owS6J80zVdmRokU4AJkzZNAjtX7Y4qZZ6CvycFb0LLD2mQOu
6Om9TW+dtxNt6jyArJRKldNIIiYQi6S6aoFJh2gYWRwzMlL4QuXFejlln47f
vgmWiagAiJje4vGImzWutYsJ6bokvymjlTmozXuCFqTletnyg7Xbbnnbz0tc
kbMKuRgxxY7e+ra91ybO0/CF+9Kg4lFQ6N3Xr96elYzvqsNr449le1avCQ56
S5NYtg+ElA9D8Q72sfm220FqlhbrOmb10rd+Ph53rK4SfNxUUdBaewFRkIxe
mA3tTm0AYhrvqfLViiGpOeqdZmw0MlarwZORwVcAsYByXJCU4wwo76HVtTzF
bal4QqPRo+GukFpoWRNRP9s/C0U0rGxKhX3Xiw3PzC+A9QPk68FSXdyA9xGY
eCFN7YkYReCGhSyCMuoOw7ZEtl4HIhLVsRq4SDOy92hLTtiJo/PdpnVb6jeD
1qR+cCAlXP+1dYmPxzU1DiHnKelNkVulilyTrloYgVqEZXS80fB43FphPY99
V1Tu1YBMZO3SqS9kCJepj8fECXAszFoWoa1V3ZlDp7kBDGLINYm9OuW20Olg
xYOg/ur8bIKCSftYQ/QShzjSOSb3jDBbSl5r5f3MBjjVO7nbB1ZGbdkRWfwA
LbVvXb5jNVYAD/jZZbWum7Z1g6VlvuJR5Bz2sawb7zpE4Gf+2zyPInilrwyf
BWGMBD1ELSc0a0FLULqYLheO6VNvpUID7gid/84XLqdNzq+weRWR0g5yDuLq
tuRBc/zIedJCixnbKU13JeKRilJQAtbuk6QQQggKQO9bg5Fn9V6SVlpSvl0Y
uh1lE5ZS9mhtJNIRVYXkdHw2brlL28eKsUKYWB/0SsK34P3hcAgAhZXBQMfA
Lm407PvizXHy/ODwe9A0Zvx9xxSGltBa+pqU07rEnAaMmP3p9cXpmz8BN6JA
ayNa4tzOUEWHPaLlDxQLPAFqdizTgng2o9g+LGDsnB1cNWOZ/qWs9EkKHNPa
AlxEjhxTA6XBR7AvQjfiBjnoe7k0K+82E/ZZEHUnP8N5AE0S5DuEmtJIZ1JB
LYwqptm5opXoXMpdIy8Bp/MKX/jBWUgT7HUGQ7IlPej9hwEVZUEa0sXJGbb2
vS3KexKQro7P4LJfMYHXY6A1ntiG/e2i6GhwijiCd1XWwg/ew9hq1GO4nFfx
TVgmCHgKhvSnWhXc4cceod2UjaJYs3YunRjoKFzNUWyn6JTfmpeukXWfA/gK
7s5pI7jMgAmm1Q0ILOl6nrEFmTrtkGal7xmqE4fG8mSXQln2uOJTuDyazEmL
rn7Cz6Pv9/clGKqsNtJRag3nvWEegnQIUNGVhcRMbzZPkncWdgTKKCbjfkrG
W2Yd57nnCnXw0HrFkXiyFlD5acfUqZh6u4gwwVDq6EoxKhX2Xi3wjER0ErwA
T+Bo0WjMVzFkS+nLMLIsoD2IkO7gUyxSThNsLzyi7lIOYyQSg5Uj587zTa4x
bg8SZrLCPJjfQtmsqOUJtkwWJcZ4SREgR6zgVmIgU+Agdp4c/onKpgNKIUXh
qpUZqdfUN6MBwWmNHm1jfm+vYb5yfkPJHkPuF2Ln8ZByMELRSeCXNm4CpOh+
UlwSjVMnNyjtXq+ppswMLzZc2htgcAAVCuhW2zqvSIOC6OJhZRVY8DskiwUA
slzWkhtHz8oa9Xgp+kss09JnCzc79pNyvtnDk7T11WfzcCS6oJ3/4zfXILXY
bzDMxm5bPcr+G0lmihdURnAzvxZuaXFbs9QEIx2nFZrqkldosi4KaRZMuaZB
MAofkCtaDO8BwG7nSEFxGG4KLEo9eYxtWmcYEgGriUH7DRDcbDgfYkQbXsgr
o6EOUn0taGoTkt1CPANMxlAkGIggrLkxK1ui9cxFPZSIlhmZsTH0jWSVoMUx
dSxEOo0yn7VzZOhH5hgWvwFgYGn/fGAugGsVyQmooXl2PzA/ZbfoxTtZ3y7K
uyIbmLeYcvQaO3g0A3OewhHdJm/++t/yBqTJv/7HcmB+ny2TNwAyDDB5n8ON
+X0J8K8xE9vAn0XyhxyJDnx6B1QKNMM/gPgFVOF+MzAfU6Rb8M0yrTJ5/F3a
NPTyOLefYKXvbF5kt+XdwJxgQjtQxPMMBIUBgBKu2gXaVGvcxjSZpJsKFL8/
pRUGPCws8gH4ZYMh+rkFEA3MK+BI8GkJHAZ2Y5sq+V//vkr/53+1t7B4ED6S
SWMtao/xkeLSgIximNXA/PW/VNks+WlTzG4tgmSdJx+BM2l7GvNHeO/jmjQ5
7IPoygfcIbvCzE4k5dRgelpWFWjAc82oC0wV/xvwnUHEPdsAAA==
</rfc> </rfc>
 End of changes. 203 change blocks. 
1605 lines changed or deleted 536 lines changed or added

This html diff was produced by rfcdiff 1.48.