Internet X.509 Public Key Infrastructure -- Certificate Image
draft-ietf-pkix-certimage-11

[Ballot comment]
As W3C has finally requested registration of image/svg+xml (see ), I am going to unblock this draft on the image/svg+xml registration issue.


1) 5. Embedded images

  The certificate image otherLogos type MAY be stored within the
  logotype extension using the "data" URL scheme defined in RFC 2397
  [RFC2397] if the logotype image is provided through direct
  addressing, i.e. the image is referenced using the LogotypeDetails
  structure.

To clarify: this document doesn't update RFC 3709 to allow use of "data" in
    1) Community logotype
    2) Issuer organization logotype
    3) Subject organization logotype
?

2) 4.2. PNG

  If a certificate image is provided as a bit mapped image, the PNG
  [ISO15948] format SHOULD be used.

  PNG images are identified by the following mediaType in
  LogotypeDetails:

      image/png

It is a shame that there is no RFC that describe this MIME type. But this is not a problem of this document.


3) I have some small set of issues on RFC 3709, which would have been a COMMENT level material if I were to review it for IESG:

In Section 4.1 of RFC 3709:

LogotypeDetails ::= SEQUENCE {
  mediaType      IA5String, -- MIME media type name and optional
                              -- parameters

The format of this field is not specified. This turned out to be an interop problem in some other similar cases.


In Section 4.1 of RFC 3709:

LogotypeImageInfo ::= SEQUENCE {
  type            [0] LogotypeImageType DEFAULT color,
  fileSize        INTEGER,  -- In octets
  xSize          INTEGER,  -- Horizontal size in pixels
  ySize          INTEGER,  -- Vertical size in pixels
  resolution      LogotypeImageResolution OPTIONAL,
  language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

I have to say that I don't see much point in tagging *images* with a language tag. If the image is in a format like PDF, then one would hope that language tagging is possible in the document itself. If the image is in a format like text/plain, then it is not really an image.

But I suppose this is mostly harmless, as long as any language tagging information in the media itself overrides this value.
So I think this is something that needs to be clarified if RFC 3709 is updated.

[...]

  When using indirect addressing, the URI (refStructURI) pointing to
  the external data structure MUST point to a binary file containing
  the DER encoded data with the syntax LogotypeData.  The referenced
  file name SHOULD include a file extension of "LTD".

This should have been a proper MIME type registration. I don't think it is possible to just register a file extension.

[Ballot discuss]
This is a fine document and I generally support its publication:

5) (Thanks to Robert)

In Section 5.2:

  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].

According to the updated MIME type registration (see ), this text is no longer correct.

If you want to be able to use this feature, you need to add a new parameter that can be used to specify Content encoding.

[Ballot comment]
As W3C has finally requested registration of image/svg+xml (see ), I am going to unblock this draft on the image/svg+xml registration issue.


1) 5. Embedded images

  The certificate image otherLogos type MAY be stored within the
  logotype extension using the "data" URL scheme defined in RFC 2397
  [RFC2397] if the logotype image is provided through direct
  addressing, i.e. the image is referenced using the LogotypeDetails
  structure.

To clarify: this document doesn't update RFC 3709 to allow use of "data" in
    1) Community logotype
    2) Issuer organization logotype
    3) Subject organization logotype
?

2) 4.2. PNG

  If a certificate image is provided as a bit mapped image, the PNG
  [ISO15948] format SHOULD be used.

  PNG images are identified by the following mediaType in
  LogotypeDetails:

      image/png

It is a shame that there is no RFC that describe this MIME type. But this is not a problem of this document.


3) I have some small set of issues on RFC 3709, which would have been a COMMENT level material if I were to review it for IESG:

In Section 4.1 of RFC 3709:

LogotypeImageInfo ::= SEQUENCE {
  type            [0] LogotypeImageType DEFAULT color,
  fileSize        INTEGER,  -- In octets
  xSize          INTEGER,  -- Horizontal size in pixels
  ySize          INTEGER,  -- Vertical size in pixels
  resolution      LogotypeImageResolution OPTIONAL,
  language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

I have to say that I don't see much point in tagging *images* with a language tag. If the image is in a format like PDF, then one would hope that language tagging is possible in the document itself. If the image is in a format like text/plain, then it is not really an image.

But I suppose this is mostly harmless, as long as any language tagging information in the media itself overrides this value.
So I think this is something that needs to be clarified if RFC 3709 is updated.

[...]

  When using indirect addressing, the URI (refStructURI) pointing to
  the external data structure MUST point to a binary file containing
  the DER encoded data with the syntax LogotypeData.  The referenced
  file name SHOULD include a file extension of "LTD".

This should have been a proper MIME type registration. I don't think it is possible to just register a file extension.

[Ballot discuss]
This is a fine document and I generally support its publication:

3) I have some small set of issues on RFC 3709, which would have been DISCUSS level material if I were to review it for IESG. So this is DISCUSS DISCUSS (i.e. I want to discuss it with the rest of IESG):

