<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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.10) -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-uta-rfc6125bis-15" number="9525" submissionType="IETF" category="std" consensus="true" submissionType="IETF" obsoletes="6125" updates="" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.5 -->

  <front>
    <title abbrev="Service Identity">Service Identity in TLS">Service Identity in TLS</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-uta-rfc6125bis-15"/> name="RFC" value="9525"/>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>independent</organization>
      <organization>Independent</organization>
      <address>
        <postal>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>stpeter@stpeter.im</email>
      </address>
    </author>
    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <date year="2023" month="August" day="10"/>
    <area>Applications</area>
    <keyword>Internet-Draft</keyword> month="November"/>
    <area>art</area>
    <workgroup>uta</workgroup>

<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>
      <?line 197?>
<t>Many application technologies enable secure communication between two entities
by means of Transport Layer Security (TLS) with
Internet Public Key Infrastructure Using using X.509 (PKIX) certificates.
This document specifies
procedures for representing and verifying the identity of application services
in such interactions.</t>
      <t>This document obsoletes RFC 6125.</t>
    </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/uta/"/>.</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>
  <middle>
    <?line 208?>

<section anchor="intro">
      <name>Introduction</name>
      <section anchor="motivation">
        <name>Motivation</name>
        <t>The visible face of the Internet largely consists of services that employ a
client-server architecture in which a client
communicates with an application service.  When a client communicates with an
application service using <xref target="TLS"/>, target="RFC8446"/>, <xref target="DTLS"/>, target="RFC9147"/>, or a protocol built on those
(<xref target="QUIC"/> target="RFC9001"/> being a notable example),
it has some notion of the server's
identity (e.g., "the website at bigcompany.example") while attempting to establish
secure communication.  Likewise, during TLS negotiation, the server presents
its notion of the service's identity in the form of a public-key public key certificate
that was issued by a certificate certification authority (CA) in the context of the
Internet Public Key Infrastructure using X.509 <xref target="PKIX"/>. target="RFC5280"/>.  Informally, we can
think of these identities as the client's "reference identity" and the
server's "presented identity"; more formal definitions are given later.  A
client needs to verify that the server's presented identity matches its
reference identity so it can deterministically and automatically authenticate the communication.</t>
        <t>This document defines procedures for how clients do perform this verification.
It therefore also defines requirements on other parties, such as
the certificate certification authorities that issue certificates, the service administrators requesting
	them, and the protocol designers defining how things are named.</t> interactions between clients and servers.</t>
        <t>This document obsoletes RFC 6125. 6125 <xref target="RFC6125"/>. Changes from RFC 6125 <xref target="RFC6125"/> are described under <xref target="changes"/>.</t>
      </section>
      <section anchor="applicability">
        <name>Applicability</name>
        <t>This document does not supersede the rules for certificate issuance or
validation specified by <xref target="PKIX"/>. target="RFC5280"/>.  That document also governs any
certificate-related topic on which this document is silent.  This includes
certificate syntax, extensions such as name constraints or
extended key usage, and handling of certification paths.</t>
        <t>This document addresses only name forms in the leaf "end entity" server
certificate.  It does not address the name forms in the chain of certificates
used to validate a certificate, let alone creating nor does it create or checking check the validity
of such a chain.  In order to ensure proper authentication, applications need
to verify the entire certification path.</t>
      </section>
      <section anchor="overview">
        <name>Overview of Recommendations</name>
        <t>The previous version of this specification, <xref target="VERIFY"/>, target="RFC6125"/>, surveyed the then-current
practice from many IETF standards and tried to generalize best practices
(see Appendix A of <xref target="VERIFY"/> target="RFC6125"/> for details).</t>
        <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
length in the remainder of this document:</t>
        <ul spacing="normal">
          <li>Only check DNS domain names via the subjectAltName
extension designed for that purpose: dNSName.</li>
          <li>Allow use of even more specific
subjectAltName extensions where appropriate such as
uniformResourceIdentifier, iPAddress, and the otherName form SRVName.</li>
          <li>Wildcard support is now the default in certificates.
Constrain wildcard certificates so that the wildcard can only
be the complete left-most label of a domain name.</li>
          <li>Do not include or check strings that look like domain names
in the subject's Common Name.</li>
        </ul>
      </section>
      <section anchor="scope">
        <name>Scope</name>
        <section anchor="in-scope">
          <name>In Scope</name>
          <t>This document applies only to service identities that are used in TLS or DTLS
and that are included in PKIX certificates.</t>
          <t>With regard to TLS and DTLS, these security protocols are used to
protect data exchanged over a wide variety of application protocols,
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
Time Security <xref target="NTS"/>. target="RFC8915"/>.  The TLS handshake protocol can also be used
with different record layers to define secure transport protocols;
at present present, the most prominent example is QUIC <xref target="RFC9000"/>.  The
rules specified here are intended to apply to all protocols in this
extended TLS "family".</t>
          <t>With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in <xref target="PKIX"/>. target="RFC5280"/>.
In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) <xref target="DANE"/> target="RFC6698"/> sometimes use certificates based
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
modes.  Alternatively, a TLS peer could issue delegated credentials
that are based on a CA-issued certificate, as in <xref target="TLS-SUBCERTS"/>. target="RFC9345"/>.
In both cases, a TLS client could learn of a service identity
through its inclusion in the relevant certificate.  The rules specified
here are intended to apply whenever service identities are included in
X.509 certificates or credentials that are derived from such certificates.</t>
        </section>
        <section anchor="out-of-scope">
          <name>Out of Scope</name>
          <t>The following topics are out of scope for this specification:</t>
          <ul spacing="normal">
            <li>Security protocols other than those
described above.</li>
            <li>Keys or certificates employed outside the context of PKIX-based systems.</li>
            <li>Client or end-user identities.
Other than as described above, certificates representing client identities
	    (e.g., rfc822Name) are beyond the scope of this document.</li>
            <li>Identification of servers using other than a domain name, an IP address, or an SRV service name.
This document discusses Uniform Resource Identifiers <xref target="URI"/> target="RFC3986"/> only to the
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
"query" component) are the responsibility of specific protocols or URI
schemes.</li>
            <li>
              <t>Certification authority policies.
This includes items such as the following:  </t>
              <ul spacing="normal">
                <li>How to certify or validate fully-qualified fully qualified domain names (FQDNs) and application
service types (see <xref target="ACME"/> for some definition of this).</li>
                <li>Types target="RFC8555"/>).</li>
                <li>What types or "classes" of certificates to issue and whether to apply different
policies for them.</li>
                <li>How to certify or validate other kinds of information that might be
included in a certificate (e.g., organization name).</li>
              </ul>
            </li>
            <li>Resolution of DNS domain names.
Although the process whereby a client resolves the DNS domain name of an
application service can involve several steps, for the purposes of this
specification
specification, the only relevant consideration is that the client needs to
verify the identity of the entity with which it will communicate once the
resolution process is complete.  Thus, the resolution process itself is
out of scope for this specification.</li>
            <li>User interface issues.
