Technical Summary
RFC 3709 defines a way to bind a logo or analogous image
to a certificate, to aid human interpretation of a certificate
by providing meaningful visual information to the user
interface. This document specifies three new encodings for
visual representations, as an extension of RFC 3709, using
the otherLogos extension capability of that RFC. Thus it
represents an incremental change to the fundamental
capability provided by 3709.
Working Group Summary
WG process was not particularly smooth. At the first WGLC
this document generated a fairly large amount of discussion
where several WG members voiced security concerns as well
as concerns whether the problem addressed by this draft
requires a solution or whether this problem would be better
served by another solution. These security concerns were
addressed as a result of changes made after the first WGLC.
The residual objection that was raised by a few individuals
(during the second WGLC) is whether this solution is will be
successful, i.e., deployed.
The WG chair judged this document to have "very rough consensus".
The wg emails were reviewed by both SEC ADs, and believe
that sufficient consensus existed to progress.
Document Quality
We have seen no deployment of certificates with the 3709
extension, nor are we aware of code to make use of this extension
in relying party software. However, several major implementers
have stated their support for the current draft. The ETSI ESI
(Electronic Signature Infrastructure) group is also referencing
this specification as a component for their Visible Signatures work.
Personnel
Steve Kent is the Document Shepherd for this document. Tim
Polk is the Responsible Area Director.
RFC Editor Note
In section 4.1, please make the following substitution:
OLD
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters
NEW
LogotypeDetails ::= SEQUENCE {
mediaType IA5String, -- MIME media type name and optional
-- parameters (see section 5)
In Section 5.2, please make the following substitution:
OLD
The referenced SVG file MAY be provided in GZIP [RFC1952] compressed
form as an SVGZ file according to section 1.2 in SVG 1.1 [SVG].
NEW
The referenced SVG file MAY be provided in GZIP [RFC1952] compressed
form as an SVGZ file. In this case, the extension 'svgz' is used as
an alias for 'svg.gz' [RFC1952], i.e. octet streams of type
image/svg+xml, subsequently compressed with gzip as specified in [SVGR].
In Section 5.2, please replace the 2nd to the last paragraph to read:
OLD:
When the SVG image is embedded using the "data" URL scheme as defined
in section 5, SVG image data SHOULD be provided in SVGZ (GZIP
^ ^^^^^^
compressed) form and MAY be provided in uncompressed SVG form.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Compliant implementations that process embedded SVG images MUST be
able to handle both compressed and uncompressed image data.
NEW:
When the SVG image is embedded using the "data" URL scheme as defined
in section 4, SVG image data MUST be provided in SVGZ (GZIP
^ ^^^^
compressed) form (i.e. it MUST NOT be provided in uncompressed SVG form).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please add the following informative reference:
[SVGR] "Media Type Registration for image/svg+xml",
http://dev.w3.org/SVG/profiles/1.1F2/master/mimereg.html