Protocol Action: 'Internet X.509 Public Key Infrastructure - Certificate Image' to Proposed Standard (draft-ietf-pkix-certimage-11.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Internet X.509 Public Key Infrastructure - Certificate Image'
  (draft-ietf-pkix-certimage-11.txt) as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509)
Working Group.

The IESG contact persons are Tim Polk and Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-pkix-certimage/




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