In Section 4.1 of RFC 3709:

LogotypeDetails ::= SEQUENCE {
  mediaType      IA5String, -- MIME media type name and optional
                              -- parameters

The format of this field is not specified. This turned out to be an interop problem in some other similar cases.

Alexey: Sorry, but I don't remember what was decided about this issue?


5) (Thanks to Robert)

In Section 5.2:

  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].

According to the updated MIME type registration (see <), this text is no longer correct.

If you want to be able to use this feature, you need to add a new parameter that can be used to specify Content encoding.

[Ballot comment]
In Section 3:

The optional LogotypeImageInfo structure is defined in [RFC3709] and
  is included here for convenience:

      LogotypeImageInfo ::= SEQUENCE {
        type          [0] LogotypeImageType DEFAULT color,
        fileSize      INTEGER,  -- In octets
        xSize        INTEGER,  -- Horizontal size in pixels
        ySize        INTEGER,  -- Vertical size in pixels
        resolution    LogotypeImageResolution OPTIONAL,
        language      [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

Alexey already observed in a COMMENT that it looks useless to tag a logo image for language. Moreover, RFC 3709 is using the RFC 3066 Lamnguage Tag, while 3066 was obsolete by RFC 4646 which was later obsoleted by RFC 5646. I wonder if this would not rather cause problems than help.

I suggest the following:

- explain why a language tag is useful in a logo image

- clarify if the RFC 3066 tag still applies  although RFC 3066 was twice obsolete since it was published by RFC 4646 and  RFC 5646

[Ballot comment]
In Section 3:

The optional LogotypeImageInfo structure is defined in [RFC3709] and
  is included here for convenience:

      LogotypeImageInfo ::= SEQUENCE {
        type          [0] LogotypeImageType DEFAULT color,
        fileSize      INTEGER,  -- In octets
        xSize        INTEGER,  -- Horizontal size in pixels
        ySize        INTEGER,  -- Vertical size in pixels
        resolution    LogotypeImageResolution OPTIONAL,
        language      [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

Alexey already observed in a COMMENT that it looks useless to tag a logo image for language. Moreover, RFC 3709 is using the RFC 3066 Lamnguage Tag, while 3066 was obsolete by RFC 4646 which was later obsoleted by RFC 5646. I wonder if this would not rather cause problems than help.

I suggest to following:

- explain why a language tag is useful in a logo image

- clarify if the RFC 3066 tag still applies  although RFC 3066 was twice obsolete since it was published by RFC 4646 and  RFC 5646

[Ballot discuss]
This is a fine document and I generally support its publication:

3) I have some small set of issues on RFC 3709, which would have been DISCUSS level material if I were to review it for IESG. So this is DISCUSS DISCUSS (i.e. I want to discuss it with the rest of IESG):

In Section 4.1 of RFC 3709:

LogotypeDetails ::= SEQUENCE {
  mediaType      IA5String, -- MIME media type name and optional
                              -- parameters

The format of this field is not specified. This turned out to be an interop problem in some other similar cases.

  logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
  logotypeURI    SEQUENCE SIZE (1..MAX) OF IA5String }

4) Process related issue: image/svg+xml MIME type is not registered in the IANA MIME type registry.

Update on 31 October 2010: I am still waiting for W3C to submit the registration of image/svg+xml to IESG for approval.

5) (Thanks to Robert)

In Section 5.2:

  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]. Hash
  over the SVGZ file is calculated over the decompressed SVG content
  with canonicalized EOL characters () as specified above.

This would require a separate MIME type registration. I don't think it is Ok to just reuse image/svg+xml.

Update on 31 October 2010: Discussions with MIME experts in IETF and W3C suggest that IETF+W3C might need to work on an update to MIME to clarify this issue. One possible outcome might be to allow this variance for use in HTTP.