In general, such issues are properly the responsibility of client
software developers and standards development organizations
dedicated to particular application technologies (see, for (for example, see
<xref target="WSC-UI"/>).</li>
          </ul>
        </section>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <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
for use in this specification.</t>
        <dl>
          <dt>application service:</dt>
          <dd>
            <t>A service on the Internet that enables clients to connect for the
purpose of retrieving or uploading information, communicating with other
entities, or connecting to a broader network of services.</t>
          </dd>
          <dt>application service provider:</dt>
          <dd>
            <t>An entity that hosts or deploys an application service.</t>
          </dd>
          <dt>application service type:</dt>
          <dd>
            <t>A formal identifier for the application protocol used to provide a
particular kind of application service at a domain.  This often appears as
a URI scheme <xref target="URI"/>, target="RFC3986"/>, a DNS SRV Service <xref target="DNS-SRV"/>, target="RFC2782"/>, or an ALPN Application-Layer Protocol Negotiation (ALPN) <xref target="ALPN"/> target="RFC7301"/>
identifier.</t>
          </dd>
          <dt>identifier:</dt>
          <dd>
            <t>A particular instance of an identifier type that is either presented by a
server in a certificate or referenced by a client for matching purposes.</t>
          </dd>
          <dt>identifier type:</dt>
          <dd>
            <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
conciseness and convenience, we define the following identifier types of
interest:
</t>
            <ul
       <dl spacing="normal">
              <li>DNS-ID: a
              <dt>DNS-ID:</dt><dd> A subjectAltName entry of type dNSName as defined in <xref target="PKIX"/>.</li>
              <li>IP-ID: a target="RFC5280"/>.</dd>
              <dt>IP-ID:</dt><dd> A subjectAltName entry of type iPAddress as defined in <xref target="PKIX"/>.</li>
              <li>SRV-ID: a target="RFC5280"/>.</dd>
              <dt>SRV-ID:</dt><dd> A subjectAltName entry of type otherName whose name form is
SRVName,
SRVName as defined in <xref target="SRVNAME"/>.</li>
              <li>URI-ID: a target="RFC4985"/>.</dd>
              <dt>URI-ID:</dt><dd> A subjectAltName entry of type uniformResourceIdentifier
as defined in <xref target="PKIX"/>. target="RFC5280"/>. See further discussion in <xref target="security-uri"/>.</li>
            </ul> target="security-uri"/>.</dd>
            </dl>
          </dd>
          <dt>PKIX:</dt>
          <dd>
            <t>The short name for the Internet Public Key Infrastructure using X.509
defined in <xref target="PKIX"/>. target="RFC5280"/>.  That document provides a profile of the X.509v3
certificate specifications and X.509v2 certificate revocation list (CRL)
specifications for use on the Internet.</t>
          </dd>
          <dt>presented identifier:</dt>
          <dd>
            <t>An identifier presented by a server to a client within a PKIX certificate
when the client attempts to establish secure communication with the server.
The certificate can include one or more presented identifiers of different
types, and if the server hosts more than one domain domain, then the certificate
might present distinct identifiers for each domain.</t>
          </dd>
          <dt>reference identifier:</dt>
          <dd>
            <t>An identifier used expected by the client when examining presented identifiers.
It is constructed from the source domain, and optionally domain and, optionally, an application
service type.</t>
          </dd>
          <dt>Relative Distinguished Name (RDN):</dt>
          <dd>
            <t>An ASN.1-based construction which itself that is itself a building-block component of
Distinguished Names. See <xref section="2" sectionFormat="comma" target="LDAP-DN"/>.</t> target="RFC4514"/>.</t>
          </dd>
          <dt>source domain:</dt>
          <dd>
            <t>The fully qualified domain name (FQDN) FQDN that a client expects an application
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 URL. The combination of a source domain and, optionally, an application
service type enables a client to construct one or more reference
identifiers. This specification covers FQDNs. Use of any names that
are not fully qualified is out of scope and may result in unexpected
or undefined behavior.</t>
          </dd>
          <dt>subjectAltName entry:</dt>
          <dd>
            <t>An identifier placed in a subjectAltName extension.</t>
          </dd>
          <dt>subjectAltName extension:</dt>
          <dd>
            <t>A standard PKIX extension enabling identifiers of various types to be
bound to the certificate subject.</t>
          </dd>
          <dt>subjectName:</dt>
          <dd>
            <t>The name of a PKIX certificate's subject, encoded in a certificate's
subject field (see <xref section="4.1.2.6" sectionFormat="comma" target="PKIX"/>).</t> target="RFC5280"/>).</t>
          </dd>
        </dl>
        <t>TLS uses the words "client" and "server," "server", where the client is the entity
that initiates the connection.  In many cases, this is consistent with common practice,
such as a browser connecting to a Web web origin.
For the sake of clarity, and to follow the usage in <xref target="TLS"/> target="RFC8446"/> and related
specifications, we will continue
to use the terms client and server in this document.
However, these are TLS-layer roles, and the application protocol
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
layer match the TLS layer.</t>
        <t>Security-related terms used in this document, but not defined here or in
<xref target="PKIX"/> target="RFC5280"/>, should be understood in the sense defined in <xref target="SECTERMS"/>. target="RFC4949"/>. Such
terms include "attack", "authentication", "identity", "trust", "validate",
	and "verify".</t>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>
</section>
    </section>
    <section anchor="names">
      <name>Identifying Application Services</name>
      <t>This document assumes that an application service is identified by a DNS domain
name (e.g., <tt>bigcompany.example</tt>), an IP address (IPv4 or IPv6), or by an identifier
that contains additional supplementary information.  Supplementary information
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>
      <t>In a DNS-ID - -- and in the DNS domain name portion of an SRV-ID or URI-ID - -- any
characters outside the range described in <xref target="US-ASCII"/> range are prohibited prohibited, and internationalized
domain labels are represented as A-labels <xref target="IDNA-DEFS"/>.</t> target="RFC5890"/>.</t>
      <t>An IP address is either a 4-octet IPv4 address <xref target="IPv4"/> target="RFC0791"/> or a 16-octet
IPv6 address <xref target="IPv6"/>. target="RFC4291"/>.  The identifier might need to be converted from a
textual representation to obtain this value.</t>
      <t>From the perspective of the application client or user, some identifiers are
<em>direct</em> because they are provided directly by a human user.  This includes
runtime input, prior configuration, or explicit acceptance of a client
communication attempt.  Other names are <em>indirect</em> because they are
automatically resolved by the application based on user input, such as a
target name resolved from a source name using DNS SRV or the records described in <xref target="NAPTR"/> records. target="RFC3403"/>.
The distinction matters most for certificate consumption, specifically
verification as discussed in this document.</t>
      <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
single certificate being used for both the HTTP and IMAP services at the host
"bigcompany.example".  Other identifiers are <em>restricted</em> because they can only be used for
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
issuance.</t>
      <t>We can categorize the
      <t>The four identifier types can be categorized as follows:</t>
      <ul spacing="normal">
        <li>A DNS-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 it is restricted.</li>
        <li>A URI-ID is direct and restricted.</li>
      </ul>
      <t>It is important to keep these distinctions in mind, mind because best practices
for the deployment and use of the identifiers differ.
Note that cross-protocol attacks such as those described in <xref target="ALPACA"/>
are possible when two
different protocol services use the same certificate.
This can be addressed by using restricted identifiers or deploying
services so that they do not share certificates.
Protocol specifications <bcp14>MUST</bcp14> specify which identifiers are
mandatory-to-implement
mandatory to implement and <bcp14>SHOULD</bcp14> provide operational guidance when necessary.</t>
      <t>The Common Name RDN <bcp14>MUST NOT</bcp14> be used to identify a service because
