<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.26 (Ruby 2.3.7) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-rfc3709bis-10" number="9399" submissionType="IETF" category="std" consensus="true" submissionType="IETF" obsoletes="3709, 6170" updates="" tocInclude="true"
sortRefs="true" symRefs="true" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.15.3 -->
<front>
<title abbrev="Logotypes in X.509 Certificates">Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc3709bis-10"/> name="RFC" value="9399"/>
<author initials="S." surname="Santesson" fullname="Stefan Santesson">
<organization abbrev="IDsec Solutions">IDsec Solutions AB</organization>
<address>
<postal>
<postalLine>Forskningsbyn Ideon</postalLine>
<postalLine>SE-223 70 Lund</postalLine>
<postalLine>SE</postalLine>
<postalLine>Sweden</postalLine>
</postal>
<email>sts@aaa-sec.com</email>
</address>
</author>
<author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address>
<postal>
<street>516 Dranesville Road</street>
<city>Herndon, VA</city>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>US</country>
<country>United States of America</country>
</postal>
<email>housley@vigilsec.com</email>
</address>
</author>
<author initials="T." surname="Freeman" fullname="Trevor Freeman">
<organization>Amazon Web Services</organization>
<address>
<postal>
<street>1918 8th Ave</street>
<city>Seattle, WA</city>
<city>Seattle</city>
<region>WA</region>
<code>98101</code>
<country>US</country>
<country>United States of America</country>
</postal>
<email>frtrevor@amazon.com</email>
</address>
</author>
<author initials="L." surname="Rosenthol" fullname="Leonard Rosenthol">
<organization>Adobe</organization>
<address>
<postal>
<street>345 Park Avenue</street>
<city>San Jose, CA</city> Jose</city>
<region>CA</region>
<code>95110</code>
<country>US</country>
<country>United States of America</country>
</postal>
<email>lrosenth@adobe.com</email>
</address>
</author>
<date year="2022" month="December" day="11"/>
<area>Security</area>
<keyword>Internet-Draft</keyword> year="2023" month="April"/>
<area>sec</area>
<workgroup>lamps</workgroup>
<keyword>X.509</keyword>
<keyword>Public Key Infrastructure</keyword>
<keyword>authentication</keyword>
<keyword>security identification</keyword>
<keyword>certificates</keyword>
<abstract>
<t>This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
This document obsoletes RFC RFCs 3709 and RFC 6170.</t>
</abstract>
</front>
<middle>
<section anchor="intro">
<name>Introduction</name>
<t>This specification supplements <xref target="RFC5280"/>, which profiles
public-key
public key certificates and certificate revocation lists (CRLs) for use in
the Internet, and it supplements <xref target="RFC5755"/> target="RFC5755"/>, which profiles
attribute certificates for use in the Internet.</t>
<t>This document obsoletes RFC 3709 <xref target="RFC3709"/> and RFC 6170 <xref target="RFC6170"/>.
<xref target="changes"/> provides a summary of the changes since the publication of
RFC 3709
<xref target="RFC3709"/> and RFC 6170.</t> <xref target="RFC6170"/>.</t>
<t>The basic function of a certificate is to bind a public key to the
identity of an entity (the subject). From a strictly technical
viewpoint, this goal could be achieved by signing the identity of the
subject together with its public key. However, the art of Public Key
Infrastructure (PKI) has developed certificates far beyond this
functionality in order to meet the needs of modern global networks and
heterogeneous information and operational technology structures.</t>
<t>Certificate users must be able to determine certificate policies,
appropriate key usage, assurance level, and name form constraints.
Before a relying party can make an informed decision whether a
particular certificate is trustworthy and relevant for its intended
usage, a certificate may be examined from several different
perspectives.</t>
<t>Systematic processing is necessary to determine whether a particular
certificate meets the predefined prerequisites for an intended usage.
Much of the information contained in certificates is appropriate and
effective for machine processing; however, this information is not
suitable for a corresponding human trust and recognition process.</t>
<t>Humans prefer to structure information into categories and
symbols. Most humans associate complex structures of reality with easily
recognizable logotypes and marks. Humans tend to trust things that
they recognize from previous experiences. Humans may examine
information to confirm their initial reaction. Very few consumers
actually read all terms and conditions they agree to in accepting a service, rather
service; instead, they commonly act on trust derived from previous
experience and recognition.</t>
<t>A big part of this process is branding. Service providers and product
vendors invest a lot of money and resources into creating a strong
relation between positive user experiences and easily recognizable
trademarks, servicemarks, and logotypes.</t>
<t>Branding is also pervasive in identification instruments, including
identification cards, passports, driver's licenses, credit cards,
gasoline cards, and loyalty cards. Identification instruments are
intended to identify the holder as a particular person or as a member
of the community. The community may represent the subscribers of a
service or any other group. Identification instruments, in physical
form, commonly use logotypes and symbols, solely to enhance human
recognition and trust in the identification instrument itself. They
may also include a registered trademark to allow legal recourse for
unauthorized duplication.</t>
<t>Since certificates play an equivalent role in electronic exchanges,
we examine the inclusion of logotypes in certificates. We consider
certificate-based identification and certificate selection.</t>
<section anchor="cert-ident">
<name>Certificate-based
<name>Certificate-Based Identification</name>
<t>The need for human recognition depends on the manner in which
certificates are used and whether certificates need to be visible to
human users. If certificates are to be used in open environments and
in applications that bring the user in conscious contact with the
result of a certificate-based identification process, then human
recognition is highly relevant, relevant and may be a necessity.</t>
<t>Examples of such applications include:</t>
<ul spacing="normal">
<li>Web server identification where a user identifies the owner
of the website.</li>
<li>Peer e-mail email exchange in business-to-business (B2B),
business-to-consumer (B2C), and private communications.</li>
<li>Exchange of medical records, records and system for medical prescriptions.</li>
<li>Unstructured e-business applications (i.e., non-EDI applications).</li>
<li>Wireless client authenticating to a service provider.</li>
</ul>
<t>Most applications provide the human user with an opportunity to view
the results of a successful certificate-based identification
process. When the user takes the steps necessary to view these results,
the
user is presented with a view of a certificate. This solution has two
major problems. First, the function to view a certificate is often
rather hard to find for a non-technical user. Second, the
presentation of the certificate is too technical and is not user
friendly. It contains no graphic symbols or logotypes to enhance
human recognition.</t>
<t>Many investigations have shown that users of today's applications do
not take the steps necessary to view certificates. This could be due
to poor user interfaces. Further, many applications are structured to
hide certificates from users. The application designers do not want
to expose certificates to users at all.</t>
</section>
<section anchor="cert-select">
<name>Selection of Certificates</name>
<t>One situation where software applications must expose human users to
certificates is when the user must select a single certificate from a
portfolio of certificates. In some cases, the software application
can use information within the certificates to filter the list for
suitability; however, the user must be queried if more than one
certificate is suitable. The human user must select one of them.</t>
<t>This situation is comparable to a person selecting a suitable plastic
card from his their wallet. In this situation, substantial assistance is
provided by card color, location, and branding.</t>
<t>In order to provide similar support for certificate selection, the
users need tools to easily recognize and distinguish
certificates. Introduction of logotypes into certificates provides
the necessary graphic.</t>
</section>
<section anchor="cert-combo">
<name>Combination of Verification Techniques</name>
<t>The use of logotypes will, in many cases, affect the users user's decision to
trust and use a certificate. It is therefore important that there be
a distinct and clear architectural and functional distinction between
the processes and objectives of the automated certificate
verification and human recognition.</t>
<t>Since logotypes are only aimed for human interpretation and contain
data that is inappropriate for computer based computer-based verification schemes,
the logotype certificate extension <bcp14>MUST NOT</bcp14> be an active component in automated
certification path validation validation, as specified in <xref section="6" sectionFormat="of" target="RFC5280"/>.</t>
<t>Automated certification path verification determines whether the
end-entity
end entity certificate can be verified according to defined
policy. The algorithm for this verification is specified in <xref target="RFC5280"/>.</t>
<t>The automated processing provides assurance that the certificate is
valid. It does not indicate whether the subject is entitled to any
particular information, information or whether the subject ought to be trusted to
perform a particular service. These are authorization
decisions. Automatic processing will make some authorization decisions,
but others, depending on the application context, involve the human user.</t>
<t>In some situations, where automated procedures have failed to
establish the suitability of the certificate to the task, the human
user is the final arbitrator of the post certificate verification
authorization decisions. In the end, the human will decide whether
or not to accept an executable email attachment, to release personal
information, or to follow the instructions displayed by a web browser.
This decision will often be based on recognition and previous
experience.</t>
<t>The distinction between systematic processing and human processing is
rather straightforward. They can be complementary. While the
systematic process is focused on certification path construction and
verification, the human acceptance process is focused on recognition
and related previous experience.</t>
<t>There are some situations where systematic processing and human
processing interfere with each other. These issues are discussed in
the <xref target="sec-cons"/>.</t>
</section>
<section anchor="terms">
<name>Terminology</name>
<name>Requirements Language</name>
<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>
</section>
</section>
<section anchor="logotypes">
<name>Different Types of Logotypes in Certificates</name>
<t>This specification defines the inclusion of three standard logotype types:</t>
<ul spacing="normal">
<li>Community
<li>community logotype</li>
<li>Issuer
<li>issuer organization logotype</li>
<li>Subject
<li>subject organization logotype</li>
</ul>
<t>The community logotype is the general mark for a community. It
identifies a service concept for entity identification and
certificate issuance. Many issuers may use a community logotype to
co-brand with a global community in order to gain global recognition
of its local service provision. This type of community branding is
very common in the credit card business, where local independent card
issuers include a globally recognized brand (such as VISA Visa and
MasterCard).
Mastercard). Certificate issuers may include more than one community
logotype to indicate participation in more than one global community.</t>
<t>Issuer
<t>The issuer organization logotype is a logotype representing the
organization identified as part of the issuer name in the
certificate.</t>
<t>Subject
<t>The subject organization logotype is a logotype representing the
organization identified in the subject name in the certificate.</t>
<t>In addition to the standard logotype types, this specification
accommodates inclusion of other logotype types where each class of
logotype is defined by an object identifier. The object identifier
can be either locally defined or an identifier defined in <xref target="extn-other"/>
of this document.</t>
</section>
<section anchor="logotype-data">
<name>Logotype Data</name>
<t>This specification defines two types of logotype data: image data and
audio data. Implementations <bcp14>MUST</bcp14> support image data; however, support
for audio data is <bcp14>OPTIONAL</bcp14>.</t>
<t>Image and audio data for logotypes can be provided by reference by including
a URI that identifies the location to the logotype data and a one-way hash
of the referenced data in the certificate. The privacy-related properties
for remote logotype data depend on four parties: the certificate relying
parties that use the information in the certificate extension to fetch
the logotype data, the certificate issuers that populate the certificate
extension, certificate subscribers that request certificates that include
the certificate extension, and server operators that provide the logotype
data.</t>
<t>Alternatively, embedding the logotype data in the certificate with direct
addressing (as defined in <xref target="embedded-image"/>) provides improved privacy
properties and depends upon fewer parties. However, this approach can
significantly increase the size of the certificate.</t>
<t>Several image objects, representing the same visual content in different
formats, sizes, and color palates, may represent each logotype image. At
least one of the image objects representing a logotype <bcp14>SHOULD</bcp14> contain an
image with a width between 60 pixels and 200 pixels and a height between
45 pixels and 150 pixels.</t>
<t>Several instances of audio data may further represent the same audio
sequence in different formats, resolutions, and languages. At least one
of the audio objects representing a logotype <bcp14>SHOULD</bcp14> provide text-based
audio data suitable for processing by text-to-speech software.</t>
<t>A typical use of text based text-based audio data is inclusion in web applications where the
audio text is placed as the "alt" atttribute attribute value of an HTML image (img) element element,
and the language value obtained from LogotypeAudioInfo is included as the "lang"
attribute of that image.</t>
<t>If a logotype of a certain type (as defined in <xref target="logotypes"/>) is
represented by more than one image object, then each image object <bcp14>MUST</bcp14>
contain variants of roughly the same visual content. Likewise, if a
logotype of a certain type is represented by more than one audio object,
then the audio objects <bcp14>MUST</bcp14> contain variants of the same audio information.
A spoken message in different languages is considered a variation of
the same audio information. When more than one image object or more than
one audio object for the same logotype type is included in the certificate,
the certificate issuer is responsible for ensuring that the objects contain
roughly the same content. Compliant applications <bcp14>MUST NOT</bcp14> display more than
one of the image objects and <bcp14>MUST NOT</bcp14> play more than one of the audio objects
for any logotype type (see <xref target="logotypes"/>) at the same time.</t>
<t>A client <bcp14>MAY</bcp14> simultaneously display multiple logotypes of different
logotype types. For example, it may display one subject organization
logotype while also displaying a community logotype, but it <bcp14>MUST NOT</bcp14>
display multiple image variants of the same community logotype.</t>
<t>Each logotype present in a certificate <bcp14>MUST</bcp14> be represented by at
least one image data object.</t>
<t>Client applications <bcp14>SHOULD</bcp14> enhance processing and off-line
functionality by caching logotype data.</t>
</section>
<section anchor="extn">
<name>Logotype Certificate Extension</name>
<t>This section specifies the syntax and semantics of the logotype
certificate extension.</t>
<section anchor="extn-format">
<name>Extension Format</name>
<t>The logotype certificate extension <bcp14>MAY</bcp14> be included in public key certificates
<xref target="RFC5280"/> or attribute certificates <xref target="RFC5755"/>.
The logotype certificate extension <bcp14>MUST</bcp14> be identified by the following object
identifier:</t>
<artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
]]></artwork>
]]></sourcecode>
<t>This extension <bcp14>MUST NOT</bcp14> be marked critical.</t>
<t>Logotype data may be referenced through either direct or indirect
addressing. Client applications <bcp14>SHOULD</bcp14> support both direct and indirect
addressing. Certificate issuing applications <bcp14>MUST</bcp14> support direct
addressing, and certificate issuing applications <bcp14>SHOULD</bcp14> support
indirect addressing.</t>
<t>The direct addressing includes information about each logotype in the
certificate, and URIs point to the image and audio data object. Multiple
URIs <bcp14>MAY</bcp14> be included for locations for obtaining the same logotype object.
Multiple hash values <bcp14>MAY</bcp14> be included, each computed with a different
one-way hash function. Direct addressing supports cases where just
one or a few alternative images and audio objects are referenced.</t>
<t>The indirect addressing includes one or more references to an external
hashed data structure that contains information on the type, content, and
location of each image and audio object. Indirect addressing supports
cases where each logotype is represented by many alternative audio or
image objects.</t>
<t>Both direct and indirect addressing accommodate alternative URIs to
obtain exactly the same logotype data. This opportunity for replication is
intended to improve availability. Therefore, if a client is unable to
fetch the item from one URI, the client <bcp14>SHOULD</bcp14> try another URI in the
sequence. All direct addressing URIs <bcp14>SHOULD</bcp14> use the HTTPS scheme (https://...)
or (https://...),
the HTTP scheme (http://...) (http://...), or the DATA scheme (data://...) <xref target="RFC3986"/>.
However, the "data" URI scheme <bcp14>MUST NOT</bcp14> be used with the indirect addressing.
Clients <bcp14>MUST</bcp14> support retrieval of the referenced LogoTypeData LogotypeData with the
HTTP <xref target="RFC9110"/> and the target="RFC9110"/>, HTTP with TLS <xref target="RFC8446"/>, or subsequent versions of
these protocols. Client applications <bcp14>SHOULD</bcp14> also support the "data" URI
scheme <xref target="RFC2397"/> for direct addressing with embedded logotype data
within the extension.</t>
<t>Note that the HTTPS scheme (https://...) requires the validation of other
certificates to establish a secure connection. For this reason, the
HTTP scheme (http://...) may be easier for a client to handle. Also, the
hash of the logotype data provides data integrity.</t>
<t>The logotype certificate extension <bcp14>MUST</bcp14> have the following syntax:</t>
<artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media Media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits per pixel
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified,
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same LogotypeData
-- image or audio object
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
]]></artwork>
]]></sourcecode>
<t>When using indirect addressing, the URI (refStructURI) pointing to
the external data structure <bcp14>MUST</bcp14> point to a resource that contains
the DER-encoded data with the syntax LogotypeData.</t>
<t>At least one of the optional elements in the LogotypeExtn structure
<bcp14>MUST</bcp14> be present.</t>
<t>When using direct addressing, at least one of the optional elements
in the LogotypeData structure <bcp14>MUST</bcp14> be present.</t>
<t>The LogotypeReference and LogotypeDetails structures explicitly
identify one or more one-way hash functions employed to authenticate
referenced image or audio objects. CAs Certification Authorities (CAs) <bcp14>MUST</bcp14> include a hash value for each
referenced object, calculated on the whole object. CAs <bcp14>MUST</bcp14> use the
one-way hash function that is associated with the certificate signature to
compute one hash value, and CAs <bcp14>MAY</bcp14> include other hash values. Clients
<bcp14>MUST</bcp14> compute a one-way hash value using one of the identified functions,
and clients <bcp14>MUST</bcp14> discard the logotype data if the computed hash value does
not match the hash value in the certificate extension.</t>
<t>A MIME media type is used to specify the format of the image or audio object
containing the logotype data. The mediaType field <bcp14>MUST</bcp14> contain a string
that is constructed according to the ABNF <xref target="RFC5234"/> rule for media-type
provided in
Section 4.2 of <xref target="RFC6838"/>. MIME target="RFC9110" sectionFormat="of" section="8.3.1"/>. Media types <bcp14>MAY</bcp14> include parameters.</t> parameters. To keep the mediaType field as
small as possible, optional whitespace <bcp14>SHOULD NOT</bcp14> be included.</t>
<t>Image format requirements are specified in <xref target="image-format"/>, and audio
format requirements are specified in <xref target="audio-format"/>.</t>
<t>When language is specified, the language tag <bcp14>MUST</bcp14> use the syntax in <xref target="RFC5646"/> syntax.</t>
<t>Logotype target="RFC5646"/>.</t>
<t>The following logotype types are defined in this specification are:</t>
<ul empty="true">
<li>
<t>Community Logotype: specification:</t>
<ul>
<li>community logotype: If communityLogos is present, the logotypes
<bcp14>MUST</bcp14> represent one or more communities with which the certificate
issuer is affiliated. The communityLogos <bcp14>MAY</bcp14> be present in an end
entity certificate, a CA certificate, or an attribute
certificate. The communityLogos contains a sequence of Community Logotypes, community logotypes,
each representing a different community. If more than one Community community
logotype is present, they <bcp14>MUST</bcp14> be placed in order of preferred
appearance.
Some clients <bcp14>MAY</bcp14> choose to display a subset of the
present community logos; therefore therefore, the placement within the
sequence aids the client selection. The most preferred logotype
<bcp14>MUST</bcp14> be first in the sequence, and the least preferred logotype
<bcp14>MUST</bcp14> be last in the sequence.</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Issuer Organization Logotype: sequence.</li>
<li>issuer organization logotype: If issuerLogo is present, the
logotype <bcp14>MUST</bcp14> represent the issuer's organization. The logotype
<bcp14>MUST</bcp14> be consistent with, and require the presence of, an
organization name stored in the organization attribute in the
issuer field (for either a public key certificate or attribute
certificate). The issuerLogo <bcp14>MAY</bcp14> be present in an end entity
certificate, a CA certificate, or an attribute certificate.</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Subject Organization Logotype: certificate.</li>
<li>subject organization logotype: If subjectLogo is present, the
logotype <bcp14>MUST</bcp14> represent the subject's organization. The logotype
<bcp14>MUST</bcp14> be consistent with, and require the presence of, an
organization name stored in the organization attribute in the
subject field (for either a public key certificate or attribute
certificate). The subjectLogo <bcp14>MAY</bcp14> be present in an end entity
certificate, a CA certificate, or an attribute certificate.</t>
</li> certificate.</li>
</ul>
<t>The relationship between the subject organization and the subject
organization logotype, and the relationship between the issuer and
either the issuer organization logotype or the community logotype,
are relationships asserted by the issuer. The policies and practices
employed by the issuer to that check subject organization logotypes or
claims about its issuer and community logotypes is are outside the scope of
this document.</t>
</section>
<section anchor="image-info">
<name>Conventions for LogotypeImageInfo</name>
<t>When the optional LogotypeImageInfo is included with a logotype
image, the parameters <bcp14>MUST</bcp14> be used with the following semantics and
restrictions.</t>
<t>The xSize and ySize fields represent the recommended display size for
the logotype image. When a value of 0 (zero) is present, no recommended
display size is specified. When non-zero values are present and these
values differ from corresponding size values in the referenced image object,
then the referenced image <bcp14>SHOULD</bcp14> be scaled to fit within the size parameters
of LogotypeImageInfo, LogotypeImageInfo while preserving the x and y ratio. Dithering may
produce a more appropriate image than linear scaling.</t>
<t>The resolution field is redundant for all logotype image formats
listed in <xref target="image-format"/>. The optional resolution field <bcp14>SHOULD</bcp14>
be omitted when the image format already contains this information.</t>
</section>
<section anchor="embedded-image">
<name>Embedded Images</name>
<t>If
<t> If the logotype image is provided through direct addressing, then the
image <bcp14>MAY</bcp14> be stored within the logotype certificate extension using
the "data" scheme <xref target="RFC2397"/>. The syntax of the "data" URI scheme
defined is included here for convenience:</t>
<artwork><![CDATA[
shown below, which incorporates Errata ID 2045 and uses modern ABNF
<xref target="RFC5234"/>:</t>
<sourcecode type="abnf"><![CDATA[
dataurl := = "data:" [ mediatype media-type ] [ ";base64" ] "," data
mediatype := [ type "/" subtype ] *( ";" parameter )
data := *urlchar
parameter := attribute = *(reserved / unreserved / escaped)
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" value
]]></artwork> / "+" /
"$" / ","
unreserved = alphanum / mark
alphanum = ALPHA / DIGIT
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
escaped = "%" hex hex
hex = HEXDIG / "a" / "b" / "c" / "d" / "e" / "f"
]]></sourcecode>
<t>where media-type is defined in <xref target="RFC9110" sectionFormat="of" section="8.3.1"/> and
ALPHA, DIGIT, and HEXDIG are defined in <xref target="RFC5234" sectionFormat="of" section="B.1"/>.</t>
<t>When including the image data in the logotype certificate extension using the
"data" URI scheme, the following conventions apply:</t>
<ul spacing="normal">
<li>The value of mediaType in LogotypeDetails <bcp14>MUST</bcp14> be identical to the
media type value in the "data" URL.</li>
<li>The hash of the image <bcp14>MUST</bcp14> be included in logotypeHash and <bcp14>MUST</bcp14> be
calculated over the same data as it would have been, had been if the image
had been referenced through a link to an external resource.</li>
</ul>
<aside>
<t>NOTE: As the "data" URI scheme is processed as a data source rather
than as a URL, the image data is typically not limited by any
URL length limit settings that otherwise apply to URLs in general.</t>
<t>NOTE: Implementations need to be cautious about the size of images
included in a certificate in order to ensure that the size of
the certificate does not prevent the certificate from being
used as intended.</t>
</aside>
</section>
<section anchor="extn-other">
<name>Other Logotypes</name>
<t>Logotypes identified by otherLogos (as defined in <xref target="extn-format"/>) can be used to
enhance the display of logotypes and marks that represent partners,
products, services, or any other characteristic associated with the
certificate or its intended application environment when the standard
logotype types are insufficient.</t>
<t>The conditions and contexts of the intended use of these logotypes
are defined at the discretion of the local client application.</t>
<t>Three other logotype types are defined in the follow subsections.</t>
<section anchor="extn-other-1">
<name>Loyalty Logotype</name>
<t>When a loyalty logotype appears in the otherLogos, it <bcp14>MUST</bcp14> be identified
by the id-logo-loyalty object identifier.</t>
<artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
]]></artwork>
]]></sourcecode>
<t>A loyalty logotype, if present, <bcp14>MUST</bcp14> contain a logotype associated
with a loyalty program related to the certificate or its use. The
relation between the certificate and the identified loyalty program
is beyond the scope of this document. The logotype certificate extension <bcp14>MAY</bcp14>
contain more than one Loyalty loyalty logotype.</t>
<t>If more than one loyalty logotype is present, they <bcp14>MUST</bcp14> be
placed in order of preferred appearance. Some clients <bcp14>MAY</bcp14> choose
to display a subset of the present loyalty logotype data; therefore therefore, the
placement within the sequence aids the client selection. The most
preferred loyalty logotype data <bcp14>MUST</bcp14> be first in the sequence, and the
least preferred loyalty logotype data <bcp14>MUST</bcp14> be last in the sequence.</t>
</section>
<section anchor="extn-other-2">
<name>Certificate Background Logotype</name>
<t>When a certificate background logotype appears in the otherLogos, it
<bcp14>MUST</bcp14> be identified by the id-logo-background object identifier.</t>
<artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
]]></artwork>
]]></sourcecode>
<t>The certificate background logotype, if present, <bcp14>MUST</bcp14> contain a
graphical image intended as a background image for the certificate, certificate
and/or a general audio sequence for the certificate. The background
image <bcp14>MUST</bcp14> allow black text to be clearly read when placed on top of
the background image. The logotype certificate extension <bcp14>MUST NOT</bcp14> contain more
than one certificate background logotype.</t>
</section>
<section anchor="extn-other-3">
<name>Certificate Image Logotype</name>
<t>When a certificate image logotype appears in the otherLogos, it
<bcp14>MUST</bcp14> be identified by the id-logo-certImage object identifier.</t>
<artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 }
]]></artwork>
]]></sourcecode>
<t>The certificate image logotype, if present, aids human interpretation
of a certificate by providing meaningful visual information to the
user interface (UI). The logotype certificate extension <bcp14>MUST NOT</bcp14> contain more
than one certificate image logotype.</t>
<t>Typical situations when a human needs to examine
the visual representation of a certificate are:</t>
<ul spacing="normal">
<li>A person establishes a secured channel with an authenticated
service. The person needs to determine the identity of the
service based on the authenticated credentials.</li>
<li>A person validates the signature on critical information, such as
signed executable code, and needs to determine the identity of the
signer based on the signer's certificate.</li>
<li>A person is required to select an appropriate certificate to be
used when authenticating to a service or Identity Management identity management
infrastructure. The person needs to see the available
certificates in order to distinguish between them in the selection
process.</li>
</ul>
<t>The display of certificate information to humans is challenging due
to lack of well-defined semantics for critical identity attributes.
Unless the application has out-of-band knowledge about a particular
certificate, the application will not know the exact nature of the
data stored in common identification attributes attributes, such as serialNumber,
organizationName, country, etc. Consequently, the application can
display the actual data, data but faces the problem of labeling that data
in the UI and informing the human about the exact nature (semantics)
of that data. It is also challenging for the application to
determine which identification attributes are important to display
and how to organize them in a logical order.</t>
<t>When present, the certificate image <bcp14>MUST</bcp14> be a complete visual
representation of the certificate. This means that the display of
this certificate image represents all information about the
certificate that the issuer subjectively defines as relevant to show
to a typical human user within the typical intended use of the
certificate, giving adequate information about at least the following
three aspects of the certificate:</t>
<ul spacing="normal">
<li>Certificate Context</li>
<li>Certificate Issuer</li>
<li>Certificate Subject</li>
<li>certificate context</li>
<li>certificate issuer</li>
<li>certificate subject</li>
</ul>
<t>Certificate Context context information is visual marks and/or textual
information that helps the typical user to understand the typical
usage and/or purpose of the certificate.</t>
<t>It is up to the issuer to decide what information -- in the form of
text, graphical symbols, and elements -- represents a complete visual
representation of the certificate. However, the visual
representation of Certificate Subject certificate subject and Certificate Issuer certificate issuer
information from the certificate <bcp14>MUST</bcp14> have the same meaning as the
textual representation of that information in the certificate itself.</t>
<t>Applications providing a Graphical User Interface (GUI) to the
certificate user <bcp14>MAY</bcp14> present a certificate image as the only visual
representation of a certificate; however, the certificate user <bcp14>SHOULD</bcp14>
be able to easily obtain the details of the certificate content.</t>
</section>
</section>
</section>
<section anchor="cert-types">
<name>Type of Certificates</name>
<t>Logotypes <bcp14>MAY</bcp14> be included in public key certificates and attribute
certificates at the discretion of the certificate issuer; however, the
relying party <bcp14>MUST NOT</bcp14> use the logotypes as part of certification path
validation or automated trust decision. decisions. The sole purpose of logotypes is
to enhance the display of a particular certificate, regardless of its
position in a certification path.</t>
</section>
<section anchor="use-in-clients">
<name>Use in Clients</name>
<t>All PKI implementations require relying party software to have some
mechanism to determine whether a trusted CA issues a particular
certificate. This is an issue for certification path validation,
including consistent policy and name checking.</t>
<t>After a certification path is successfully validated, the replying
party trusts the information that the CA includes in the certificate,
including any certificate extensions. The client software can choose
to make use of such information, or the client software can ignore
it. If the client is unable to support a provided logotype, the
client <bcp14>MUST NOT</bcp14> report an error, rather error; instead, the client <bcp14>MUST</bcp14> behave as
though no logotype certificate extension was included in the certificate. Current standards
do not provide any mechanism for cross-certifying CAs to constrain
subordinate CAs from including private extensions (see <xref target="sec-cons"/>).</t>
<t>Consequently, if relying party software accepts a CA, then it should
be prepared to (unquestioningly) display the associated logotypes to
its human user, given that it is configured to do so. Information
about the logotypes is provided so that the replying party software
can select the one that will best meet the needs of the human
user. This choice depends on the abilities of the human user, as well as
the
capabilities of the platform on which the replaying party software is
running. If none of the provided logotypes meets the needs of the
human user or matches the capabilities of the platform, then the
logotypes can be ignored.</t>
<t>A client <bcp14>MAY</bcp14>, subject to local policy, choose to display none, one, or
any number of the logotypes in the logotype certificate extension. In many cases,
a client will be used in an environment with a good
network connection and also used in an environment with little or no
network connectivity. For example, a laptop computer can be docked
with a high-speed LAN connection, or it can be disconnected from the
network altogether. In recognition of this situation, the client <bcp14>MUST</bcp14>
include the ability to disable the fetching of logotypes. However,
locally cached logotypes can still be displayed when the user
disables the fetching of additional logotypes.</t>
<t>A client <bcp14>MAY</bcp14>, subject to local policy, choose any combination of
audio and image presentation for each logotype. That is, the client
<bcp14>MAY</bcp14> display an image with or without playing a sound, and it <bcp14>MAY</bcp14> play
a sound with or without displaying an image. A client <bcp14>MUST NOT</bcp14> play
more than one logotype audio sequence at the same time.</t>
<t>The logotype is to be displayed in conjunction with other identity
information contained in the certificate. The logotype is not a
replacement for this identity information.</t>
<t>Care is needed when designing replying party software to ensure that an
appropriate context of logotype information is provided. This is
especially difficult with audio logotypes. It is important that the
human user be able to recognize the context of the logotype, even if
other audio streams are being played.</t>
<t>If the relying party software is unable to successfully validate a
particular certificate, then it <bcp14>MUST NOT</bcp14> display any logotype data
associated with that certificate.</t>
</section>
<section anchor="image-format">
<name>Image Formats</name>
<t>Animated images <bcp14>SHOULD NOT</bcp14> be used.</t>
<t>The following table lists many common image formats and the
corresponding MIME media type. The table also indicates the support
requirements for these image formats. The filename file name extensions
commonly used for each of these formats is also
provided. Implementations <bcp14>MAY</bcp14> support other image formats.</t>
<table anchor="image-format-table">
<name>Image Formats</name>
<thead>
<tr>
<th align="left">Format</th>
<th align="left">MIME align="left">Media Type</th>
<th align="left">Extension</th>
<th align="left">References</th>
<th align="left">Implement?</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">JPEG</td>
<td align="left">image/jpeg</td>
<td align="left">.jpg<br/>.jpeg</td>
<td align="left">
<xref target="JPEG"/><br/><xref target="RFC2046"/></td>
<td align="left">
<bcp14>MUST</bcp14> support</td>
</tr>
<tr>
<td align="left">GIF</td>
<td align="left">image/gif</td>
<td align="left">.gif</td>
<td align="left">
<xref target="GIF"/><br/><xref target="RFC2046"/></td>
<td align="left">
<bcp14>MUST</bcp14> support</td>
</tr>
<tr>
<td align="left">SVG</td>
<td align="left">image/svg+xml</td>
<td align="left">.svg</td>
<td align="left">
<xref target="SVGT"/><br/><xref target="SVGR"/></td>
<td align="left">
<bcp14>SHOULD</bcp14> support</td>
</tr>
<tr>
<td align="left">SVG + GZIP</td>
<td align="left">image/svg+xml+gzip</td>
<td align="left">.svgz<br/>.svg.gz</td>
<td align="left">
<xref target="SVGT"/><br/><xref target="SVGZR"/></td>
<td align="left">
<bcp14>MUST</bcp14> support</td>
</tr>
<tr>
<td align="left">PNG</td>
<td align="left">image/png</td>
<td align="left">.png</td>
<td align="left">
<xref target="ISO15948"/><br/><xref target="PNGR"/></td>
<td align="left">
<bcp14>SHOULD</bcp14> support</td>
</tr>
<tr>
<td align="left">PDF</td>
<td align="left">application/pdf</td>
<td align="left">.pdf</td>
<td align="left">
<xref target="ISO32000"/><br/><xref target="ISO19005"/><br/><xref target="RFC8118"/></td>
<td align="left">
<bcp14>MAY</bcp14> support</td>
</tr>
</tbody>
</table>
<aside>
<t>NOTE: The image/svg+xml-compressed media type is widely implemented, but it
has not yet been registered with IANA.</t>
</aside>
<t>When a Scalable Vector Graphics (SVG) image is used, whether the image is
compressed or not, the SVG Tiny profile <xref target="SVGT"/> <bcp14>MUST</bcp14> be followed, with
these additional restrictions:</t>
<ul spacing="normal">
<li>The SVG image <bcp14>MUST NOT</bcp14> contain any Internationalized Resource
Identifier (IRI) references to information stored outside of the
SVG image of type B, C, or D, according to Section 14.1.4 of <xref target="SVGT"/>.</li>
<li>The SVG image <bcp14>MUST NOT</bcp14> contain any 'script' script element, according to
Section 15.2 of <xref target="SVGT"/>.</li>
<li>The XML structure in the SVG file <bcp14>MUST</bcp14> use linefeed (0x0A) as
the end-of-line (EOL) character when calculating a hash over the
SVG image.</li>
</ul>
<t>When a GZIP-compressed SVG image is fetched with HTTP, the
client will receive a response that includes these headers:</t>
<artwork><![CDATA[
Content-Type: image/svg+xml
Content-Encoding: gzip
]]></artwork>
<t>In this case, the octet stream of type image/svg+xml is compressed with
GZIP <xref target="RFC1952"/> target="RFC1952"/>, as specified in <xref target="SVGR"/>.</t>
<t>When an uncompressed SVG image is fetched with HTTP, the client will receive
a response with the same Content-Type header, header but no Content-Encoding header.</t>
<t>Whether the SVG image is GZIP-compressed or uncompressed, the hash value for
the SVG image is calculated over the uncompressed SVG content with
canonicalized EOL characters characters, as specified above.</t>
<t>When an SVG image is embedded in the certificate extension using the
"data" URL scheme, the SVG image data <bcp14>MUST</bcp14> be provided in GZIP-compressed
form, and the XML structure, prior to compression, <bcp14>SHOULD</bcp14> use linefeed
(0x0A) as the end-of-line (EOL) character.</t>
<t>When a bitmap image is used, the PNG <xref target="ISO15948"/> format <bcp14>SHOULD</bcp14> be used.</t>
<t>When
<t>According to <xref target="ISO32000"/>, when a Portable Document Format (PDF) document according to <xref target="ISO32000"/>
is used, it <bcp14>MUST</bcp14> also be formatted according to the profile PDF/A <xref target="ISO19005"/>.</t>
</section>
<section anchor="audio-format">
<name>Audio Formats</name>
<t>Implementations that support audio <bcp14>MUST</bcp14> support the MP3 audio format
<xref target="MP3"/> with a MIME media type of "audio/mpeg" <xref target="RFC3003"/>. Implementations <bcp14>SHOULD</bcp14> support
text-based audio data with a MIME media type of "text/plain;charset=UTF-8".
Implementations <bcp14>MAY</bcp14> support other audio formats.</t>
<t>Text-based audio data using the MIME media type of "text/plain;charset=UTF-8" is
intended to be used by text-to-speech software. When this audio type is used,
the following requirements apply:</t>
<ul spacing="normal">
<li>LogotypeAudioInfo <bcp14>MUST</bcp14> be present and specify the language of the text.</li>
<li>The fileSize, playTime, and channels elements of LogotypeAudioInfo <bcp14>MUST</bcp14> have the value of 0.</li>
<li>The sampleRate element of LogotypeAudioInfo <bcp14>MUST</bcp14> be absent.</li>
</ul>
</section>
<section anchor="sec-cons">
<name>Security Considerations</name>
<t>Implementations that simultaneously display multiple logotype types
(subject organization, issuer, issuer organization, community, or other), other) <bcp14>MUST</bcp14> ensure that
there is no ambiguity as to the binding between the image and the
type of logotype that the image represents. "Logotype type" is
defined in <xref target="cert-ident"/>, and it refers to the type
of entity or affiliation represented by the logotype, not the
of binary format of the image or audio.</t>
<t>Logotypes are very difficult to securely and accurately define. Names
are also difficult in this regard, but logotypes are even worse. It
is quite difficult to specify what is, and what is not, a legitimate
logotype of an organization. There is an entire legal structure around
this issue, and it will not be repeated here. However, issuers should
be aware of the implications of including images associated with a
trademark or servicemark before doing so. As logotypes can be
difficult (and sometimes expensive) to verify, the possibility of errors
related to assigning wrong logotypes to organizations is increased.</t>
<t>This is not a new issue for electronic identification instruments. It
is already dealt with in a number of similar situations in the
physical world, including physical employee identification cards. In
addition, there are situations where identification of logotypes is
rather simple and straightforward, such as logotypes for well-known
industries and institutes. These issues should not stop those service
providers who want to issue logotypes from doing so, where relevant.</t>
<t>It is impossible to prevent fraudulent creation of certificates by
dishonest or badly performing issuers, containing names and logotypes
that the issuer has no claim to or has failed to check correctly. Such
certificates could be created in an attempt to socially engineer a user
into accepting a certificate. The premise used for the logotype work is
thus that logotype graphics in a certificate are trusted only if the
certificate is successfully validated within a valid path. It is thus
imperative that the representation of any certificate that fails to
validate is not enhanced in any way by using the logotype data.</t>
<t>This underlines the necessity for CAs to provide reliable services, services
and the relying party's responsibility and need to carefully select
which CAs are trusted to provide public key certificates.</t>
<t>This also underlines the general necessity for relying parties to use
up-to-date software libraries to render or dereference data from
external sources, including logotype data in certificates, to minimize
risks related to processing potentially malicious data before it has been
adequately verified and validated. Implementers should review the guidance
in <xref section="7" sectionFormat="of" target="RFC3986"/>.</t>
<t>Referenced image objects are hashed in order to bind the image to the
signature of the certificate. Some image types, such as SVG, allow
part of the image to be collected from an external source by
incorporating a reference to an external file that contains the image. If
this feature were used within a logotype image, the hash of the image
would only cover the URI reference to the external image file, file but
not the referenced image data. Clients <bcp14>SHOULD</bcp14> verify that SVG
images meet all requirements listed in <xref target="image-format"/> and reject
images that contain references to external data.</t>
<t>CAs issuing certificates with embedded logotype images should be
cautious when accepting graphics from the certificate requestor requester for
inclusion in the certificate if the hash algorithm used to sign the
certificate is vulnerable to collision attacks such attacks, as described in <xref target="RFC6151"/>. In
such a case, the accepted image may contain data that could help an
attacker to obtain colliding certificates with identical certificate
signatures.</t>
<t>Certification paths may also impose name constraints that are
systematically checked during certification path processing, which,
in theory, may be circumvented by logotypes.</t>
<t>Certificate path processing processing, as defined in <xref target="RFC5280"/> target="RFC5280"/>, does not constrain
the inclusion of logotype data in certificates. A parent CA can
constrain certification path validation such that subordinate CAs cannot
issue valid certificates to end-entities end entities outside a limited name space or
outside specific certificate polices. policies. A malicious CA can comply with
these name and policy requirements and still include inappropriate
logotypes in the certificates that it issues. These certificates will
pass the certification path validation algorithm, which means the client
will trust the logotypes in the certificates. Since there is no
technical mechanism to prevent or control subordinate CAs from including
the logotype certificate extension or its contents, where appropriate, a parent CA
could employ a legal agreement to impose a suitable restriction on the
subordinate CA. This situation is not unique to the logotype certificate extension.</t>
<t>When a relying party fetches remote logotype data, a mismatch between the
media type provided in the mediaType field of the LogotypeDetails and the
Content-Type HTTP header of the retrieved object <bcp14>MUST</bcp14> be treated as a
failure
failure, and the fetched logotype data should not be presented to the
user. However, if more than one location for the remote logotype data is
provided in the certificate extension, the relying party <bcp14>MAY</bcp14> try to fetch
the remote logotype data from an alternate location to resolve the failure.</t>
<t>When a subscriber requests the inclusion of remote logotype data in a
certificate, the CA cannot be sure that any logotype data will be
available at the provided URI for the entire validity period of the
certificate. To mitigate this concern, the CA may provide the logotype
data from a server under its control, rather than a subscriber-controlled
server.</t>
<t>The controls available to a parent CA to protect itself from rogue
subordinate CAs are non-technical. They include:</t>
<ul spacing="normal">
<li>Contractual agreements of suitable behavior, including
terms of liability in case of material breach.</li>
<li>Control mechanisms and procedures to monitor and follow the behavior of
subordinate CAs, including Certificate Transparency <xref target="RFC9162"/>.</li>
<li>Use of certificate policies to declare an assurance level
of logotype data, as well as to guide applications on how
to treat and display logotypes.</li>
<li>Use of revocation functions to revoke any misbehaving CA.</li>
</ul>
<t>There is not a simple, straightforward, and absolute technical
solution. Rather, involved parties must settle some aspects of PKI
outside the scope of technical controls. As such, issuers need to
clearly identify and communicate the associated risks.</t>
</section>
<section anchor="priv-cons">
<name>Privacy Considerations</name>
<t>Certificates are commonly public objects, so the inclusion of
privacy-sensitive information in certificates should be avoided. The more
information that is included in a certificate, the greater the likelihood
that the certificate will reveal privacy-sensitive information. The
inclusion of logotype data needs to be considered in this context.</t>
<t>Logotype data might be fetched from a server when it is needed. By
watching activity on the network, an observer can determine which clients
are making use of certificates that contain particular logotype data.
Since clients are expected to locally cache logotype data, network
traffic to the server containing the logotype data will not be generated
every time the certificate is used. Further, when logotype data is not
cached, activity on the network might reveal certificate usage frequency.
Even when logotype data is cached, regardless of whether direct or
indirect addressing is employed, network traffic monitoring could reveal
when logotype data is fetched for the first time. Implementations <bcp14>MAY</bcp14>
encrypt fetches of logotype data using HTTPS, padding the data to a common
size to reduce visibility into the data that is being fetched. Likewise,
servers <bcp14>MAY</bcp14> reduce visibility into the data that is being returned by
encrypting with HTTPS and padding to a few common sizes.</t>
<t>Similarly, when fetching logotype data from a server, the server operator
can determine which clients are making use of certificates that contain
particular logotype data. As above, locally caching logotype data will
eliminate the need to fetch the logotype data each time the certificate
is used, and lack of caching would reveal usage frequency. Even when
implementations cache logotype data, regardless of whether direct or
indirect addressing is employed, the server operator could observe when
logotype data is fetched for the first time.</t>
<t>In addition, the use of an encrypted DNS mechanism, such as DoT DNS over TLS (DoT) <xref target="RFC7858"/>
or DoH DNS over HTTPS (DoH) <xref target="RFC9230"/>, hides the name resolution traffic associated traffic, which is usually a first step in fetching
remote logotype objects from third parties.</t> objects.</t>
<t>When the "data" URI scheme is used with direct addressing, there is no
network traffic to fetch logotype data, which avoids the observations of
network traffic or server operations described above. To obtain this
benefit, the certificate will be larger than one that contains a URL.
Due to the improved privacy posture, the "data" URI scheme with direct
addressing will be the only one that is supported by some CAs.
Privacy-aware certificate subscribers <bcp14>MAY</bcp14> wish to insist that logotype
data is embedded in the certificate with the "data" URI scheme with
direct addressing.</t>
<t>In cases where logotype data is cached by the relying party, the cache
index should include the hash values of the associated logotype data with the
goal of fetching the logotype data only once, even when it is referenced by
multiple URIs. The index should include hash values for all supported
hash algorithms. The cached data should include the media type as well as
the logotype data. Implementations should give preference to logotype data
that is already in the cache when multiple alternatives are offered in the
LogotypeExtn certificate extension.</t>
<t>When the "data" URI scheme is used, the relying party <bcp14>MAY</bcp14> add the embedded
logotype data to the local cache, which could avoid the need to fetch the
logotype data if it is referenced by a URL in another certificate.</t>
<t>When fetching remote logotype data, relying parties should use the most
privacy-preserving options that are available to minimize the opportunities
for servers to "fingerprint" clients. For example, avoid cookies, e-tags, ETags, and
client certificates.</t>
<t>When a relying party encounters a new certificate, the lack of network traffic
to fetch logotype data might indicate that a certificate with references to the
same logotype data has been previously processed and cached.</t>
<t>TLS 1.3 <xref target="RFC8446"/> includes the ability to encrypt the server's certificate
in the TLS handshake, which helps hide the server's identity from anyone that
is watching activity on the network. If the server's certificate includes
remote logotype data, the client fetching that data might disclose the
otherwise protected server identity.</t>
</section>
<section anchor="iana">
<name>IANA Considerations</name>
<t>For the new ASN.1 Module module in <xref target="asn1-mod-new"/>, IANA
is requested to assign an object identifier (OID) for has
assigned the module
identifier. The following OID for the module should be allocated
in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).</t>
<t>For
(1.3.6.1.5.5.7.0):</t>
<table anchor="iana1" align="left">
<name></name>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>107</td>
<td>id-mod-logotype-2022</td>
<td>RFC 9399</td>
</tr>
</tbody>
</table>
<t>IANA has updated the existing entries in the Structure "Structure of Management
Information (SMI)
Numbers Numbers" registry that refer referred to RFC 3709 <xref
target="RFC3709"/> or RFC 6170, IANA is requested
update the entries <xref target="RFC6170"/> to refer to this
document. These entries are:</t>
<artwork><![CDATA[
1.3.6.1.5.5.7.0.22 id-mod-logotype
1.3.6.1.5.5.7.0.68 id-mod-logotype-certimage
1.3.6.1.5.5.7.1.12 id-pe-logotype
1.3.6.1.5.5.7.20.1 id-logo-loyalty
1.3.6.1.5.5.7.20.2 id-logo-background
1.3.6.1.5.5.7.20.3 id-logo-certImage
]]></artwork>
</section>
<section anchor="acks">
<name>Acknowledgments</name>
<section anchor="acks-rfc3709">
<name>Acknowledgments from RFC 3709</name>
<t>This document is are noted in the result of contributions from many
professionals. The authors appreciate contributions from all members
of tables below.</t>
<t>From the IETF PKIX Working Group. We extend a special thanks to Al
Arsenault, David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex
Deacon, Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan
Hurst, and Phil Griffin "SMI Security for their efforts and support.</t>
<t>Russ Housley thanks the management at RSA Laboratories, especially
Burt Kaliski, who supported the development of this specification. The
vast majority of the work on this specification was done while
Russ was employed at RSA Laboratories.</t>
</section>
<section anchor="acks-rfc6170">
<name>Acknowledgments from RFC 6170</name>
<t>The authors recognize valuable contributions from members of the PKIX
working group, the CA Browser Forum, and James Manger, for their
review and sample data.</t>
</section>
<section anchor="acks-additional">
<name>Additional Acknowledgments</name>
<t>Combining RFC 3709 and RFC 6170 has produced an improved
specification. The authors appreciate contributions from all members
of Module Identifier" registry (1.3.6.1.5.5.7.0):</t>
<table anchor="iana2" align="left">
<name></name>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>22</td>
<td>id-mod-logotype</td>
<td>RFC 9399</td>
</tr>
<tr>
<td>68</td>
<td>id-mod-logotype-certimage</td>
<td>RFC 9399</td>
</tr>
</tbody>
</table>
<t>From the IETF LAMPS Working Group. We extend a special thanks to
Alexey Melnikov for his guidance on media types. We extend a special
thanks to Tim Geiser "SMI Security for his careful checking of PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1):</t>
<table anchor="iana3" align="left">
<name></name>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>12</td>
<td>id-pe-logotype</td>
<td>RFC 9399</td>
</tr>
</tbody>
</table>
<t>From the new examples in
Appendix B.4 and B.5. We extend a special thanks to Corey Bonnell,
Daniel Kahn Gillmor, Roman Danyliw, Paul Wouters, Paul Kyzivat, Shuping Peng,
Sheng Jiang, Rob Wilton, Eric Vyncke, Donald Eastlake, and Dan Harkins "SMI Security for their careful review and helpful comments.</t>
</section> PKIX Other Logotype Identifiers" registry (1.3.6.1.5.5.7.20):</t>
<table anchor="iana4" align="left">
<name></name>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>id-logo-loyalty</td>
<td>RFC 9399</td>
</tr>
<tr>
<td>2</td>
<td>id-logo-background</td>
<td>RFC 9399</td>
</tr>
<tr>
<td>3</td>
<td>id-logo-certImage</td>
<td>RFC 9399</td>
</tr>
</tbody>
</table>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper">
<organization/>
</author>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="S. Boeyen" initials="S." surname="Boeyen">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="W. Polk" initials="W." surname="Polk">
<organization/>
</author>
<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="RFC5755" target="https://www.rfc-editor.org/info/rfc5755">
<front>
<title>An Internet Attribute Certificate Profile for Authorization</title>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<date month="January" year="2010"/>
<abstract>
<t>This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5755"/>
<seriesInfo name="DOI" value="10.17487/RFC5755"/>
</reference>
<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<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="RFC2397" target="https://www.rfc-editor.org/info/rfc2397">
<front>
<title>The "data" URL scheme</title>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<date month="August" year="1998"/>
<abstract>
<t>A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2397"/>
<seriesInfo name="DOI" value="10.17487/RFC2397"/>
</reference>
<reference anchor="RFC2046" target="https://www.rfc-editor.org/info/rfc2046">
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/>
</author>
<author fullname="N. Borenstein" initials="N." surname="Borenstein">
<organization/>
</author>
<date month="November" year="1996"/>
<abstract>
<t>This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2046"/>
<seriesInfo name="DOI" value="10.17487/RFC2046"/>
</reference>
<reference anchor="RFC3003" target="https://www.rfc-editor.org/info/rfc3003">
<front>
<title>The audio/mpeg Media Type</title>
<author fullname="M. Nilsson" initials="M." surname="Nilsson">
<organization/>
</author>
<date month="November" year="2000"/>
<abstract>
<t>The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3003"/>
<seriesInfo name="DOI" value="10.17487/RFC3003"/>
</reference>
<reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646">
<front>
<title>Tags for Identifying Languages</title>
<author fullname="A. Phillips" initials="A." role="editor" surname="Phillips">
<organization/>
</author>
<author fullname="M. Davis" initials="M." role="editor" surname="Davis">
<organization/>
</author>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. 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="47"/>
<seriesInfo name="RFC" value="5646"/>
<seriesInfo name="DOI" value="10.17487/RFC5646"/>
</reference>
<reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<date month="January" year="2013"/>
<abstract>
<t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="6838"/>
<seriesInfo name="DOI" value="10.17487/RFC6838"/>
</reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="Crocker">
<organization/>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization/>
</author>
<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="RFC1952" target="https://www.rfc-editor.org/info/rfc1952">
<front>
<title>GZIP file format specification version 4.3</title>
<author fullname="P. Deutsch" initials="P." surname="Deutsch">
<organization/>
</author>
<date month="May" year="1996"/>
<abstract>
<t>This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1952"/>
<seriesInfo name="DOI" value="10.17487/RFC1952"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<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="RFC9110" target="https://www.rfc-editor.org/info/rfc9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) 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>
<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.5755.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2397.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3003.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5646.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.1952.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.9110.xml"/>
<reference anchor="NEW-ASN1" target="https://www.itu.int/rec/T-REC-X.680">
<front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2021" month="February"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference>
<reference anchor="SVGT" target="https://www.w3.org/TR/2008/PR-SVGTiny12-20081117"> target="http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/">
<front>
<title>Scalable Vector Graphics (SVG) Tiny 1.2 Specification</title>
<author>
<organization>World Wide Web Consortium</organization>
</author>
<date year="2008" month="November" day="17"/> month="December"/>
</front>
<seriesInfo name="W3C" value="PR-SVGTiny12-20081117"/> value="REC-SVGTiny12-20081222"/>
</reference>
<reference anchor="ISO15948">
<front>
<title>Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG): Functional specification</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2004"/> year="2004" month="March"/>
</front>
<seriesInfo name="ISO/IEC" value="15948:2004"/>
</reference>
<reference anchor="JPEG">
<front>
<title>Information technology -- Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2011" year="2013" month="May"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="T.871"/>
<seriesInfo name="ISO/IEC" value="10918-5:2013"/>
</reference>
<reference anchor="GIF" target="https://www.w3.org/Graphics/GIF/spec-gif89a.txt">
<front>
<title>Graphics Interchange Format</title>
<author>
<organization>CompuServe Incorporated</organization>
</author>
<date year="1990" month="July" day="31"/> month="July"/>
</front>
<seriesInfo name="Version" value="89a"/>
</reference>
<reference anchor="MP3">
<front>
<title>Information technology -- Generic coding of moving pictures and associated audio information -- Part 3: Audio</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="1998"/> year="1998" month="April"/>
</front>
<seriesInfo name="ISO/IEC" value="13818-3:1998"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<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" target="https://www.rfc-editor.org/info/rfc8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<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>
<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"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912">
<front>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization/>
</author>
<date month="June" year="2010"/>
<abstract>
<t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5912"/>
<seriesInfo name="DOI" value="10.17487/RFC5912"/>
</reference>
<reference anchor="RFC6151" target="https://www.rfc-editor.org/info/rfc6151">
<front>
<title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<author fullname="L. Chen" initials="L." surname="Chen">
<organization/>
</author>
<date month="March" year="2011"/>
<abstract>
<t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6151"/>
<seriesInfo name="DOI" value="10.17487/RFC6151"/>
</reference>
<reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6268">
<front>
<title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad">
<organization/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization/>
</author>
<date month="July" year="2011"/>
<abstract>
<t>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6268"/>
<seriesInfo name="DOI" value="10.17487/RFC6268"/>
</reference>
<reference anchor="RFC8118" target="https://www.rfc-editor.org/info/rfc8118">
<front>
<title>The application/pdf Media Type</title>
<author fullname="M. Hardy" initials="M." surname="Hardy">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<author fullname="D. Markovic" initials="D." surname="Markovic">
<organization/>
</author>
<author fullname="D. Johnson" initials="D." surname="Johnson">
<organization/>
</author>
<author fullname="M. Bailey" initials="M." surname="Bailey">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993. This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8118"/>
<seriesInfo name="DOI" value="10.17487/RFC8118"/>
</reference>
<reference anchor="RFC3709" target="https://www.rfc-editor.org/info/rfc3709">
<front>
<title>Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates</title>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="T. Freeman" initials="T." surname="Freeman">
<organization/>
</author>
<date month="February" year="2004"/>
<abstract>
<t>This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3709"/>
<seriesInfo name="DOI" value="10.17487/RFC3709"/>
</reference>
<reference anchor="RFC6170" target="https://www.rfc-editor.org/info/rfc6170">
<front>
<title>Internet X.509 Public Key Infrastructure -- Certificate Image</title>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="S. Bajaj" initials="S." surname="Bajaj">
<organization/>
</author>
<author fullname="L. Rosenthol" initials="L." surname="Rosenthol">
<organization/>
</author>
<date month="May" year="2011"/>
<abstract>
<t>This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6170"/>
<seriesInfo name="DOI" value="10.17487/RFC6170"/>
</reference>
<reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7858">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</title>
<author fullname="Z. Hu" initials="Z." surname="Hu">
<organization/>
</author>
<author fullname="L. Zhu" initials="L." surname="Zhu">
<organization/>
</author>
<author fullname="J. Heidemann" initials="J." surname="Heidemann">
<organization/>
</author>
<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization/>
</author>
<author fullname="D. Wessels" initials="D." surname="Wessels">
<organization/>
</author>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<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="RFC9162" target="https://www.rfc-editor.org/info/rfc9162">
<front>
<title>Certificate Transparency Version 2.0</title>
<author fullname="B. Laurie" initials="B." surname="Laurie">
<organization/>
</author>
<author fullname="E. Messeri" initials="E." surname="Messeri">
<organization/>
</author>
<author fullname="R. Stradling" initials="R." surname="Stradling">
<organization/>
</author>
<date month="December" year="2021"/>
<abstract>
<t>This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t>
<t>This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.</t>
<t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9162"/>
<seriesInfo name="DOI" value="10.17487/RFC9162"/>
</reference>
<reference anchor="RFC9216" target="https://www.rfc-editor.org/info/rfc9216">
<front>
<title>S/MIME Example Keys and Certificates</title>
<author fullname="D. K. Gillmor" initials="D. K." role="editor" surname="Gillmor">
<organization/>
</author>
<date month="April" year="2022"/>
<abstract>
<t>The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9216"/>
<seriesInfo name="DOI" value="10.17487/RFC9216"/>
</reference>
<reference anchor="RFC9230" target="https://www.rfc-editor.org/info/rfc9230">
<front>
<title>Oblivious DNS over HTTPS</title>
<author fullname="E. Kinnear" initials="E." surname="Kinnear">
<organization/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<author fullname="T. Verma" initials="T." surname="Verma">
<organization/>
</author>
<author fullname="C.A. Wood" initials="C.A." surname="Wood">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.</t>
<t>This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9230"/>
<seriesInfo name="DOI" value="10.17487/RFC9230"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8118.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3709.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6170.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.9162.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9216.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9230.xml"/>
<reference anchor="OLD-ASN1" target="https://www.itu.int/rec/T-REC-X.208/en">
<front>
<title>Specification of Abstract Syntax Notation One (ASN.1)</title>
<author>
<organization>CCITT</organization>
</author>
<date year="1988" month="November"/>
</front>
<refcontent>CCITT Recommendation X.208</refcontent>
<seriesInfo name="CCITT Recommendation" value="X.208"/>
</reference>
<reference anchor="ISO19005">
<front>
<title>Document management -- Electronic document file format for long-term preservation -- Part 1: Use of PDF 1.4 (PDF/A-1)</title>
<author>
<organization>ISO</organization>
</author>
<date year="2005"/> year="2005" month="October"/>
</front>
<seriesInfo name="ISO" value="19005-1:2005"/>
</reference>
<reference anchor="ISO32000">
<front>
<title>Document management -- Portable document format -- Part 1: PDF 1.7</title>
<author>
<organization>ISO</organization>
</author>
<date year="2008"/> year="2008" month="July"/>
</front>
<seriesInfo name="ISO" value="32000-1:2008"/>
</reference>
<reference anchor="SVGR" target="https://www.iana.org/assignments/media-types/image/svg+xml">
<front>
<title>Media Type Registration for image/svg+xml</title>
<author>
<organization>World Wide Web Consortium</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="SVGZR" target="https://github.com/w3c/svgwg/issues/701">
<front>
<title>A separate MIME type for svgz files is needed</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="PNGR" target="https://www.iana.org/assignments/media-types/image/png">
<front>
<title>Media Type Registration for image/png</title>
<author>
<organization>World Wide Web Consortium</organization>
</author>
<date/>
</front>
</reference>
</references>
</references>
<section anchor="asn1-mods">
<name>ASN.1 Modules</name>
<section anchor="asn1-mod-old">
<name>ASN.1 Modules with 1988 Syntax</name>
<t>This appendix contains two ASN.1 modules, both using the old
syntax <xref target="OLD-ASN1"/>.</t>
<t>The first ASN.1 module provides the syntax for the Logotype logotype certificate
extension. Only comments have changed in the module from RFC 3709, <xref target="RFC3709"/> and
the IMPORTS now come from <xref target="RFC5280"/>.</t>
<t>The second ASN.1 module provides the Certificate Image certificate image
object identifier. The module is unchanged from RFC 6170.</t> <xref target="RFC6170"/>.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[
LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 5280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- Logotype Certificate Extension OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Certificate Extension Syntax
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
OPTIONAL }
-- Note: At least one of the OPTIONAL components MUST be present
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
-- Note: At least one of the OPTIONAL components MUST be present
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media Media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits per pixel
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified,
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same LogotypeData
-- image or audio object
-- Note: The referenced LogotypeData binary file contains a
-- DER-encoded LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
-- Other logotype type OIDs
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
END
CERT-IMAGE-MODULE { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype-certimage(68) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL; -- export all items from this module
id-logo-certImage OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-logo(20) 3 }
END
]]></sourcecode>
</section>
<section anchor="asn1-mod-new">
<name>ASN.1 Module with 2002 Syntax</name>
<t>Some developers like to use the latest version of ASN.1 standards. This
appendix provides an ASN.1 module to assist in that goal. It uses the ASN.1
syntax defined in <xref target="NEW-ASN1"/>, and it follows the conventions
established in <xref target="RFC5912"/> and <xref target="RFC6268"/>.</t>
<t>This ASN.1 module incorporates the module from RFC 3709 <xref target="RFC3709"/> and the module
from RFC 6170.</t> <xref target="RFC6170"/>.</t>
<t>Note that <xref target="NEW-ASN1"/> was published in 2021, and all of the features
used in this module are backward compatible with the specification
that was published in 2002.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[
LogotypeCertExtn
LogotypeCertExtn-2022
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(TBD)
id-mod-logotype-2022(107) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
AlgorithmIdentifier{}, DIGEST-ALGORITHM
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ;
-- Logotype Certificate Extension
ext-logotype EXTENSION ::= {
SYNTAX LogotypeExtn
IDENTIFIED BY id-pe-logotype }
-- Logotype Certificate Extension OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Certificate Extension Syntax
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
OPTIONAL }
-- At least one of the OPTIONAL components MUST be present
( WITH COMPONENTS { ..., communityLogos PRESENT } |
WITH COMPONENTS { ..., issuerLogo PRESENT } |
WITH COMPONENTS { ..., subjectLogo PRESENT } |
WITH COMPONENTS { ..., otherLogos PRESENT } )
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
LogotypeData ::= SEQUENCE {
image SEQUENCE OF LogotypeImage OPTIONAL,
audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
-- At least one image component MUST be present
( WITH COMPONENTS { ..., image PRESENT } )
LogotypeImage ::= SEQUENCE {
imageDetails LogotypeDetails,
imageInfo LogotypeImageInfo OPTIONAL }
LogotypeAudio ::= SEQUENCE {
audioDetails LogotypeDetails,
audioInfo LogotypeAudioInfo OPTIONAL }
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media Media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
LogotypeImageInfo ::= SEQUENCE {
type [0] LogotypeImageType DEFAULT color,
fileSize INTEGER, -- In octets, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
OtherLogotypeInfo ::= SEQUENCE {
logotypeType OBJECT IDENTIFIER,
info LogotypeInfo }
LogotypeReference ::= SEQUENCE {
refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
refStructURI SEQUENCE SIZE (1..MAX) OF IA5String }
-- Places to get the same LogotypeData
-- image or audio object
-- Note: The referenced LogotypeData binary file contains a
-- DER-encoded LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
hashValue OCTET STRING }
-- Other logotype type OIDs
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 }
END
]]></sourcecode>
</section>
</section>
<section anchor="examples">
<name>Examples</name>
<section anchor="example-rfc3709">
<name>Example from RFC 3709</name>
<t>The following example displays a logotype certificate extension containing one
Issuer
issuer organization logotype using direct addressing. The issuer organization logotype image is
of the type image/gif. The logotype image is referenced through
one URI URI, and the image is hashed with SHA-256. This example
is changed from RFC 3709 <xref target="RFC3709"/> to use SHA-256 instead of SHA-1.</t>
<t>The values on the left are the ASN.1 tag (in hexadecimal) and
the length (in decimal).</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
30 122: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 110: OCTET STRING, encapsulates {
30 108: SEQUENCE {
A1 106: [1] {
A0 104: [0] {
30 102: SEQUENCE {
30 100: SEQUENCE {
30 98: SEQUENCE {
16 9: IA5String 'image/gif'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 6A 58 50 2E 59 67 F9 DD D1 8A FE BD 0D B1 FE 60
: A5 13 1B DF 0F B2 BE F0 B5 73 45 50 BA 1B BF 19
: }
: }
30 34: SEQUENCE {
16 32: IA5String 'http://logo.example.com/logo.gif'
: }
: }
: }
: }
: }
: }
: }
: }
: }
]]></artwork>
]]></sourcecode>
</section>
<section anchor="example-new">
<name>Issuer Organization Logotype Example</name>
<t>The following example displays a logotype certificate extension containing one
Issuer
issuer organization logotype using direct addressing. The issuer organization logotype image is
of the type image/jpeg. The logotype image is referenced through
one URI URI, and the image is hashed with SHA-256.</t>
<t>The values on the left are the ASN.1 tag (in hexadecimal) and
the length (in decimal).</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
30 124: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 112: OCTET STRING, encapsulates {
30 110: SEQUENCE {
A1 108: [1] {
A0 106: [0] {
30 104: SEQUENCE {
30 102: SEQUENCE {
30 100: SEQUENCE {
16 10: IA5String 'image/jpeg'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 1E 8F 96 FD D3 50 53 EF C6 1C 9F FC F0 00 2E 53
: B4 9C 24 9A 32 C5 E9 0C 2C 39 39 D3 AD 6D A9 09
: }
: }
30 35: SEQUENCE {
16 33: IA5String 'http://logo.example.com/logo.jpeg'
: }
: }
: }
: }
: }
: }
: }
: }
: }
]]></artwork>
]]></sourcecode>
</section>
<section anchor="example-embed">
<name>Embedded Image Example</name>
<t>The following example displays a logotype certificate extension
containing one
Subject subject organization logotype using direct addressing.
The subject organization logotype image uses image/svg+xml-compressed. image/svg+xml+gzip.
The logotype image is embedded in the certificate extension with a
"data:" URI URI, and the image is hashed by SHA-256. This technique
produces a large certificate extension, extension but offers reduced latency
and improved privacy.</t>
<t>The values on the left are the ASN.1 tag (in hexadecimal) and the
length (in decimal).</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
30 2160: 2148: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 2146: 2134: OCTET STRING, encapsulates {
30 2142: 2130: SEQUENCE {
A2 2138: 2126: [2] {
A0 2134: 2122: [0] {
30 2130: 2118: SEQUENCE {
30 2126: 2114: SEQUENCE {
30 2122: 2110: SEQUENCE {
16 24: 18: IA5String 'image/svg+xml-compressed' 'image/svg+xml+gzip'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: C5 AC 94 1A 0A 25 1F B3 16 6F 97 C5 52 40 9B 49
: 9E 7B 92 61 5A B0 A2 6C 19 BF B9 D8 09 C5 D9 E7
: }
: }
30 2041: 2035: SEQUENCE {
16 2037: 2031: IA5String
: 'data:image/svg+xml-compressed;base64,H4sICIGpy2E' 'data:image/svg+xml+gzip;base64,H4sICIGpy2EAA2xvZ'
: 'AA2xvZ28tY29weS5zdmcApVbbbhs3EH3nV0y3Lw2Q9fK2JLe' '28tY29weS5zdmcApVbbbhs3EH3nV0y3Lw2Q9fK2JLewHDROU'
: 'wHDROUBRo2iBxW+RRlTa2UFkypIWV5ut7zlB2UqF9cuLlUkt' 'BRo2iBxW+RRlTa2UFkypIWV5ut7zlB2UqF9cuLlUktyLmfOz'
: 'yLmfOzPD8xafbtdyPu/1qu5k17sw2sp/mm+V8vd2Ms2azbV5' 'PD8xafbtdyPu/1qu5k17sw2sp/mm+V8vd2Ms2azbV5cmPNvX'
: 'cmPNvXv16efXh7WvZ31/L299e/vzTpTRt1/0RLrvu1dUref/' 'v16efXh7WvZ31/L299e/vzTpTRt1/0RLrvu1dUref/7j+Ktd'
: '7j+KtdXawsete/9IYaW6m6e77rjscDmeHcLbdXXdX7zpu6t6' 'Xawsete/9IYaW6m6e77rjscDmeHcLbdXXdX7zpu6t69vmxxo'
: '9vmxxon08AREdRDt7tpyWDRRSz7+tgp2b/ew/hEKI5WGoPKy' 'n08AREdRDt7tpyWDRRSz7+tgp2b/ew/hEKI5WGoPKyW082s8'
: 'W082s8SmeWf13NzVyM66ub6ZZk+xXH+9X4+Hl9tOssWLly35' 'SmeWf13NzVyM66ub6ZZk+xXH+9X4+Hl9tOssWLly3553ARpd'
: '53ARpd7txP+7uxx/2d+NiejefVttZ8+nNavkBj9yO40RLb8d' '7txP+7uxx/2d+NiejefVttZ8+nNavkBj9yO40RLb8dpvpxP8'
: 'pvpxP8wtzuRvn07iUP/+Wu+20my9GcWfOPpfDbjVN44YLb8d' 'wtzuRvn07iUP/+Wu+20my9GcWfOPpfDbjVN44YLb8dp3Mn7c'
: 'p3Mn7cb3aXGNCAICCc+a8+yLo/FpwfLP/uN3dzhqdriH5uwf' 'b3aXGNCAICCc+a8+yLo/FpwfLP/uN3dzhqdriH5uwfbnj9a+'
: 'bnj9a+Uz2i/maK66utA+zZ435uFqvZ823R38Q1t32Lw3pZqT' 'Uz2i/maK66utA+zZ435uFqvZ823R38Q1t32Lw3pZqThd/PpR'
: 'hd/PpRpaz5o2LNkocvCzaIm0vrQvSpog359lLy3my0ga+e3H' 'paz5o2LNkocvCzaIm0vrQvSpog359lLy3my0ga+e3Hp+B4In'
: 'p+B4InjVFPD9awdhnrGEFW30Sl/Pnpvta2QBVxUEVxFbJ2VU' 'jVFPD9awdhnrGEFW30Sl/Pnpvta2QBVxUEVxFbJ2VUFfYC01'
: 'FfYC01pUs+O4GK84V/k6CHUFyhvhiDVQF8Y5aPDbmnsrXbS7' 'pUs+O4GK84V/k6CHUFyhvhiDVQF8Y5aPDbmnsrXbS74DANjg'
: '4DANjguwgENZLPwjUYVTRJQgEpiLR0ctiWj+Ig8rCvZAArxK' 'uwgENZLPwjUYVTRJQgEpiLR0ctiWj+Ig8rCvZAArxKExEEWM'
: 'ExEEWMJLqMA1F+ggnsQDXgpQeomJPCVhtCRycNrAWxgAI+g1' 'JLqMA1F+ggnsQDXgpQeomJPCVhtCRycNrAWxgAI+g1Qsr6IU'
: 'Qsr6IUxlomBswjydYBEgOeVCDoRreBjiFjX2SdSA60BP5DgQ' 'xlomBswjydYBEgOeVCDoRreBjiFjX2SdSA60BP5DgQM63xoP'
: 'M63xoPlWHbNq+egAEeAzxyNAdCQz+sDEMOhaGisKJdSlS6gt' 'lWHbNq+egAEeAzxyNAdCQz+sDEMOhaGisKJdSlS6gtWWm4M1'
: 'WWm4M1rQwP0egEBIhhFLoXuCJhR4mT5RJBaiLKqqFROUEzYr' 'rQwP0egEBIhhFLoXuCJhR4mT5RJBaiLKqqFROUEzYr1idG0g'
: '1idG0gahwCzEnk+AMJLdp0FevQQ6VZ+SKOwGlOIJOh1MVjo0' 'ahwCzEnk+AMJLdp0FevQQ6VZ+SKOwGlOIJOh1MVjo0eB6DRA'
: 'eB6DRA10SRpSY6il/eFFKAm+MKSIWNFqSo4OFnORfwH5wJHC' '10SRpSY6il/eFFKAm+MKSIWNFqSo4OFnORfwH5wJHCMNM0ql'
: 'MNM0qlDRlcIwUEkDlgiSBhiEpBgMKOx5FdAYqI3KYewKKkAI' 'DRlcIwUEkDlgiSBhiEpBgMKOx5FdAYqI3KYewKKkAItTABTk'
: 'tTABTkp5khI86kgbOgRywEBR0VGcwAjf8t9wqvdUMG6gLAbI' 'p5khI86kgbOgRywEBR0VGcwAjf8t9wqvdUMG6gLAbI0QQ8Cb'
: '0QQ8CbzCTtCSn/DEhCbm++duQaiRG1mQkdWHnminHA+r5wpL' 'zCTtCSn/DEhCbm++duQaiRG1mQkdWHnminHA+r5wpLvsJbCA'
: 'vsJbCALUKsDW5NAj43J+AD5vpfamUzJqiRJACmCWwIMhQq4H' 'LUKsDW5NAj43J+AD5vpfamUzJqiRJACmCWwIMhQq4HmYGKai'
: 'mYGKaiiJPmIvpS80UzTtAjdSraApQZogslgFcJHw0y5WoEXD' 'iJPmIvpS80UzTtAjdSraApQZogslgFcJHw0y5WoEXDYr/aTq'
: 'Yr/aTqfxk2qhcg3z6ETQL+S18llvHOZQvlEOVEVpzqCozE9V' 'fxk2qhcg3z6ETQL+S18llvHOZQvlEOVEVpzqCozE9V6JZhh/'
: '6JZhh/lCslg7mUFY4AR7IlcApmgV6gz3DCSDe56fQ0SRS7el' 'lCslg7mUFY4AR7IlcApmgV6gz3DCSDe56fQ0SRS7el0NJWO8'
: '0NJWO8mQ6mkc6ylPpaL7QUZ5IR/M/dEwoJiEp+L6iT4cdSyI' 'mQ6mkc6ylPpaL7QUZ5IR/M/dEwoJiEp+L6iT4cdSyIp4ljDk'
: 'p4ljDkoaZpQlgMoz0ApahjTiTWbZYu9v+MUqVjY61j2Bxr68' 'oaZpQlgMoz0ApahjTiTWbZYu9v+MUqVjY61j2Bxr68bPF3uS'
: 'bPF3uS1232qAyAQDMhr4MRyVZq5l2QcuwgY/oTozbgoIKycH' '1232qAyAQDMhr4MRyVZq5l2QcuwgY/oTozbgoIKycH+yQxhz'
: '+yQxhzQsPJQ/ne9OmRKvYH1AeKA/EQRtzrmaYUiHUhpJOW4b' 'QsPJQ/ne9OmRKvYH1AeKA/EQRtzrmaYUiHUhpJOW4breSaxZ'
: 'reSaxZ/TVc3ZAQJKOagAJiw6pRHVkBMIBa5E+SUMWi0ZNW1R' '/TVc3ZAQJKOagAJiw6pRHVkBMIBa5E+SUMWi0ZNW1Rfn/xQX'
: 'fn/xQXywHXyMHN5G8WF6gZ2IVjANHMIJQ1lAJQE8MJjZHJiU' 'ywHXyMHN5G8WF6gZ2IVjANHMIJQ1lAJQE8MJjZHJiUtQZAWz'
: 'tQZAWzmkisDywTVWSqLkkQG2NNB3wwyaerqRGLNKpvwUOhaQ' 'mkisDywTVWSqLkkQG2NNB3wwyaerqRGLNKpvwUOhaQFiYcqv'
: 'FiYcqviSjvp1n8WnRRzXFs9IXDxiiDd8HU/ROoAGn9+QgTPE' 'iSjvp1n8WnRRzXFs9IXDxiiDd8HU/ROoAGn9+QgTPEVu6HaN'
: 'Vu6HaN6i0VPuv1SCzwyZeHwBA1EjFYoAk2jJ3OFeJ5Gp1E+3' '6i0VPuv1SCzwyZeHwBA1EjFYoAk2jJ3OFeJ5Gp1E+3Dlf3Aj'
: 'Dlf3Aj70bbvmag5oyKHunVyGPq6+EnvTua/JUn3iadMHlqUa' '70bbvmag5oyKHunVyGPq6+EnvTua/JUn3iadMHlqUapsK2T8'
: 'psK2T8SwCBJUF1JnEmhu0ntBthJoQpZqumsBk5mA1hRc0LR5' 'SwCBJUF1JnEmhu0ntBthJoQpZqumsBk5mA1hRc0LR5ZFerdj'
: 'ZFerdjksaCqt3IUWXcXW16vb6xdWyHLTgCaKXWKUKK1kOp9H' 'ksaCqt3IUWXcXW16vb6xdWyHLTgCaKXWKUKK1kOp9HK5B3EL'
: 'K5B3ELjSdXb0loB5RYtS01L6h9yTPW51Wpqwgosr5I927aw6' 'jSdXb0loB5RYtS01L6h9yTPW51Wpqwgosr5I927aw6401+Yf'
: '401+YfwDria4WoQwAAA==' 'wDria4WoQwAAA=='
: }
: }
: }
: }
: }
: }
: }
: }
: }
]]></artwork>
]]></sourcecode>
</section>
<section anchor="example-rfc6170">
<name>Embedded Certificate Image Example</name>
<t>The following example displays a logotype certificate extension
containing one
Certificate Image certificate image logotype using direct addressing.
The Certificate
Image certificate image logotype uses image/svg+xml-compressed. image/svg+xml+gzip. The
logotype image is embedded in the certificate extension with a
"data:" URI URI, and the image is hashed by SHA-256. This example
contains the image from
Appendix B of RFC 6170, <xref target="RFC6170" sectionFormat="of" section="B"/>; however, the media
type used here is explicit about the use of GZIP compression
<xref target="RFC1952"/>.</t>
<t>The values on the left are the ASN.1 tag (in hexadecimal) and the
length (in decimal).</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
30 2914: 2902: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 2900: 2888: OCTET STRING, encapsulates {
30 2896: 2884: SEQUENCE {
A3 2892: 2880: [3] {
30 2888: 2876: SEQUENCE {
30 2884: 2872: SEQUENCE {
06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 20 3'
A0 2870: 2858: [0] {
30 2866: 2854: SEQUENCE {
30 2862: 2850: SEQUENCE {
30 2858: 2846: SEQUENCE {
16 24: 18: IA5String 'image/svg+xml-compressed' 'image/svg+xml+gzip'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 83 14 B3 26 9B D3 8B 0B 2A E6 6E 42 74 E2 A7 57
: 7A 40 B7 E1 2E 53 42 44 CC 7C AE 14 68 1B 0E B6
: }
: }
30 2777: 2771: SEQUENCE {
16 2773: 2767: IA5String
: 'data:image/svg+xml-compressed;base64,H4sICLXutU0' 'data:image/svg+xml+gzip;base64,H4sICLXutU0AA0Nlc'
: 'AA0NlcnRJbWFnZURlbW8uc3ZnANVaW2/bOBZ+n19BqBigwdo' 'nRJbWFnZURlbW8uc3ZnANVaW2/bOBZ+n19BqBigwdoS7xK9j'
: 'S7xK9jmeapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1Em' 'meapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1Em8C9d9i'
: '8C9d9iERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJt' 'ERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJteOv/66'
: 'eOv/661M/cFBZhVkcpnmmL50sd34b/TIsH6YoiS+da11UySS' '1M/cFBZhVkcpnmmL50sd34b/TIsH6YoiS+da11UySSJwkqj2'
: 'Jwkqj21k41Q6CDbNyUMSTS+e+quYDz1sul+6SuXkx9YhSysP' '1k41Q6CDbNyUMSTS+e+quYDz1sul+6SuXkx9YhSysPUo7QPK'
: 'Uo7QPK/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDj' '/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDjGiGHQ9'
: 'GiGHQ914n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKm' '14n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKmSbLVWN'
: 'SbLVWNoo2cqNCh1XyoKN8Nsuz0iqwVW8Qb1fOF0Vqp+PI06m' 'oo2cqNCh1XyoKN8Nsuz0iqwVW8Qb1fOF0Vqp+PI06me6awqP'
: 'e6awqPeISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83n8wzGkb' 'eISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83n8wzGkbR4Gtef'
: 'R4GtefENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5u' 'ENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5uF1Wqu7'
: 'F1Wqu7R6FLvNFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9Br' 'R6FLvNFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9BrFrMbeV'
: 'FrMbeVuWhtzbHvMR6UlobPyVpBWjXBk7six2vH5nCwY6nXCo' 'uWhtzbHvMR6UlobPyVpBWjXBk7six2vH5nCwY6nXCo5xb7Yu'
: '5xb7YusvFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov8' 'svFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov8IF2WZh'
: 'IF2WZhNlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1bo' 'NlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1boUJvQFs'
: 'UJvQFsvi+LOJyxZkPE/vCwHuAmXmoj1AarnRBatzqkbv7cK5' 'vi+LOJyxZkPE/vCwHuAmXmoj1AarnRBatzqkbv7cK5Ls2ORf'
: 'Ls2ORfwM/vsOG5lURZqXxOnDXPKZw5t5jVzIhFKO0B6D6hAR' 'wM/vsOG5lURZqXxOnDXPKZw5t5jVzIhFKO0B6D6hARSXDR6F'
: 'SXDR6Fzqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpc' 'zqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpcOcOb9u'
: 'OcOb9u63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZL' '63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZLH96SH4'
: 'H96SH4R9xRYApl6q3Y02f+NzlRAl+cZSKhB6qSIVa80fsqMn' 'R9xRYApl6q3Y02f+NzlRAl+cZSKhB6qSIVa80fsqMnWOqZJp'
: 'WOqZJpmsXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIzBKabmLI' 'msXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIzBKabmLIil470z'
: 'il470zfSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KM' 'fSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KMk+l0SO'
: 'k+l0SOXlOopltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXP' 'XlOopltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXPoTe0pn'
: 'oTe0pnu4dYbp7hJ/kxWySN0ey0o/1qbiCsxDXJMWWo37QekB' 'u4dYbp7hJ/kxWySN0ey0o/1qbiCsxDXJMWWo37QekBcAUFPS'
: 'cAUFPSGkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzIq' 'GkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzIqxT4CKs'
: 'xT4CKsPlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugq' 'PlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugqzb7c3Q'
: 'zb7c3Q89u3WQKY9aegbsA/AUJB/bJs6pfJt9BHFEuk5DWITz' '89u3WQKY9aegbsA/AUJB/bJs6pfJt9BHFEuk5DWITzOH5uZS'
: 'OH5uZSThLUsDjQ5GE6RMsyihMTaQLfA6BIiAQMAhnHHN1sd6' 'ThLUsDjQ5GE6RMsyihMTaQLfA6BIiAQMAhnHHN1sd61WtUhD'
: '1WtUhDVJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAX' 'VJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAXNB8sm9'
: 'NB8sm9Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs' 'Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs8C1Okb'
: '8C1Okb2/ggwLdxlDC1D6DFPZDD98txv8xQf5TEc7Ax6ZyaDf' '2/ggwLdxlDC1D6DFPZDD98txv8xQf5TEc7Ax6ZyaDf6BC4Sy'
: '6BC4SylWKCMqtizp80+UMchATal63qHq0M3ZTs83Ob/XO6LY' 'lWKCMqtizp80+UMchATal63qHq0M3ZTs83Ob/XO6LYsFzpGV'
: 'sFzpGVY5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53X' 'Y5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53XStSh1e'
: 'StSh1eogfeojV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7Oam' 'ogfeojV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7OamhjU1HB'
: 'hjU1HB3DLGm66n6iajz4bqn2oICmNFxDR/x2mC5s+rKhlkUA' '3DLGm66n6iajz4bqn2oICmNFxDR/x2mC5s+rKhlkUA3Ne3P8'
: '3Ne3P8lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yjE' 'lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yjEEd9EUh'
: 'Ed9EUhkwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8i' 'kwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8iHPud16'
: 'HPud16wApnCvTOzjIFAj9TQdCxa+ddOTizaa1xJvD0qMrKx+' 'wApnCvTOzjIFAj9TQdCxa+ddOTizaa1xJvD0qMrKx+Ydaj6i'
: 'Ydaj6iwJQG0vaSdYWpTv4HwVRAP3Z6ONjOJunEIeKRVmhujp' 'wJQG0vaSdYWpTv4HwVRAP3Z6ONjOJunEIeKRVmhujpA2+wPm'
: 'A2+wPmQR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGeb' 'QR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGebcMg7Og'
: 'cMg7OgQKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwW' 'QKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwWY1F0Hl'
: 'Y1F0HlBUC2lbyIuYF58O8p+adMwUt9YAoX/IwRtAC9NAdBAy' 'BUC2lbyIuYF58O8p+adMwUt9YAoX/IwRtAC9NAdBAyGuEB3V'
: 'GuEB3VR59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xxfiwtr0G' 'R59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xxfiwtr0GXECqed'
: 'XECqedQQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3' 'QQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3+av4Jc'
: '+av4Jcj78O/vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfR' 'j78O/vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfRVjwfmO'
: 'VjwfmOnNn3GuWR+FzhcPmPqiptHcayacT28T8j3Cs0/LQCwo' 'nNn3GuWR+FzhcPmPqiptHcayacT28T8j3Cs0/LQCwo6J2iYx'
: '6J2iYxP4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbkB' 'P4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbkBYwETNP'
: 'YwETNPt/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjk' 't/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjkji8quL'
: 'ji8quL3cDyW7TpI3unxezMcSTNhQJhfpGctKgKN2Amo7/7Sh' '3cDyW7TpI3unxezMcSTNhQJhfpGctKgKN2Amo7/7ShSev4oX'
: 'Sev4oXicPSYS+6GkCm9a1Qw3VEchCUA+z5HtTcbQhK6F14YF' 'icPSYS+6GkCm9a1Qw3VEchCUA+z5HtTcbQhK6F14YFUp+Yn7'
: 'Up+Yn7WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnT' 'WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnTW61zjQ'
: 'W61zjQ7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9T' '7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9TeNGUHi'
: 'eNGUHibE9Nv//2jRJGZfQmK3v7ykJJOv1IXjBsDCPpmgWppe' 'bE9Nv//2jRJGZfQmK3v7ykJJOv1IXjBsDCPpmgWppe6sHxR3'
: '6sHxR3KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLhdCXKq8u' 'KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLhdCXKq8uR0R+LD'
: 'R0R+LDEqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz' 'EqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz31cuoc'
: '31cuocvoO/qemClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlD' 'voO/qemClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlDpE/oyl'
: 'pE/oylpy+2/6pWXK31PEYagP04epV1cE50UMy6IQZeQM7+Ol' 'py+2/6pWXK31PEYagP04epV1cE50UMy6IQZeQM7+Ol74Z+eH'
: '74Z+eHfpHNc7OjffQ/HeV0X8BopoDkGEkAAA=' 'fpHNc7OjffQ/HeV0X8BopoDkGEkAAA='
: }
: }
: }
: }
: }
: }
: }
: }
: }
: }
: }
]]></artwork>
]]></sourcecode>
</section>
<section anchor="example-full-cert">
<name>Full Certificate Example</name>
<t>The following example contains a certificate for Alice; it is
essentially a renewal of the certificate that appears in <xref target="RFC9216"/>.
Of course, the serial number and issue dates are different. In
addition, Alice's certificate now has a logotype certificate extension. The
extension contains URLs for two community logotype images, both at
fictional URLs. The extension also contains URLs for two subject
organization logotype images, both at fictional URLs. An implementation would
display at most three of these images, both of the community logotype
images and one of the subject organization logotype images. Direct addressing is
used for all of the images, and the images are hashed by SHA-256.</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
-----BEGIN CERTIFICATE-----
MIIFpTCCBI2gAwIBAgITN0EFee11f0Kpolw69Phqzpqx1zANBgkqhkiG9w0BAQ0F
ADBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzExMC8GA1UEAxMo
U2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAgFw0yMjA2
MTUxODE4MThaGA8yMDUyMDkyNzA2NTQxOFowOzENMAsGA1UEChMESUVURjERMA8G
A1UECxMITEFNUFMgV0cxFzAVBgNVBAMTDkFsaWNlIExvdmVsYWNlMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtPSJ6Fg4Fj5Nmn9PkrYo0jTkfCv4TfA/
pdO/KLpZbJOAEr0sI7AjaO7B1GuMUFJeSTulamNfCwDcDkY63PQWl+DILs7GxVwX
urhYdZlaV5hcUqVAckPvedDBc/3rz4D/esFfs+E7QMFtmd+K04s+A8TCNO12DRVB
DpbP4JFD9hsc8prDtpGmFk7rd0q8gqnhxBW2RZAeLqzJOMayCQtws1q7ktkNBR2w
ZX5ICjecF1YJFhX4jrnHwp/iELGqqaNXd3/Y0pG7QFecN7836IPPdfTMSiPR+peC
rhJZwLSewbWXLJe3VMvbvQjoBMpEYlaJBUIKkO1zQ1Pq90njlsJLOwIDAQABo4IC
hDCCAoAwDAYDVR0TAQH/BAIwADAXBgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYD
VR0RBBcwFYETYWxpY2VAc21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZz
MB8GA1UdIwQYMBaAFJEwjnwHFwyn8QkoZTYaZxxodvRZMIIB0AYIKwYBBQUHAQwE
ggHCMIIBvqCB4zCB4KBvMG0wazBpFgppbWFnZS9qcGVnMDEwLzALBglghkgBZQME
AgEEIK/8EBZGy1YltJl95Yk+rjqEb1oC04LW2o7U7vh8vR3tMCgWJmh0dHA6Ly93
d3cuZXhhbXBsZS5uZXQvaW1hZ2VzL2xvZ28uanBnoG0wazBpMGcWCWltYWdlL2dp
ZjAxMC8wCwYJYIZIAWUDBAIBBCCIkIGBrftmri9m0EmgTY6g7E6oZEI4WzZKvyyL
0unpZjAnFiVodHRwOi8vd3d3LmV4YW1wbGUub3JnL2xvZ28taW1hZ2UuZ2lmooHV
oIHSMIHPMGUwYxYJaW1hZ2UvZ2lmMDEwLzALBglghkgBZQMEAgEEIGpYUC5ZZ/nd
0Yr+vQ2x/mClExvfD7K+8LVzRVC6G78ZMCMWIWh0dHA6Ly93d3cuc21pbWUuZXhh
bXBsZS9sb2dvLmdpZjBmMGQWCmltYWdlL2pwZWcwMTAvMAsGCWCGSAFlAwQCAQQg
vct7dXJtjBszpCzerHly2krZ8nmEClhYas4vAoDq16UwIxYhaHR0cDovL3d3dy5z
bWltZS5leGFtcGxlL2xvZ28uanBnMA0GCSqGSIb3DQEBDQUAA4IBAQBbjdCNVFA/
emCc5uKX5WSPrdvRFZSs57SEhE0odxvhTrOs13VM8Om0TxhNJ0Pl6d9CJdbUxtFw
SSnSu9fnghDO7OZDJnPiIYLNY5eTTzY6sx85mde9TLaBTE7RZf0W7NV0hqDqcfM+
9HnQrU4TtPSvtPS5rr5SvqkaMM0k89bpbkgZlh9HH14+x+DIeT0dLythiXJvkVod
qEfyZTcdplQHQ4szWO7lsjmvHrUIbS1tdAJnah8AZRZfqiJEFeiUp06hvAWnPc3y
1TMwYI8onfwPIVzyT6YLgjiT6PuLwSB/wtlhI+vWfdINaHdotegjawLm/3jZ+ceN
tu39FvbV0uKJ
-----END CERTIFICATE-----
]]></artwork>
]]></sourcecode>
<t>The following displays the logotype certificate extension from Alice's
certificate. The values on the left are the ASN.1 tag (in hexadecimal)
and the length (in decimal).</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
30 464: SEQUENCE {
06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
04 450: OCTET STRING, encapsulates {
30 446: SEQUENCE {
A0 227: [0] {
30 224: SEQUENCE {
A0 111: [0] {
30 109: SEQUENCE {
30 107: SEQUENCE {
30 105: SEQUENCE {
16 10: IA5String 'image/jpeg'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: AF FC 10 16 46 CB 56 25 B4 99 7D E5 89 3E AE 3A
: 84 6F 5A 02 D3 82 D6 DA 8E D4 EE F8 7C BD 1D ED
: }
: }
30 40: SEQUENCE {
16 38: IA5String 'http://www.example.net/images/logo.jpg'
: }
: }
: }
: }
: }
A0 109: [0] {
30 107: SEQUENCE {
30 105: SEQUENCE {
30 103: SEQUENCE {
16 9: IA5String 'image/gif'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 88 90 81 81 AD FB 66 AE 2F 66 D0 49 A0 4D 8E A0
: EC 4E A8 64 42 38 5B 36 4A BF 2C 8B D2 E9 E9 66
: }
: }
30 39: SEQUENCE {
16 37: IA5String 'http://www.example.org/logo-image.gif'
: }
: }
: }
: }
: }
: }
: }
A2 213: [2] {
A0 210: [0] {
30 207: SEQUENCE {
30 101: SEQUENCE {
30 99: SEQUENCE {
16 9: IA5String 'image/gif'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: 6A 58 50 2E 59 67 F9 DD D1 8A FE BD 0D B1 FE 60
: A5 13 1B DF 0F B2 BE F0 B5 73 45 50 BA 1B BF 19
: }
: }
30 35: SEQUENCE {
16 33: IA5String 'http://www.smime.example/logo.gif'
: }
: }
: }
30 102: SEQUENCE {
30 100: SEQUENCE {
16 10: IA5String 'image/jpeg'
30 49: SEQUENCE {
30 47: SEQUENCE {
30 11: SEQUENCE {
06 9: OBJECT IDENTIFIER
: sha-256 (2 16 840 1 101 3 4 2 1)
: }
04 32: OCTET STRING
: BD CB 7B 75 72 6D 8C 1B 33 A4 2C DE AC 79 72 DA
: 4A D9 F2 79 84 0A 58 58 6A CE 2F 02 80 EA D7 A5
: }
: }
30 35: SEQUENCE {
16 33: IA5String 'http://www.smime.example/logo.jpg'
: }
: }
: }
: }
: }
: }
: }
: }
: }
]]></artwork>
]]></sourcecode>
</section>
</section>
<section anchor="changes">
<name>Changes Since RFC since RFCs 3709 and RFC 6170</name>
<t>This appendix summarizes the changes since RFC 3709. <xref target="RFC3709"/>. The changes are:</t>
<ul spacing="normal">
<li>Combine RFC RFCs 3709 and RFC 6170 into one document, and encourage
implementers to support the "data" URI scheme (data:...) that was
originally specified in RFC 6170. Merging RFC RFCs 3709 and RFC 6170 lead led
to many editoral editorial changes throughout the document.</li>
<li>Drop SHA-1 as the mandatory-to-implement hash algorithm, and encourage
use of the one-way hash function that is employed by the certificate
signature algorithm.</li>
<li>RFC 3709 required client applications to support both direct and indirect
addressing. This requirement is changed to <bcp14>SHOULD</bcp14> support both direct and
indirect addressing to allow implementations to be more privacy preserving.</li>
<li>Update the reference for language tags to be RFC 5646 instead of
the now obsolete RFC 3066.</li>
<li>Update the reference for the URI Generic Syntax to be RFC 3986 instead
of the now obsolete RFC 2396.</li>
<li>Update the reference for the application/pdf media type to be RFC 8118
instead of the now obsolete RFC 3778.</li>
<li>No longer require support for the FTP scheme (ftp://...) URI.</li>
<li>Require support for the HTTP scheme (http://...) URI and the
HTTPS scheme (https://...) URI.</li>
<li>Provide syntax of the "data" URI scheme using modern ABNF.</li>
<li>Require support for the compressed SVG image format with the
image/svg+xml+gzip media type.</li>
<li>Media types <bcp14>MUST</bcp14> follow the ABNF <xref target="RFC5234"/> that is
provided in Section 4.2 of <xref target="RFC6838"/>. target="RFC9110" sectionFormat="of" section="8.3.1"/>. This change resolves
Errata ID 2679.</li>
<li>Remove the requirement that the LogotypeData file name have
a file extension of ".LTD". This change resolves Errata ID 2325.</li>
<li>Encourage, instead of requiring, each logotype to be represented by
at least one image.</li>
<li>Encourage the inclusion of text-based audio data suitable for
processing by a text-to-speech software using the MIME media type of
"text/plain;charset=UTF-8".</li>
<li>Encourage the use of dithering if an image needs to be scaled.</li>
<li>Require that the logotype certificate extension not contain more than one certificate
image logotype.</li>
<li>Privacy-related topics that were previously discussed in the Security
Considerations section are now covered in a separate Privacy Considerations
section. Additional topics are covered in both sections.</li>
<li>Provide ASN.1 modules for both the older syntax <xref target="OLD-ASN1"/> and the most
recent ASN.1 syntax <xref target="NEW-ASN1"/>.</li>
<li>Provide additional references.</li>
<li>Provide additional examples.</li>
<li>Several editorial changes to improve clarity.</li>
<li>The example in Appendix B.1 <xref target="example-rfc3709"/> was changed to use SHA-256 instead of SHA-1.</li>
</ul>
</section>
<section anchor="acks" numbered="false">
<name>Acknowledgments</name>
<ul spacing="normal">
<li><t>Acknowledgments from RFC 3709</t>
<t>This document is the result of contributions from many
professionals. The authors appreciate contributions from all members
of the IETF PKIX Working Group. We extend a special thanks to <contact fullname="Al
Arsenault"/>, <contact fullname="David Cross"/>, <contact fullname="Tim Polk"/>, <contact fullname="Russel Weiser"/>, <contact fullname="Terry Hayes"/>, <contact fullname="Alex
Deacon"/>, <contact fullname="Andrew Hoag"/>, <contact fullname="Randy Sabett"/>, <contact fullname="Denis Pinkas"/>, <contact fullname="Magnus Nystrom"/>, <contact fullname="Ryan
Hurst"/>, and <contact fullname="Phil Griffin"/> for their efforts and support.</t>
<t><contact fullname="Russ Housley"/> thanks the management at RSA Laboratories, especially
<contact fullname="Burt Kaliski"/>, who supported the development of this specification. The
vast majority of the work on this specification was done while
Russ was employed at RSA Laboratories.</t>
</li>
<li><t>Acknowledgments from RFC 6170</t>
<t>The authors recognize valuable contributions from members of the PKIX
working group, the CA Browser Forum, and <contact fullname="James Manger"/>, for their
review and sample data.</t>
</li>
<li><t>Additional Acknowledgments</t>
<t>Combining RFCs 3709 and 6170 has produced an improved
specification. The authors appreciate contributions from all members
of the IETF LAMPS Working Group. We extend a special thanks to
<contact fullname="Alexey Melnikov"/> for his guidance on media types. We extend a special
thanks to <contact fullname="Tim Geiser"/> for his careful checking of the new examples in
Appendices <xref target="example-rfc6170" format="counter"/> and <xref target="example-full-cert" format="counter"/>. We extend a special thanks to <contact fullname="Corey Bonnell"/>,
<contact fullname="Daniel Kahn Gillmor"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Shuping Peng"/>,
<contact fullname="Sheng Jiang"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Donald Eastlake 3rd"/>, and <contact fullname="Dan Harkins"/>
for their careful review and helpful comments.</t>
</li>
</ul>
</section>
</back>
<!-- ##markdown-source:
H4sIAJ2dlmMAA+y96XbiWLIw+l9PoZv1o5zHYDMbsr869zDa2EwGPPbqdZcA
AbKFhCUBxnnye5b7LPfJbkTsQVtCuLKq+wzfOp3dq9tI2lPs2DFH7HQ6rfmB
4cz+H8N2HfObHngbU7PWHv3lB7lMppLJaTN36hgreD3zjHmQtsxgnraN1dpP
e/Np/iJTmVh+OpvRpkbwTfeDmeZOfNc2A9P/puPrlF7KXsBr1/FNx9/A019x
oF+1tfVN0/XAncKTven/Cj981ws8c+4rT/Yr9UFgBTZM5de2E5ieYwb641kx
U9EHm4ltTfUbc6+3nbln+DDCNNh48GnHXbjBfm36uuXwr+umF1hzCyaMXRqT
iWduf/dDzd9MVpbvW64zhq++6e3muKUZnml800fmdONZwV573cFzPrV0A+Gl
zaDxNz2XyeXSWfhvVtOMTbB0vW9aWmdwHQXm3HD0kQENfd91YNWut4COGr45
1UeuvQlgUF+v1uCNmG3sJbxZu7CZNoI0rbdcz391LGfhT/aO3p6Z1GtaHzXT
uVxev8jonY0zg0dTd+ME3h4m0YRf5sqwbNxE/98Mw0jDCGdTdyUnOtz4vn7l
bnzb3ItJ3lsLy5YASOmdTl2ZZfQtbidsrwl4UsyWdICPY/pby7ZNfegaNB34
6pt+BfCbuU5Kv6/SFGcEQEQiZcJ3o3DCSzanf9vicPFZj2Emrqe3YOCVIYFb
XRkfrqM/mBOYnre1pqavTC9byZb1crDUq1tTTmtkGgFgX0p/CKdVKWcz2WPT
miMyw9j/ZtBgkVl1YEsMbwYLh1MB+GDLic3cialMJV8o6gPDe8WpOBtlNoAy
19A4pdeV6RSz2aNQsj021r8ZOATNRrOcueutjMDamog5w1a9WMnm+J+lbDEr
/syVyvzPcjYr/sTjLb+9yPA/L8pF8UElWxKdVXLZkvwzT9/2O410ddSjMYAQ
GN4CF7wMgrX/7fx8t9udWcHmzHKCc8+cno/Tw2Y9/XiWy5TPTYc1YdRgtDan
7JjCUdDduV6dAPSMaaCP9k5gvOs9N2Dv+o6pn8CQZ9mv1IE4ivh3msG/Xm+P
x/SAndxspVzGY4tPgBIBGQsAiKIJfa0PTQDmynRmbBSaI3zQHvWzlUym+E2d
7L/SD11vuNMNNAl0QEpjYdKfQJDZy6ZtTgPPdYCmzcR3cwvOCdst/D8daPYi
DaRmpa890wccZoPLPgBpAj0LKOCbCJNBo6Vnzwr6CfxxXk0fBwDMWlk+MIEi
/YQRLNNHfPnGB4APETzwQTr7jX8Hz/LwZ+aPL3kApN+YwBLDBbO1HiyIreTi
p+df/mz+NFs2f/xudH85/AQdYd5nMMi5AXxg4eAs/fOVObOMNHGOc2sF6zr3
t4vT95WtgqCLH+nIOABZFhaiJ+0WbuRho4RVPbiePdMfrJlJNKsONB8AZm1W
ylrnBhA/tojnI6tYWMFyM8Gzf77LT3HQ3eIcuNoGJn+RyapTrgLI1gbM09S7
7W5TxxXSfKHRB2EjcEpfd0xzZs4SZjHo/QNAuXYWfwyMosHfBUInThNzZUHc
ihfFoqB+lbKgaLl85UL8mSmIp/lMJi+aleTTUjlflv3mC/zPbKUoKGW5IL+t
ADnHP3vNhz9BKUvlTNIxbAuaD4ALzOnScW13sQ/P2c9QT3GGDkjvxPCBaDm8
ydEzOr5Lq0QWxKNsGmTNIwcVv44R2W96uD46yuftZv2bXi7nCnSac1l2EMbH
QbbLEwKOh+d4+M8HwzR+bzl7kNPwSTabvYiwmalhE4W6B+IMCHfpGeulNfX1
E2j3VceWQJdyUZj8PciIkwDWk+bTOATMQx6WfGzeyH2KlUI5kRT/Hg7U3dV6
A8xFX4hFgp7AjhiwGxekJZjIIoF698xg54K0EgIH6IBEl9bGmeKYhq37PwMl
vq9RmBSO03OGBGzZ/MvrQfPyT4GgAcIkCNQgS62QwaLgT0AASQuXDriOsoDl
bED4TAegQIHIBrIsA5IvJoXD6y1k3aQXTJeGAyBsMdZ2ct1qt44z4oNDArhw
nBsnHpLxWfkiewCfDIi36SJAKJuHd5ft1u8eErGd5/DxOW5demHNyxXjLHgP
VODKbT9c7VGBC1ENZXAE0dT11i7yHJWjZCuVTDpzkc5nj6z93vR8Wi7MCB51
B/k/teOXpgNdT5UdXrlb/GttkTLJDgEwLHdq4RRhNTPL1S2l26iwkgcuip/8
PHrDUj8RV/j25cuwfflv9K2WTqdB3WIUW9PGS2DJUoLiZwwnrk9DXVY330GG
9SXjdKb2Bles2aoKvGY69Svo1EpbDoMg8KwJEIjIq7PY8NIQgKyMbAHUGH+g
unDGJr+yZjPb1LRfEGc8d7YhCqF//8XCnz/4miLkQvc367VNAqSvf//OOfSP
Hyl9B8i3RApF8onG1pBOXIMKEFTTeNc2SBVAterDjv+VwLMB+dlytGBpStU+
xahhkDAPEA9+/IhPIxlcSu+62vtZfBsT4EiD4V8wmApT9gL/+vHjTPv+nZ1A
H76CyWyB2yAq+JvVyvD2iOA4Lv9GB2ybmvSEgU3wdO3Y7o3hU8bv55yuY5dR
VIN1BK4+sRBpVJSChzCSBjMCGhrQXECh5T9OcBL+ZvICjPbrGbANz13hvAGK
08Des8ML/dva1jJ3axcwJQXdwVgLlyj2BnjrxNSN6dIyt3BQJ3sdpUw8y9i1
OirOgg8FkwL6twSutwMxGfbXV2YM07hyd9Cbl6I+8HyjWiUtT1rU8gSM76b9
VV8asJHQynbX5iy2/YYHk9y7ABqcuzaXzBGnBkjhejOYC0BqZZoBDYrCts8I
E7xy9IXtTmDBDmO6hNfaEjDFg4U4JjCmCHHC7YNpMJkZmik0UE4bDrGmmL0Q
Pz1fX238gACKLB4mNMMxVpYTQWh97QIogNqkNGMN6Lb2kErSbm984IkpJJ0b
z0AssxEk7BihPYR0PeSnSMdgN2EWNROewYhwNu09EWGAOBxjwJKV8WoitrC1
AVhnQBuInO2WbP8MDb+2phsbYBxHR7RtAriC5Z7Gh/7NrcH0TdpzCzV81GnE
rCM9rIw9QsJ8N3D9M32OuOkjXgBEZ9Z8bnqAXBqAGUkWKhEI0tHeD0zchqkq
PpH6hD/wNEbAKheihwvRItMAlPDZYfVAAZvTXOBPz3zbACwEeSEoseWwTTjT
uhsgTfzoq9iB0oxB3QDqRRAVpqluKCKZCeukxdEoKzxojioZ/kVfhofFiqIh
rtoN4NBZTGSkecLwHmDfGk4DQma5WcHUaav4Jk1dOL/Uno8CUL3Cr3xc9pwd
lPD0RQZ04BUuZeF6FqP+mr9fTVzbh1PddWGMJetJ8naS+mzzXTkYCDPPZIeT
6IMJpM/ea3xqH7SWkIPirIHKvuIQfJ64D0T4aFkAF2eBWwiiEezFXqzxw2Q4
BavaWniEzfc1CgNwbJS+EA05DmrqWnGlrjO34DhBpxZyd4AaoCZMnajLGYlL
e31u7ujAAYvxgEPBGg3bxkkYQKltJA7eijNK3BNmgqZ5GgvPJCoAXNGYTs11
gDtmoMiCdtSUDgQGcZc+RnHUdaBjVChdsaVAvKwtPzxawkLjew57XQUmwogA
Q17LF4iACDUBsoKIA6vj5lzB8Dy2iDWTLLQt7IHrIULCwQTcgh0LGEF1TEEP
fHfjTUkIQmgCRMQC0SS3gA23GawnQHZN00HLu0VnAYmlul3UH0MTXUUTDajc
zCTsSAmw8V/YQiIRLLvGF0aH0PZdfY2WPh9Hg2PKGJkUiyyknyQzQE+hWBf7
amp4M3i/BmQHWRs/neFueL/6IPxMQTAECo7Lhk3n32oLAyQQIvesLZvl3rCJ
IsMjgHv76FyAVyKScjKEiMM+3RMNWro2sjnDjxA7XKePAgV/szJXE9PThMgC
WLUB1ECuPFZ/07nwTLKIOoxnAnP3pyB+ISaglKFxgFPXoLK7hKwLz92sP11F
ioTi5d4nwQNPXCrEbhTjomefExjYX5DdbCLvprMk5kfERlNJGjZgJ4PLgkc3
FjmUac/ZuvcaLpfQgu0245doGANGgF1yNMPR4VC7O2C8CyIGICN5PtFebeMw
1QQoD7DSzVqIfsi2SCSMMIO1jUOCqAZ8ZmvYOCUPVogTN0OrtfnOpcqUtpPM
krMcmKjPZcWIwhFRJXT9wST6hEdY5XxpkDiRR0UBFBfofZoLW4T2yy+qJ493
ENvo779g8zR1+4OJtihsEXNizEjdr5m5BmT2iaAtUSZwQHPENZDgr0V1DY8I
w4zmKPh65AsaCKVkU98C72YylsZGJfkL8XKuH/TKmlDfKC3ClADFthbsAD92
wOfgBfBusaWM3QC1FJIwUSyLmL8/JSJMYgDQamJxKBzDUdrYwYFkn7wPnCST
iOwkIDpQsaW1WBI9ZGJXinNKkqoMLg/hyda0JqDN2mac10epJbISjvHfNO1f
yISGxxoXE50QAJykSLZQ/s5kkpO7g10D7ZoTlZ05QcHpDDscmEjJ0+g4k7iM
cJoA6jowwXTgpsXf+kktV/uago7Ut4K34tv61xRnQnBkAkmu+EpowKYYBHkR
kN4pP6WS3PokQTJxi79HKgeUbR32cudIeQUYTzjDCOBOrDPzLAUymJNuNtqR
d1+plwcLNweaTW0LzzeSBwTclDFCpCWCa0kuCw1JkIqMxF8yMi/RmaGWgRiL
/IfRbegUdTlSsxnGMWqNG48YMd/Yv4t9mpAMgXgg+kkED0BhYFsOMFzHhG4c
Ft/5cuAUzkJjGOPrnJfAaGzerEH8OBBBRjsF98iT4gdqBlDoF9gymBkc6xVO
rWV5fsB0SKk2i2kc6M7uHLimxgWqJTqM4dM5atNMasZNlNowLZYkIBTZaAiN
z17a54l7xvVzN9SomWWDJHTqTpujLDOzkdO2A6Ek4HthGhacTiefpKDnIbvT
Dsgn4gpyXiaDWQuOLUsDhBof9AaHUSmmeuKc3Zmx/zWGxTNXwzni1n66szGu
QpskDQSzDchiIFO5zBLjkbLkzQ0marc2HsI9hfR9Hx0dya9y1JBcI6JH9XuU
4gX9Roai9AAcBA0SuMCZS8DeAS3EuYD46PqxnuAxAwZABdg452kjweMQRmqo
imBmjAkCN0PHDZC2jUoSfUCtHS4jsi5S9PkUFAaEC4yrhLvIEaOGbEA8tEAn
7CiiETRAL4cTPwdZ0iUDenRv2g7MaoVCJomgtKsJs9SmbFoRHQ/PJped4qCb
W3bA1BEy7pHMw5RPC5W5iKqqrgbw422DojwcCFQQkOMukWyByhU7QkKX5Rut
0DoVLugjYEdwJWx84a4QWq7Q4cptLIYQgbksw1QQoTSDGAZHZ6qh9M1gi93t
ADvMgIEyiPSfIjk4ACRDZRCdrvhjirPXOJkmMxn1N3VtF8Bhc5soY0BSxdK0
tmKbEjTet1YWyu1oEoU9JvqUKJExusTQiks+SD0Q9aOaEtMCZzBRGHVj+VG5
ihap2Itj0iRqbhGxlZs/NWZGE1SC0zAhJbqrieVIWgl6cihIjIlCAkLI4wXb
NXG5rLhhQRbhDHaWbZPGQLSDY7RBVhOJZn5ouILzFRo7sLM4cwHaaxEL85hd
zFohlA3ScYyAvQCM1QwOsCnramqbsCeGN12CZIPEilP40NYov1c0Wo3ZlYiZ
cnXGJQspWrMEFwGpwF2RG0SZKejXXlQqT6L+TK1Q9CWYOzMSWKuIzE3kGFhY
oEj5jANhXJ3B1k7mJdVARagnHJhMUIhMy5/CCTQZm5ezUJwi3bvRWO/1xySR
Omi5QHUbe4QT7JCOJhev4CTJv8CpdVCLLB4KZEjPBRPSv38fcZpdQjhKzwUa
OBLgGXapzl+aCX2pT+CRAjad5nZt9eAhtUTNgnpANWSKUiUX5LjlUCPTrdCm
DRsNZcGSSZtERyLjWweLUtcxjuCGYu0MPRDSDCxwNyaSaARBhvUz12TSCAg9
7L2yZuEkwCnR0m2mScGZUy3ACqNIoZiS1IO7WSwDrlLRUWRsHWgw2aYjtgku
/DJw4WH1TF3o0IxFiYONZIpvbNT0i/SBGbKJ5UVaS7IAKDrZBMxCgWYa0jrJ
Nck4nSpQUGDae4A0Z+va27jQzag2jSV5gp8S6lF0u2Zk7iRxbA4KEAMESGrA
eIAKc6hJ/pkkVTLvDghn/msqnIgUqUn2tZD4GN7EwiAe2BTeDYaxRvpSUU87
AifB8eAUc8GXL53AjJ/NJN5oMBZJjq7OrJdkzXg3pxvGWSlaEj2cxnSJenQK
v0SFCAgJZ8mGrcVRCmQaNK8wCweTDJmYavloMWHM1UAdExipu6MdYV4+6bvA
qZK8jyjIyJYbNTswHZJZS7XQzsgPXQIh51pjHPlCuhxxRgg9g5wwcBpghSB7
zbitSRASZhlHyAADJVULoxvIjXYwGG723J1u+FoSCBvz+XAejgYLdbvVnWR7
RVQjuXMFUBr363CUPjAvM4B57ODGzoQQjz8HnKYCjnQGbMTdAuhfQUBK+sAC
7Gg02CSYMTPZEP/5/t03p2QtIOqJYsiYqDtzzH3/hQzxXMxAX9oObQL6F2RS
X1Ls/5FZ4d/D5u1de9hs4N+jq2qnI//Q+Bejq/5dpxH+Fbas97vdZq/BGiPz
izzSvnSrT1+YIPilPxi3+71q5wuzVqqu6tAsJVk3shwfCCIzwhLDqNUH/9//
my3A2v8vjJjLZtGNzX6UsxcFcqCbXOwkuYD9RIcCuhZNIunkpZgaawzSQdnK
57ojbh+aMf6KkPnbN/1/TabrbOFf+QNccOShgFnkIcHs8MlBYwbEhEcJw0ho
Rp7HIB2db/Up8lvAXXmICKM3hNeRIiNJQIskM8R0Qyl3JcdWMJHAPzTWBkv0
+1DGCCoJUnCivsgMV5dmePESn7YR+z2MeDEcQbnV9yPBgZM/iNr35aicjaCf
G4VasnILT2LoHGgHmmL0C81WcN6I9GMLLjMdWpRjWp6/QeqDHkMyXtCqmCOO
C+yHk0S12U2T5iSsR9xlH36sOvoXINmKL1R6BtBHzzQqZHbU9OYzlx7tIw1J
cWmi70noPULCKtxxwsugOHmk7VLIBGwsELpI6EDkws80sezQ38Cmq+ptXFfU
T5jR1tfv26MqAbRroGeiDh1hWEc9Bl4BTtF3ROUOV6Up4A2lQiaeWWvhMIm1
joMd5aFP8JLcbeEv6VHidnMt0khiGFI6xUUpVsVCHBjMVZxCTegz3P+zk+C7
KyRbZXQ9OjrITMaM+XaFyHbkeHM3fjRoEzUJQKcZswippIL51KJdcLwi9ji1
QQfA0CJ1qSKKYUL+JZcL9mJZnJsePte4XGJafNApYaPojQdByM/lC1JcQGJ2
0jTbHz804VcW3IzYsSSlegM1zpB8plED/R0SunP52hXbAEb6Gd94LC1psXgy
WCgh/kSqJSUsJpIQ4xKGlbChYrniLzWigLIrhKpgGrjd1JLi98JP5hGzLYel
ahGi4Apyyk/E0USnsqHfDdtcAY+6VYTZSKBUZOFseDyS6R0c9aXhL4VTVw40
45M/RFmGAuRGme7ToYSHUU0BjE/r98yVG8SHZWRMp5DHjceoBWYoxjUXHm2k
8Q+kJfogXOZwdooFAa2OZjBdagfrTyWou4zy0Uhrd72xSYOKfqXJvlNRq5ri
3KYOMP7HjGpQ/A2nqtrRWXM/E3OjsTgxV85L8eRI1kzYqmlVNK86lC9h71M6
OupnM+FgjO5CEtSIL84s4B6BBtTI41L1ieHHjir1a87SdAB+/PgaGhSsFf5p
zgRmaCFGMBsid9du1rj/5s6UCBCN6hOBTkSiQMinmEGcpoNRhwBAj5RAopNo
nzzUfJGk81gwdk4ZuQL6Gafeuo9kGRj4htgSZZXhQsMQMoZrGEEAY3EvIFlm
YfKII34qFu1ApDWkqDg+mh8CDXVX1fwcnVt0agrD4aIst7jB+BprxyWZnTWD
/xeaZimjr61302YQz2UiPw2QylGjlAbGQlF9nS2Kr1X4OcxCzfyAIcHCNc+Z
ZyYe6WGQJQUDrn08BmTeViCqS4hijA/PnOXBLIaz2GDcPgFMlwDTpLETx/9J
gMnDAkeLOSoV8q5H4t4UNXKyZw0CNw3cxIStFM4Pin6CAYSPj3YRPuVGgii9
D/kwhiOYk6h/h/FgFB5YK+rGoqiOKRNfcLVfDDv4giYQEba8NeyNyWN0r8bd
DkegE2u1+IphH8irSOmmI89hKVpNeFgheSkEN6W4eAzIl3OeKeNjF1+UsGna
BYPzPuRkcxXs0heLWEpPDohHqPMA3UBLhxm6dQHwUVlRPR08koGOlvqceLIm
jsbW8CzDYS5rDy2J9v7YGQcE61iv5s7C1F0L45E+WYel4FrSTFW0JHO2k4Ct
JD0kzTR6ZlTudgYI56/dV+hvhZ6SRewgyePC3FYsSgf3j/UvAsc/GYC76I8D
HgU3+VaLL1bnpmnef0TSjGDUIcNJHXBALqUTsDEClYXgMNXQ3/BYGW6oFkAV
boiD3Q63GRNbbAR29AhK7wI3DcZWmUih8WjJdtFGKlmP7DuTBZ19DDgnvmnG
D4Sh0M/AWjGCw4M/utUn9O1tbCDGGFGOorWYODy01pGoV5hIyMCi8j861BGk
LKgnhekTSMpFZ5RAlaANhb3syNBI0W68ESO/h3p3SkezuRVImGkHU2bwTTwN
h/1hLFKEtwqug1wxgko04MSMn1pD5cGK5M+2CkPueaSNiiicm4iowZgZ0p3P
0xiSGUsbIBcuRmMvoqJXTJdpSlH1+y+oA0k9hnunwswhAgtLBGXi4Qp9yFMJ
MikNJsqU3KIZDscz39ioaUYPuHEzyRMHyDcxI6f5SFqSpjihSOdLTrlRknTO
jg7K91DRqCfsgDMjPzlgaONC25L3TdP+N/zDXC1rlgbtUHas92vXzfpYbzea
vXG71W4Odf3bt994Vtd3IDvuSfarMlpaRf+T/FfQR2cnpa/MouqYwQnP3Wdp
Yqy0xknxK1BqDCGz/JWPv9av1vvJxVc2Gxwgm9N/sDmyrU72d6IdDV2Q0CmK
G7B/nYgEzwP1FF0tWBINFPo3k+R1yis7kOqRKh7HdKHhTlypEbBwpOSOYhSc
DsYBoRV9HvSQOogZTewkOjVNTEVXpiK8L7HnAmtjOTgTd3MgqR9YhtjkQMEG
yQyzm4QqbSVp8JyI6HqXEzeNGsbPDlP0xbrwF5PMIvpIKItwyiT6JE2dSXQH
Xae4UYe53KWlM2QEqrYvQw/OMMU2DjMOZ59FTHBx9WXjB4w3onkXExeMUOXk
+bYKUCTT9FQ85duUsIHhRvExiLfKlj5zKNN58dD1h6sQNoow4YQkBBkep245
d9YyxsTFA9pgTVpKgJYqEmZ8KeTdPJy2gJWmwiqGWYfyI4WyKeDjA3laROLA
zIMjp1CdgmIBjHRKCBi4GsMw5Pksb+8AzbjBiwiSGg7K7DihdxtE9kgCAVP4
dWNrWDb3QzPjEAuPYZK1EGGg743Dw6o0ssuww0TxtKiU4L7DlLlthjXiBz/w
0BrJ7Jlo8OJnVeiXqC6ih/kAMgQB3ocwH12Nx4MRjz7RT0SW9dnZ2VeNC7P4
ReQD/l7n7xvVcVW+Jzsif8/yQSvlEvK1SJ7iF/zsC82dN1TJPTlPRah30haf
cdEkRk49E9irCeSAZUVJZoDMAp1QZCuVIeS0LJoiFrTgKatyvfTZuDNiX2D1
C8zkxUIjmwmDc4BBAOTo51qFT+JQ4E5ZCtcnPIXERTHrKDw0Dg8aFit4wMQQ
7w43k/l1uf0piryaEnioSj09N1DCW47vPBnsLI8LWkrkkLCiR+MuMUpOBmIY
jP2TzuGYgqi2RMwOGqtEuN1RxBLpjIaPtnHuQGPghLFAnpjZDMl9l/VENDwm
+zFaKM1x3HobmAuPeVo+E7QozCQqXDFxU0hUQv4AGdJBwUkfNW/vmr16U/+O
YpCU1vE7X9f/mvmb3nwcdNr19jj8tN+Ssi8ZHYRVPEUCG+l/+J4JVX/NKl0c
b8a1Fdnur7mfaka7yidLzfJHJtwXH4p+pNR3+E+MACKeFhkaAVa/6rcFuDhy
y38ILtEADy0DiBP9DAEiPhpKd4AyFB33w71hLCX8l7gd9E0EQowlKXOE4ZOa
kg0peenU6ZEJNUxgSjZBX86fPUrJbwh27F+kz8h2qiOyuRyOSGv5nRENaQuL
jhjayJJGFJ0ejklllKhIEq8cUS2OAo9k3nSaFXOiT5hBgNyDLDWcqZGfoBn+
gy4wSnmFQYhYM0+e7CukDOouj9rPTf0ke3bWrT5+xY3DL6r2ourM7lGQTKmt
kUF93lou42CnJaZH4RCEIDjAdWpHMGo0W9W7zpgHPWM7LNowQvu+gF9v3Lxs
DlO0dox9ngYmWpEzv20cGQiJDd/VVvGGVxi3hvKhzZwHqMuSzRtb7j9reY8c
YJrYLjRkJyDrMHwZOV/SQCvgUvibAtwQ12hwrPeA1av0jmg1NhYx+BMcEf58
2qDVLjxjjwWTzJPM1xSDLSqh8Z1TphinVM5mVcOgB5UKhGChqYWNMTWL6jWg
awehQ/uPMp8CWCTQYoZscb0NZpWymAkbnV0uZoJSeQrH9GOn+wiW/WlsQYPU
2FodbbiybGDzlMuT1ByVfce0/cTmka9Tn59o+Dz728p1gMHnfqPMUfir8Nvb
hkpyosAO+t8QRXwGxXwIRYlW1MuIp+vhJrB5/6Ow7YAVJuyDICSC8B2YXThr
m6usJcqnFewM2dzhSCDvjkjv4xTvjxE82ZpTvJ8jeEc2boB+GxILF6ZixFX5
8rGmXN/zIqqmpsWmnLD8JftC9lUV4eJtaQ1Lie9YH+xfvz5ugoQzHrZ7l9IU
RV6ADVfDDyRvpsIgoE5UsH1lVhEWw64J0dujbIaoVk4ipjShGDK5P6quUxeN
5jANG+7OhG4v1SJu/lSBihZyxU0oBGLBQoVPzBf+h4gQK6enCVMjV9HPIvBI
gIbxM2NqsTEbCSCJjDlWPg7xHkWCuKyhVMMw31HZskCtF1bQfcR+kmjzgWZA
Itw9j9IP80oxzVgqkYmYSXpelauhYfRZaJZiDhtjulS7Ek484ETTDYsW4eaY
3RKz1qWBRXbNlfVkm5VMOFGKgEk0icRlWAvHYHYhDAEkwxiBJ5wvs/HRuNUn
uSJmaVCMbVK99TXuyGOdRWNoOAgY4qhupNCGLfcgpbHMIEWtx6hkSi49UOos
WXCB2faUwTAzg3IwV4YwqShvP4uPIf9SWFQU7TM+QwnGs4S1nVwFUYdYjFzx
E5wYbcKjhUJpGMBgz6LuUFZUylloYmNlPHo8Uwa7r9Z6LZHtki+ERbUomFsk
9hTOcjhnVoirnC//+IGmWbHY6G6HgrQMz+Kr5mYBWT8jnnFD4BD+kx+p0Gao
/WQH9LHsQFAeyazVHJ9U1K0fGIvIUeEQKaHdhtNK1W3AVq144w8jCXF+oO7/
qxJALJp/Y6UPokp+mJWdimw7isQ0szAuRCVJoheL8vPg1LIybfFQK11xCBtz
EO/onMcrjbCZcEu46g/EIgwo+BymYmEpqXo1+oSFJ0pvFbQ7jHeLjSmNzGj/
4WEumAF8ADvSLskgHAtYCR35kVjpWJJr2KOmR0zKKuz3IT9hISQynBmmxAoz
eSSvsrh9HkE9ojRfQYEAhtOliynHgXTtUq7rxDfF+YceBJCj/ln/L/iaZ0Xi
VtI8KBkhNM1peggqw5r5qqE3LBXC6QUmIMmZh/5NXa50jhn8MsqW95uSRk3G
oT/tAZN34x2c4QHgMcl9NbI3ehQUY1VsK9Rdip2CQMYi/+pHvOt8zQlTpKgO
PxBwTPHaSERUGJypb8I9fKnp0SBmMiv4geuFQRiR96GDVm4RP3aMTJ8QO2c+
ReOI1zfi6I0ena98ZQq4jp1VflKj7X/irMbi/v5VJjJ8snuqzfCPbR9v+d95
/0T4xj90A1WI/Qfv4JiCkFlxL39prWVsowL/GBD4kecvtcQw/pAyHO2cYz5V
1mMQU54m5wZwj1BC8IvGHJ/hUCSuwkrDQAbWswin5mUbeXohpjvjbRhSUo+0
oQJzS3P6mgwQJRLI06a2Ya18VlNRLjBhxsTQ3U3giwhjf+pSOJx2GI6PSfrO
FvdbeLEPLYHff2HSEer6P7hgE9GUDpuoIWPcfS3PFHXGBI1QXpPnLOpBU5wY
MlAGdxUwloqXWqxSD4KdGQsRIsz4R6fGj516T9RzNmeSM5IVEItYRCReEe5L
qzXCiM2MfvJheu7XCLlxXLVnLdKzKvmJ/rDMDPYiAgAQw8Q0OXL7psZfMumC
eVajVR2pf/4VpymHal88mPHgC+7ZmyCeGDzhe26p7J4NpFiplYw4uecpHlDG
b88QKgQLc9rrVCWVYhTwPOLblUGB5bMNChFMVFKrDrDJkfCEcVmYJg7TCwNE
FFMtI5DkopttnJkoPooJjdH9FBHLGhYuSRb9z1hWjEDtg1EYtDSAlruyAlJY
BWTVIWBwLP24D6XLeN1OEcol3KBtFnfx/ZdYYD5F5x6iJsM/ri6JmKFkgw9L
jGWtOMnnjEjZYtl7cgYG04SRL3GH76GzFzaXcRhm3uF65oG/XJOqi0IjKNaC
1ZlAakRZxUoIGPax8Wy0en37jXX57Yv+V6aL0qz/Br++/AUDuEuFL/DrS+oL
8yfruvIVtv4rU5K/nH9Bkssb/8sJtP4Sorj+VQzLjW3Q8F9gBtOl4ZGtWX6I
b0IG+OW3L+xAquY4meSjYImakZPgyj0Adwi/VIwwThX6jR77PaWOjpdKlHmo
slvOgQ0qGp6HbhFeS1pXvVoRI4ScU+dMjKW6sTmmiX6VYMOIa0sG4dL9TKpF
aWsqscgsywnZnr6jOlPk4Z6YmMG8NGbhiFgwDgWAhFg6A0nIayzwSBov8ST2
+uPmN73qH4nxCKujsqh6gxtGmfGT5flrRKvoJUAmdbDZvsg5sPdUMMG2gICI
/Ly9Bm1A1XEWwPnoDXC8IJAlbZkhC6Pc2SbjWqAF0X2es3smVhFPd1PqIU4N
pGUbn8fNSdqOCbFEfzR1u2Ll05TEWgrkVgIyeCcHoeCy2ghWDRBM+KCM1cRE
k9GGw1YEJnECSb4KJQGbh7qyJMPQLuLH4kuVsIDD1CclVvbHV5Gkx21mmggQ
DigKkUdTq7WIZClinaeICdaNSVBYgyzF+VoQlqP1U9H6qEhIQDIETohlp5Ls
n1pMrldLaUcqlSg1KkNeJPJOY0HjJGkAN9rM5yijSnO1UpNYFAUCIMmgZKXm
tTCFqgVaSUIWEOYYgSZQz1TL5LEM6OlBbBFNAVPhE7Nc1a45+eG1QcieIUVA
QBWMx2Y1dKWxTEWWdFYIr4YstisHY+YUKUaF2JOSce+REGZNSPEzikxOiw4P
02wjgcz4bUIAMzqFvlNo8av1rucy6DkLG8jOk7xwYVvqOys9QdWDRVIUn5RZ
Y3bbEBISFTUpubN+AKkXwPZkJRBuxU3AU0ATpgwdFneOtxC6nHJ6Y+NpWI9a
1PUPlRk9qsxEFfdozLvMK4ra4zox+LBEqOg3B4hyzF6nfWav+ylrnXbcWieV
g4PpsLzliMVOS7LY/TF7naZa2xJG/EnTnXZouvussyNWPDrZanR6zZi+Yn1p
xaEWPei58KCrqDYJ2/3cudeOpy6Io6n0+RNHX/38906yml5g/t46PjvaGi/K
J3NoQy6CsorSm1Rg4qeUXFznFMwoCoQwt5HEqoRGHJ/C/jVFMGTVsyeAqa8s
aZLLJ1hfT5TNJ2bGjxUlga+FiBGf8yenXwTnqiRAC4tgfA7WJOxjbqVkxMsn
Ix5b9z8M57Drtpra9ynKhV//Hsblj2JcdAFRZCN6klReUDu4vGay5yorqf+m
gX5GLETMMzpj9y4EsmiwKCKrn9y1v/5D9jq6IJRAeDpwtHAVbiRbGrsphurJ
sksicEP4vKUAKCONo8tm3rh/0auiAqkMOeY1dKZU9JYHIMlyzqo7f0YeF6VK
nuhKziu86yTkpuGNPLJ1WAgNP4sMQeVrTCpoyqpfy/nyMGqRvSZ98ViCjCc2
RWsC8kI1OCxW5Z2p9eAwIoTfVPPTc6fSvtGps2e/+jGbszJrsgeRfZ65wnkx
XSdiZYpV2SNVlJkgafc/qdQNBK8tZtqVF7BqFBKl3Ft0ZLswa5R2gGVc2DFr
vR/RtpSaraoctQqZJWfh5NUTt7mMo/pLVJWLnDR+Wwu665dY8dZZULwMK+ZM
JBra70zbTgtJPLTGktFGIoEAiLSIwETuHCp+TqtV1BYs6A06aNqdA1cEbHh1
3J1tzjBfh3TTY1f1pA56okp/qGRiF/SWEmR0gaUMjXgkk3DAiMpNsSpVct4C
h+nmOMNmkY2piEeiZ6woA4nuhk7pZjClLGWHJ1lg8Y74VLEKhtgTekf3xPBK
JphkO2fxZyTyUYlzUj2NiWnLtGkya/Gdv2vzXCLcT2Fh4gX+pIYfgcaJ3Lqv
migDIMrkBPJWFBUPBGtX1wFqsnq5Err9j0PSiNbXlVIuxc0scctc4fUwJV6T
RkJIRcdABFRE4hQOKbpgngYvqxgIIq0dEukkcQXWj3zJDy0b4Qli3pPDMWXP
PlmcD7MT48q87Jt7cbjnh+q9yFpHhh/epIX0AuCkEf3hRqT4BQCWzIrj5PhA
Y48eooVFJnpjBsgaJwn8AIrguIi9UWNl6wy6jctPgCOrXKcst86MCfHHzDUf
f8p9vtFL03gP0XpBvmC/zBTDBVT8bhOtJ8rgvTTttR8BEbvKwNVB4APiHAhF
lL9mt5WJbtcbj2q4J1aoYedms5ZZpdKzJyulGtHJY7iosGV4K8ItqjUbSury
uhu68khEP0I7Fdv+FJJHstmOtkvYExZfd7iD6sLInBc/mtG8JDLqcuGPFyjR
+K4lSFJBHHQJcXD8Ch9Nqx5elsECdC4lXO9w09uhQHkJEqUQNtU+CTlQN5du
uYSTz8urUEnNo5CMNIwVxz8YMfQuibL1vIg7z/wkisQN9wl1gkWxDCpOQAb/
I1cZkG0tYj39+dIA0RtLY5fzHDP+HdYHiYJCi15LKEV5EROnWF/DkoCH9W81
NePPUwoxi3vSpmGFR5OuklKPtupA15QLpmKW4Ejt6ghR9cyF4c1I3GElJjV2
lxnDWyNhwmyr7titpSI19PsvsOy05aS5kegHFgWz9cFNG/loxLYvIlCi4JPX
PFDO4ZYV5dVkQYNjdyOKOt31qiyxe0QIE8wS5QWHfRy7oUAsUMnBTGmhJ0wJ
p2G10sO7Kykcgvl5q/OAJpbQLd0SIa6ywfPHdRQeXYnJzrLw3J6tTNRgjXEG
fIgrDssLHJo/wonT9QNJLlJxK4kwq4ktQO9CaOCjEuWcJ5OEGS98HRzpAtQd
1GatgEUWKp+p6dgyNdcIncOh2h420uQBA0DR96CVeh7eUhHeNihL1jChihCJ
SB751BxXS9DBd8anxYJQQN54FCopPBS+xm9sEWW+EMIhqjL9wvX9NOuGsByj
vNnNjOyCU7xxlkKLSVqo8rtiwk0TF0WFmyXq9oTFovGupqjwbs2PHStWPNun
iChe0Qoddkv0T2osogpaML3zZONQCUEYFW9x2X/VIwpA6PgJqQ9I12hFDyU8
EtdMES4vAqvn1oLfloOX3vjuWeRKbi1UACKBQRIvfDfEf3FcYgulWqBccWac
jkuvpHJNsDDi4V26UgXR+P1J7I6gpYtac+ymN1ZrwDKjDfmaAZVQ6URDArFn
Y33wOcAxYCKUo0Qf42qMpH3DSmUbx2EFT+AUOUpo/8F58ZVLYdXFKTfJUSg0
Rutzne2zKXI8IbO4HIG7HtnhnsXqRKX08CJl7j1jtDKVEN+LS0np7H88Dc+Q
I5PxYjhwLOqAVf1XLljRZO463295OZ4RczvyWsyuO9P45clKEj0TGFCt/Kw5
QC2wyawClCXeyZaFVEcKXoGGaKzRKCzvJuHQnLnT19B7hffjUQXAmd6p9pRp
pZi3SrYCmYW9E7X1cKvERAxbXGbNoKReIyB8UcrlQDHqKbzqCs7v+eYxwo2a
ABbSoHQTRRBR5HVNVOLFelQRNKVDGvAdCi9IiFwopfGh/IOxRMViw1aG/aOI
SDgTue2HF0Q0pFshIheL3KLQBItkglJGomwKpFLpE3N0pV6my9ReJHFh6TIf
rffyNnkS38nOwF4cNFTLnjlhgc8I3xMV4rS4X1AY86N+kITSbxFrNb+/Xd0n
dl3ki0iJYpMkHizMaREVK3KvdLLLRR0NOauhEUXkTkF5CY201kWj0uqMUhLN
E2jErldDQB3hFPGgEKD+ETMr1+DVus0xbV7Q31C01EwKnGTlpy2MWMCLM9mx
Jqirx4Qp4YfXOKnUWlGrwkuxgmVkeippTOkYtAJygMb2g+914JnGipm1KHJF
Zxt5JiP1jkgNMUEtQXg9etF6KGQclDuMlCQk2+BhMIkRxEwWoHMwnxCrH+fL
GF9ZQa7qWExz4vWgwnsYBB/gqB1GojH7PoZW+pyLcBurGnopfcPRUFaZ0MVR
mPXFr+KdiWoteLJ45bBIPhY3UfqxME/eF2aUk2YRin+aetPwLCRHMrZFzJYb
RDUFOw+qiWNFRy5283MbmYSm/bso04f//p2tVaknQQ/Dkn7hs2FYM+sn/v17
OLP/mz2Aga8HzUv5nuZ1/rI2F0qjs5f14n9NvPN/PRMv/h3kYmz34wc9ZyGe
GUpHOzJwpJYRG/iy3Qrfs4EXIFCrA0d+i4Gh3c+Omzzw6P4yfM8G9reL0/eV
LQeG34cDQ7uxHBl+DI8Oi9/HSuyJgU/1y+f2ID7w6eLDWvOBPxis4a+zxUfi
wM+fjJy44kHvYMVrZ6E2Oov8Fituj/rZYqVQloNDR8fGTlzxoKHsseIeOF/P
5mLgWcIew8D5XCaTkQPjTCqZTFHd+XI2CzPDFSvni1b8/ZseoVZpRizourLf
vkTo2pcfIihyLKIxxabgfYMok+D5VwJd8dZHOOhYn1ycJrQpsAKoWK2JOOre
DESwqbwdnGhtu9qrnskgAKzYQXO7B+EJaAy3Q4L2Cfv8NQzkRiKUilyjJl5p
yizZRVtMPkJkG1sOOdSRvkk8CkNziC5TvzAxXuVLEfbUFAoZMozdKp4U1ZmO
BJ0Mp0zEA46FN5MMeQytFl71jnc0t7GoQLTkn8ruuRtO5KhIR284PD7C7ail
9DoJ6o1UNH9YpAdnC2fZswLLEGYQOPvJxfzKLnv+VZjXowNoejhEUaQgxwZ4
7HaUQgBcHMNRaUdkTi+mL8xR/zjJvGeqX5ljnBxzzgzdn/heP2n2O1/DsFAm
domgaCbdshhrHhytQitEOKQ+KmKHIMDLvVDqF4iKFcyY5VVV8UAsMqmKoSjd
bAoLPDeOMTRamgb6TFiEPgab1JnhOT2mzLzIOVNfN7EeBCzmm44UkRpr4mpV
VDkZblOFFy5mSUSIUnJ+uytfJSE4EV6iHNlKMYdF8Q7viiSqLqEFUqHzx2Cl
J8BKU2AVlrhAcUMFCgcZIySOewAR/p7NTVKByJTie4t3LCvz55e7Reo3aAed
JIXZH0BBXJ9AcAXt0qWrrOm8A5aGSOpHYWxMoEsFupGBZbm/Ty/6SMh76ETy
HsI+I6GDSuGAOJw0ZnwR7r3ImU2hZdBlSXi8AanvSqFJcXg1eXh/7+iGp3Fi
BStjHSfz2BxZtsqARdZQmIvFJWze0wC1GmQkDXEzHJcoT4AHf1Xui1NJpMpo
NTm80CFItp4IMTWxPoPgLTDGeVVX2fQZahCsRluoQURKIGD9haicTIRE2qep
bUSYwRG7gzx/xbrRvn+HR3iBHTPmhEUugC58oS/PVyC2fuEVOzOZPCYixYeO
VR0OL5JQ6/4mDoGfnoOeZTl/wQ32zeC3u3ErXf5ydrC+Qz1AXQlF5CSOK3H+
Z4eOV28VdrlPbrzQedImqjPsogqlUAir4B/qcdFSFzylKJ1QRi9W+oYVNFcq
jsgSF1yvxtmdYVdCK8NEzZQs3MVLSIs6XNLrrWQbxsaWTuUwPVP2r9TZ4j19
0hFZBnj5HrwJnlUBp2AevIqB7/D3X6S74Bh6/2Rlf5bcoJ0kJf2muIM0Fab2
kgREOPWVR/cqthbcPW6xcXVjNbEWGwrB8sUxnlhMx45kSMvKyOR/5zgXTk+G
qMRCXED//RIpRULYGMmuIQcz2ZZEIRUrYLKgnBHlAWORZh7o58nCIBbdPBop
sRy1yNBVs0tqjdZGb/9pXZsz1cWNNhi6tS80JlEkHoZf2swBCSRwA7sdBuLA
ejHMi6W48LsSRGNRe4V5fRlrtyOjkflo53q+ye9O9HU4WpgXFZkBPzI7YQCl
6w15AR2S+A3dBj0jIItM9H4TJ6F8AUMGsrEH6BuGthhRIgVVg0VjMxsgoprc
JRlJx65cMElOoAtAlbgRccFW6O4yyLwlN0AJwkAvuPTCicriMfOUoQUeyD50
46QrL4OmnxOW1DBzKdsZHVxV/+B2NS0E5glRIHdloumV3VALB3hrUogH3YTL
Y/LWLnD68L5lcn36mpLYApPkBs+d5yqXP/hKsBpfI8tjpausmE2M+cXJ8Ko7
5k5xj5MnzUNxKh4uxy45XvEjxlBFpBDPTEPYPSmKIHTsALmx6ALtMGqZV49Y
L/c+BbwA9tnI9UNfqHjDCxKY8alg5Sp2A7Qm1EUCmrjfN361b6x5PI5CXIJM
6jRjEdH7kGW4sNIOgUUBpxjS6eA1ARvUVnnwCQILZhGYfvxKYIaTBHsfXUPB
Er0THKWEEc/Dmbv6jofWse1Rxkbfj0A5cX2niMWT4V5oafbZzTbQh0hvnHtA
djY2ldWBzRMAicTITPbojFliRUy612FizIDc8IvR2eWidMBSQlvFZ2i/ZIsP
s+7icYTMOKFTmQiGpvRI3jnOC02Q4RXrx2MqEkA+GsEzJQBOTDZ/6a5DCXG1
ZuTK5TZ5ig81KUCDXEwgk4g7wPlNMglXDZorzGGVVteIJ5I8bRh6s9xwfipf
LYTl5CAtlZwPPHCFLLrWQbTj8WARETppsEcsJEc4E3AaGuwz8f+twhQTgrxi
USH06ZzCtAJXk+Z9ThZ4XBGHLRB+gy6aCQXBaN01TlMoTtGWdwk7Jl1fw4v7
84gIEUMB6GqRviDTT+V1YhHnxK/KHU2MGorAfMIXgC0DGIsB0JiLHcdSoa6M
eyRkTCyBOYGj6xAJRdH1qLO0GNUFnNE2a5RuCZbSrWJbE8/w+EceSsXkl8cb
tETtRXYzJ5xrTSZ/M7OVr1LGWKU+J7IEurYejidQ3A9T8yz/1VcTIZXbhNZu
wLIobLweAmvBYMI19cn5GXBaPJhoQNREAC5iJV3VjsoB7IFEUdXjELJdHW9h
N1m0O8h7M8QnjRk5uNXqAvFSucVAGyaXBmF7yS/hULMOUGxURCoeJKlkfyRF
l1JuI29AJdMkcQfNPcXSvrTIlb6ic6qxZNuK/13N1eeZ9hP0hQIBAyVLWMXC
XY6l95PqGr1GRA5I4R9MApqbbDk7JPOy+kw0J1YpWXNQ6EBjVQmI9EylTQVr
B0RmRkYDMTXuILJsdrWWxoXaw9osPDJfBAZyPZZJMmxtAFaNC1YUimOQZUpR
4I6XOuElrNjNS6wLFVwx+22kJCy6iau+vOInwkGO3O7AR+DoO8F4Hl6LgKXa
SL4hSX1iMDG/kNWlyxW0yO2M8U95rU3aMUMU1Q1LYwIiJzGK7cZGgsQZO6Ik
hYwiBzSmr2FeCCtImS1mqfJJG2PQ8IVix2RLknuJV0MI0BI14MCmmhamvSaf
OQ3Czh8P+aUZzJKhHNbsUAsuyiOKdLd+EDrJLgVnrtUVhb46/KI9FkwXcDTA
+C9/D8iDRnseeoICBJZOYrf4JYRlhnQwxQKyUjxVxcUUGX47xtTyppvVVmp4
atyJGmAe61GP13EIbyiTdSbCkEA6oOol2p+Sd4r7wJg9kNywyhnshezq86hW
hhDcuBWNQoReYE7sjncuYBzcPuLM0qQFU8QY94cYsjYIqxq3NijfTBPvRbHP
CLZTRA5fSMh22FpYosBe9QTJawp4+G3U6ENSukXZLCxwCRYVhnMoAWyHx05c
jxxwmVyK6DH0tW3gAzwv7HMAy7PLUUqm6MgwIdJbWYh3YqxbbKdHFo/qFmYT
LTCnSzJy65EgaSHWs8JEoLnZB3scjTSN1hAL7dq8LgI3rPtCq1BgmmKx1gz/
NEYVmIbGtH9MuV54JjNkBfLoKvffKg49Hl4ZC4sVkTVSgxPy6MaxgKge3C+u
1hfmduhoZAtzkviJN4TjekDUZ7WMFcuTpvhaVas9jhwvLczZbLxikbBaRfwr
dCMPc6KIdvxSJXOm3jGL9Cfgqg3mv2sopZNVhEs7wvMTJReKYhkaPGUNDBHp
GtpIDutITMPINza5hFvVQfeJw+TI1eKHYUZofsbbtSJ3pSeOIoQrccNY9Ip5
qngm7hBisAn3P7wfXTBiEVSvENrkpWElgoM0TkaeOFTV6LF4jQgegKrJfFkR
aSfhhRKXAC43fBENQY0CVDjLFfgUz2NAsT6wFkxtY5HV8IUjJ4hM6+h97RyY
4pp30m3kUQd6ocTTG1EApvkXoJtrrHVYiwef+2FuMEs8DrkT0zcCSv2n3Cc2
C89dbOJnnkn3WG9QkjhGkPeCtLN8PRyTJ6NKMuOzJAVOXigBwMIMgZDa6Tom
kdB3qG8yDRIZpsEyHNBeidmz+sTD8KozOZSrEFpRKBPY/IxK4aOi5TpW4LIC
l7zcD1my+RwwvlSPk2JVlVOliLEH3IKAB2yO35pWynE3/h2b6AEj5erkzJza
ZPnFwl6An5QOZMMZR7d2XKZQI9bpCokNMXM1KQ3znkEB0oluIBWiFQo3gSoH
yakBC5K0Q5b9p3O6dV95toTlM8hQagRDI88MjZDM9pY6NLyRyXtCFQ7RO8MR
RBMlDwFThoS9CNotUoWZVMhXyGyxRJnNsovUjNDBTVtLqj8aDiGRnJl0UYQK
Dcvc/KCJYiDyPgSl3Cm3skQSKEgpZ8GNA0z4mCY4cDATRHhwIolxBi9oTnoc
N2NwBTnFUiWiVE5bsyHSPpJkdnNmNE0xIu9ItQdOtSvDXE1WouIgJSl247Zx
EAqKt+rg2WIEyXo1bWuJwffSRKUiNI9W2JoYt/3ZrHnNpk+kZlm/QFREZveU
C08Ij6M9vOUWsY6czZy5Rqnmjse2yqBjmEhtr+0MHqVu8AwAkTXCg/JT5P6Y
8E5QzI3npPP8OXLerAxMKhO5V4cCq1DNlADcmBmOiY2icBP5d97XzF4h4uJF
eH6cMPAZo6cDfRVC1BJT/+TWhYhPhtnKsByISY4sdHMcqr3Mq4vpEhuPnV4C
cFzUwE41lkyQOgZivnMceaLpqmTC8Fjg+/5Ma5KvK3EgMUg0PVKEu8kbjpNu
A2ahI6xysgSjLsDI2QRLKORWMZioljwNiXxcSmDFqyhKPzGqV4OFeft1IOXc
g+PALLZ0G2UKEGcmi3wy/d7lt6m7jkYFEolqU73brSUNrmQ1D9vw488Cy/mM
YXodOONY/THFZQUWbvDHegN5eOM5pHKLpcnbONmNmsSIxTJcfjkwj+LGFSB1
HTGfEybIEZhlLkmSkMkxPKViu0sGdaxnffzE6n/gxGpHTyzxFopKSkWO5+Fs
SR01Uet2BGMRRvDwgttoE4oXTzqAYagNuWt4+RQx7k7B04NDpOvyFGnxTN9E
uvJ3n6iEfeFHiRNWNpk/cpYopC/iORRbSC5pwjto2eiNQhkwNBM33DET0i7K
xfKPH3iTb8O94nJbLp/BmIKlNRNOELRiKDWaBWFQpAKBn1pcLRHmb25mtDwp
3JwpRc4Ta8GGRcqTKy5Lu0KcYEl8iu0jQ34SDXhNAYK+9KIfdMQd5XLb6DuA
CukWIhSPlBtZOQCUywnwj7mVUD1F5PfBGVoIZUUmeyoXpFDJ30ZoK+AXR8+E
XIGOdRZYlww7BWZa5EJgNjytHAUwOTZ57iimipkKSdQEYf9M4yJemgUfRC6L
kjoWo5I7rJtEEciYch51LGoCoT+LT5RhnckL0pLusG87kTvXj/BEEd8SUeX5
9uAHeIDNdyE9qlmE6v3x3N6RkEscvXlNW7jshmlJsw/JGgf/VCQ/KbKZ4p0A
DiJjmvBqbnE7SNJs1ZmKsuxyT7WodV4m0TPoqKYXdfGKDSmaJHzAAOJsnXeG
6dS8LqVw0ERzqOTFZDwGQ2AFEWGCiVy/clE741su3QYkMCl64fKx+7t+n94c
s/kA1jGbB0fgGK2WRj3SunD6gtowMk80J5nhxan+PAkPGFFgnmxe2ljNNNN1
tjSJccm2wri7l2+TqP7Ba5KyA69cMMDK9If+iqjJRHhrGVkhhOPXVWFMsC4E
Kfjyyxx6w9KFID59ETLIWSzdmAA1dd1XC92aZjowFixWS0TQxzzeiSZTvBFx
wxy5LDjoQLMTAkOM4mvJrIML6CJHjkPikHpFfXlkG0bWGe1LOKXJ7m2xEEal
7Dlq33Qu0cLQGenZs7x6x3wkSUDNchZidChrRMv2iWJm2CfekO4vjVeJpaxu
01KaEkR7mbzKrZl7wTJQ/Po9zTGsoZE0H7mQA5GBIWvoeFAJKa+jxjcEs8lt
V9x9GIja7dxsRxX0iHuLZZzpLCmz2qseGi0swzF+aFqLy1qINtVR7yyrd10M
NmLOMMN3sumVO0vDaxSSsCuN10A0/UhYG9ObY6VD9ZN+u/FVCnQr6loL37OL
MeCb2CeqacMmQ3LIRL+Mum1NRtNiu8FN+1FMO0wY+sLzqEClPQGsOiudZc+K
8J+LswyW5RALN99ZIUS071LAh0i5kaGNcG7CWoxqNQz9BKbyVWNl/PxwOF7B
fc5crnhdbv4iU0HxCv8uZS8yDJK6Cklts54JNUFMhXQ73k1CZWo//JKVA+WJ
M7HVnuVyVLkV91GKKAmflcoHn7H6KPwihFiD7FmW9QufHe82lwGUihcdT/ws
l1TROPHLfEIhWpb384tenYqajyte9ggd7D+o6n/8HZ1yuT3sy7Q3n+LPHzy6
SGZBWD7nlT4GhdJt1A4rV0UHivrCBGV0tsxZzodhC9EDa37i1dXomzOnMns9
1hyFmJVJyKRx8avdHLcYfj8AiUE0vQS4rPHOH87rZ6gQs5R2ErFfCW2qtlb1
fNMxYLIpvWFsgc3UseJNSh9bK33g2q8pfbgBGmxDTxaVRhmbHiDvlbFHVlS1
zXetAfooqltVB4TQnX7lGqCKDIGa7vWRMTED7NoEVUsfWM6rAa26xsLZ+Hpv
D+fABQVsuDcc7WoDahxTXAdLy4YVYGyt9FpZwA/n8LdwETMpDmOLYHowJnAM
cy+XhiQiPIxwzoajqt4B1YTUTMZFZYa/Vtt4gX5j2Jb/aqUoQDMU/MmggVZ3
dy0C+Q9vveTWyy2WLFwZL64X1pBlkYVu4l2ZWLFo5jIDBBA8Wgk+k/d1JUyc
X01xFEmRbihIij9/MOeOwK6w/gBKxrww7iGSMgwTq0Dk0nYcufDQraWTqua5
OyxxAKRyw7OdrilkFMjhAjFG7qDGI8doA0m2ERE9tKQwQTT5eKbDFFI0oVPN
D5yOPJvYr4QBShT8jqcZq7HB9EUtYef+zpPXqXYHoz929DQ8OVjC37Qd69Xd
EpAQQ0REHaJMqGv4yf1p4VHG83pJR1R2xWMoZVUzsZfIxLlsiXwMaxdCr9a7
XjsrEAxrQEJ/j3TUXQ+mX8OyNbad0hqGYwGRuDGWjn4JKvUKvXVDF+tfwKu9
be1S+gDIDEAJ6+X4/NfN/gPLY6X00XKzxikOTGeR0kYgvy70axA+kJK4E/3B
sgMkMU3Pmur3e2eKUloDMWGmN+HU2SS24dxhNCBOuBNM1GakQ4BCQUCU7gg6
dHcaJUlp6XSaarETi1DEHMJALuQILhF5TYJutlIu6yN2BVX4fdq1Z4JNGALS
YVjgzuVdMZEGADMBmU0JyIXmGr/X6vv3fqeRhs+z5EIcS+OX2oNwGPOaFayl
kJukb0SVgdUqTH0WS8hAwpKc0E62UCIl2CgRrsh0EToP3UF/OB7pWA55igYT
+k6Jl+Lz9k289+WTiR/UvdcOK84LPxaTRDFMWcw1Qg55ZXqQQJ2zrNSJcQDU
i0F2+A6N3ZPsV6XwfVpNtDjJY57j7KT0lRWEB1Eevkahg6XwALU/KX5V3Mr4
C+9TObn4ymWlkwz7PiY5neRyX/HGlUaz1e61x+1+b4Qg7LTr7bE+rl6OsE6+
VmtetnuaxmGL/VSF1ULJfG8N+12i09kmv9Ad0BEQGsGAsKfx/561/onlshXj
u2xaXDN/ki3Dmv+Cpy3Ex7AGCYj5mhaVF5PuniHA/J3r+anVwCZB71m8E+PY
lNmZ16LmFrzgYNS8vWv26k39Ow4Yu/xZ/2vmb3rzkW+2/LTfCi84xCTB/gDR
otpJ0c0K4R249O+vWaWL483Um1epWe6nmikXWbFm+SMT7osPRT9i8xP+iREQ
ngDOHmil3/SqKPisVMWTH2IEITyXV9yHUVAhyGnyCPL6Vb8tAM6No/IfAlxG
dKE+TSB1op8hSMVHMm5dVwrWYsuE3WWRtuG/xA1ll2GoMGY5scocYfikpizj
+T8IeDStI0sSoW/wLxYNl5LfEPTZv0ifEZRSYchWczgiQeN3RjRk/mx0xDCv
NmlE0enhmGHoH/vXrhZBqyd/CoCYEqMVo68MXhX3dH6C6vgPulBuL9XDm6Hp
IkIVT0bt5ybaIM661cevuPX4BRB6UKvu0YSdUlujkfbz1nIZKhTCXTmEQxAp
CxU9LdSOYAScqnrXwXImNoh42E5kU4t27d64edkcpmjtbYfV1AC5JvPbxpEV
G7Dhu9oq3vAK+NsHSkk2v8vW0dfWu2kTDPeftbxHyWGa2E5x1x0i6zB8GTmh
MpVcwKXwNwW4Ia7pktmWCiXQ2XirsbGIwZ/giPDn0wYetvCMPVbsMYFxphhs
kevEd06ZYpzWOZtVDYP/VDoSgoWmFjYGoEzw4zWIDQQd2n9UBRXAIpMQM2SL
68nsT5oh3gyN0UBoaXVMP3a6j2DZn8YWkap/rOHKwnQJEiuTmsvc/qTmka9T
+udHGr7P/rZyHTel536jAkzwV+G3t41BAynJ/wyM+RCMEq+olxFXwXAX2MT/
Ueh2wI8TNkJQEkH5DkQszh3nKneKCgsKeoac8nAkUL2YmZSTvD9G8WRrTvJ+
juId2biBbXA/xMJUymWqrP1Y02h2PzdiK1x4HE2iikgLolyAxW0tzKWNbdm/
RnOYRvfMLN6QrKVaDCwJIF6yL+R8E/SDlPiO9cH+9evjJohy42G7d8llCnbp
aaRaBMrkPgnl+Pj4ZV6/J4iTTHYgi/+EGM6upfyTd1Jqf/IGPK3ZA01EqzeH
43S7W71sprv9xl2n+QdUDqby/aGlfqouhob2k1L5QHGUonlccYQXpJRXO52/
MGQGXYxK4WCaTWCuwkgUX3hftMNL3P4rtTCcykku85VuiqOdoevivn/j6Zl4
dtJYuAGkrN9+BXph/vpDOzDUMDtNLpPJJdhp0HmlaZRFyg2+aP/ECFeeAsx9
pAEmz6P7loepsgFkTXme6qJJW480axhO1N7BnWLi5kkj0DFIguWAb3xuB6EW
wgAUSUHrNR+4LUgW0WDx6jw/KbycWwtvfVPS1yrZHE/EZPmEuVKZm2cACyIT
DfNe+aSSbEAyi4UjUNwEg1SSrVKdOtm7KeZZTC6XyWV5eLhtC3WGZ8r6mijj
raAqq4YLZxsDy0nfAZSb2GpJNNXiy+IrEobN5P47G4rGtcafsRQ1H8fN3gi+
hr+lgShdp7hK5Px+GhZeCWUJQAoa/u8yE/1xKxFfLb5mc0tncifFi6/sNuIE
bvYdkL7RvmyOxulq57I/bI+vumKJ4eehE5aW+V+4MiNpTrhGJOP6X46ZljQ0
zoZ2MLmbjF3hEKOn3rj6KJtyRA1pdEOvPcXcr5zR/x9me/un6e0faXqTYu2f
NR6xDk70Bzh5er0PBKcH+DECnDg7O0vFAT4YNkfwGlD93+X8jrRU4PwHWqlg
/gPNFDCHrb7+TzYrJiMGm4VEhz+KDax5MoT/aXv8p+3xn7bH/3G2x39aHKNf
f3qK/2lv/Ke98f80e+P3uHqW0r+DMPDjxz8NkX/UEPnTpjil4R+0k4FKxanD
919EbBgLdOIvDsJg+VeRSFi1lDN/LyoM+GpRs7A6jZJ/DBRdY/f6hh+yMKjD
JCee8xP7Wt5cIYo+y4d4AczBDVWiNrpyioKlhzdMaijz4vkXNi35LS9WR6al
0VU1nSuWRG0bvmCN3WUfDUMimHErIm9GpURNg0qD4KMsj4wSiVX8qjxzztJL
pC0QuOZCPwEuuoQB8VbZlWF/lfFXeHM6TA3fi3fcqqXlM6BJ576pJzlTAtQt
f0tCJwmmkyzgUgkQuAj/uYD/z+a+apmCns1mvkXPbQrTLYy1T0X+AZFoxAx2
r45ZhR4ypW/EakBOgAf4VeEbYz6Zv4l2OfZEbUrPM/x57IVeKYsX6pssrrAi
3yg0+1eJGL9S+4LyVazrwkX4Kv4um1XeHcC2or48hDKn/ZGPdH9pEH6c5HSY
fbmQQZhncBcKQA6kKSra6AduiZ7PqU/VvUlqVKrqxbJezOi5pl6s6KULvVXR
Gw29kdXLVb3V1GsNPdPQa1n8u5RJ6qJa1LN5PVvTGy0909JrOb3W1FsZvQao
AvMtYu+1Kn5Qa+nZSlIXPxIe/iDQ5guJO4JbGlmosqfLIFh/Oz9H5D3j5/EM
tFb2gLY6abCDZ4ePDp7EH8R+R39Gfqk/frCjSYSW0z7FyMUIaEhqmYfivzOZ
xXu8/sPo7H8GfSz8A+lj7mfoI1HRA/pYjtPH0gF9LByhj7lk+qgQzvhhymY+
oY+4o/9TCWS2qZdbeqWkt4Ao5pGWFfN6s6XXYbvreqWlA2cHYpdhFDSf1EWt
oFfqeg7+twqD6/Wi3qzoGXgCMkEF/wv9Vht6qaFX4fkfJZDF4wQy/ycIJNvr
pNEOnv2XUMimSJRnQvAhgaRE5H8MiRzx6zF+kkb68c9ZOhy5cY/d/XaUUMYK
AmiJmdvi0hjK2v725VMyOtlrMWGVlcPC0os8R4aggiUYjpX9w2LBlF7u89ov
M/KFY2UzdtNutBzDfwK1zmVLmUNy/WfpdS5bKP0EwYbPcnGKnYOneU6yc5xk
w5O4TAuPMolEO5fNlZKpdo4k9uQjrucKn9DtQ3RjVPwzMv4pHf8dQv6TlPzP
kfJEWv77xDzSDEhvFYg2MOaqnqnqOZBcQWDN47glIPIX+EExp8MUKjUAUlIX
laZ+UdMrOb0E2FPVaxkdtr5UB8EWxdsaEPMy0HDsqFHRmxeJk/+R9JTIeS5T
yB6j57lM/iKJoCd09ivRg2NI8Be8A6pUSF0V/Ha9fbne55q/JnVSrebet8+5
cvCUq+zMUfFjtppW1/eTyWTp55tXeec+s893drnbyvwmd90xEzvZXTWG/bva
0M1ZtfeH0+HQHhu5u9brft1+uC9ugosPu5a7e2tVppuOffcaJHay76zm/Y9B
o/xuzCfBbD/YnGffNsXX7IW/y/nr89Xq9L68neW6fs74mNwXEzuZrga97eM2
WzLnj8uLh+1zPnveyVUq5vn2Y7weD4PseWbY8bab7OwOxNTzxE4uXk5vgtmj
sfPNwDyvtJ+Mh9KqZF5ceC/+tLEyr6adyezxcfZ48bHelIJSYieV7er93XUy
5eqwORs2gotgvX9oDIejj4vTYLHOTc7N3fmyedMuPly6g5t9YicPmXLOL49W
5sM8m+993O+7pdJmUnp+fj19f7w6rTwWTq/sStD3/YeOvc8nw6SYrw7Xs4vg
fXB6sXl/P8/NTnuW+WLO74PguXzq9Izta+2lsu8XADST8iyxk/V2/T4o74KP
zXDrZC6su8H56cPmNJdZ7SuX04d5f7CeNyYv971C4el4J/muczGd5I3Hy169
2q7Xp6dG+XTfcc9b6928Mzjf9PKzj+XbzLOuipvdPLGTifNSMU7vPnLW+cq4
AXgE1dOP50K+uGm9bZ/LufwwX77NBvlcZ5dfP7+NEztZzs4H6+Ha+Ci6uU7v
1Z1u6x9Ge5XZerfb0dpd5IsVu7PPr/aZhXFq5q+Sl3NaK7Sdl/vWoFExdrOl
4102Ww/5zMg+HzjrbWDkbmv373fN+/fW5Dp3f5fYSWv+VM9k13f+ab9weVMu
3J+/lupXd639cru0Gve3rfJT0Rg0JivH9x4no4vETgqNau9lsdktmr3nzmD3
cvd0Px5e3y6aa6szzEwD6+HltL0oe/Xtc7Xqvd8kdtJ8bzYfutedt2412zpd
LBz/tvG4WN+a7up6UL9fBvXhftrzqg/vi2r7dJFN7OTW90rtu3fbXdX83ct+
9lRrLvrmfb3hDj2z9mK1Xh5zo9moWsrUBsXG4jaxk24p/+4O7IerSe/t1FxU
m2b1433fq87qtx+nfqPZ7S+NS8u/uZ6N7FFpkUxPHh5WhW7Wu90NMuaiWWsv
l62O+7ipXy+HhdW4OLyuGVbn5u2tBaSr+fHkJXaStWaXgALLXf2j6byeVgE8
s3WmZW5vb0v3z6ejm/7u0u63r/vLbPf+xc0kdmLWSo1hNZsZDdejp5Jln5ut
1k11ddq9GbUfeq23kVvot5z+cL67Ku6ur+rJMOl1M292Y2hP27u75mvDXlij
2tJqrmuL7k3/vdiaVZ/e2vmbJ3N3c/NabSd2EoyrtfHruvi6bJdLr4tJfzHc
75q1Yeb+crqrvszLQWX3tp3ddS9Li051ktxJ5va2XJ981MdBfeScN5rL+mR1
ejrb3BrW8DK7un2dPVw5K8u5qp56xd26k9jJ1r+e1Kuduxu/8VDsVV8K+evT
aqO4Xc+N1d3H9Zs1vK7WV/WHXbu7vH0rJB/A1dPljWFZ14NVe7selTN3H+Og
+jIbeUZ1ffvsLnx70ZpeX+0y++KD23xsJHby5J0b47f5+2vubTld5D9KzfFt
53SULdv29qr/fLu1m/375v36463ufjQr94mdlK6fl8tzuw4jXqzuWk+F6vCi
bQMnXS3uS4uPfKM+apjF0vwWkGB0YdrJgO1dP/TLq9vS6nVa2tuDtdG5uL17
LraH593zWXPnXsN2n3ZK1rgwnY32ybuzLtgvjVfXeF7f2ouu+5Gpro3ly9ga
P0yenzaV7Wn37u3+5amUfcnV3r1SOZnGDlr5zSiby+feqvvqbaO79Ard4f7+
+a1o526nQGiezt2x+zFZuO2b/TR5d073t+/Lj1t/cH177piV/mp4s326ylbN
m+p583YYfHgr4+nOurpbrq/7D4VJYieeOTLen8/H99P8c/X2+qZvLKrX1q60
Hl7dv9a67ZpRbJ6O7roPVua595AdJnYyd87fbx/3u6vHffeqV7wsP7RKi+dc
+/6l2rvqtq9vs3b1+rZZ7l6/PF9dW8mEOrh9rj58rF4tv7Hfje8fRm+d19fb
y1yvV8vvdnvD9N6Gl53ezXq7uwP6lEzZWtbT9G1rjV6266xTfnCGw4/Hll9p
PzbeLasxK1/dnQ/7bvXSqZzeLsaDZJntflO6MnolK3M/2Gyzo/rHbv9sXu1q
1WzzpfXkVl9zL9f5fsu8Ll6us83TfGInDXuer75cZCaTLYiQRXd/c7Vx7veX
g7fSadPZjjfG+fWdk7eMWffKfrszkpHNv8mNy6NdvXZ918peO83VcpNxglqw
vHZvgfluVn7ttbiqZpfDaaYzTJZPnlumN3t59Y36W5Bv3z08Th8fsqXtpPQ+
e9hfdcaLunHz+HBzd3OTfe2vK8nIdlOs5Zudl9HscZKx3Vpx+BSMMtlOaVnZ
jwcPxezD+m23cH2v2K7kLoxdssxWyGRPn+a7hmcZhQf3dletVn/7LenLROk+
4dnho4Mn8Qex39GfkV+JFpODdPoE60m0XMjfaT85HPAnLSlKQ+2g4R+1pmg/
ff3zcWuKdmhNOeL6S7jtiV39FVbY4Ddj8fJOS3FpQ6yyIEW5i1qeIm9eMybu
JlCLmtK948rt0eod5P8Z9pdKNsFc/qftL5XMzzgUc+VKKW5/yeNTZgzA6Bf+
XZk7BGMWlXI5wXIezpz+HU7/1+iscxkdyCeaecoX0noeGnrKJWnPORi+pFgt
4u+KZYVufGbu+bMGn98x+fye0ed3zT4/bfj5s6afI8af3zf/lPN6toD2nlwJ
DTyNvF6u6ZmanqvqzZJeauqFnH5R0Js5vXqhFxNtNxdVtA7VLvRmlhn8sU2h
oNfr+kVdrzZxgFIZnZ2Zpl4rHVlAogFImIAuLi6ObBYagS4u8pFG/yAzUOdx
E9wlqyjVaqZnT53h9eSh5TzfDe3JQ3kDIpdT7d0bD7nzSb/2fOpkK7W3mrXY
zdzETkYX7zeVl5VprGuZ5sPV7dWH+ZF7eH52h9nguWvdFl+2W69SrI86F5d2
trlK7KRcr8wqVnM4GvRn5eJpv9is5U8rL8tO5qm72VvjQWeZt54W83Wn671c
XyfrfmZ/e14qZbvn01bteXn/Ol07q1WnmPFn+cLkfNz2r0pPrjU6nRnZ7N1+
NErs5Hr3+vaSy74WsrelemPS2991R+PRqXn6tnlqfGSBWp2WRpvH1/fK03K0
9weJndy5F7eDm3PPvnnb1t/zxYftanNqnG8un9xdpdm3FsvM7dY771yNdtOX
l8ZLYieX1uXVLRBhJ3Pu39jdeeF+Nw1eL6zS48W5f9l8mvWqxc75gzkcF9t3
jZtkwI4mnfuHnuvmpm+9+jL7uHdveuWev/nIWG+7+4fy7SQ777cy92/r00E7
U0ruxCwZu7eB2R59vDuVhfv08fh0//4AQtt6/tCpd3fTS7ezXuzLeae8+7h8
TZbph4XLwJw3e6tu7cOpXzSannuz7tfW3fKq/XD/Nmg+XQbV09rW7c5HuWZx
kyxJZx/eNhfDUquz7bWapv0wNHuuvbbu83bufn3pBN2HivNaGt7M5pnTSi1Z
vW953Yl5v3lYBh+Tq213WLqz3clgf7+uPbw81l4vfOs9t70qOvXdU8l5rCej
ffF9cvG08bet+8FbvX+5zJbmo/fR+8JeDV5H0858u2o0VvVCy25Mszt3m6xx
tVtwUpY9+36zWjQHQ9uyoFV+sLwc7MeLu7tuvQQYdFN9eTfWwVt2kjyTu+vt
bcvfWqed/vX+/fl10Dzf1ndXm+rqceW+ZKuG5wxrRvDx9jrZXkxvksXxjp9D
U0T3fOv3L4v23fD57fG97zQeBzfPu2JQfLn/aC9bN/1MrdQoLavJGtfosQFb
8/H2dnF1sbo1r6v9W+tuNNi22t7dVX++2Vj5D6/VLs6e7s3qaj1N7KQ/7U8q
m1J+23kxzMLr02NhP7TmTwNvbORGdtdaPM36p9Pmg3lZbXQ7z8mGhqtKaXRV
GFbeh0/VtV16yz9lcvPT3oc9rNqn0+fRzbJWehu1741yZu6/dZ1kW1L/7fl6
vfIfd9WBu+8Zt5Xipte+NPybwW75fvlx+9F//Oi22x+1G2Oy6iRr5pZduMh8
zEcvDw/O6et2ve3cVhZZO78ftqflxeb1I7PZ+82p8TptzPf5m25iJ6+ndmbU
f7T77toOrjsXzUFwZ388zweFwOleZF7L76839f0oqOS6u3n7MZkouWMzs3Y2
hdnTZH2xvD5/fX/Yj3oZc59xz7NvE6vuvzcer7sPD27+4tZ8rSWb2qt3rcHo
8nVQd+6uW8XdrmZMGzfF6aXdXBdq9Zz95F5PvV7v8n560fhovyV28j4u1G/8
ge1VL8urTnm3HJov1q1Zaa7aq3bV/cj7M7/Sex8Uhs/Nj80iuZOPycU0f1uu
bPIPtzdPFcNcTPzqefXuunY+ufZL6/l1UKldtZqb12LjoT3+SEa2q+LmeTRe
du78xstt8bJZGnb9vbXsjo3bzrxaqrWt6m23unSurnpZf5asQGYfgrtl4/7a
2ixfvVntcXZRyJwuO7XK/Sp79XJrFva7Tr/Weeh3u9b+tvqY2EmvVvZXlcv3
3NvscnH52r0s7Z7KRmf+trgqzObOyrufnq4HXvP8+fzWee77R9hotv86yZ0v
FrvO7N1u1LONUqM1eG40KuXgfVt+v50Xx83pRfW99Lw3Gsmm9lKtXhjt7Yeb
evctsD7W5czpXXe6rI4Nu5R/u3rLdPPPY7+c70/OH/ulzlNiJ37rY315/1Q8
tTqg0G93T6c948Ydnmes6/ZjJz+rvYxzy8vTXf+097gq5pNhMgpGy6zpLuam
+3KfL9bGfeNteT5dDe7MXHe2rmTXt+tc/eWh38+9XvSNZOa1fLnLXtXyjc7l
qlRySpbx8lGYvDk5t11f9VrvjeH5e25VL/qn3s3Sfr2rJnaS75n5QdleDDJv
1/OXeWWz3ZxePTyO5q1dz70qbN4u71ZjY/bUDfrTi/1LsgWnOas075avu2az
P22Mrm5uT/dLZ7S9expelVfWrZtr3RTHsJzn58uHm1rZSqZsg80sW9pV1059
O+5/vLRb1ZfK+HZWfzdOZ7P+2PowjOz79baReet6N++nydbPmfFSsnbXt5eZ
rTGaPT2sx9vC1e5+WB3kn0v93kv/euM02+bN8H613Lysk6XH3OlusLodVh5a
t9XWclmZXN5+tJqPj6cPu77z+FZew54NctXpzMmsL81kqWDaXVz0F7c3RnPW
v2lWX1v263nlatO8uazd7zbTaaH64lyfd2pPd5nK8n73kLycbCtzZdfugPxM
9u3NU6tY7pfXp8asu7sLKk9V9/G8vRsG1XqlV53Vqslet8sNyJz3w2JlUz4f
Xz69V84fXz7Kk0ENTlyrUsuMFsvazWnh/X1u7QIvc5nYyWOz/mbObm8rg+H9
ulm9Pc2VutZscjlaDVbl4W74Mb31x1mg36OV63pXyUa6U2NbuJ6+XJT759v2
+nzz0W2+Xt1Um6Xz1sX91dXopXw1mw0zt/n9anr5PE/mxfcvu/mq7/Sc/OXm
YXja+lhOB6vBm7UOrqbG3piOc+Vx+SVf9zPnndv6Llm0KF3nrCekw8Vy1Xcn
Ly1zsfHd6+Xm7eK+N8qZ2+Fg+lYdbW9frdPF5AjLeNo1x71BcJ6t5tbj0l3T
G2Y/uh937fHzcNsqdtZF0Fb62flr7q5g1EYvr4mdvFjlt00n//+3d23NiipX
+J1fQZ3zksTMCIqClcpDc1NUVARUeFNA8cJFQFBT+e/pbvCy99bJ5NSpSlLJ
lO6xoG90r17drNXr+xzxMmeNWGmewrN3VR3dGPla31/HXScbbAajBggits7q
/mt94uVMtNg6E93Sa+3uXgg6S1ormjPJ8QUT1K6tXmY4K80ftGWaseTX2624
ZoXsfBNci9gWxHVLFLcLo8OzZnvq9kAvdlescgyGs93R1ofha0/kvE1fdxpb
77Ji0w86Ese0T4ZoRyMViMHwELBKt7H1FmszO9Gm3nldiDfqmr3tSuqM8nq9
sZv2oTBowaCZs5d9vz/OaWWx41NRmMTBZh7Hr7347bR3njYHM10bwHeAuXJc
BsGpv8qO+7MdqL3kwkR6vRMPfVdYDI7c6235lJrWhqJ0FAbT89FpzRZuPsmV
SQ2uQ/DW/sKvx53twM6TeRcMZu7rtbhJO6fIyaNx/egFwkFWLUmWemyk1PJ4
7+2ZlFkJKn8c1FpBTzMPr/06sVSPLof4UmvU2/F8MWjS8MViCfU248Uz2pFa
lKle2opme5rK1savXTIsY9e83jrujRx2vFuvtXrPm1ELjo/iSNx3pT0yEb+0
EL8zALw5F/L14r/TnCyfDocPpuSvRuQ1TIIDVd6akZ84fZ5NsQiiFiAe6b+U
XB8EMlSEGUboxlwWoVcs74AgzzlL4gkovsskvcObdBp0G1lBxyh08JTciNHT
khQ0LOMK8cE1TJHt3pkY3S3mUMHo+UpIPNikcOM+0TUgmFsENP3KIl6Bgn+x
kKeItaTko0Hov/dI+c989RUS8DIj1iW1Mmw3ylkZuh/lYj7114VXxxKJd0WT
X4oGGCn7ibimpA0jbkShMA+iREEnuL0bYED6qdzbGH15stKUXiK4P+ENvD48
iVojvqAQKzFgbnQ+VRG3+j+cgCwH9KvVvjJhf0P/MGIKiUCeFFkRgCHhqwR8
aZNjQxB4pbEBhcKDjWKMKEn2PJpeU4M4OhTtzsQ/XuPjmb6CEb/ZH/39ttsp
KB5olEwAkZ+pGlUIhSXONG0gFdP+dDbtqlOpEMtrQ6nwVc2kNfPCL6ZX6awK
XBfQpgTOakSYDTlzuueDIp15Y8bD5vUNTedFe9GnlnM7thoy/L9zUiSZdrt+
7gQHyjPARi6oi7oDDUI1zPNYlBjV8JddwF1U0YTf/WV0BY2RoZ3HclSMrxJc
UFJcq+Crkm7OzOlOmqqA6xL44llVDEkembK6mVHOWb6CGb8ZzXigGuJeTpfz
EWph7gaz1IK/Yb/xyq7sD+LRIZIMwFgAGgdQAmEzgL8lkE30flveMPKuNQrC
zmSfWBG1M/ZrIWeMNagTsTuuD4axveqPgZRQqcKC3XLM8nT3pJpy39ON02EZ
jNZCITri3mo3J9r8UBOVYcp2z7NiQZwS33Ltw3LW8h3zOAPOfpJ7rsg79WZy
ZcS6l8rrtCaxmipngVsbUExaA5whjMZ0Q5zOeEKMVxOmL4sdP3W4OBGzuBvI
ezZxqSO3OYb+mZ83pjbwhsdrf6wuL4KWFSl9ZPfZfsRPGwVhL1qKAKVbpq2+
7C+YXRL2iri+lYbd43E5WrjNugU3v6wme86I5ZptZTJx14aqbyfTWuwJROL3
7WKoe8Vqvhj2veZMzVe5tot4NZasw7LPm8pgP6avGj05dqhwd0j7w3GhiEAD
fMQoAuGLggAiUIgASt2UMoDWq/NAKYAIFmgoezqQJBGMVVB0hUDo6kA+IJFX
gVT0NpZIwExTnncK2ZIMa36Gkgc7skHHq7l5she+v1rwqW0AoyzMlEQRDPjN
JuE3ksxrjkjwsHR8U+N4sOYkKDwCn4Kip+EWjXkeLuTDvHEdKhm8pvf63mkw
P2pQNjd2YF8JlccTw1UKzVL5JZD7UrELi55cXEJO20e2YS3t8zly86mNBIwC
ljIoLJ7XzB7QConYbHoCupEfBZ65wu+Az9UuVSyvfCxv4hibt/XO0enOQlWU
iuEVDPnNYePvN7ytqRIBNpKkDOqw7Xb3QluHrH/otKx9LdkdpRUdCRQznDci
1mRzn8unzUwVNvN+4FNwv9ceXjpNwm06j87SW/C3li/ntG83ZtdhedbytAz5
MKpapXaduTA/ZNbcPQwbbkzYO4AUBFIofUuxFTA3RTiMPC8Iyl7p8sk6C5Jt
J6CkYGNY7Q0rtSNbUpj51R7kl8uQoE5hDAsJ5e0scnvTYrzlcrfpNofBjLHm
dLHqmqdVsx9WrcnK1sEhbhzgq0hvRkRKT1eV3kTtmoV1tvpVghwleNVpuM+6
sWUKLduuhy5BWUkt1xrnOty8QZ2xFtlBjRvOrtOZ0O6ynK0K6lyZPzoN9dmz
oBFl53XSVcPNh4ELH4cP1K42F4JbR8WFPXcK1QA5UmvC/CbOGlQ42obInYx1
F/0M7nqvsXD1kt7h0tgnNhcGknDwrWXK5CASj3TbLJSz5S97U8oRo3wI2+Je
WldiBYcEDt/B65ba+XnoVEB1Bf3Y1ZVVU9QkXtRMABi4dmj8aucKo5kMVRrc
uDqt02DRmuuTBMqrbOtpi9UlX6Ii95z7RjJOaTjJuXFAGWd/1Kcmh7bbEfru
yjxnckHoeqifOutw44tjdmyL/XCyVazhyGp5hnG12umZawWu1zGGS96Q2Km9
pubsaEb5R/HorNUa0emFWmIyBtS+Ofy2kqSl58f9UlWpPddZxav9xj74nV6P
ZmpnqEw9g3KHl8zfLvr5HooOcZTWF9tw3Pig9TQmvc7H7CHdBXkvMZWVTmcu
6IdLnwM2rPu47cNFc2vGVNvPwTycOM0LQRtqYSlcFK6LiTK7Xoy2NdzstkZ7
choWOl8vsoMP9/TztauMlj03yrzNblkMg3pzZ9ccb0Rkp2ZHzlcz6jTol8u4
NBK/LuLlxvXjLvRxiiF7Pi3w2E3hmN1qr/cceVFtu36TQ524bUt+7FBn2r9f
+BnT+hlvOsN8caZTZKNROiEf/uyb6/ljOvruHH4KS7v7gz+Hnz0cm5/vvI9i
eo5M+9nQtB/Gpv04OO2fRKf9ZHjab4tPexmg9k8j1ACOQaMpVBHTJgWehPU2
WjjsrEOyIim1SK5DNiXknm6CV0VwDIp/aAGSamCvOPzbJkVAchIpMqQkkTKH
3Nu8SNKwOPFl41+FqFUxagz1emhwkNrzcYcXUWpFUdyD1EIvq5eb+lus2stQ
tTfRcl+u/VT8GngW6CcZZ9/JeOutjDffyvgHIfu58PT/KRHnOLJDkRyNPkAk
ZZ5st5E0N2T0Q4Q6rEPCgWJEJLHgZZS6JJAMvMeRbQYd2WhyZIsnm3DGABS3
0xDQURCxgSIz4afd/ldFvPlmaLCIsz8v4lGywbL9DQ/9u3D131XCP174EqFZ
RraVi8EjsK2a0Y/l4T4hPks9/XqiQN30aqL8H6vhvxir4TeHIqMZkAaIvb2a
B78HWMP/I+F/X/GD0gX3Fiz8QGFpoHB1TkCS0mySgEEaVJRQdCXbQXfFl/sM
qGzFDik3UCK456BKgeaQZAtYm8P9B0eREkzGQln9N4vfm+3Ff0Ik/K+kgOGF
UlLfIgC01/SHf/u1BCFKv3DPpacgWCbba4XlXSUj0w+F3cjQq5slceyfyJJ0
8V2d2zCLsF33Roda2mMx8XRSssPebcsV/XVFtPmGf/wP+BDj9+/f/0jeULth
GVGy3WxD7Be4Q+ghu/8dbJwkVS/ZvKeGPHgYOg/xdC/DC+m52yxKEEd59bQV
OsnttPWdThf1gJhEcYnXhPjfK6JRF5FzXr5laOmuno/8yC7/tSeqM9yY4i/0
vhXLS5llfQqxSZ688cDf2UBXl8+uD1gMIlXG2OiPunA770+OqIO3iBO+4o2G
cnCooNA/jAC23N8O5SO/SAVgC+v4dEa/4iOGd2+Utze8K1ic3hubQ/FdqcQT
MO6TUR8h4aMX9E+uB9y+FUKUT7wbrgD54GDHz2k++JDv+DLYOXDHNURk6VVB
d/jCB/YWkgO/dOREqzQ6eFkl3VS7/eMK0BUkq10v9BAtZcUo8Kip2eHuNSGx
Xb+uqdHs/ERNT8NWj931c7TAo0aOpjncxXdksdfPxrIcrnEUkYcIkbTeBvQ+
brdqZWNyn4xrrDDxbITPXUrZm2w94ylfpWlvGe9xFSROpn9Il/5sDY+zzKQ+
696CLTC0+h34nyA/RovUNtdt/NRzuAL1QbJawhqXtqLSosOP5Bt5ZZP5+99v
cxIWXLE6YMWje+WMZb43UJ+XdApcE9EpVPOlnCAlBmzuofxSkiDARUUkG222
Uz1qEOW38X/ML1znM3knRmrE2I4YEBiRdKJJWl56GLJgS375PjTEX9404rkJ
zUYLN0G6Kag/PwtR2RqMSuwtHf8JkxFLXuJVMNAl0giJfISfoKM/Fl566BDT
/a2hGYK5R2fS3QruEvPZp6cthohF41p2uVMpjBVyCeNMUOfCRcCDrUqjdVYg
W9yDOxUDKOOW4on+C8pRjw/LbfgX2BlJ6mV/NQ35G/fLi/ZV+hmuDb6Hdwzb
dUkjjBKEnufelEqKsHPd77D8J3G9D9oLC2MYZTd3banaEKsu7quPqn37IfoJ
N3FSKsFviXfAZPdZFG+dtFocPawlvXyLyLAvyNDpnNL0EfikV/CWsGgBKlco
vUmlZtNKgFHvlcytuZeUGeEoeAhEGqqOqvJPmQnylh15jx8czlXTUJFPxeH1
oEqfVo+EJ9JHFlw8zXHaigIXQdZ+JcF94hxJ0UIF1xU0YypGllv6B9vIhwof
bNIPdZu+S3HDxMT3dRS0hS7ijcP2eecQ3YBw4HK7RJ2NM5T++vL4A+yEJ8Jl
GjORPK2fP0aI/AdRsHAt6U0BAA==
-->
</rfc>