[Ballot comment]
updated 2010-10-11

Abstract should not include citations (e.g., [RFC5280]).

Please reword "to a [RFC5280] public key certificate"; e.g., "to a
public key certificate as defined in RFC 5280."

[Ballot comment]
Nit: OK, so I've learned to live with (or at least stop complaining about) the citation syntax "... as defined in [RFC FOO]" because of the availability of hyperlinks (in some representations) and the convenience of clicking through to the cited reference.  But I can't parse this syntax: "...to that [RFC5280] certificate...".  Is "[RFC5280]" an adjective describing a kind of certificate?

[Ballot discuss]
After a little reflection, I decided to change this point to a DISCUSS...

Following up on Peter's first DISCUSS point, without additional description of how the information that might be represented in the certimage, I don't understand how these points from the Security Considerations might be enforced:

  A bad performing CA may for example;

      - include information in graphical form that is in conflict with
        information in provided text based attributes or other name
        forms

Another nit: s/;/:/ above.

  Certificates, and hence their cert images, are commonly public
  objects and as such usually will not not contain privacy sensitive
  information.  However, when a cert image that is referenced from a
  certificate contains privacy sensitive information appropriate
  security controls should be in place to protect the privacy of that
  information. Details of such controls are outside the scope of this
  document.

[Ballot comment]
Nit: OK, so I've learned to live with (or at least stop complaining about) the citation syntax "... as defined in [RFC FOO]" because of the availability of hyperlinks (in some representations) and the convenience of clicking through to the cited reference.  But I can't parse this syntax: "...to that [RFC5280] certificate...".  Is "[RFC5280]" an adjective describing a kind of certificate? 

Following up on Peter's first DISCUSS point, without additional description of how the information that might be represented in the certimage, I don't understand how these points from the Security Considerations might be enforced:

  A bad performing CA may for example;

      - include information in graphical form that is in conflict with
        information in provided text based attributes or other name
        forms

Another nit: s/;/:/ above.

  Certificates, and hence their cert images, are commonly public
  objects and as such usually will not not contain privacy sensitive
  information.  However, when a cert image that is referenced from a
  certificate contains privacy sensitive information appropriate
  security controls should be in place to protect the privacy of that
  information. Details of such controls are outside the scope of this
  document.

[Ballot discuss]
1. What in the world is "a visual representation of a certificate"? This notion is not explained very clearly in the spec. Is it a company logo for the organization to which the cert was issued? Is it something like a "tag cloud"  that maps out the information contained in the cert? Is it a geeky form of kitten auth ? Is it whatever the issuer decides to include? Please explain this intriguing idea in more concrete terms or at least provide examples.

2. Memorability and therefore perhaps security would be enhanced if a visual representation were assigned by the relying party. This would result in something like a petname system  instead of using an issuer-imposed or even subject-created representation that is common to all relying parties. It might make sense to mention this alternate (or complementary) approach in the security considerations.

[Ballot discuss]
In Section 3:

The optional LogotypeImageInfo structure is defined in [RFC3709] and
  is included here for convenience:

      LogotypeImageInfo ::= SEQUENCE {
        type          [0] LogotypeImageType DEFAULT color,
        fileSize      INTEGER,  -- In octets
        xSize        INTEGER,  -- Horizontal size in pixels
        ySize        INTEGER,  -- Vertical size in pixels
        resolution    LogotypeImageResolution OPTIONAL,
        language      [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

Alexey already observed in a COMMENT that it looks useless to tag a logo image for language. Moreover, RFC 3709 is using the RFC 3066 Lamnguage Tag, while 3066 was obsolete by RFC 4646 which was later obsoleted by RFC 5646. I wonder if this would not rather cause problems than help.

[Ballot comment]
Support Alexey's Discuss points regarding the mime type

Please consider an additional sentence or so at the start of the security considerations section explicitly reinforcing that a CA needs to understand the security considerations section of 3709 before signing a certificate using this extension.

[Ballot discuss]
The -06 version added RFC 1952 as a normative reference.  This RFC is not in the DOWNREF registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry) and (obviously) wasn't part of the IETF LC, which was on the -02 version.  A second abbreviated IETF LC is required to call out this DOWNREF.

[Ballot comment]
1) 5. Embedded images

  The certificate image otherLogos type MAY be stored within the
  logotype extension using the "data" URL scheme defined in RFC 2397
  [RFC2397] if the logotype image is provided through direct
  addressing, i.e. the image is referenced using the LogotypeDetails
  structure.

