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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
