RFC 9399: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates

RFC 9399: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
RFC 9399
Logotypes in X.509 Certificates
May 2023
Santesson, et al.
Standards Track
[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9399
Obsoletes:
3709
6170
Category:
Standards Track
Published:
May 2023
ISSN:
2070-1721
Authors:
S. Santesson
IDsec Solutions
R. Housley
Vigil Security
T. Freeman
Amazon Web Services
L. Rosenthol
Adobe
RFC 9399
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
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
) 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
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.
Table 1
Image Formats
Format
Media Type
Extension
References
Implement?
JPEG
image/jpeg
.jpg
.jpeg
JPEG
RFC2046
MUST
support
GIF
image/gif
.gif
GIF
RFC2046
MUST
support
SVG
image/svg+xml
.svg
SVGT
SVGR
SHOULD
support
SVG + GZIP
image/svg+xml+gzip
.svgz
.svg.gz
SVGT
SVGZR
MUST
support
PNG
image/png
.png
ISO15948
PNGR
SHOULD
support
PDF
application/pdf
.pdf
ISO32000
ISO19005
RFC8118
MAY
support
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):
Table 2
Decimal
Description
References
107
id-mod-logotype-2022
RFC 9399
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):
Table 3
Decimal
Description
References
22
id-mod-logotype
RFC 9399
68
id-mod-logotype-certimage
RFC 9399
From the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1):
Table 4
Decimal
Description
References
12
id-pe-logotype
RFC 9399
From the "SMI Security for PKIX Other Logotype Identifiers" registry (1.3.6.1.5.5.7.20):
Table 5
Decimal
Description
References
id-logo-loyalty
RFC 9399
id-logo-background
RFC 9399
id-logo-certImage
RFC 9399
12.
References
12.1.
Normative References
[GIF]
CompuServe Incorporated
"Graphics Interchange Format"
Version 89a
July 1990
[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
[RFC1952]
Deutsch, P.
"GZIP file format specification version 4.3"
RFC 1952
DOI 10.17487/RFC1952
May 1996
[RFC2046]
Freed, N.
and
N. Borenstein
"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"
RFC 2046
DOI 10.17487/RFC2046
November 1996
[RFC2119]
Bradner, S.
"Key words for use in RFCs to Indicate Requirement Levels"
BCP 14
RFC 2119
DOI 10.17487/RFC2119
March 1997
[RFC2397]
Masinter, L.
"The "data" URL scheme"
RFC 2397
DOI 10.17487/RFC2397
August 1998
[RFC3003]
Nilsson, M.
"The audio/mpeg Media Type"
RFC 3003
DOI 10.17487/RFC3003
November 2000
[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
[RFC5234]
Crocker, D., Ed.
and
P. Overell
"Augmented BNF for Syntax Specifications: ABNF"
STD 68
RFC 5234
DOI 10.17487/RFC5234
January 2008
[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
[RFC5646]
Phillips, A., Ed.
and
M. Davis, Ed.
"Tags for Identifying Languages"
BCP 47
RFC 5646
DOI 10.17487/RFC5646
September 2009
[RFC5755]
Farrell, S.
Housley, R.
, and
S. Turner
"An Internet Attribute Certificate Profile for Authorization"
RFC 5755
DOI 10.17487/RFC5755
January 2010
[RFC8174]
Leiba, B.
"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
BCP 14
RFC 8174
DOI 10.17487/RFC8174
May 2017
[RFC8446]
Rescorla, E.
"The Transport Layer Security (TLS) Protocol Version 1.3"
RFC 8446
DOI 10.17487/RFC8446
August 2018
[RFC9110]
Fielding, R., Ed.
Nottingham, M., Ed.
, and
J. Reschke, Ed.
"HTTP Semantics"
STD 97
RFC 9110
DOI 10.17487/RFC9110
June 2022
[SVGT]
World Wide Web Consortium
"Scalable Vector Graphics (SVG) Tiny 1.2 Specification"
W3C REC-SVGTiny12-20081222
December 2008
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
[PNGR]
World Wide Web Consortium
"Media Type Registration for 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
[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
[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
[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
[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
[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
[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
[RFC9162]
Laurie, B.
Messeri, E.
, and
R. Stradling
"Certificate Transparency Version 2.0"
RFC 9162
DOI 10.17487/RFC9162
December 2021
[RFC9216]
Gillmor, D. K., Ed.
"S/MIME Example Keys and Certificates"
RFC 9216
DOI 10.17487/RFC9216
April 2022
[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
[SVGR]
World Wide Web Consortium
"Media Type Registration for image/svg+xml"
[SVGZR]
"A separate MIME type for svgz files is needed"
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

LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }