Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
obsoletes
Extracted elements (29)
Indirect addressing supports cases where each logotype is represented by many alternative audio or image objects, while direct addressing is suited to one or a few alternatives. Both mechanisms accommodate multiple URIs for replication to improve availability.
The HTTP scheme (rather than HTTPS) may be easier for clients when fetching logotype data because HTTPS requires validating additional certificates to establish a secure connection. The hash of the logotype data already provides data integrity regardless of transport scheme.
This document obsoletes RFC 3709 (logotype extension) and RFC 6170 (certificate image). The ASN.1 module from RFC 3709 is updated only in comments and IMPORTS; the OIDs and structure are unchanged. A new 2002-syntax ASN.1 module (id-mod-logotype-2022, arc 107) is also provided.
All direct addressing URIs SHOULD use the HTTPS, HTTP, or DATA scheme. The 'data' URI scheme MUST NOT be used with indirect addressing. Clients MUST support retrieval via HTTP (RFC 9110) and HTTP with TLS (RFC 8446).
CAs MUST include a hash value for each referenced logotype object calculated over the whole object, and MUST use the hash function associated with the certificate signature. Clients MUST compute a hash using one of the identified functions and MUST discard logotype data if the computed hash does not match the certificate extension value.
Compliant applications MUST NOT display more than one of the image objects and MUST NOT play more than one audio object for any logotype type at the same time. A client MAY simultaneously display logotypes of different types.
If a client is unable to support a provided logotype, it MUST NOT report an error; instead it MUST behave as though no logotype certificate extension was included. The client MUST include the ability to disable the fetching of logotypes.
If relying party software is unable to successfully validate a particular certificate, it MUST NOT display any logotype data associated with that certificate.
Implementations MUST support image data. Support for audio data is OPTIONAL. Each logotype present in a certificate MUST be represented by at least one image data object.
Implementations that support audio MUST support MP3 (audio/mpeg). Implementations SHOULD support text-based audio (text/plain;charset=UTF-8) for text-to-speech. When text-based audio is used, LogotypeAudioInfo MUST be present with language specified, and fileSize, playTime, and channels MUST be 0 with sampleRate absent.
JPEG and GIF image formats MUST be supported. SVG+GZIP (image/svg+xml+gzip) MUST be supported. SVG and PNG SHOULD be supported. When SVG is used, the SVG Tiny 1.2 profile MUST be followed; the SVG image MUST NOT contain external IRI references of type B, C, or D, and MUST NOT contain any script element.
Relying parties MUST NOT use logotypes as part of certification path validation or automated trust decisions. The sole purpose of logotypes is to enhance the display of a certificate.
The logotype certificate extension MUST be identified by id-pe-logotype (1.3.6.1.5.5.7.1.12) and MUST NOT be marked critical.
The logotype certificate extension MUST NOT be an active component in automated certification path validation as specified in RFC 5280 Section 6. Logotypes are solely aimed at human interpretation.
When a certificate image logotype (id-logo-certImage) is present, it MUST be a complete visual representation of the certificate showing certificate context, issuer, and subject. The visual representation of subject and issuer information MUST have the same meaning as the textual representation in the certificate.
Remote logotype fetching enables network observers and server operators to determine which clients are using certificates with particular logotype data, potentially revealing certificate usage frequency. Clients SHOULD cache logotype data to reduce fetching frequency, and MAY use HTTPS with padding to reduce visibility.
Using the 'data' URI scheme with direct addressing embeds logotype data in the certificate, generating no network traffic to fetch logotype data and thereby avoiding network observation and server-side tracking. Privacy-aware subscribers MAY insist on embedded logotype data.
When TLS 1.3 encrypts the server's certificate during handshake to hide server identity, a client that subsequently fetches remote logotype data referenced in that certificate may disclose the otherwise-protected server identity through the logotype fetch request.
The LogotypeExtn ASN.1 SEQUENCE contains four OPTIONAL fields: communityLogos [0], issuerLogo [1], subjectLogo [2], and otherLogos [3]. At least one of the optional elements MUST be present. LogotypeInfo is a CHOICE between direct (LogotypeData) and indirect (LogotypeReference) addressing.
Three 'other' logotype types are defined under id-logo (1.3.6.1.5.5.7.20): id-logo-loyalty (arc 1) for loyalty program logotypes, id-logo-background (arc 2) for certificate background images (MUST NOT exceed one per certificate), and id-logo-certImage (arc 3) for a complete visual certificate representation (MUST NOT exceed one per certificate).
Three standard logotype types are defined: community logotype (identifies a service community or brand affiliation), issuer organization logotype (represents the issuer's organization), and subject organization logotype (represents the subject's organization). Additional types may be defined via OID.
IANA assigned OID arc 107 (id-mod-logotype-2022) in the 'SMI Security for PKIX Module Identifier' registry (1.3.6.1.5.5.7.0), and updated existing entries for id-mod-logotype (22) and id-mod-logotype-certimage (68) to reference RFC 9399. The 'SMI Security for PKIX Certificate Extension' registry entry 12 (id-pe-logotype) and 'SMI Security for PKIX Other Logotype Identifiers' entries 1–3 (loyalty, background, certImage) are also updated.
CAs accepting graphics from certificate requesters for embedded logotypes should be cautious if the hash algorithm used to sign the certificate is vulnerable to collision attacks (per RFC 6151), as the accepted image may help an attacker obtain colliding certificates with identical signatures.
Fraudulent CAs can create certificates with names and logotypes they have no claim to, attempting social engineering. The logotype trust model requires that logotype graphics are trusted only if the certificate is successfully validated within a valid certification path. No technical mechanism prevents subordinate CAs from including inappropriate logotypes; parent CAs must rely on contractual agreements, monitoring (e.g., Certificate Transparency), and revocation.
SVG images can reference external data. If this feature were used, the hash would only cover the URI reference, not the referenced image data. Clients SHOULD verify that SVG images meet all Section 7 requirements and reject images containing references to external data.
When fetching remote logotype data, a mismatch between the mediaType field in LogotypeDetails and the Content-Type HTTP header MUST be treated as a failure and the fetched data MUST NOT be presented to the user. The relying party MAY try an alternate URI location.
LogotypeDetails contains mediaType (IA5String for MIME type), logotypeHash (SEQUENCE OF HashAlgAndValue, minimum one entry), and logotypeURI (SEQUENCE OF IA5String, minimum one entry). HashAlgAndValue pairs an AlgorithmIdentifier with an OCTET STRING hash value.
LogotypeImageInfo encodes type (grayScale=0 or color=1, DEFAULT color), fileSize in octets, xSize and ySize in pixels, optional resolution (bits per pixel or color table size), and optional RFC 5646 language tag. LogotypeAudioInfo encodes fileSize, playTime in milliseconds, channels (0=unspecified, 1=mono, 2=stereo, 4=quad), optional sampleRate, and optional language tag.
LogotypeReference for indirect addressing contains refStructHash (SEQUENCE OF HashAlgAndValue) and refStructURI (SEQUENCE OF IA5String). The URI MUST point to a resource containing DER-encoded LogotypeData.