it is not strongly typed (essentially (it is essentially free-form text) and therefore
suffers from ambiguities in interpretation.</t>
      <t>For similar reasons, other RDNs within the subjectName <bcp14>MUST NOT</bcp14> be used to
identify a service.</t>
      <t>An IP address that is the result of a DNS query is not direct. indirect. Use of IP-IDs
that are not direct indirect is out of scope for this document.</t>
      <t>The IETF continues to define methods for looking up information needed
to make connections to network services. One recent example is service
binding via the "SVCB" and "HTTPS" DNS resource record (RR) types. This
document does not define any identity representation or verification procedures
that are specific to SVCB-compatible records, because the use of such records during
connection establishment does not currently alter any of the PKIX validation
requirements specified herein or in any other relevant specification.
For example,
the PKIX validation rules for <xref target="HTTP-OVER-TLS"/> target="RFC9110"/> and <xref target="DNS-OVER-TLS"/> target="RFC7858"/> do not change
when the client uses the DNS resource records defined in <xref target="SVCB-FOR-HTTPS"/> target="RFC9460"/> or <xref target="SVCB-FOR-DNS"/>. 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>
    </section>
    <section anchor="design">
      <name>Designing Application Protocols</name>
      <t>This section defines how protocol designers should reference this document,
      which would typically be a normative reference in their specification.
Its specification.</t>
      <t>A specification
<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 domain
names of application services, then its the specification <bcp14>MUST</bcp14> state that SRV-ID
as defined in this document is not supported.  Note that many existing
application technologies use DNS SRV records to resolve the DNS domain names
of application services, but they do not rely on representations of those records
in PKIX certificates by means of SRV-IDs as defined in <xref target="SRVNAME"/>.</t> target="RFC4985"/>.</t>
      <t>If the technology does not use URIs to identify application services, then
its
the specification <bcp14>MUST</bcp14> state that URI-ID as defined in this document is not
supported.  Note that many existing application technologies use URIs to
identify application services, but they do not rely on representation of those
URIs in PKIX certificates by means of URI-IDs.</t>
      <t>A technology <bcp14>MAY</bcp14> disallow the use of the wildcard character in presented identifiers. If
it does so, then the specification <bcp14>MUST</bcp14> state that wildcard certificates as
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
might use the same field without distinguishing the type of identifier, as identifier as, for
example
example, in the "host" components of a URI.  In this case, applications need to be aware that the textual
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
address, as is done by the "first-match-wins" algorithm in <xref section="3.2.2" sectionFormat="of" target="URI"/>.</t> target="RFC3986"/>.</t>
    </section>
    <section anchor="represent">
      <name>Representing Server Identity</name>
      <t>This section provides instructions for issuers of
certificates.</t>
      <section anchor="represent-rules">
        <name>Rules</name>
        <t>When a certificate certification authority issues a certificate based on the FQDN
at which the application service provider
will provide the relevant application, the following rules apply to
the representation of application service identities.
Note that some of these rules are cumulative
and can interact in important ways that are illustrated later in this
document.</t>
        <ol spacing="normal" type="1"><li>The certificate <bcp14>MUST</bcp14> include at least one identifier.</li>
          <li>The certificate <bcp14>SHOULD</bcp14> include a DNS-ID as a baseline
for interoperability.  This is not mandatory because
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>

<li>If the service using the certificate deploys a technology for which
the relevant specification stipulates that certificates should
include identifiers of type "SRV-ID" SRV-ID (e.g., this is true of the Extensible Messaging and Presence Protocol (XMPP) as described in <xref target="XMPP"/>), target="RFC6120"/>),
then the certificate <bcp14>SHOULD</bcp14> include an SRV-ID.  This
identifier type could supplement the DNS-ID, unless the certificate
is meant to be scoped to only the protocol in question.</li>
          <li>If the service using the certificate deploys a technology for which
the relevant specification stipulates that certificates should include
identifiers of type URI-ID (e.g., this is true of the Session Initiation Protocol <xref target="SIP"/> target="RFC3261"/> as specified by
<xref target="SIP-CERTS"/>), target="RFC5922"/>), then the certificate <bcp14>SHOULD</bcp14> include a URI-ID.  The scheme
<bcp14>MUST</bcp14> be that of the protocol associated with the application service type type,
and the "host" component <bcp14>MUST</bcp14> be the FQDN
of the service.  The application protocol specification
<bcp14>MUST</bcp14> specify which URI schemes are acceptable in URI-IDs contained in PKIX
certificates used for the application protocol (e.g., <tt>sip</tt> but not <tt>sips</tt>
or <tt>tel</tt> for SIP as described in <xref target="SIP-SIPS"/>). target="RFC5630"/>). Typically, this
identifier type would supplement the DNS-ID, unless the certificate
is meant to be scoped to only the protocol in question.</li>
          <li>The certificate <bcp14>MAY</bcp14> contain more than one DNS-ID, SRV-ID, URI-ID, or IP-ID
as further explained under in <xref target="security-multi"/>.</li>
          <li>The certificate <bcp14>MAY</bcp14> include other application-specific identifiers
for compatibility with a deployed base, especially identifiers for
types that were defined before publication of <xref target="SRVNAME"/> target="RFC4985"/> or for which
SRV service names or URI schemes do not exist. Such identifiers are out
of scope for this specification.</li>
        </ol>
      </section>
      <section anchor="represent-examples">
        <name>Examples</name>
        <t>Consider a simple website at <tt>www.bigcompany.example</tt>, <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
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
<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
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.example</tt>
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
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"/>) target="RFC6186"/>) along with DNS-IDs of <tt>isp.example</tt>
	and <tt>mail.isp.example</tt>.</t>

        <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>user@voice.college.example</tt> and identified by a URI of &lt;sip:voice.college.example&gt;.
A certificate for this service would include a URI-ID of
<tt>sip:voice.college.example</tt>
<tt>&lt;sip:voice.college.example&gt;</tt> (see <xref target="SIP-CERTS"/>) target="RFC5922"/>) along with a DNS-ID of
	<tt>voice.college.example</tt>.</t>
        <t>Consider an XMPP-compatible instant messaging (IM) server at the host
<tt>messenger.example</tt> servicing that services IM addresses of the form <tt>user@messenger.example</tt> and that is
discoverable via DNS SRV lookups on the <tt>messenger.example</tt> domain.  A
certificate for this service might include SRV-IDs of
<tt>_xmpp-client.messenger.example</tt> and <tt>_xmpp-server.messenger.example</tt> (see
<xref target="XMPP"/>), target="RFC6120"/>), as well as a DNS-ID of <tt>messenger.example</tt>.</t>
      </section>
    </section>
    <section anchor="request">
      <name>Requesting Server Certificates</name>
      <t>This section provides instructions for service providers regarding
the information to include in certificate signing requests (CSRs).
In general, service providers <bcp14>SHOULD</bcp14> request certificates that
include all the identifier types that are required or recommended for
the application service type that will be secured using the certificate to
be issued.</t>
      <t>A service provider <bcp14>SHOULD</bcp14> request certificates with as few identifiers as
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
service, the service provider <bcp14>SHOULD</bcp14> request a certificate that includes
DNS-ID or IP-ID values that identify that service 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
defined application service type.</t>
      <t>If the certificate might be used for any type of application service, then
