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

From: "Housley, Russ" <[email-masked]>
Date: Thu, 18 Apr 2002 15:57:39 -0400

Olle:

>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?

I am glad you got a good laugh, but it was not intended as a joke.

Recall that there are two uses of the logos.  One use aids in the selection 
of your own certificate from a portfolio. In this case, I envision the logo 
being used as an icon to select a particular certificate.  The other use 
provides a logo along with other information about a valid 
certificate.  For example, the logo might be displayed along with other 
information for a Web server.  In neither case should the logo dominate the 
display.

What maximum size do you suggest?

>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?

We should update the file suffix part to indicate that either case is 
acceptable.

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.

Russ

---

From: [email-masked]
Date: Fri, 19 Apr 2002 10:59:47 +1000

>What maximum size do you suggest?

Yes but you don't describe the other use which is to aid identification of
the subject.  In this case 150x50 may well be insufficient for some uses
(i.e identification of humans). There doesn't seem to be any good reason to
limit the size of the external image.  For the use you describe, what is
probably more important is the aspect-ratio, as the application can scale
the image to any size.  Also the recommend for a black border seems to be
unnecessary (is there a good reason for this?).  Lastly
150x50 (I am assuming this is XxY) seems like a pretty odd aspect-ratio to
pick.  I would of thought 100x100 made more sense.  A recommended size/
aspect-ratio for logos with a SHOULD here seems more appropriate.

Also I would prefer to see a statement in the draft to say "Applications 
SHOULD NOT use the embedded version unless offline processing of the 
certificate is required".  Adding an embedded image will roughly double 
the size of the cert, so we want to make sure implementers think carefully 
before they do it.  The draft should be worded to encourage the use of 
external images, and discourage the use of embedded images.

Also I think the fields highRes and lowRes should be called externalImage and 
embeddedImage for this reason.

Minor nit: In section 3, cashing -> caching 

>web page.  This size seems appropriate for a logo in a header.

I think what Olle was trying to say was that rather than use the file 
extension to identify the image, we should be using the mime type (i.e.
"image/gif", "image/jpeg" instead of GIF, JPG, JPEG).  I think this is a 
good idea as it means that the images are identified by a managed 
identifier.  Otherwise how do we define new image formats?  All this 
requires is changing imageFileExtn to imageMimeType and some words to that 
effect.

Note that this means the reference to the external image should also
contain this mime type.  This has the benefit of being an explicit 
statement about the image format, rather than an implicit interpretation 
of the file extension.  Text also should be added to say that the 
application should make sure that the retrieved image matches the expected 
image format.  It is quite easy for a browser to tell you the file with 
the extension JPG has the mime type image/gif.  Yet another reason to 
explicitly use the mime type.

It may be worth adding a statement to security considerations about why it
is important to include the image format in the certificate (either by mime
type or file extension). The reason is that if the image format is not part
of the signature it may be possible for an attacker to coerce the user into
viewing the image in a different image format (but with the same binary
image).  You can conceive that it would possible (but of course difficult)
to construct an image that would view differently in two different image
formats (especially with the various extension and options in image formats
these days) and trick the CA into signing one of them. 

Also note that the specification MANDATES the support of GIF which is 
covered by a Unisys patent.  I don't think this will fly in the IETF.  
At the very least a patent statement is required.  A patent free 
alternative is PNG which is widely supported.

Because both JPEG and GIF are allowed for the embedded image maybe wording
should be added to the effect that "an application SHOULD use which ever
image format is smaller"). (GIF is often smaller for simple images with 
not many colors, whereas JPEG usually does better on photo type images with 
lots of colors).

Lastly, I think a good restriction to add would be that the images should be 
static (i.e. not use any of the animated extensions).
-- 
Dean Povey,              |em: [email-masked] |  JCSI: Java security toolkit
Senior S/W Developer     |ph:  +61 7 3023 5139    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: +61 7 3864 1282    | uSSL: Embedded/C SSL toolkit
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Apr 2002 14:48:47 +0200

Thank you for many useful comments,

Just one quick remark for now:
The logos are not intended for subjects (i.e. photos). They are intended 
exclusively for organizational and service branding logos.
An image of the subject (photo) can be attached and certified in the cert 
by using the biometric info extension defined in RFC 3039.

The image sizes suggested in the draft was not proposed out of science. It 
was an initial input to start the discussion.

/Stefan

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 19 Apr 2002 17:20:45 +0200

Stefan,
During the 3039 process I suggested using mime-tags instead
of inventing new schemes.

http://www.imc.org/ietf-pkix/old-archive-99/msg00462.html

It seems that the idea has popped up again.
Then you may use PNG, AVI whatever.

If 3039 is to be revised I would look over this as well.

Anders

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>; "Housley, Russ" <[email-masked]>
Cc: "Olle Mulmo" <[email-masked]>; <[email-masked]>
Sent: Friday, April 19, 2002 14:48
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 

/Stefan