To clarify: this document doesn't update RFC 3709 to allow use of "data" in
    1) Community logotype
    2) Issuer organization logotype
    3) Subject organization logotype
?

2) 4.2. PNG

  If a certificate image is provided as a bit mapped image, the PNG
  [ISO15948] format SHOULD be used.

  PNG images are identified by the following mediaType in
  LogotypeDetails:

      image/png

It is a shame that there is no RFC that describe this MIME type. But this is not a problem of this document.


3) I have some small set of issues on RFC 3709, which would have been a COMMENT level material if I were to review it for IESG:

In Section 4.1 of RFC 3709:


In Section 4.1 of RFC 3709:

LogotypeImageInfo ::= SEQUENCE {
  type            [0] LogotypeImageType DEFAULT color,
  fileSize        INTEGER,  -- In octets
  xSize          INTEGER,  -- Horizontal size in pixels
  ySize          INTEGER,  -- Vertical size in pixels
  resolution      LogotypeImageResolution OPTIONAL,
  language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

I have to say that I don't see much point in tagging *images* with a language tag. If the image is in a format like PDF, then one would hope that language tagging is possible in the document itself. If the image is in a format like text/plain, then it is not really an image.

But I suppose this is mostly harmless, as long as any language tagging information in the media itself overrides this value.
So I think this is something that needs to be clarified if RFC 3709 is updated.

[...]

  When using indirect addressing, the URI (refStructURI) pointing to
  the external data structure MUST point to a binary file containing
  the DER encoded data with the syntax LogotypeData.  The referenced
  file name SHOULD include a file extension of "LTD".

This should have been a proper MIME type registration. I don't think it is possible to just register a file extension.

[Ballot discuss]
This is a fine document and I generally support its publication:

3) I have some small set of issues on RFC 3709, which would have been DISCUSS level material if I were to review it for IESG. So this is DISCUSS DISCUSS (i.e. I want to discuss it with the rest of IESG):

In Section 4.1 of RFC 3709:

LogotypeDetails ::= SEQUENCE {
  mediaType      IA5String, -- MIME media type name and optional
                              -- parameters

The format of this field is not specified. This turned out to be an interop problem in some other similar cases.

  logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
  logotypeURI    SEQUENCE SIZE (1..MAX) OF IA5String }

4) Process related issue: image/svg+xml MIME type is not registered in the IANA MIME type registry.

5) (Thanks to Robert)

In Section 5.2:

  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]. Hash
  over the SVGZ file is calculated over the decompressed SVG content
  with canonicalized EOL characters () as specified above.

This would require a separate MIME type registration. I don't think it is Ok to just reuse image/svg+xml.

[Ballot discuss]
4) in section 6, "Clients SHOULD parse ..." seems unclear as compare the MUST NOT langauge in the related section 4.2.

I think this should say "Clients MUST parse ... and reject if ..."

[Ballot comment]
1) in section 3, no explanation is given for why Resolution MUST NOT be specified.

2) in section 4.1, LogotypeDetails is used before being defined (or referenced). I recommend moving the copied definitoon from section 5 to precede its first use.

[Ballot discuss]
1) section TBD needs to be D. (It apparently is D'd in appendix A)

2) it is unclear which formats MUST be supported by a compliant implementation.

3) in section 5, the second Note says to be cautious. That is rather ambiguous. How does one "be cautious" about the size if the use is not necessary known? Please provide actionable advice.

4) in section 6, "Clients SHOULD parse ..." seems unclear as compare the MUST NOT langauge in the related section 4.2. Are there additional constraints about external data that must be followed, or should be followed? Where does one find a definitive list of what those constraints are?

[Ballot comment]
1) 5. Embedded images

  The certificate image otherLogos type MAY be stored within the
  logotype extension using the "data" URL scheme defined in RFC 2397
  [RFC2397] if the logotype image is provided through direct
  addressing, i.e. the image is referenced using the LogotypeDetails
  structure.

To clarify: this document doesn't update RFC 3709 to allow use of "data" in
    1) Community logotype
    2) Issuer organization logotype
    3) Subject organization logotype
?

2) 4.2. PNG

  If a certificate image is provided as a bit mapped image, the PNG
  [ISO15948] format SHOULD be used.

  PNG images are identified by the following mediaType in
  LogotypeDetails:

      image/png

