Internet X.509 Public Key Infrastructure -- Certificate Image
RFC 6170

Note: This ballot was opened for revision 11 and is now closed.

(Tim Polk) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss, No Objection) No Objection

Comment (2010-07-15)
No email
send info
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?

(Adrian Farrel) No Objection

Comment (2010-07-15 for -)
No email
send info
I was disappointed to find that this draft has nothing to do with 
reliability of magicians.

(David Harrington) (was Discuss) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2010-12-22)
No email
send info
As W3C has finally requested registration of image/svg+xml (see <http://dev.w3.org/SVG/profiles/1.1F2/master/mimereg.html>), 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.

(Dan Romascanu) (was Discuss) No Objection

Comment (2010-11-01)
No email
send info
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

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2010-07-14 for -)
No email
send info
1. There are many violations of subject-verb agreement, such as "Images incorporated according to RFC 3709 provides" (instead of "provide").

(Robert Sparks) No Objection

Comment (2010-07-13 for -)
No email
send info
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.

(Sean Turner) (was Discuss) No Objection

(Russ Housley) Recuse