Internet X.509 Public Key Infrastructure -- Certificate Image
obsoleted by
- rfc-9399 — Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
updates
- rfc-3709 — Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
Extracted elements (25)
Certificate images were introduced because applications lack out-of-band knowledge to interpret semantics of identity attributes (serialNumber, organizationName, country, etc.), making it difficult to label and organize certificate information meaningfully in a UI. A complete visual representation authored by the issuer solves this display challenge.
SVG images embedded via the 'data' URL scheme are required to be in SVGZ (compressed) form to limit certificate size growth, since large embedded objects could prevent the certificate from being used as intended.
The LogotypeImageInfo structure references RFC 3066 for language tags (as inherited from RFC 3709), but RFC 3066 is obsolete and replaced by RFC 5646. Implementations should treat the language tag field as an RFC 5646 language tag.
A certificate image provided as PDF MUST conform to ISO 32000 and MUST also be formatted according to the PDF/A profile (ISO 19005). The MIME media type 'application/pdf' MUST be used as mediaType in LogotypeDetails.
Applications providing a GUI MAY present a certificate image as the only visual representation of a certificate.
If a certificate image is provided as a bitmapped image, the PNG format SHOULD be used, identified by mediaType 'image/png' in LogotypeDetails.
Implementations MUST support JPEG and GIF as defined in RFC 3709. Additionally, PDF, SVG, and PNG are specified as supported image formats.
SVG certificate images MUST follow the SVG Tiny 1.2 profile and MUST NOT contain any IRI references to external resources of type B, C, or D (per SVG Tiny 1.2 Section 14.1.4), and MUST NOT contain any 'script' element.
The hash of the embedded image MUST be included in logotypeHash and MUST be calculated over the same data as if the image had been referenced through a link to an external resource.
The MIME media type 'image/svg+xml' MUST be used as mediaType in LogotypeDetails for all SVG and SVGZ images. Compliant implementations SHOULD be able to process SVG images formatted per Section 5.2.
The resolution parameter in LogotypeImageInfo is redundant for all relevant certificate image formats and MUST NOT be specified.
The visual representation of Certificate Subject and Certificate Issuer information in the image MUST have the same meaning as the textual representation of that information in the certificate itself.
The XML structure in SVG files MUST use <LF> (0x0A) as the end-of-line character when calculating a hash over the SVG image, ensuring canonical hash computation.
When an SVG image is embedded using the 'data' URL scheme, the SVG data MUST be provided in SVGZ (GZIP compressed) form. Hashing of SVGZ is calculated over the decompressed SVG content with canonicalized EOL characters.
When embedding image data via the 'data' URL scheme, the value of mediaType in LogotypeDetails MUST be identical to the media type value in the 'data' URL.
When non-zero xSize/ySize values differ from the actual image dimensions, the referenced image SHOULD be scaled to fit within the LogotypeImageInfo size parameters while keeping the x/y aspect ratio intact. A value of 0 means no recommended display size.
When present, the certificate image MUST be a complete visual representation of the certificate, covering at minimum Certificate Context, Certificate Issuer, and Certificate Subject information.
Certificates and their images are commonly public objects, but if a certificate image referenced from a certificate contains privacy-sensitive information, appropriate security controls should be in place to protect that information.
Certificate images MAY be embedded directly in the Logotype extension using the RFC 2397 'data' URL scheme within the LogotypeDetails structure, which carries mediaType (MIME type), logotypeHash (sequence of hash values), and logotypeURI.
The certificate image otherLogos type is identified by OID id-logo-certimage, defined as { id-pkix 20 3 }, where id-pkix is { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }. It extends the Logotype extension of RFC 3709 to carry a complete visual representation of the certificate.
The optional LogotypeImageInfo structure from RFC 3709 carries type (color/grayscale), fileSize (octets), xSize and ySize (pixels), optional resolution, and optional language tag (RFC 5646). When included with a certificate image, specific semantics and restrictions apply.
This document registers OID id-logo-certimage ({ id-pkix 20 3 }, i.e., 1.3.6.1.5.5.7.20.3) as a new otherLogos type for the certificate image extension, and registers ASN.1 module id-mod-logotype-certimage (OID { id-pkix id-mod(0) 68 }).
A CA with bad intentions or weak security procedures could include false, conflicting, or malicious graphical information in a certificate image — e.g., visual content contradicting text-based attributes, or image data exploiting vulnerabilities in rendering libraries. Relying parties must carefully select trusted CAs and use up-to-date software libraries.
CAs should be cautious when accepting graphics for embedding if the hash algorithm used to sign the certificate is vulnerable to collision attacks, as accepted image data could assist an attacker in obtaining colliding certificates with identical signatures.
SVG images allow references to external resources; if such references appeared in a certificate image, the certificate hash would cover only the URI and not the referenced data. Clients SHOULD verify that SVG images meet all Section 5.2 requirements and reject images containing external data references.