It is a shame that there is no RFC that describe this MIME type. But this is not a problem of this document.


3) I have some small set of issues on RFC 3709, which would have been a COMMENT level material if I were to review it for IESG:

In Section 4.1 of RFC 3709:

LogotypeImageInfo ::= SEQUENCE {
  type            [0] LogotypeImageType DEFAULT color,
  fileSize        INTEGER,  -- In octets
  xSize          INTEGER,  -- Horizontal size in pixels
  ySize          INTEGER,  -- Vertical size in pixels
  resolution      LogotypeImageResolution OPTIONAL,
  language        [4] IA5String OPTIONAL }  -- RFC 3066 Language Tag

I have to say that I don't see much point in tagging *images* with a language tag. If the image is in a format like PDF, then one would hope that language tagging is possible in the document itself. If the image is in a format like text/plain, then it is not really an image.

But I suppose this is mostly harmless, as long as any language tagging information in the media itself overrides this value.
So I think this is something that needs to be clarified if RFC 3709 is updated.

[Ballot discuss]
This is a fine document and I generally support its publication:

1) In Section 4 and subsections: It looks like PDF and SVG are MAY level requirements and PNG is a SHOULD level requirement. Is there a mandatory-to-implement format?

2) In Section 5:

  The syntax of the "data" URL Scheme defined in RFC 2397 is included
  here for convenience:

        dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
        mediatype  := [ type "/" subtype ] *( ";" parameter ) data   
          := *urlchar parameter  := attribute "=" value

You have a formatting error here, this doesn't look like a valid BNF.

3) I have some small set of issues on RFC 3709, which would have been DISCUSS level material if I were to review it for IESG. So this is DISCUSS DISCUSS:

In Section 4.1 of RFC 3709:

LogotypeDetails ::= SEQUENCE {
  mediaType      IA5String, -- MIME media type name and optional
                              -- parameters

The format of this field is not specified. This turned out to be an interop problem in some other similar cases.

  logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
  logotypeURI    SEQUENCE SIZE (1..MAX) OF IA5String }

[...]

  When using indirect addressing, the URI (refStructURI) pointing to
  the external data structure MUST point to a binary file containing
  the DER encoded data with the syntax LogotypeData.  The referenced
  file name SHOULD include a file extension of "LTD".

This should have been a proper MIME type registration. I don't think it is possible to just register a file extension.

  (1.a) Who is the Document Shepherd for this document?

        Has the Document Shepherd personally reviewed this version of
          the document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Steve Kent is the document shepherd for this document, and I have personally reviewed this version of the document and believe this version is ready for forwarding to the IESG for publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has received adequate review from key WG members. This draft has also been reviewed by independent implementers as well as from members of the ETSI standards community, which is very supportive of this work.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no specific concerns to highlight to the AD or IESG. I am aware of no IPR disclosures that have been filed related to this document.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The technical aspects of this document represents rough consensus of active WG members. The document, which is fairly brief, was discussed on the PKIX list over the course of about 10 months (over 270 messages). The authors made a number of changes in response to comments from WG members. As a result of these changes, I believe that the substantive objections were addressed. A few folks still object to this document, but their objections do not seem reasonable to me, as the cognizant WG co-chair.


    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

Yes. Paul Hoffman has threatened to appeal, on procedural grounds. Specifically, Paul feels that I improperly declared consensus based on analysis of list comments over the last 3 months of discussion, vs. just those comments that were posted during the 2-week WGLC.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

Yes. There is one normative down reference, to an informational RFC defining GZIP, but I think this is an allowable exception, given the context.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

References have been split into normative and informative sections.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The I-D has an IANA Considerations section stating that this document requires no actions by IANA.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

I have been informed that the ASN.1 modules provided in this document have been compiled and tested separately by Jim Schaad, the PKIX ASN expert.

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in WG process that is worth noting? For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

          Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

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.

Work Group Summary

This draft went through two WG last calls. 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. (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. Thus the objection raised by a few individuals is essentially of the form “the base RFC was not deployed, and we believe that these extensions will not help.”) Several major implementers have stated their support for the current draft. Support has also been voiced from representatives of the ETSI standardization community as this draft is needed as standard for ETSI standardization work that is to be concluded this year. Thus I believe that it is appropriate to progress this work.

Document Quality

The document is brief and reasonably clearly written.