doc: Add RFC documents

1 files changed, 2202 insertions, 0 deletions

diff --git a/doc/rfc/rfc9399.txt b/doc/rfc/rfc9399.txt
new file mode 100644
index 0000000..89277ec
--- /dev/null
+++ b/doc/rfc/rfc9399.txt
@@ -0,0 +1,2202 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      S. Santesson
+Request for Comments: 9399                               IDsec Solutions
+Obsoletes: 3709, 6170                                         R. Housley
+Category: Standards Track                                 Vigil Security
+ISSN: 2070-1721                                               T. Freeman
+                                                     Amazon Web Services
+                                                            L. Rosenthol
+                                                                   Adobe
+                                                                May 2023
+
+
+      Internet X.509 Public Key Infrastructure: Logotypes in X.509
+                              Certificates
+
+Abstract
+
+   This document specifies a certificate extension for including
+   logotypes in public key certificates and attribute certificates.
+   This document obsoletes RFCs 3709 and 6170.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9399.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Certificate-Based Identification
+     1.2.  Selection of Certificates
+     1.3.  Combination of Verification Techniques
+     1.4.  Requirements Language
+   2.  Different Types of Logotypes in Certificates
+   3.  Logotype Data
+   4.  Logotype Certificate Extension
+     4.1.  Extension Format
+     4.2.  Conventions for LogotypeImageInfo
+     4.3.  Embedded Images
+     4.4.  Other Logotypes
+       4.4.1.  Loyalty Logotype
+       4.4.2.  Certificate Background Logotype
+       4.4.3.  Certificate Image Logotype
+   5.  Type of Certificates
+   6.  Use in Clients
+   7.  Image Formats
+   8.  Audio Formats
+   9.  Security Considerations
+   10. Privacy Considerations
+   11. IANA Considerations
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Appendix A.  ASN.1 Modules
+     A.1.  ASN.1 Modules with 1988 Syntax
+     A.2.  ASN.1 Module with 2002 Syntax
+   Appendix B.  Examples
+     B.1.  Example from RFC 3709
+     B.2.  Issuer Organization Logotype Example
+     B.3.  Embedded Image Example
+     B.4.  Embedded Certificate Image Example
+     B.5.  Full Certificate Example
+   Appendix C.  Changes since RFCs 3709 and 6170
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   This specification supplements [RFC5280], which profiles public key
+   certificates and certificate revocation lists (CRLs) for use in the
+   Internet, and it supplements [RFC5755], which profiles attribute
+   certificates for use in the Internet.
+
+   This document obsoletes [RFC3709] and [RFC6170].  Appendix C provides
+   a summary of the changes since the publication of [RFC3709] and
+   [RFC6170].
+
+   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.
+
+   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.
+
+   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.
+
+   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; instead, they commonly act on trust derived from previous
+   experience and recognition.
+
+   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.
+
+   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.
+
+   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.
+
+1.1.  Certificate-Based Identification
+
+   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 and may be a necessity.
+
+   Examples of such applications include:
+
+   *  Web server identification where a user identifies the owner of the
+      website.
+
+   *  Peer email exchange in business-to-business (B2B), business-to-
+      consumer (B2C), and private communications.
+
+   *  Exchange of medical records and system for medical prescriptions.
+
+   *  Unstructured e-business applications (i.e., non-EDI applications).
+
+   *  Wireless client authenticating to a service provider.
+
+   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.
+
+   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.
+
+1.2.  Selection of Certificates
+
+   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.
+
+   This situation is comparable to a person selecting a suitable plastic
+   card from their wallet.  In this situation, substantial assistance is
+   provided by card color, location, and branding.
+
+   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.
+
+1.3.  Combination of Verification Techniques
+
+   The use of logotypes will, in many cases, affect the 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.
+
+   Since logotypes are only aimed for human interpretation and contain
+   data that is inappropriate for computer-based verification schemes,
+   the logotype certificate extension MUST NOT be an active component in
+   automated certification path validation, as specified in Section 6 of
+   [RFC5280].
+
+   Automated certification path verification determines whether the end
+   entity certificate can be verified according to defined policy.  The
+   algorithm for this verification is specified in [RFC5280].
+
+   The automated processing provides assurance that the certificate is
+   valid.  It does not indicate whether the subject is entitled to any
+   particular 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.
+
+   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.
+
+   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.
+
+   There are some situations where systematic processing and human
+   processing interfere with each other.  These issues are discussed in
+   the Section 9.
+
+1.4.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Different Types of Logotypes in Certificates
+
+   This specification defines the inclusion of three standard logotype
+   types:
+
+   *  community logotype
+
+   *  issuer organization logotype
+
+   *  subject organization logotype
+
+   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 and
+   Mastercard).  Certificate issuers may include more than one community
+   logotype to indicate participation in more than one global community.
+
+   The issuer organization logotype is a logotype representing the
+   organization identified as part of the issuer name in the
+   certificate.
+
+   The subject organization logotype is a logotype representing the
+   organization identified in the subject name in the certificate.
+
+   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 Section 4.4
+   of this document.
+
+3.  Logotype Data
+
+   This specification defines two types of logotype data: image data and
+   audio data.  Implementations MUST support image data; however,
+   support for audio data is OPTIONAL.
+
+   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.
+
+   Alternatively, embedding the logotype data in the certificate with
+   direct addressing (as defined in Section 4.3) provides improved
+   privacy properties and depends upon fewer parties.  However, this
+   approach can significantly increase the size of the certificate.
+
+   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 SHOULD contain an image with a width between 60 pixels and
+   200 pixels and a height between 45 pixels and 150 pixels.
+
+   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 SHOULD provide text-
+   based audio data suitable for processing by text-to-speech software.
+
+   A typical use of text-based audio data is inclusion in web
+   applications where the audio text is placed as the "alt" attribute
+   value of an HTML image (img) element, and the language value obtained
+   from LogotypeAudioInfo is included as the "lang" attribute of that
+   image.
+
+   If a logotype of a certain type (as defined in Section 2) is
+   represented by more than one image object, then each image object
+   MUST 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 MUST 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 MUST NOT display more than one of
+   the image objects and MUST NOT play more than one of the audio
+   objects for any logotype type (see Section 2) at the same time.
+
+   A client MAY 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 MUST NOT
+   display multiple image variants of the same community logotype.
+
+   Each logotype present in a certificate MUST be represented by at
+   least one image data object.
+
+   Client applications SHOULD enhance processing and off-line
+   functionality by caching logotype data.
+
+4.  Logotype Certificate Extension
+
+   This section specifies the syntax and semantics of the logotype
+   certificate extension.
+
+4.1.  Extension Format
+
+   The logotype certificate extension MAY be included in public key
+   certificates [RFC5280] or attribute certificates [RFC5755].  The
+   logotype certificate extension MUST be identified by the following
+   object identifier:
+
+      id-pe-logotype  OBJECT IDENTIFIER  ::=
+         { iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
+
+   This extension MUST NOT be marked critical.
+
+   Logotype data may be referenced through either direct or indirect
+   addressing.  Client applications SHOULD support both direct and
+   indirect addressing.  Certificate issuing applications MUST support
+   direct addressing, and certificate issuing applications SHOULD
+   support indirect addressing.
+
+   The direct addressing includes information about each logotype in the
+   certificate, and URIs point to the image and audio data object.
+   Multiple URIs MAY be included for locations for obtaining the same
+   logotype object.  Multiple hash values MAY 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.
+
+   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.
+
+   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 SHOULD
+   try another URI in the sequence.  All direct addressing URIs SHOULD
+   use the HTTPS scheme (https://...), the HTTP scheme (http://...), or
+   the DATA scheme (data://...) [RFC3986].  However, the "data" URI
+   scheme MUST NOT be used with the indirect addressing.  Clients MUST
+   support retrieval of the referenced LogotypeData with HTTP [RFC9110],
+   HTTP with TLS [RFC8446], or subsequent versions of these protocols.
+   Client applications SHOULD also support the "data" URI scheme
+   [RFC2397] for direct addressing with embedded logotype data within
+   the extension.
+
+   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.
+
+   The logotype certificate extension MUST have the following 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 }
+
+   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, -- 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 }
+
+   When using indirect addressing, the URI (refStructURI) pointing to
+   the external data structure MUST point to a resource that contains
+   the DER-encoded data with the syntax LogotypeData.
+
+   At least one of the optional elements in the LogotypeExtn structure
+   MUST be present.
+
+   When using direct addressing, at least one of the optional elements
+   in the LogotypeData structure MUST be present.
+
+   The LogotypeReference and LogotypeDetails structures explicitly
+   identify one or more one-way hash functions employed to authenticate
+   referenced image or audio objects.  Certification Authorities (CAs)
+   MUST include a hash value for each referenced object, calculated on
+   the whole object.  CAs MUST use the one-way hash function that is
+   associated with the certificate signature to compute one hash value,
+   and CAs MAY include other hash values.  Clients MUST compute a one-
+   way hash value using one of the identified functions, and clients
+   MUST discard the logotype data if the computed hash value does not
+   match the hash value in the certificate extension.
+
+   A media type is used to specify the format of the image or audio
+   object containing the logotype data.  The mediaType field MUST
+   contain a string that is constructed according to the ABNF [RFC5234]
+   rule for media-type provided in Section 8.3.1 of [RFC9110].  Media
+   types MAY include parameters.  To keep the mediaType field as small
+   as possible, optional whitespace SHOULD NOT be included.
+
+   Image format requirements are specified in Section 7, and audio
+   format requirements are specified in Section 8.
+
+   When language is specified, the language tag MUST use the syntax in
+   [RFC5646].
+
+   The following logotype types are defined in this specification:
+
+   *  community logotype: If communityLogos is present, the logotypes
+      MUST represent one or more communities with which the certificate
+      issuer is affiliated.  The communityLogos MAY be present in an end
+      entity certificate, a CA certificate, or an attribute certificate.
+      The communityLogos contains a sequence of community logotypes,
+      each representing a different community.  If more than one
+      community logotype is present, they MUST be placed in order of
+      preferred appearance.  Some clients MAY choose to display a subset
+      of the present community logos; therefore, the placement within
+      the sequence aids the client selection.  The most preferred
+      logotype MUST be first in the sequence, and the least preferred
+      logotype MUST be last in the sequence.
+
+   *  issuer organization logotype: If issuerLogo is present, the
+      logotype MUST represent the issuer's organization.  The logotype
+      MUST 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 MAY be present in an end entity
+      certificate, a CA certificate, or an attribute certificate.
+
+   *  subject organization logotype: If subjectLogo is present, the
+      logotype MUST represent the subject's organization.  The logotype
+      MUST 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 MAY be present in an end entity
+      certificate, a CA certificate, or an attribute certificate.
+
+   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 that check subject organization logotypes or
+   claims about its issuer and community logotypes are outside the scope
+   of this document.
+
+4.2.  Conventions for LogotypeImageInfo
+
+   When the optional LogotypeImageInfo is included with a logotype
+   image, the parameters MUST be used with the following semantics and
+   restrictions.
+
+   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 SHOULD be scaled
+   to fit within the size parameters of LogotypeImageInfo while
+   preserving the x and y ratio.  Dithering may produce a more
+   appropriate image than linear scaling.
+
+   The resolution field is redundant for all logotype image formats
+   listed in Section 7.  The optional resolution field SHOULD be omitted
+   when the image format already contains this information.
+
+4.3.  Embedded Images
+
+   If the logotype image is provided through direct addressing, then the
+   image MAY be stored within the logotype certificate extension using
+   the "data" scheme [RFC2397].  The syntax of the "data" URI scheme is
+   shown below, which incorporates Errata ID 2045 and uses modern ABNF
+   [RFC5234]:
+
+        dataurl    = "data:" [ media-type ] [ ";base64" ] "," data
+        data       = *(reserved / unreserved / escaped)
+        reserved   = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" /
+                     "$" / ","
+        unreserved = alphanum / mark
+        alphanum   = ALPHA / DIGIT
+        mark       = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
+        escaped    = "%" hex hex
+        hex        = HEXDIG / "a" / "b" / "c" / "d" / "e" / "f"
+
+   where media-type is defined in Section 8.3.1 of [RFC9110] and ALPHA,
+   DIGIT, and HEXDIG are defined in Appendix B.1 of [RFC5234].
+
+   When including the image data in the logotype certificate extension
+   using the "data" URI scheme, the following conventions apply:
+
+   *  The value of mediaType in LogotypeDetails MUST be identical to the
+      media type value in the "data" URL.
+
+   *  The hash of the image MUST be included in logotypeHash and MUST be
+      calculated over the same data as it would have been if the image
+      had been referenced through a link to an external resource.
+
+      |  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.
+      |  
+      |  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.
+
+4.4.  Other Logotypes
+
+   Logotypes identified by otherLogos (as defined in Section 4.1) 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.
+
+   The conditions and contexts of the intended use of these logotypes
+   are defined at the discretion of the local client application.
+
+   Three other logotype types are defined in the follow subsections.
+
+4.4.1.  Loyalty Logotype
+
+   When a loyalty logotype appears in otherLogos, it MUST be identified
+   by the id-logo-loyalty object identifier.
+
+      id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }
+
+      id-logo-loyalty    OBJECT IDENTIFIER ::= { id-logo 1 }
+
+   A loyalty logotype, if present, MUST 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 MAY contain more than one loyalty logotype.
+
+   If more than one loyalty logotype is present, they MUST be placed in
+   order of preferred appearance.  Some clients MAY choose to display a
+   subset of the present loyalty logotype data; therefore, the placement
+   within the sequence aids the client selection.  The most preferred
+   loyalty logotype data MUST be first in the sequence, and the least
+   preferred loyalty logotype data MUST be last in the sequence.
+
+4.4.2.  Certificate Background Logotype
+
+   When a certificate background logotype appears in otherLogos, it MUST
+   be identified by the id-logo-background object identifier.
+
+      id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
+
+   The certificate background logotype, if present, MUST contain a
+   graphical image intended as a background image for the certificate
+   and/or a general audio sequence for the certificate.  The background
+   image MUST allow black text to be clearly read when placed on top of
+   the background image.  The logotype certificate extension MUST NOT
+   contain more than one certificate background logotype.
+
+4.4.3.  Certificate Image Logotype
+
+   When a certificate image logotype appears in otherLogos, it MUST be
+   identified by the id-logo-certImage object identifier.
+
+      id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 }
+
+   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 MUST NOT
+   contain more than one certificate image logotype.
+
+   Typical situations when a human needs to examine the visual
+   representation of a certificate are:
+
+   *  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.
+
+   *  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.
+
+   *  A person is required to select an appropriate certificate to be
+      used when authenticating to a service or identity management
+      infrastructure.  The person needs to see the available
+      certificates in order to distinguish between them in the selection
+      process.
+
+   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, such as
+   serialNumber, organizationName, country, etc.  Consequently, the
+   application can display the actual 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.
+
+   When present, the certificate image MUST 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:
+
+   *  certificate context
+
+   *  certificate issuer
+
+   *  certificate subject
+
+   Certificate 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.
+
+   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 and certificate issuer
+   information from the certificate MUST have the same meaning as the
+   textual representation of that information in the certificate itself.
+
+   Applications providing a Graphical User Interface (GUI) to the
+   certificate user MAY present a certificate image as the only visual
+   representation of a certificate; however, the certificate user SHOULD
+   be able to easily obtain the details of the certificate content.
+
+5.  Type of Certificates
+
+   Logotypes MAY be included in public key certificates and attribute
+   certificates at the discretion of the certificate issuer; however,
+   the relying party MUST NOT use the logotypes as part of certification
+   path validation or automated trust decisions.  The sole purpose of
+   logotypes is to enhance the display of a particular certificate,
+   regardless of its position in a certification path.
+
+6.  Use in Clients
+
+   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.
+
+   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 MUST NOT report an error; instead, the client MUST 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 Section 9).
+
+   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.
+
+   A client MAY, 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
+   MUST 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.
+
+   A client MAY, subject to local policy, choose any combination of
+   audio and image presentation for each logotype.  That is, the client
+   MAY display an image with or without playing a sound, and it MAY play
+   a sound with or without displaying an image.  A client MUST NOT play
+   more than one logotype audio sequence at the same time.
+
+   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.
+
+   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.
+
+   If the relying party software is unable to successfully validate a
+   particular certificate, then it MUST NOT display any logotype data
+   associated with that certificate.
+
+7.  Image Formats
+
+   Animated images SHOULD NOT be used.
+
+   The following table lists common image formats and the corresponding
+   media type.  The table also indicates the support requirements for
+   these image formats.  The file name extensions commonly used for each
+   of these formats is also provided.  Implementations MAY support other
+   image formats.
+
+      +========+==============+===========+============+============+
+      | Format | Media Type   | Extension | References | Implement? |
+      +========+==============+===========+============+============+
+      | JPEG   | image/jpeg   | .jpg      | [JPEG]     | MUST       |
+      |        |              | .jpeg     | [RFC2046]  | support    |
+      +--------+--------------+-----------+------------+------------+
+      | GIF    | image/gif    | .gif      | [GIF]      | MUST       |
+      |        |              |           | [RFC2046]  | support    |
+      +--------+--------------+-----------+------------+------------+
+      | SVG    | image/       | .svg      | [SVGT]     | SHOULD     |
+      |        | svg+xml      |           | [SVGR]     | support    |
+      +--------+--------------+-----------+------------+------------+
+      | SVG +  | image/       | .svgz     | [SVGT]     | MUST       |
+      | GZIP   | svg+xml+gzip | .svg.gz   | [SVGZR]    | support    |
+      +--------+--------------+-----------+------------+------------+
+      | PNG    | image/png    | .png      | [ISO15948] | SHOULD     |
+      |        |              |           | [PNGR]     | support    |
+      +--------+--------------+-----------+------------+------------+
+      | PDF    | application/ | .pdf      | [ISO32000] | MAY        |
+      |        | pdf          |           | [ISO19005] | support    |
+      |        |              |           | [RFC8118]  |            |
+      +--------+--------------+-----------+------------+------------+
+
+                           Table 1: Image Formats
+
+      |  NOTE: The image/svg+xml-compressed media type is widely
+      |  implemented, but it has not yet been registered with IANA.
+
+   When a Scalable Vector Graphics (SVG) image is used, whether the
+   image is compressed or not, the SVG Tiny profile [SVGT] MUST be
+   followed, with these additional restrictions:
+
+   *  The SVG image MUST NOT 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
+      [SVGT].
+
+   *  The SVG image MUST NOT contain any script element, according to
+      Section 15.2 of [SVGT].
+
+   *  The XML structure in the SVG file MUST use linefeed (0x0A) as the
+      end-of-line (EOL) character when calculating a hash over the SVG
+      image.
+
+   When a GZIP-compressed SVG image is fetched with HTTP, the client
+   will receive a response that includes these headers:
+
+      Content-Type: image/svg+xml
+      Content-Encoding: gzip
+
+   In this case, the octet stream of type image/svg+xml is compressed
+   with GZIP [RFC1952], as specified in [SVGR].
+
+   When an uncompressed SVG image is fetched with HTTP, the client will
+   receive a response with the same Content-Type header but no Content-
+   Encoding header.
+
+   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, as specified above.
+
+   When an SVG image is embedded in the certificate extension using the
+   "data" URL scheme, the SVG image data MUST be provided in GZIP-
+   compressed form, and the XML structure, prior to compression, SHOULD
+   use linefeed (0x0A) as the end-of-line (EOL) character.
+
+   When a bitmap image is used, the PNG [ISO15948] format SHOULD be
+   used.
+
+   According to [ISO32000], when a Portable Document Format (PDF)
+   document is used, it MUST also be formatted according to the profile
+   PDF/A [ISO19005].
+
+8.  Audio Formats
+
+   Implementations that support audio MUST support the MP3 audio format
+   [MP3] with a media type of "audio/mpeg" [RFC3003].  Implementations
+   SHOULD support text-based audio data with a media type of "text/
+   plain;charset=UTF-8".  Implementations MAY support other audio
+   formats.
+
+   Text-based audio data using the 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:
+
+   *  LogotypeAudioInfo MUST be present and specify the language of the
+      text.
+
+   *  The fileSize, playTime, and channels elements of LogotypeAudioInfo
+      MUST have the value of 0.
+
+   *  The sampleRate element of LogotypeAudioInfo MUST be absent.
+
+9.  Security Considerations
+
+   Implementations that simultaneously display multiple logotype types
+   (subject organization, issuer organization, community, or other) MUST
+   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 Section 1.1, and it refers to the type of entity or
+   affiliation represented by the logotype, not the of binary format of
+   the image or audio.
+
+   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.
+
+   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.
+
+   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.
+
+   This underlines the necessity for CAs to provide reliable services
+   and the relying party's responsibility and need to carefully select
+   which CAs are trusted to provide public key certificates.
+
+   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 Section 7 of [RFC3986].
+
+   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 but not the referenced image data.  Clients SHOULD verify that
+   SVG images meet all requirements listed in Section 7 and reject
+   images that contain references to external data.
+
+   CAs issuing certificates with embedded logotype images should be
+   cautious when accepting graphics from the certificate requester for
+   inclusion in the certificate if the hash algorithm used to sign the
+   certificate is vulnerable to collision attacks, as described in
+   [RFC6151].  In such a case, the accepted image may contain data that
+   could help an attacker to obtain colliding certificates with
+   identical certificate signatures.
+
+   Certification paths may also impose name constraints that are
+   systematically checked during certification path processing, which,
+   in theory, may be circumvented by logotypes.
+
+   Certificate path processing, as defined in [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 outside a limited
+   name space or outside specific certificate 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.
+
+   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 MUST be
+   treated as a 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 MAY try to fetch the remote logotype data from an
+   alternate location to resolve the failure.
+
+   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.
+
+   The controls available to a parent CA to protect itself from rogue
+   subordinate CAs are non-technical.  They include:
+
+   *  Contractual agreements of suitable behavior, including terms of
+      liability in case of material breach.
+
+   *  Control mechanisms and procedures to monitor and follow the
+      behavior of subordinate CAs, including Certificate Transparency
+      [RFC9162].
+
+   *  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.
+
+   *  Use of revocation functions to revoke any misbehaving CA.
+
+   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.
+
+10.  Privacy Considerations
+
+   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.
+
+   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 MAY 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
+   MAY reduce visibility into the data that is being returned by
+   encrypting with HTTPS and padding to a few common sizes.
+
+   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.
+
+   In addition, the use of an encrypted DNS mechanism, such as DNS over
+   TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC9230], hides the name
+   resolution traffic, which is usually a first step in fetching remote
+   logotype objects.
+
+   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 MAY wish to
+   insist that logotype data is embedded in the certificate with the
+   "data" URI scheme with direct addressing.
+
+   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.
+
+   When the "data" URI scheme is used, the relying party MAY 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.
+
+   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, ETags, and client certificates.
+
+   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.
+
+   TLS 1.3 [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.
+
+11.  IANA Considerations
+
+   For the new ASN.1 module in Appendix A.2, IANA has assigned the
+   following OID in the "SMI Security for PKIX Module Identifier"
+   registry (1.3.6.1.5.5.7.0):
+
+   +=========+======================+============+
+   | Decimal | Description          | References |
+   +=========+======================+============+
+   | 107     | id-mod-logotype-2022 | RFC 9399   |
+   +---------+----------------------+------------+
+
+                       Table 2
+
+   IANA has updated the entries in the "Structure of Management
+   Information (SMI) Numbers" registry that referred to [RFC3709] or
+   [RFC6170] to refer to this document.  These entries are noted in the
+   tables below.
+
+   From the "SMI Security for PKIX Module Identifier" registry
+   (1.3.6.1.5.5.7.0):
+
+   +=========+===========================+============+
+   | Decimal | Description               | References |
+   +=========+===========================+============+
+   | 22      | id-mod-logotype           | RFC 9399   |
+   +---------+---------------------------+------------+
+   | 68      | id-mod-logotype-certimage | RFC 9399   |
+   +---------+---------------------------+------------+
+
+                         Table 3
+
+   From the "SMI Security for PKIX Certificate Extension" registry
+   (1.3.6.1.5.5.7.1):
+
+   +=========+================+============+
+   | Decimal | Description    | References |
+   +=========+================+============+
+   | 12      | id-pe-logotype | RFC 9399   |
+   +---------+----------------+------------+
+
+                    Table 4
+
+   From the "SMI Security for PKIX Other Logotype Identifiers" registry
+   (1.3.6.1.5.5.7.20):
+
+   +=========+====================+============+
+   | Decimal | Description        | References |
+   +=========+====================+============+
+   | 1       | id-logo-loyalty    | RFC 9399   |
+   +---------+--------------------+------------+
+   | 2       | id-logo-background | RFC 9399   |
+   +---------+--------------------+------------+
+   | 3       | id-logo-certImage  | RFC 9399   |
+   +---------+--------------------+------------+
+
+                      Table 5
+
+12.  References
+
+12.1.  Normative References
+
+   [GIF]      CompuServe Incorporated, "Graphics Interchange Format",
+              Version 89a, July 1990,
+              <https://www.w3.org/Graphics/GIF/spec-gif89a.txt>.
+
+   [ISO15948] ISO/IEC, "Information technology -- Computer graphics and
+              image processing -- Portable Network Graphics (PNG):
+              Functional specification", ISO/IEC 15948:2004, March 2004.
+
+   [JPEG]     ITU-T, "Information technology -- Digital compression and
+              coding of continuous-tone still images: JPEG File
+              Interchange Format (JFIF)", ITU-T Recommendation T.871,
+              ISO/IEC 10918-5:2013, May 2013.
+
+   [MP3]      ISO/IEC, "Information technology -- Generic coding of
+              moving pictures and associated audio information -- Part
+              3: Audio", ISO/IEC 13818-3:1998, April 1998.
+
+   [NEW-ASN1] ITU-T, "Information technology -- Abstract Syntax Notation
+              One (ASN.1): Specification of basic notation", ITU-T
+              Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
+              <https://www.itu.int/rec/T-REC-X.680>.
+
+   [RFC1952]  Deutsch, P., "GZIP file format specification version 4.3",
+              RFC 1952, DOI 10.17487/RFC1952, May 1996,
+              <https://www.rfc-editor.org/info/rfc1952>.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              DOI 10.17487/RFC2046, November 1996,
+              <https://www.rfc-editor.org/info/rfc2046>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
+              DOI 10.17487/RFC2397, August 1998,
+              <https://www.rfc-editor.org/info/rfc2397>.
+
+   [RFC3003]  Nilsson, M., "The audio/mpeg Media Type", RFC 3003,
+              DOI 10.17487/RFC3003, November 2000,
+              <https://www.rfc-editor.org/info/rfc3003>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
+              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
+              September 2009, <https://www.rfc-editor.org/info/rfc5646>.
+
+   [RFC5755]  Farrell, S., Housley, R., and S. Turner, "An Internet
+              Attribute Certificate Profile for Authorization",
+              RFC 5755, DOI 10.17487/RFC5755, January 2010,
+              <https://www.rfc-editor.org/info/rfc5755>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Semantics", STD 97, RFC 9110,
+              DOI 10.17487/RFC9110, June 2022,
+              <https://www.rfc-editor.org/info/rfc9110>.
+
+   [SVGT]     World Wide Web Consortium, "Scalable Vector Graphics (SVG)
+              Tiny 1.2 Specification", W3C REC-SVGTiny12-20081222,
+              December 2008,
+              <http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/>.
+
+12.2.  Informative References
+
+   [ISO19005] ISO, "Document management -- Electronic document file
+              format for long-term preservation -- Part 1: Use of PDF
+              1.4 (PDF/A-1)", ISO 19005-1:2005, October 2005.
+
+   [ISO32000] ISO, "Document management -- Portable document format --
+              Part 1: PDF 1.7", ISO 32000-1:2008, July 2008.
+
+   [OLD-ASN1] CCITT, "Specification of Abstract Syntax Notation One
+              (ASN.1)", CCITT Recommendation X.208, November 1988,
+              <https://www.itu.int/rec/T-REC-X.208/en>.
+
+   [PNGR]     World Wide Web Consortium, "Media Type Registration for
+              image/png",
+              <https://www.iana.org/assignments/media-types/image/png>.
+
+   [RFC3709]  Santesson, S., Housley, R., and T. Freeman, "Internet
+              X.509 Public Key Infrastructure: Logotypes in X.509
+              Certificates", RFC 3709, DOI 10.17487/RFC3709, February
+              2004, <https://www.rfc-editor.org/info/rfc3709>.
+
+   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
+              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
+              DOI 10.17487/RFC5912, June 2010,
+              <https://www.rfc-editor.org/info/rfc5912>.
+
+   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
+              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
+              RFC 6151, DOI 10.17487/RFC6151, March 2011,
+              <https://www.rfc-editor.org/info/rfc6151>.
+
+   [RFC6170]  Santesson, S., Housley, R., Bajaj, S., and L. Rosenthol,
+              "Internet X.509 Public Key Infrastructure -- Certificate
+              Image", RFC 6170, DOI 10.17487/RFC6170, May 2011,
+              <https://www.rfc-editor.org/info/rfc6170>.
+
+   [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
+              for the Cryptographic Message Syntax (CMS) and the Public
+              Key Infrastructure Using X.509 (PKIX)", RFC 6268,
+              DOI 10.17487/RFC6268, July 2011,
+              <https://www.rfc-editor.org/info/rfc6268>.
+
+   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
+              and P. Hoffman, "Specification for DNS over Transport
+              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
+              2016, <https://www.rfc-editor.org/info/rfc7858>.
+
+   [RFC8118]  Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M.
+              Bailey, "The application/pdf Media Type", RFC 8118,
+              DOI 10.17487/RFC8118, March 2017,
+              <https://www.rfc-editor.org/info/rfc8118>.
+
+   [RFC9162]  Laurie, B., Messeri, E., and R. Stradling, "Certificate
+              Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
+              December 2021, <https://www.rfc-editor.org/info/rfc9162>.
+
+   [RFC9216]  Gillmor, D. K., Ed., "S/MIME Example Keys and
+              Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022,
+              <https://www.rfc-editor.org/info/rfc9216>.
+
+   [RFC9230]  Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
+              Wood, "Oblivious DNS over HTTPS", RFC 9230,
+              DOI 10.17487/RFC9230, June 2022,
+              <https://www.rfc-editor.org/info/rfc9230>.
+
+   [SVGR]     World Wide Web Consortium, "Media Type Registration for
+              image/svg+xml", <https://www.iana.org/assignments/media-
+              types/image/svg+xml>.
+
+   [SVGZR]    "A separate MIME type for svgz files is needed",
+              <https://github.com/w3c/svgwg/issues/701>.
+
+Appendix A.  ASN.1 Modules
+
+A.1.  ASN.1 Modules with 1988 Syntax
+
+   This appendix contains two ASN.1 modules, both using the old syntax
+   [OLD-ASN1].
+
+   The first ASN.1 module provides the syntax for the logotype
+   certificate extension.  Only comments have changed in the module from
+   [RFC3709] and the IMPORTS now come from [RFC5280].
+
+   The second ASN.1 module provides the certificate image object
+   identifier.  The module is unchanged from [RFC6170].
+
+   <CODE BEGINS>
+   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, -- 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
+   <CODE ENDS>
+
+A.2.  ASN.1 Module with 2002 Syntax
+
+   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 [NEW-ASN1], and it follows the
+   conventions established in [RFC5912] and [RFC6268].
+
+   This ASN.1 module incorporates the module from [RFC3709] and the
+   module from [RFC6170].
+
+   Note that [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.
+
+   <CODE BEGINS>
+   LogotypeCertExtn-2022
+     { iso(1) identified-organization(3) dod(6) internet(1)
+       security(5) mechanisms(5) pkix(7) id-mod(0)
+       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, -- 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
+   <CODE ENDS>
+
+Appendix B.  Examples
+
+B.1.  Example from RFC 3709
+
+   The following example displays a logotype certificate extension
+   containing one 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, and the image is hashed
+   with SHA-256.  This example is changed from [RFC3709] to use SHA-256
+   instead of SHA-1.
+
+   The values on the left are the ASN.1 tag (in hexadecimal) and the
+   length (in decimal).
+
+   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'
+         :           }
+         :          }
+         :         }
+         :        }
+         :       }
+         :      }
+         :     }
+         :    }
+         :   }
+
+B.2.  Issuer Organization Logotype Example
+
+   The following example displays a logotype certificate extension
+   containing one 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, and the image is
+   hashed with SHA-256.
+
+   The values on the left are the ASN.1 tag (in hexadecimal) and the
+   length (in decimal).
+
+   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'
+         :           }
+         :          }
+         :         }
+         :        }
+         :       }
+         :      }
+         :     }
+         :    }
+         :   }
+
+B.3.  Embedded Image Example
+
+   The following example displays a logotype certificate extension
+   containing one subject organization logotype using direct addressing.
+   The subject organization logotype image uses image/svg+xml+gzip.  The
+   logotype image is embedded in the certificate extension with a
+   "data:" URI, and the image is hashed by SHA-256.  This technique
+   produces a large certificate extension but offers reduced latency and
+   improved privacy.
+
+   The values on the left are the ASN.1 tag (in hexadecimal) and the
+   length (in decimal).
+
+   30 2148: SEQUENCE {
+   06    8:  OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
+   04 2134:  OCTET STRING, encapsulates {
+   30 2130:   SEQUENCE {
+   A2 2126:    [2] {
+   A0 2122:     [0] {
+   30 2118:      SEQUENCE {
+   30 2114:       SEQUENCE {
+   30 2110:        SEQUENCE {
+   16   18:         IA5String '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 2035:         SEQUENCE {
+   16 2031:          IA5String
+          :          'data:image/svg+xml+gzip;base64,H4sICIGpy2EAA2xvZ'
+          :          '28tY29weS5zdmcApVbbbhs3EH3nV0y3Lw2Q9fK2JLewHDROU'
+          :          'BRo2iBxW+RRlTa2UFkypIWV5ut7zlB2UqF9cuLlUktyLmfOz'
+          :          'PD8xafbtdyPu/1qu5k17sw2sp/mm+V8vd2Ms2azbV5cmPNvX'
+          :          'v16efXh7WvZ31/L299e/vzTpTRt1/0RLrvu1dUref/7j+Ktd'
+          :          'Xawsete/9IYaW6m6e77rjscDmeHcLbdXXdX7zpu6t69vmxxo'
+          :          'n08AREdRDt7tpyWDRRSz7+tgp2b/ew/hEKI5WGoPKyW082s8'
+          :          'SmeWf13NzVyM66ub6ZZk+xXH+9X4+Hl9tOssWLly3553ARpd'
+          :          '7txP+7uxx/2d+NiejefVttZ8+nNavkBj9yO40RLb8dpvpxP8'
+          :          'wtzuRvn07iUP/+Wu+20my9GcWfOPpfDbjVN44YLb8dp3Mn7c'
+          :          'b3aXGNCAICCc+a8+yLo/FpwfLP/uN3dzhqdriH5uwfbnj9a+'
+          :          'Uz2i/maK66utA+zZ435uFqvZ823R38Q1t32Lw3pZqThd/PpR'
+          :          'paz5o2LNkocvCzaIm0vrQvSpog359lLy3my0ga+e3Hp+B4In'
+          :          'jVFPD9awdhnrGEFW30Sl/Pnpvta2QBVxUEVxFbJ2VUFfYC01'
+          :          'pUs+O4GK84V/k6CHUFyhvhiDVQF8Y5aPDbmnsrXbS74DANjg'
+          :          'uwgENZLPwjUYVTRJQgEpiLR0ctiWj+Ig8rCvZAArxKExEEWM'
+          :          'JLqMA1F+ggnsQDXgpQeomJPCVhtCRycNrAWxgAI+g1Qsr6IU'
+          :          'xlomBswjydYBEgOeVCDoRreBjiFjX2SdSA60BP5DgQM63xoP'
+          :          'lWHbNq+egAEeAzxyNAdCQz+sDEMOhaGisKJdSlS6gtWWm4M1'
+          :          'rQwP0egEBIhhFLoXuCJhR4mT5RJBaiLKqqFROUEzYr1idG0g'
+          :          'ahwCzEnk+AMJLdp0FevQQ6VZ+SKOwGlOIJOh1MVjo0eB6DRA'
+          :          '10SRpSY6il/eFFKAm+MKSIWNFqSo4OFnORfwH5wJHCMNM0ql'
+          :          'DRlcIwUEkDlgiSBhiEpBgMKOx5FdAYqI3KYewKKkAItTABTk'
+          :          'p5khI86kgbOgRywEBR0VGcwAjf8t9wqvdUMG6gLAbI0QQ8Cb'
+          :          'zCTtCSn/DEhCbm++duQaiRG1mQkdWHnminHA+r5wpLvsJbCA'
+          :          'LUKsDW5NAj43J+AD5vpfamUzJqiRJACmCWwIMhQq4HmYGKai'
+          :          'iJPmIvpS80UzTtAjdSraApQZogslgFcJHw0y5WoEXDYr/aTq'
+          :          'fxk2qhcg3z6ETQL+S18llvHOZQvlEOVEVpzqCozE9V6JZhh/'
+          :          'lCslg7mUFY4AR7IlcApmgV6gz3DCSDe56fQ0SRS7el0NJWO8'
+          :          'mQ6mkc6ylPpaL7QUZ5IR/M/dEwoJiEp+L6iT4cdSyIp4ljDk'
+          :          'oaZpQlgMoz0ApahjTiTWbZYu9v+MUqVjY61j2Bxr68bPF3uS'
+          :          '1232qAyAQDMhr4MRyVZq5l2QcuwgY/oTozbgoIKycH+yQxhz'
+          :          'QsPJQ/ne9OmRKvYH1AeKA/EQRtzrmaYUiHUhpJOW4breSaxZ'
+          :          '/TVc3ZAQJKOagAJiw6pRHVkBMIBa5E+SUMWi0ZNW1Rfn/xQX'
+          :          'ywHXyMHN5G8WF6gZ2IVjANHMIJQ1lAJQE8MJjZHJiUtQZAWz'
+          :          'mkisDywTVWSqLkkQG2NNB3wwyaerqRGLNKpvwUOhaQFiYcqv'
+          :          'iSjvp1n8WnRRzXFs9IXDxiiDd8HU/ROoAGn9+QgTPEVu6HaN'
+          :          '6i0VPuv1SCzwyZeHwBA1EjFYoAk2jJ3OFeJ5Gp1E+3Dlf3Aj'
+          :          '70bbvmag5oyKHunVyGPq6+EnvTua/JUn3iadMHlqUapsK2T8'
+          :          'SwCBJUF1JnEmhu0ntBthJoQpZqumsBk5mA1hRc0LR5ZFerdj'
+          :          'ksaCqt3IUWXcXW16vb6xdWyHLTgCaKXWKUKK1kOp9HK5B3EL'
+          :          'jSdXb0loB5RYtS01L6h9yTPW51Wpqwgosr5I927aw6401+Yf'
+          :          'wDria4WoQwAAA=='
+          :           }
+          :          }
+          :         }
+          :        }
+          :       }
+          :      }
+          :     }
+          :    }
+          :   }
+
+B.4.  Embedded Certificate Image Example
+
+   The following example displays a logotype certificate extension
+   containing one certificate image logotype using direct addressing.
+   The certificate image logotype uses image/svg+xml+gzip.  The logotype
+   image is embedded in the certificate extension with a "data:" URI,
+   and the image is hashed by SHA-256.  This example contains the image
+   from Appendix B of [RFC6170]; however, the media type used here is
+   explicit about the use of GZIP compression [RFC1952].
+
+   The values on the left are the ASN.1 tag (in hexadecimal) and the
+   length (in decimal).
+
+   30 2902: SEQUENCE {
+   06    8:  OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12)
+   04 2888:  OCTET STRING, encapsulates {
+   30 2884:   SEQUENCE {
+   A3 2880:    [3] {
+   30 2876:     SEQUENCE {
+   30 2872:      SEQUENCE {
+   06    8:       OBJECT IDENTIFIER '1 3 6 1 5 5 7 20 3'
+   A0 2858:       [0] {
+   30 2854:        SEQUENCE {
+   30 2850:         SEQUENCE {
+   30 2846:          SEQUENCE {
+   16   18:           IA5String '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 2771:           SEQUENCE {
+   16 2767:            IA5String
+          :          'data:image/svg+xml+gzip;base64,H4sICLXutU0AA0Nlc'
+          :          'nRJbWFnZURlbW8uc3ZnANVaW2/bOBZ+n19BqBigwdoS7xK9j'
+          :          'meapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1Em8C9d9i'
+          :          'ERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJteOv/66'
+          :          '1M/cFBZhVkcpnmmL50sd34b/TIsH6YoiS+da11UySSJwkqj2'
+          :          '1k41Q6CDbNyUMSTS+e+quYDz1sul+6SuXkx9YhSysPUo7QPK'
+          :          '/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDjGiGHQ9'
+          :          '14n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKmSbLVWN'
+          :          'oo2cqNCh1XyoKN8Nsuz0iqwVW8Qb1fOF0Vqp+PI06me6awqP'
+          :          'eISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83n8wzGkbR4Gtef'
+          :          'ENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5uF1Wqu7'
+          :          'R6FLvNFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9BrFrMbeV'
+          :          'uWhtzbHvMR6UlobPyVpBWjXBk7six2vH5nCwY6nXCo5xb7Yu'
+          :          'svFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov8IF2WZh'
+          :          'NlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1boUJvQFs'
+          :          'vi+LOJyxZkPE/vCwHuAmXmoj1AarnRBatzqkbv7cK5Ls2ORf'
+          :          'wM/vsOG5lURZqXxOnDXPKZw5t5jVzIhFKO0B6D6hARSXDR6F'
+          :          'zqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpcOcOb9u'
+          :          '63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZLH96SH4'
+          :          'R9xRYApl6q3Y02f+NzlRAl+cZSKhB6qSIVa80fsqMnWOqZJp'
+          :          'msXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIzBKabmLIil470z'
+          :          'fSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KMk+l0SO'
+          :          'XlOopltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXPoTe0pn'
+          :          'u4dYbp7hJ/kxWySN0ey0o/1qbiCsxDXJMWWo37QekBcAUFPS'
+          :          'GkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzIqxT4CKs'
+          :          'PlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugqzb7c3Q'
+          :          '89u3WQKY9aegbsA/AUJB/bJs6pfJt9BHFEuk5DWITzOH5uZS'
+          :          'ThLUsDjQ5GE6RMsyihMTaQLfA6BIiAQMAhnHHN1sd61WtUhD'
+          :          'VJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAXNB8sm9'
+          :          'Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs8C1Okb'
+          :          '2/ggwLdxlDC1D6DFPZDD98txv8xQf5TEc7Ax6ZyaDf6BC4Sy'
+          :          'lWKCMqtizp80+UMchATal63qHq0M3ZTs83Ob/XO6LYsFzpGV'
+          :          'Y5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53XStSh1e'
+          :          'ogfeojV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7OamhjU1HB'
+          :          '3DLGm66n6iajz4bqn2oICmNFxDR/x2mC5s+rKhlkUA3Ne3P8'
+          :          'lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yjEEd9EUh'
+          :          'kwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8iHPud16'
+          :          'wApnCvTOzjIFAj9TQdCxa+ddOTizaa1xJvD0qMrKx+Ydaj6i'
+          :          'wJQG0vaSdYWpTv4HwVRAP3Z6ONjOJunEIeKRVmhujpA2+wPm'
+          :          'QR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGebcMg7Og'
+          :          'QKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwWY1F0Hl'
+          :          'BUC2lbyIuYF58O8p+adMwUt9YAoX/IwRtAC9NAdBAyGuEB3V'
+          :          'R59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xxfiwtr0GXECqed'
+          :          'QQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3+av4Jc'
+          :          'j78O/vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfRVjwfmO'
+          :          'nNn3GuWR+FzhcPmPqiptHcayacT28T8j3Cs0/LQCwo6J2iYx'
+          :          'P4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbkBYwETNP'
+          :          't/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjkji8quL'
+          :          '3cDyW7TpI3unxezMcSTNhQJhfpGctKgKN2Amo7/7ShSev4oX'
+          :          'icPSYS+6GkCm9a1Qw3VEchCUA+z5HtTcbQhK6F14YFUp+Yn7'
+          :          'WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnTW61zjQ'
+          :          '7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9TeNGUHi'
+          :          'bE9Nv//2jRJGZfQmK3v7ykJJOv1IXjBsDCPpmgWppe6sHxR3'
+          :          'KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLhdCXKq8uR0R+LD'
+          :          'EqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz31cuoc'
+          :          'voO/qemClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlDpE/oyl'
+          :          'py+2/6pWXK31PEYagP04epV1cE50UMy6IQZeQM7+Ol74Z+eH'
+          :          'fpHNc7OjffQ/HeV0X8BopoDkGEkAAA='
+          :             }
+          :            }
+          :           }
+          :          }
+          :         }
+          :        }
+          :       }
+          :      }
+          :     }
+          :    }
+          :   }
+
+B.5.  Full Certificate Example
+
+   The following example contains a certificate for Alice; it is
+   essentially a renewal of the certificate that appears in [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.
+
+   -----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-----
+
+   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).
+
+   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'
+         :           }
+         :          }
+         :         }
+         :        }
+         :       }
+         :      }
+         :     }
+         :    }
+         :   }
+
+Appendix C.  Changes since RFCs 3709 and 6170
+
+   This appendix summarizes the changes since [RFC3709].  The changes
+   are:
+
+   *  Combine RFCs 3709 and 6170 into one document, and encourage
+      implementers to support the "data" URI scheme (data:...) that was
+      originally specified in RFC 6170.  Merging RFCs 3709 and 6170 led
+      to many editorial changes throughout the document.
+
+   *  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.
+
+   *  RFC 3709 required client applications to support both direct and
+      indirect addressing.  This requirement is changed to SHOULD
+      support both direct and indirect addressing to allow
+      implementations to be more privacy preserving.
+
+   *  Update the reference for language tags to be RFC 5646 instead of
+      the now obsolete RFC 3066.
+
+   *  Update the reference for the URI Generic Syntax to be RFC 3986
+      instead of the now obsolete RFC 2396.
+
+   *  Update the reference for the application/pdf media type to be RFC
+      8118 instead of the now obsolete RFC 3778.
+
+   *  No longer require support for the FTP scheme (ftp://...) URI.
+
+   *  Require support for the HTTP scheme (http://...) URI and the HTTPS
+      scheme (https://...) URI.
+
+   *  Provide syntax of the "data" URI scheme using modern ABNF.
+
+   *  Require support for the compressed SVG image format with the
+      image/svg+xml+gzip media type.
+
+   *  Media types MUST follow the ABNF [RFC5234] that is provided in
+      Section 8.3.1 of [RFC9110].  This change resolves Errata ID 2679.
+
+   *  Remove the requirement that the LogotypeData file name have a file
+      extension of ".LTD".  This change resolves Errata ID 2325.
+
+   *  Encourage, instead of requiring, each logotype to be represented
+      by at least one image.
+
+   *  Encourage the inclusion of text-based audio data suitable for
+      processing by a text-to-speech software using the media type of
+      "text/plain;charset=UTF-8".
+
+   *  Encourage the use of dithering if an image needs to be scaled.
+
+   *  Require that the logotype certificate extension not contain more
+      than one certificate image logotype.
+
+   *  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.
+
+   *  Provide ASN.1 modules for both the older syntax [OLD-ASN1] and the
+      most recent ASN.1 syntax [NEW-ASN1].
+
+   *  Provide additional references.
+
+   *  Provide additional examples.
+
+   *  Several editorial changes to improve clarity.
+
+   *  The example in Appendix B.1 was changed to use SHA-256 instead of
+      SHA-1.
+
+Acknowledgments
+
+   *  Acknowledgments from RFC 3709
+
+      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 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 for their efforts and
+      support.
+
+      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.
+
+   *  Acknowledgments from RFC 6170
+
+      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.
+
+   *  Additional Acknowledgments
+
+      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 Alexey Melnikov for his guidance on media types.  We
+      extend a special thanks to Tim Geiser for his careful checking of
+      the new examples in Appendices 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, Éric
+      Vyncke, Donald Eastlake 3rd, and Dan Harkins for their careful
+      review and helpful comments.
+
+Authors' Addresses
+
+   Stefan Santesson
+   IDsec Solutions AB
+   Forskningsbyn Ideon
+   SE-223 70 Lund
+   Sweden
+   Email: sts@aaa-sec.com
+
+
+   Russ Housley
+   Vigil Security, LLC
+   516 Dranesville Road
+   Herndon, VA 20170
+   United States of America
+   Email: housley@vigilsec.com
+
+
+   Trevor Freeman
+   Amazon Web Services
+   1918 8th Ave
+   Seattle, WA 98101
+   United States of America
+   Email: frtrevor@amazon.com
+
+
+   Leonard Rosenthol
+   Adobe
+   345 Park Avenue
+   San Jose, CA 95110
+   United States of America
+   Email: lrosenth@adobe.com