the service provider <bcp14>SHOULD</bcp14> request a certificate that includes
only DNS-IDs or IP-IDs. Again, because of multiprotocol attacks attacks, this practice is
discouraged; this it can be mitigated by deploying only one service on
a host.</t>
      <t>If a service provider offers multiple application service types and wishes to
limit the applicability of certificates using SRV-IDs or URI-IDs, they it <bcp14>SHOULD</bcp14>
request that multiple certificates, certificates rather than a single certificate containing
multiple SRV-IDs or URI-IDs each identifying identify a different application service
type. This rule does not apply to application service type "bundles" that
identify distinct access methods to the same underlying application such as
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>submission</tt> as described in
<xref target="EMAIL-SRV"/>.</t> target="RFC6186"/>.</t>
    </section>
    <section anchor="verify">
      <name>Verifying Service Identity</name>
      <t>At a high level, the client verifies the application service's
identity by performing the following actions:</t>
      <ol spacing="normal" type="1"><li>The client constructs a list of reference identifiers it would find acceptable
based on the source domain and, if applicable, the type of service to
which the client is connecting.</li>
        <li>The server provides its presented identifiers in the form of a PKIX
certificate.</li>
        <li>The client checks each of its reference identifiers against the
server's presented identifiers for the purpose of finding a match. When checking a
reference identifier against a presented identifier, the client matches the
source domain of the identifiers and, optionally, their application service
type.</li>
      </ol>
      <t>Naturally, in addition to checking identifiers, a client should perform
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
matter of verifying the application service identity presented in a
certificate, methods for doing so are out of scope for
this document.</t>
      <section anchor="verify-reference">
        <name>Constructing a List of Reference Identifiers</name>
        <section anchor="verify-reference-rules">
          <name>Rules</name>
          <t>The client <bcp14>MUST</bcp14> construct a list of acceptable reference identifiers, identifiers
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 identifiers
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
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
retrieve a media object or script, or some other combination of information
that can yield a source domain and an application service type.</t>
          <t>This document does not precisely define how reference identifiers are generated.
Defining reference identifiers is the responsibility of applications or protocols that use this
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
process. For example, a protocol or application could specify that the application
service type is obtained through a one-to-one mapping of URI schemes to service
types or support that the protocol or application supports only a restricted set of URI schemes.
Similarly, it could
insist
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
a web page that was delivered over an authenticated and encrypted channel
(see for instance
(for instance, see <xref target="SECURE-CONTEXTS"/> with regard to the web platform).</t>
          <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),
then the client might end up communicating with an unexpected application
service.</t>
          <t>During the course of processing, a client might be exposed to identifiers 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
that need to be further resolved. Unless an application defines a process
for authenticating intermediate identifiers in a way that then allows
them to be used as a reference identifier (see for example (for example, see <xref target="SMTP-TLS"/>), target="RFC8689"/>),
any intermediate values are not reference
identifiers and <bcp14>MUST NOT</bcp14> be treated as such.
In the DNS case, not treating intermediate domain names as reference identifiers
removes DNS and DNS resolution from the attack surface.</t>
          <t>As one example of the process of generating a reference identifier, from the user
input of the URI &lt;sip:alice@college.example&gt; &lt;sip:alice@voice.college.example&gt;, a client could derive the application
service type <tt>sip</tt> from the URI scheme and parse the domain name <tt>college.example</tt>
	  from the host "host" component.</t>
          <t>Using the combination of FQDN(s) one or more FQDNs or IP address(es), addresses, plus optionally an application service type, the client
<bcp14>MUST</bcp14> construct its list of reference identifiers in accordance with the
following rules:</t>
          <ul spacing="normal">
            <li>If a server for the application service type is typically associated
with a URI for security purposes (i.e., a formal protocol document
specifies the use of URIs in server certificates), then the reference identifier
<bcp14>SHOULD</bcp14> be a URI-ID.</li>
            <li>If a server for the application service type is typically discovered
by means of DNS SRV records, then the reference identifier <bcp14>SHOULD</bcp14> be an SRV-ID.</li>
            <li>If the reference identifier is an IP address, the reference identifier is an
IP-ID.</li>
            <li>In the absence of more specific identifiers, the reference identifier is a DNS-ID.
A reference identifier of type DNS-ID can be directly constructed from a an
FQDN that is (a) contained in or securely derived from the inputs, inputs or
(b) explicitly associated with the source domain by means of user
configuration.</li>
          </ul>
          <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
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
that application service type.  By contrast, a more lenient client, even if
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>
        </section>
        <section anchor="verify-reference-examples">
          <name>Examples</name>
          <t>The following examples are for illustrative purposes only and are not
intended to be comprehensive.</t>
          <ol spacing="normal" type="1"><li>A web browser that is connecting via HTTPS to the website at
<tt>https://www.bigcompany.example/</tt>
<tt>&lt;https://www.bigcompany.example/&gt;</tt> would have a single reference identifier:
a DNS-ID of <tt>www.bigcompany.example</tt>.</li>
            <li>A web browser connecting to <tt>https://192.0.2.107/</tt> <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
to <tt>https://[2001:db8::abcd]</tt> , <tt>&lt;https://[2001:db8::abcd]&gt;</tt>, it would have a single IP-ID
reference identifier of <tt>2001:db8::abcd</tt>.</li>
            <li>A mail user agent that is connecting via IMAPS to the email service at
<tt>isp.example</tt> (resolved as <tt>mail.isp.example</tt>) might have three reference
identifiers: an SRV-ID of <tt>_imaps.isp.example</tt> (see <xref target="EMAIL-SRV"/>), target="RFC6186"/>) and
DNS-IDs of <tt>isp.example</tt> and <tt>mail.isp.example</tt>.  An email user agent that
does not support <xref target="EMAIL-SRV"/> target="RFC6186"/> would probably be explicitly configured to
connect to <tt>mail.isp.example</tt>, whereas an SRV-aware user agent would derive
<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 reference
identifiers for the service.</li>
            <li>A voice-over-IP (VoIP) VoIP user agent that is connecting via SIP to the voice
service at <tt>voice.college.example</tt> might have only one reference identifier:
a URI-ID of <tt>sip:voice.college.example</tt> (see <xref target="SIP-CERTS"/>).</li> target="RFC5922"/>).</li>
            <li>An instant messaging (IM) IM client that is connecting via XMPP to the IM
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"/>), target="RFC6120"/>), a DNS-ID of
<tt>messenger.example</tt>, and an XMPP-specific <tt>XmppAddr</tt> of <tt>messenger.example</tt>
(see <xref target="XMPP"/>).</li> target="RFC6120"/>).</li>
          </ol>
          <t>In all these cases, presented identifiers that do not match the reference
identifier(s) would be rejected; for instance:</t>
          <ul spacing="normal">
            <li>With regard to the first example example, a DNS-ID of "web.bigcompany.example" <tt>web.bigcompany.example</tt> would
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.example" &lt;sip:www.college.example&gt;
would be rejected because the DNS domain name portion does not match
"voice.college.example"
"voice.college.example", and a DNS-ID of "voice.college.example" would be
rejected because it lacks the appropriate application service type
portion (i.e., it does not specify a "sip:" URI).</li>
          </ul>
        </section>
      </section>
      <section anchor="verify-seek">
        <name>Preparing to Seek a Match</name>
        <t>Once the client has constructed its list of reference identifiers and has
