Internet X.509 Public Key Infrastructure -- Certificate Image
draft-ietf-pkix-certimage-11
Yes
(Tim Polk)
No Objection
(David Harrington)
(Gonzalo Camarillo)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)
Recuse
(Russ Housley)
Note: This ballot was opened for revision 11 and is now closed.
Tim Polk Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-07-15)
Unknown
I was disappointed to find that this draft has nothing to do with reliability of magicians.
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2010-12-22)
Unknown
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 Former IESG member
(was Discuss)
No Objection
No Objection
(2010-11-01)
Unknown
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
David Harrington Former IESG member
(was Discuss)
No Objection
No Objection
(2010-07-12)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
(was Discuss)
No Objection
No Objection
(2010-07-14)
Unknown
1. There are many violations of subject-verb agreement, such as "Images incorporated according to RFC 3709 provides" (instead of "provide").
Ralph Droms Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2010-07-15)
Unknown
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?
Robert Sparks Former IESG member
No Objection
No Objection
(2010-07-13)
Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
Recuse
Recuse
()
Unknown