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

From: [email-masked] (Peter Gutmann)
Date: Fri, 3 May 2002 19:58:10 +1200 (NZST)

Simon Josefsson <[email-masked]> writes:

>Has the SVG format [1] been considered?  It seems to me that it has some
>advantages:

Looks like yet another future orphaned graphics format (c.f. "future ex-wife").
If you really want scalable vector graphics, a better (in the sense of "less
suboptimal") choice would be EPS, although no vector graphics format is
terribly practical for display purposes because of the lack of support.
Probably the most viable (ie least suboptimal) vector format is WMF because
about 95% of desktop platforms support it by default (actually somewhat more
than that with libwmf, which will display them under X).

Why not just use the usual { type, value } combination, with selected OIDs for
common formats?  I can see Shockwave and the usual other stuff used in web
pages being added fairly quickly if this does take off.  A problem with
standardising things in this area is that most of the widely-used formats are
proprietary (SWF, WMF, etc), so you either need to standardise proprietary
formats or go with open formats which no-one actually uses.

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 03 May 2002 10:44:52 +0200

> formats or go with open formats which no-one actually uses.

I agree with your last suggestion, altough perhaps re-using MIME types
instead of specifying new OIDs requires less work?  My thought was
only that if SVG happens (which isn't unlikely, I think there are free
implementations around) it looks as something that would be
appropriate to use for logotypes.  Hence it might be useful if the
PKIX logotype proposal supported more than two formats, especially
since one of them (GIF) requires license fees when creating images.

EPS requires a postscript interpreter from what I understand, which
seems a bit dangerous to me.

---

From: Dean Povey <[email-masked]>
Date: Fri, 03 May 2002 20:49:49 +1000

>formats or go with open formats which no-one actually uses.

Argghhh. Make it stop! Let's:

a) recommend a small standard size/aspect ratio
b) recommend 1 or 2 non-proprietary formats
c) use a mime type rather than manage another OID space.

Anyone else that wants to put shockwave in a certificate can do that 
madness in some other way.  The spec should specifically 
_exclude_ non static images, as it may be possible to influence the timing 
of images such that the CA and the relying party are given different views 
of the image (depending on the software used).

Having another look, I think that the logotype extension is probably too
complex. I think perhaps we can solve the problem of people complaining
that the selected image is not in their favourite format or color *and*
simplifying the logotype extension, by doing something like:

LogotypeInfo ::= SEQUENCE OF LogotypeData

LogotypeData ::= SEQUENCE {
	logotypeId    OBJECT IDENTIFIER,
	imageMimeType IA5String, -- e.g. image/jpeg
	reference     LogotypeReference OPTIONAL, -- At least one
	embedded      OCTET STRING OPTIONAL       -- must be present 
}

LogotypeReference ::= SEQUENCE {
	-- if omitted hashAlgorithm is the same as the signature hash 
	-- algorithm. 
	hashAlgorithm     AlgorithmIdentifier OPTIONAL, 
	logotypeHash      OCTET STRING,
	logotypeUri       IA5String 
}

id-logotype-communityLogo OBJECT IDENTIFIER ::= { ... } 
id-logotype-issuerLogo    OBJECT IDENTIFIER ::= { ... }
id-logotype-subjectLogo   OBJECT IDENTIFIER ::= { ... }

Then define a logotypeId for each _type_ of logotype (kind of like a 
policy identifier).  We then severely restrict the standard ones in terms 
of size and formats, and then allow people to dream up their own usage and 
interpretation for any others.

If you want to pick a size for the logotype then I would choose 32x32 for
an embedded image which is the standard Windows icon size and has the 
benefit of being able to be displayed on nearly any sized display.  Some people
might find this unecessarily restrictive, but I think that you have to err
on the side of small.  For external references stick to a square aspect
ratio and allow 128x128 (or at worst 256x256) which is more than enough for
any logo as far as I am concerned [I have attached jpegs of this size 
below for people to compare].  Image type should be static JPEG or PNG
which are both non-proprietary, non royalty incurring formats with wide
support. But the important thing is that this is definitive of one policy
for logotypes which we would expect to be widely supported (e.g. by
browsers).  People can do what other mad stuff they'd like in their own
policy.  Regardless of what is chosen the information on how to display the
image is clear and unambiguous which is how it should be.

The only problem is I couldn't tell if Peter was being sarcastic or not 
*sigh*.
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: "Housley, Russ" <[email-masked]>
Date: Fri, 03 May 2002 08:29:05 -0400

Peter:

We could clearly support any image format in the manner that you 
suggest.  We want to strike a balance between flexibility and 
interoperability.  Supporting formats that do not have widespread viewer 
software is not really useful.

Russ