received the server's presented identifiers,
the client checks its reference identifiers against the presented identifiers
for the purpose of finding a match.
The search fails if the client exhausts
its list of reference identifiers without finding a match.  The search succeeds
if any presented identifier matches one of the reference identifiers, at
which point the client <bcp14>SHOULD</bcp14> stop the search.</t>
        <t>Before applying the comparison rules provided in the following
sections, the client might need to split the reference identifier into
components.
Each reference identifier produces either a domain name or an IP address and
optionally an application service type as follows:</t>
        <ul spacing="normal">
          <li>A DNS-ID reference identifier <bcp14>MUST</bcp14> be used directly as the DNS domain
name
	  name, and there is no application service type.</li>
          <li>An IP-ID reference identifier <bcp14>MUST</bcp14> be exactly equal to match the value of a an
iPAddress entry in subjectAltName, with no partial (e.g., network-level) matching. There is no application service type.</li>
          <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
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
<tt>imaps</tt>, which maps to the IMAP application protocol as explained in
<xref target="EMAIL-SRV"/>.</li> target="RFC6186"/>.</li>
          <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
service type portion is the scheme, as defined above.  Matching only the
"reg-name" rule from <xref target="URI"/> target="RFC3986"/> limits the additional domain name validation
(<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
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 the
"reg-name" might necessitate normalization of the URI (as explained in
<xref section="6" sectionFormat="of" target="URI"/>). target="RFC3986"/>).  For example, a URI-ID of <tt>sip:voice.college.example</tt> <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 application
service type of <tt>sip</tt> (associated with an application protocol of SIP as
explained in <xref target="SIP-CERTS"/>).</li> target="RFC5922"/>).</li>
        </ul>
        <t>If the reference identifier produces a domain name, the client <bcp14>MUST</bcp14> match the
DNS name; see <xref target="verify-domain"/>.
If the reference identifier produces an IP address, the client <bcp14>MUST</bcp14> match the IP
address; see <xref target="verify-ip"/>.
If an application service type is present present, it <bcp14>MUST</bcp14> also match the
service type as well; type; see <xref target="verify-app"/>.</t>
      </section>
      <section anchor="verify-domain">
        <name>Matching the DNS Domain Name Portion</name>
        <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
the domain to be checked is an
internationalized domain name, as defined in <xref target="names"/>, or not.
For clients
that support presented identifiers containing the wildcard character "*", this section
also specifies a supplemental rule for such "wildcard certificates".
This section uses the description of labels and domain names in
	<xref target="DNS-CONCEPTS"/>.</t> target="RFC1034"/>.</t>
      <t>If the DNS domain name portion of a reference identifier
	is a "traditional not an internationalized domain name" name
	(i.e., a an FQDN that conforms to "preferred name syntax" as
described in <xref section="3.5" sectionFormat="of" target="DNS-CONCEPTS"/>), target="RFC1034"/>),
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
a case-insensitive ASCII comparison, as clarified by <xref target="DNS-CASE"/>. target="RFC4343"/>.  For
example, <tt>WWW.BigCompany.Example</tt> would be lower-cased to <tt>www.bigcompany.example</tt> for
comparison purposes.  Each label <bcp14>MUST</bcp14> match in order for the names to be
considered to a match, except as supplemented by the rule about checking of
wildcard labels in presented identifiers given below.</t>
        <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
<xref target="IDNA-DEFS"/> target="RFC5890"/> in the domain name to A-labels before checking the domain name
or comparing it with others.  In accordance with <xref target="IDNA-PROTO"/>, target="RFC5891"/>, A-labels
<bcp14>MUST</bcp14> be compared as case-insensitive ASCII.  Each label <bcp14>MUST</bcp14> match in order
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>
        <t>If the technology specification supports wildcards in presented identifiers, then the client <bcp14>MUST</bcp14>
match the reference identifier against a presented identifier whose DNS
domain name portion contains the wildcard character "*" in a label label, provided
these requirements are met:</t>
        <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>
        </ol>
        <t>If the requirements are not met, the presented identifier is invalid and <bcp14>MUST</bcp14>
be ignored.</t>
        <t>A wildcard in a presented identifier can only match exactly one label in a
reference identifier.  This specification covers only wildcard characters in
presented identifiers, not wildcard characters in reference identifiers or in
DNS domain names more generally.  Therefore, the use of wildcard characters
as described herein is not to be confused with DNS wildcard
matching, where the "*" label always matches at least one whole label and
sometimes more; see <xref section="4.3.3" sectionFormat="comma" target="DNS-CONCEPTS"/> target="RFC1034"/> and <xref target="DNS-WILDCARDS"/>. target="RFC4592"/>.
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
certificates, see <xref target="security-wildcards"/>.</t>
      </section>
      <section anchor="verify-ip">
        <name>Matching an IP Address Portion</name>
        <t>An
        <t>Matching of an IP-ID matches is based on an octet-for-octet comparison of the bytes of the
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 both the
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"/>). target="RFC0791"/>).
If the resulting octets are equal, the IP address matches.</t>
        <t>This document does not specify how an SRV-ID reference identity can include an
IP address, as <xref target="SRVNAME"/> target="RFC4985"/> only defines string names, not octet identifiers
such as an IP address.</t>
      </section>
      <section anchor="verify-app">
        <name>Matching the Application Service Type Portion</name>
        <t>The rules for matching the application service type depend on whether
the identifier is an SRV-ID or a URI-ID.</t>
        <t>These identifiers provide an application service type portion to be checked,
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  Consider the example of a messaging client that has two reference
identifiers includes
identifiers: (1) an SRV-ID of <tt>_xmpp-client.messenger.example</tt> and (2) a DNS-ID
of <tt>app.example</tt>, the <tt>app.example</tt>.  The client <bcp14>MUST</bcp14> check both (1) the combination of (a) an
application service type of <tt>xmpp-client</tt> and (b) a DNS domain name of
<tt>messenger.example</tt> and, separately, as well as (2)
a DNS domain name of <tt>app.example</tt>.  However, the
client <bcp14>MUST NOT</bcp14> check the combination of an application service type of
<tt>xmpp-client</tt> and a DNS domain name of <tt>app.example</tt> because it does not
have an SRV-ID of <tt>_xmpp-client.app.example</tt> in its list of reference
identifiers.</t>
        <t>If the identifier is an SRV-ID, then the application service name <bcp14>MUST</bcp14>
be matched in a case-insensitive manner, in accordance with <xref target="DNS-SRV"/>. target="RFC2782"/>.
Note that, that per <xref target="SRVNAME"/>, target="RFC4985"/>, the <tt>_</tt> character underscore "_" is part of the service name in
DNS SRV records and in SRV-IDs.</t>
        <t>If the identifier is a URI-ID, then the scheme name portion <bcp14>MUST</bcp14> be
matched in a case-insensitive manner, in accordance with <xref target="URI"/>. target="RFC3986"/>.
Note that the <tt>:</tt> character colon ":" is a separator between the scheme name
and the rest of the URI, URI and thus does not need to be included in any
comparison.</t>
      </section>
      <section anchor="outcome">
        <name>Outcome</name>
        <t>If the client has found a presented identifier that matches a reference
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
the application service.</t>
        <t>If the client does not find a presented identifier matching any of the
reference identifiers, then the client <bcp14>MUST</bcp14> proceed as described as follows.</t>
        <t>If the client is an automated application,
