Subject: I-D ACTION:draft-ietf-pkix-logotypes-02.txt

From: [email-masked]
Date: Thu, 18 Apr 2002 08:00:51 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-02.txt
	Pages		: 16
	Date		: 17-Apr-02
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [email-masked]
mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-logotypes-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Olle Mulmo" <[email-masked]>
Date: Thu, 18 Apr 2002 19:36:37 +0200

Dear authors,

I couldn't help but noticing the logotype "format restrictions" table... I don't think a Marketing dept will ever be satisfied with a 150x50 limitation on a "hi-resolution" logotype: especially not those that have circular logos... From where does this limit originate? Is there any deeper reasoning or motivation behind, or is it there just to give me a good laugh?

Also, IMHO it would be better to identify GIF & JPEG pictures by their corresponding MIME types than to invent your own way of doing this. Also, if I read it all correctly, you actually require the that the referenced logotype file must have an uppercase suffix?

I sincerely hope for a (heavily) revised update of this draft.

Regards,

/Olle

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 2:01 PM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-02.txt

	

Send a message to:
	[email-masked].
In the body type:

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 19 Apr 2002 11:52:44 +1000

A referenced logo WILL be identified by a MIME-type.  Dereferencing the URI
will (presumably) result in something like the following (with various other
header fields omitted):

	HTTP/1.1 200 OK
	Content-Length: 177
	Last-Modified: Thu, 18 Sep 1997 04:22:02 GMT
	Content-Type: image/gif

	GIF89aJH&^%&^b6TB^(&...

A ".gif" extension in the URL may suggest a "image/gif" MIME-type will be
returned, but a web server is actually free to return any MIME-type it
wants.  I think browsers will (and should) process the result based on the
MIME-type instead of the URI extension.

So perhaps it would be better for the 'imageFileExtn' field to be
'imageContentType' and hold a MIME-type.  (might you ever what to include
other MIME header fields? in which case a 'imageMIMEHeaders' field might be
needed instead.)

There is no description of the 'logotypeHash' field.  I suspect the authors
intention is to hash the bytes of the *.gif (or *.jpeg) file, excluding any
MIME or HTTP headers fields delivered with the image.  Presumably any
transfer encoding (but not Content-Encoding?) is also removed before
hashing?

Such a hash does not bind the content to the MIME-type.  This maybe
acceptable, though it might warrant a paragraph in the security
considerations section.

Change the 'highRes' and 'lowRes' field names to, say, 'reference' and
'embedded' (or 'indirect' and 'direct').  Which resolutions are appropriate
is a matter of judgement, policy, environment or best practise -- so it
should be discussed in the document, but not hard-wired into the syntax.

> ----------
> From:	Housley, Russ [SMTP:[email-masked]]
> Sent:	Friday, 19 April 2002 5:58 am
> 
> >..Also, IMHO it would be better to identify GIF & JPEG pictures by their 
> >corresponding MIME types than to invent your own way of doing this..
> 
	..We do not want to point to a MIME encoded object.  Rather we want
to point 
> to the GIF or JPEG binary object.  In this manner, one could use the same 
> file for many different purposes, including display on the organization's 
> web page.  This size seems appropriate for a logo in a header.
>

---

From: Hal Lockhart <[email-masked]>
Date: Fri, 19 Apr 2002 17:33:29 -0400

This is a reference to a historic joke made by Bob Juneneman. 

See: http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

Hal

> From: Housley, Russ [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 2:55 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
> 
> 
> 
> Peter:
> 
> We have not allowed MPEGs, just static images in JPEG or GIF format.
> 
> Russ
> 
> At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
> >"Housley, Russ" <[email-masked]> writes:
> >
> > >What maximum size do you suggest?
> >
> >I would say 320x200 *minimum*, for the MPEGs :-).
> >
> >Peter.
>

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 21 Apr 2002 16:30:02 +1200 (NZST)

>We have not allowed MPEGs, just static images in JPEG or GIF format.

Actually that was a dual-purpose comment, firstly to reference Bob Jueneman's
joke about putting MPEGs in the DN, and secondly to point out that setting
arbitrary limits on image sizes is probably pointless given that companies are
going to use whatever size and format they feel like, no matter what the spec
says.  Can you imagine KPMGCoopersPriceLybrandWaterhouseAnderson distributing a
single cert without the Official Corporate Logo(tm) with Official Corporate
Animation(tm) and Official Corporate Song(tm) playing in the background?.

You only need to look at the cert policy text size limit set in RFC 2459 as an
example.  I used to check the size limit given in the RFC, but after finding
the first dozen or so CAs who went way over the limit (some texts were five
times the size allowed by the RFC) I changed my code to use 5x the max size as
the upper limit.  After still getting complaints that certs were being
rejected, I removed the check altogether, since no-one seems to pay any
attention to the size limits.  So I think that while a comment that N x M is a
good upper limit would be useful, you'd have to accept that it's going to be
ignored by anyone who feels their Corporate Image would be slighted by such a
constraint (or, more likely, who doesn't bother to read RFCs).

Peter.