then it <bcp14>SHOULD</bcp14> terminate the communication attempt with a bad
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>
disable this security control by default.</t>
        <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
automatically terminate the communication attempt with a bad certificate
error in order to prevent users from inadvertently bypassing security
protections in hostile situations.
Such clients <bcp14>MAY</bcp14> give advanced users the option of proceeding
with acceptance despite the identity mismatch.  Although this behavior can be
appropriate in certain specialized circumstances, it needs to be handled with
extreme caution, for example by first encouraging even an advanced user to
terminate the communication attempt and, if they choose to proceed anyway, by
forcing the user to view the entire certification path before proceeding.</t>
        <t>The application <bcp14>MAY</bcp14> also present the user with the ability to accept the
presented certificate as valid for subsequent connections.  Such ad-hoc ad hoc
"pinning" <bcp14>SHOULD NOT</bcp14> restrict future connections to just the pinned
certificate. Local policy that statically enforces a given certificate for a
given peer <bcp14>SHOULD</bcp14> be made available only as prior configuration, configuration rather than a
just-in-time override for a failed connection.</t>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <section anchor="security-wildcards">
        <name>Wildcard Certificates</name>
        <t>Wildcard certificates automatically vouch for any single-label host names hostnames
within their domain, but not multiple levels of domains.  This can be
convenient for administrators but also poses the risk of vouching for rogue
or buggy hosts. See for example For example, see <xref target="Defeating-SSL"/> (beginning at slide 91) and
<xref target="HTTPSbytes"/> (slides 38-40).</t>
        <t>As specified in <xref target="verify-domain"/>, restricting the presented identifiers in certificates to only one
wildcard character (e.g., "*.bigcompany.example" but not "*.*.bigcompany.example") and
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="Defeating-SSL"/>.</t>
        <t>That same attack also relies on the initial use of a cleartext HTTP connection,
which is hijacked by an active on-path attacker and subsequently upgraded to
HTTPS.  In order to mitigate such an attack, administrators and software
developers are advised to follow the strict TLS guidelines provided in
<xref section="3.2" sectionFormat="comma" target="TLS-REC"/>.</t> target="RFC9325"/>.</t>
        <t>Because the attack described in <xref target="HTTPSbytes"/> relies on an underlying
cross-site scripting (XSS) attack, web browsers and applications are advised
to follow best practices to prevent XSS attacks; see for example example, see <xref target="XSS"/> target="XSS"/>, which was
published by the Open Web Application Security Project (OWASP).</t>
        <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 beyond the scope of this
document.</t>
        <t>As noted in <xref target="design"/>, application protocols can disallow the use of
wildcard certificates entirely as a more foolproof mitigation.</t>
      </section>
      <section anchor="security-uri">
        <name>Uniform Resource Identifiers</name>
        <t>The URI-ID type is a subjectAltName entry of type uniformResourceIdentifier
as defined in <xref target="PKIX"/>. 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"
rule; if the entry does not include both, it is not a valid URI-ID and <bcp14>MUST</bcp14> be
ignored.  Any other components are ignored, ignored because only the "scheme" and "host"
components are used for certificate matching as specified under <xref target="verify"/>.</t>
        <t>The quoted component names in the previous paragraph represent the associated
<xref target="ABNF"/> target="RFC5234"/> productions from the IETF standard Proposed Standard for Uniform Resource Identifiers
<xref target="URI"/>. target="RFC3986"/>.  Although the reader should be aware that some applications (e.g.,
web browsers) might instead conform to the Uniform Resource Locator (URL)
specification maintained by the WHATWG <xref target="URL"/>, it is not expected that
differences between the URI and URL specifications would manifest themselves
in certificate matching.</t>
      </section>
      <section anchor="security-idn">
        <name>Internationalized Domain Names</name>
        <t>This document specifies only matching between reference identifiers and
presented identifiers, not the visual presentation of domain names. More
specifically,
Specifically, the matching of internationalized domain names is performed on
A-labels only <xref target="verify"/>. (<xref target="verify-domain"/>). The limited scope of this specification likely
mitigates potential confusion caused by the use of visually similar characters
in domain names (as (for example, as described for example in <xref section="4.4" sectionFormat="comma" target="IDNA-DEFS"/>, sectionFormat="of" target="RFC5890"/>,
<xref target="UTS-36"/>, and <xref target="UTS-39"/>); in any case, such concerns are a matter for
application-level protocols and user interfaces, not the matching of certificates.</t>
      </section>
      <section anchor="ip-addresses">
        <name>IP Addresses</name>
        <t>The TLS Server Name Indication (SNI) extension only conveys domain names.
Therefore, a client with an IP-ID reference identity cannot present any
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
connection is made without SNI.</t>
        <t>The textual representation of an IPv4 address might be misinterpreted
as a valid FQDN in some contexts.  This can result in different
security treatment that might cause different components of a system
to classify the value differently, which might lead to
vulnerabilities. For example, one  Consider a system in which one component enforces a
security rule that is conditional on the type of identifier.  This component identifier but
misclassifies an IP address as an FQDN.  A different FQDN, whereas a second component
correctly classifies the identifier but might incorrectly assume assumes that
rules regarding IP addresses have been enforced. enforced by the first
component. As a result, the system as a whole might behave in an
insecure manner.  Consistent classification of identifiers avoids
this problem.</t>
        <t>See also <xref target="design"/>, particularly the last paragraph.</t>
      </section>
      <section anchor="security-multi">
        <name>Multiple Presented Identifiers</name>
        <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
domains or protocols.
TLS Extensions extensions such as TLS the Server Name Indication (SNI), as discussed in <xref section="4.4.2.2" section="3" sectionFormat="comma" target="TLS"/>, target="RFC6066"/>, and Application Layer Protocol
Negotiation (ALPN), ALPN, as discussed in <xref target="ALPN"/>, target="RFC7301"/>, provide a way for the application
to indicate the desired identifier and protocol to the server, which it
can then use to select the most appropriate certificate.</t>
        <t>This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI-IDs in a
certificate.  As a result, an application service can use the same
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
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
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>
        <t>The way to mitigate this risk is to limit the number of names that
any server can speak for, for and to ensure that all servers in the set
have a strong minimum configuration as described in Section 3.9 of <xref target="TLS-REC"/>.</t> target="RFC9325" sectionFormat="comma" section="3.9"/>.</t>
      </section>
      <section anchor="multiple-reference-identifiers">
        <name>Multiple Reference Identifiers</name>
        <t>This specification describes how a client may construct multiple acceptable
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"/> target="RFC5280"/> describes a
mechanism to allow CA certificates to be constrained in the set of presented
identifiers that they may include within server certificates.  However, these
constraints only apply to the explicitly enumerated name forms. For example,
a CA that is only name constrained name-constrained for DNS-IDs is not constrained for SRV-IDs
and URI-IDs, unless those name forms are also explicitly included within the
name constraints extension.</t>
        <t>A client that constructs multiple reference identifiers of different types,
such as both DNS-ID DNS-IDs and SRV-IDs, SRV-IDs as described in <xref target="verify-reference-rules"/>,
<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
agreement with the issuing CA, CA or <bcp14>MAY</bcp14> be enforced by the client requiring
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
identities are also constrained, such as requiring a uniformResourceIndicator
name constraint for URI-IDs.</t>
      </section>
      <section anchor="certificate-trust">
        <name>Certificate Trust</name>
        <t>This document assumes that, that if a client trusts a given CA, it trusts all
certificates issued by that CA.  The certificate checking process does not
include additional checks for bad behavior by the hosts identified with
such certificates, for instance instance, rogue servers or buggy applications.  Any
additional checks (e.g., checking the server name against trusted block
lists) are the responsibility of the application protocol or the client
itself.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t> IANA actions.</t>
    </section>
  </middle>
  <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>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="DNS-CONCEPTS">
          <front>
            <title>Domain names - concepts and facilities</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised basic definition of The Domain Name System. 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 clients and servers in the domain name system and the protocol used between them.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
        <reference anchor="DNS-SRV">
          <front>
            <title>A DNS RR for specifying the location of services (DNS SRV)</title>
            <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
            <author fullname="P. Vixie" initials="P." surname="Vixie"/>
            <author fullname="L. Esibov" initials="L." surname="Esibov"/>
            <date month="February" year="2000"/>
            <abstract>
              <t>This document describes a DNS RR which specifies the location of 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 interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-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): Definitions 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 the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document 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): Protocol</title>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="August" year="2010"/>
            <abstract>
              <t>This document is the revised protocol definition for Internationalized 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 domain 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 Representation 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 keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished 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 Certificate 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 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [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 otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of 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 characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; 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 (TLS) 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 Security (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, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of 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 published when the industry was transitioning to TLS 1.2. Years later, this transition 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, this 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</title>
            <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title>
            <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 protocol 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 IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
              <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [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 characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; 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>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4592.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5891.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4514.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4985.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      </references>
      <references>
        <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="Crocker"/>
            <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 Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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 used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management 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 Negotiation 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) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol 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) Transport 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 Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-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</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>Domain Name System (DNS) names are "case insensitive". This document 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)</title>
            <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 (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities 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 profiles for DNS over TLS and provides advice on performance considerations to minimize 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 applications 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 Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>The DTLS 1.3 protocol

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4343.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6186.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3403.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5922.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5630.xml"/>
<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"/>

<!-- [SVCB-FOR-DNS] [I-D.ietf-add-svcb-dns] is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t>This document obsoletes now 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 Services</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 locate 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="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) 9461 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9461.xml"/>

<!-- [SVCB-FOR-HTTPS] [I-D.ietf-dnsop-svcb-https] is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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, 7232, 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) to 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 Domain 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 Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes now RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series 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 for using Transport Layer Security (TLS) and Authenticated Encryption with Associated 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-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque 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="Thomson"/>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document describes how Transport Layer Security (TLS) is used 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 explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow 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, dictionary 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 application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone 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) certificate 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 identity for SIP domain authentication. As such, this document is relevant both to implementors 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 Protocol (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 also 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 encryption 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, REQUIRETLS, 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 request 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 by 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</title>
            <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility 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="Schwartz">
              <organization>Meta Platforms, Inc.</organization>
            </author>
            <date day="26" month="June" year="2023"/>
            <abstract>
              <t>   The SVCB DNS resource record type expresses a bound collection 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>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-svcb-dns-09"/>
        </reference>
        <reference anchor="SVCB-FOR-HTTPS"> 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.ietf.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. M." 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"/>
            <abstract>
              <t>   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTP origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration), and are extensible to support future uses
   (such as keys for encrypting the TLS ClientHello).  They also enable
   aliasing of apex domains, which is not possible with CNAME.  The
   HTTPS RR is a variation of SVCB for use with HTTP [HTTP].  By
   providing more information to the client before it attempts to
   establish a connection, these records offer potential benefits to
   both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc
   (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.

              </t>
            </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-12"/>
</reference>
        <reference anchor="VERIFY">
          <front>
            <title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates 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 between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services 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</title>
            <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 application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-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>
-->

<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"/>

        <reference anchor="ALPACA" target="https://alpaca-attack.com/ALPACA.pdf">
          <front>
            <title>ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication</title>
            <author initials="M." surname="Brinkmann" fullname="Marcus Brinkmann">
              <organization>Ruhr University Bochum</organization>
            </author>
            <author initials="C." surname="Dresen" fullname="Christian Dresen">
              <organization>Münster University of Applied Sciences</organization>
            </author>
            <author initials="R." surname="Merget" fullname="Robert Merget">
              <organization>Ruhr University Bochum</organization>
            </author>
            <author initials="D." surname="Poddebniak" fullname="Damian Poddebniak">
              <organization>Münster University of Applied Sciences</organization>
            </author>
            <author initials="J." surname="Müller" fullname="Jens Müler"> Müller">
              <organization>Ruhr University Bochum</organization>
            </author>
            <author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
              <organization>Paderborn University</organization>
            </author>
            <author initials="J." surname="Schwenk" fullname="Jörg Schwek"> Schwenk">
              <organization>Ruhr University Bochum</organization>
            </author>
            <author initials="S." surname="Schinzel" fullname="Sebastian Schinzel">
              <organization>Ruhr University Bochum</organization>
            </author>
            <date year="2021" month="September"/>
          </front>
	  <refcontent>30th USENIX Security Symposium (USENIX Security 21)</refcontent>
        </reference>

        <reference anchor="HTTPSbytes" target="https://media.blackhat.com/bh-ad-10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-slides.pdf">
          <front>
            <title>HTTPS Can Byte Me</title>
            <author initials="J." surname="Sokol" fullname="Josh Sokol">
              <organization>SecTheory Ltd.</organization>
            </author>
            <author initials="R." surname="Hansen" fullname="Robert Hansen">
              <organization>SecTheory Ltd.</organization>
            </author>
            <date year="2010" month="November"/>
          </front>
          <seriesInfo name="BlackHat" value="Abu Dhabi"/>
          <refcontent>Black Hat Briefings</refcontent>
        </reference>

        <reference anchor="Defeating-SSL" target="https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf">
          <front>
            <title>New Tricks for Defeating SSL in Practice</title>
            <author initials="M." surname="Marlinspike" fullname="Moxie Marlinspike">
              <organization/>
            </author>
            <date year="2009" month="February"/>
          </front>
          <seriesInfo name="BlackHat" value="DC"/>
          <refcontent>Black Hat DC</refcontent>
        </reference>

        <reference anchor="Public-Suffix" target="https://publicsuffix.org">
          <front>
            <title>Public Suffix List</title>
            <author>
              <organization/>
              <organization>Mozilla Foundation</organization>
            </author>
            <date year="2020"/>
          </front>
        </reference>

        <reference anchor="SECURE-CONTEXTS" target="https://www.w3.org/TR/secure-contexts/">
          <front>
            <title>Secure Contexts</title>
            <author initials="M." surname="West" fullname="Mike West">
              <organization/>
            </author>
            <date month="September" year="2021"/>
          </front>
	  <refcontent>W3C Candidate Recommendation Draft</refcontent>
        </reference>

        <reference anchor="US-ASCII">
          <front>
            <title>Coded Character Set Sets - 7-bit American Standard Code for Information Interchange</title> Interchange (7-Bit ASCII)</title>
            <author>
              <organization>American National Standards Institute</organization>
            </author>
            <date year="1986"/> year="2007" month="June"/>
          </front>
          <seriesInfo name="ANSI" value="X3.4"/> name="ANSI INCITS" value="4-1986 (R2007)"/>
        </reference>

        <reference anchor="URL" target="https://url.spec.whatwg.org/">
          <front>
            <title>URL</title>
            <author initials="A." surname="van Kesteren" fullname="Anne van Kesteren">
              <organization/>
            </author>
            <date month="September" year="2023"/>
          </front>
	  <refcontent>WHATWG Living Standard</refcontent>
        </reference>

        <reference anchor="UTS-36" target="https://unicode.org/reports/tr36/">
          <front>
            <title>Unicode Security Considerations</title>
            <author initials="M." surname="Davis" fullname="Mark Davis">
              <organization/>
            </author>
            <author initials="M." surname="Suignard" fullname="Michel Suignard">
              <organization/>
            </author>
            <date month= "September" year="2014"/>
          </front>
	  <seriesInfo name="Unicode Technical Report" value="#36"/>
	    <refcontent>Revision 15</refcontent>
        </reference>

        <reference anchor="UTS-39" target="https://unicode.org/reports/tr39/">
          <front>
            <title>Unicode Security Mechanisms</title>
            <author initials="M." surname="Davis" fullname="Mark Davis">
              <organization/>
            </author>
            <author initials="M." surname="Suignard" fullname="Michel Suignard">
              <organization/>
            </author>
            <date year="2022"/> month="September" year="2023"/>
          </front>
	  <seriesInfo name="Unicode Technical Standard" value="#39"/>
	  <refcontent>Version 15.1.0, Revision 28</refcontent>
        </reference>

        <reference anchor="X.509">
          <front>
            <title>Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>International Telecommunications Union</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2005"/> month="October" year="2019"/>
          </front>
	  <seriesInfo name="ITU-T" value="X.520"/> name="ISO/IEC" value="9594-8"/>
          <seriesInfo name="ITU-T Recommendation" value="X.509"/>
        </reference>

        <reference anchor="X.690">
          <front>
            <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>International Telecommunications Union</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="2008"/> month="February" year="2021"/>
          </front>
	  <seriesInfo name="ITU-T" name="ISO/IEC" value="8825-1:2021 (E)"/>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
        </reference>

        <reference anchor="WSC-UI" target="https://www.w3.org/TR/2010/REC-wsc-ui-20100812/">
          <front>
            <title>Web Security Context: User Interface Guidelines</title>
            <author initials="A." surname="Saldhana" fullname="Anil Saldhana">
              <organization/>
            </author>
            <author initials="T." surname="Roessler" fullname="Thomas Roessler">
              <organization/>
            </author>
            <date year="2010" month="August"/>
          </front>
	    <seriesInfo name="W3C Recommendation" value="REC-wsc-ui-20100812"/>
        </reference>

        <reference anchor="XSS" target="https://owasp.org/www-community/attacks/xss/">
          <front>
            <title>Cross Site Scripting (XSS)</title>
            <author>
              <organization>OWASP</organization>
              <organization>Kirsten, S., et al.</organization>
            </author>
            <date year="2022"/>
          </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="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract> year="2020"/>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
	  <refcontent>OWASP Foundation</refcontent>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

      </references>
    </references>
    <?line 1173?>
<section anchor="changes">
      <name>Changes from RFC 6125</name>
      <t>This document revises and obsoletes <xref target="VERIFY"/> target="RFC6125"/> based
on the decade of experience and changes since it was published.
The major changes, in no particular order, include:</t>
      <ul spacing="normal">
        <li>The only legal place for a certificate wildcard is as the complete left-most
label in a domain name.</li>
        <li>The server identity can only be expressed in the subjectAltNames
extension; it is no longer valid to use the commonName RDN,
known as <tt>CN-ID</tt> in <xref target="VERIFY"/>.</li> target="RFC6125"/>.</li>
        <li>Detailed discussion of pinning (configuring use of a certificate that
doesn't match the criteria in this document) has been removed and replaced
with two paragraphs in <xref target="outcome"/>.</li>
        <li>The sections detailing different target audiences and which sections
to read (first) have been removed.</li>
        <li>References to the X.500 directory, the survey of prior art, and the
sample text in Appendix A have been removed.</li>
        <li>All references have been updated to the current latest version.</li> versions.</li>
        <li>The TLS SNI extension is no longer new, new; it is commonplace.</li>
        <li>Additional text on multiple identifiers, and their security considerations,
has been added.</li>
        <li>IP-ID reference identifiers are have been added.  This builds on the definition in <xref section="4.3.5" sectionFormat="of" target="HTTP"/>.</li>
        <li>Shortened the sectionFormat="comma" target="RFC9110"/>.</li>
        <li>The document title has been shortened because the previous title was difficult to cite.</li>
      </ul>
    </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">
      <name>Acknowledgements</name>
      <t>We gratefully acknowledge everyone who contributed to the previous
version of these recommendations, this specification <xref target="VERIFY"/>. target="RFC6125"/>.
Thanks also to Carsten Bormann <contact fullname="Carsten Bormann"/> for converting the previous document version of this specification to Markdown so that we could more easily use Martin Thomson's <contact fullname="Martin Thomson's"/> <tt>i-d-template</tt>
software.</t>
<t>In addition to discussion on discussions within the mailing list, UTA Working Group, the following people
provided official reviews or especially significant feedback:
Corey Bonnell,
Roman Danyliw,
Viktor Dukhovni,
Lars Eggert,
Patrik Fältström,
Jim Fenton,
Olle Johansson,
John Klensin,
Murray Kucherawy,
Warren Kumari,
John Mattson,
Alexey Melnikov,
Derrell Piper,
<contact fullname="Corey Bonnell"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Viktor Dukhovni"/>,
<contact fullname="Lars Eggert"/>,
<contact fullname="Patrik Fältström"/>,
<contact fullname="Jim Fenton"/>,
<contact fullname="Olle Johansson"/>,
<contact fullname="John Klensin"/>,
<contact fullname="Murray Kucherawy"/>,
<contact fullname="Warren Kumari"/>,
<contact fullname="John Mattson"/>,
<contact fullname="Alexey Melnikov"/>,
<contact fullname="Derrell Piper"/>,
<contact fullname="Maria Ines Robles,
Rob Sayre,
Yaron Sheffer,
Ryan Sleevi,
Brian Smith,
Petr Špaček,
Orie Steele,
Martin Thomson,
Joe Touch,
Éric Vyncke,
Paul Wouters,
and
Qin Wu.</t> Robles"/>,
<contact fullname="Rob Sayre"/>,
<contact fullname="Yaron Sheffer"/>,
<contact fullname="Ryan Sleevi"/>,
<contact fullname="Brian Smith"/>,
<contact fullname="Petr Špaček"/>,
<contact fullname="Orie Steele"/>,
<contact fullname="Martin Thomson"/>,
<contact fullname="Joe Touch"/>,
<contact fullname="Éric Vyncke"/>,
<contact fullname="Paul Wouters"/>,
and
<contact fullname="Qin Wu"/>.</t>
      <t>A few descriptive sentences were borrowed from <xref target="TLS-REC"/>.</t> target="RFC9325"/>.</t>
    </section>
    <section anchor="contributors" numbered="false">
      <name>Contributors</name>
      <t><contact fullname="Jeff Hodges"/> coauthored the previous version of this 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 handling of IP-IDs.</t>
    </section>
  </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>