Subject: Re: draft-ietf-pkix-logotypes-06.txt

From: "Tom Gindin" <[email-masked]>
Date: Wed, 16 Oct 2002 17:06:06 -0400

Denis, Russ:

      One reason why audio might be desired would be to allow the nearest
available equivalent to logotype functionality.  This might be motivated by
one of several pieces of US legislation (the Americans with Disabilities
Act and Section 508).  If this is the case, the specification should
probably reflect that audio is a backup, especially for individuals who
cannot benefit from video.  I have a couple of suggestions in that case:
       The image component should be mandatory, while other components
should be optional
      Clients should be directed to use other components only when the use
of the video component is known to be impractical or useless, or the user
has explicitly selected the other component.

            Tom Gindin

Denis Pinkas <[email-masked]>@mail.imc.org on 10/15/2002 03:46:34 AM

Sent by:    [email-masked]

To:    "Housley, Russ" <[email-masked]>
cc:    [email-masked]
Subject:    Re: draft-ietf-pkix-logotypes-06.txt

Russ,

> We just posted an update to the logotypes draft.  There are two primary
> changes from the previous version.  First, we tried to be more clear
about
> what is mandatory to implement and what is not.

This is not yet clear enough. See below.

> Second, we added support for more than one hash function without having
> to repeat a lot of data.
>
> The loudest objections (as opposed to jokes) came from Microsoft.  Based
on
> discussions with Trevor Freeman, I believe that Microsoft can accept this
> version.
>
> We are still in Working Group Last Call.....

Since we are still in Working Group Last Call, here are my 12 comments on
that document.

1. Page 6. Section 3. Logotype data

"Implementations MUST support image data; however, support for audio data
is
OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
supposed to deal with serious documents. Please delete.

2. Page 7. Section 4.1 Extension format

"Clients MUST support both direct and indirect addressing."

I disagree. If an end-user certificate is included in a signature, it may
be
interesting to display the logotype even if the terminal is off-line.
Indirect addressing would mandate an on-line connection.

Replace with:

"Clients claiming to conform with this document SHALL support direct
addressing. Clients MAY also support indirect addressing."

3. Page 7. Section 4.1 Extension format

There is no text which states what the client should do whenever it is
unable to support a given logotype. Insert the following text:

"Whenever a client is unable to support a given logotype, no error SHALL be
reported and the client MUST behave as if there was no logotype included in
the certificate".

4. Page 8. Section 4.1.

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage     OPTIONAL,
         audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Since audio support should be suppressed, replace with:

      LogotypeData ::= SEQUENCE OF LogotypeImage

5. Page 7. Section 4.1.

We have:

      communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,

      LogotypeInfo ::= CHOICE {
         direct          [0] LogotypeData,
         indirect        [1] LogotypeReference }

      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage OPTIONAL,

No explanations are given on the text about what to do for a client when
there is more than one LogotypeImage present in a communityLogo.

First of all, a communityLogo may contain more than one logo which belongs
to one or more communities. However the client has no way to know whether
the LogotypeData includes different versions from the same logo (e.g. in
black and white or in color) or different logos.

The ASN.1 structure is not adapted to make that difference. Therefore it is
proposed to modify the ASN.1 syntax along the following way:

         communityLogos   [0] EXPLICIT CommunityLogos OPTIONAL,

CommunityLogos ::= SEQUENCE OF CommunityLogo

CommunityLogo ::= LogotypeInfo

In this way, clients can make their best efforts to support only one
instance of version for each CommunityLogo.

6. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

Text is missing to explain this structure. How is a grey scale indicated
for
jpeg and for gif ???

7. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

It is of particular importance to say what means conformance to this
document for a client with respect to the number of pixels to support and
the colors to support.

It is proposed to add a sentence along these lines:

"Clients claiming to conform with this document SHALL support an image with
a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in black and white
with X grey levels."

8. Page 9. Section 4.1.

      LogotypeImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- In pixels
         ySize           INTEGER,  -- In pixels
         numColors       INTEGER } -- In bits

It would also be appropriate to say what to do when the image is in color
and that the client has no color display available. No display at all ?
Conversion into grey scale using which kind of transposition ?

9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
should be deleted.

10. Page 9. Section 4.1. The text states:

"Implementations MUST support both the JPEG and GIF image formats (with
MIME
types of "image/jpeg" and "image/gif", respectively)"

I would guess that Animated GIF should not be supported. Could we say it ?

11. Page 10. Section 4.1.

      Community Logotype. If communityLogo is present, the logotype MUST
      represent the community to which the certificate issuer is
      affiliated. The communityLogo MAY be present in an end entity
      certificate, a CA certificate or an attribute certificate.

A certificate issuer may belong to more than one community. Replace: "the
community " by :"the community or the communities".

12. Page 11. Section 5. Type of certificates

   Logotypes MAY be present in three types of certificates:

     - CA certificates
     - End-entity certificates
     - Attribute certificates

Why is there such a limitation ? CRL Issuers, OCSP responders or TSUs may
have logotypes present in their certificates.

Replace with : "Logotypes MAY be present in any type of certificate".

Denis

> Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 17 Oct 2002 13:03:12 +0200

Tom,

This is an answer to the first argument raised.

> cannot benefit from video.  

One of the key issue is to understand the properties that a client compliant
with this specification must support. Currently we have:

"Compliant applications MUST display more just one (or none) of the images
*and* play just one (or none) of the audio sequences at the same time." 
The *AND* is not acceptable.

First of all, if audio is going to be supported, then separate requirements
should be made so that client compliant with requirements fo image
representation, can ignore compliance requirements for audio representation.

Now, do we want to promote the use of gingles for VISA, AMEX, MasterCard ?
They would need to invent them.

If a user using a client is blind, do we think he will be more confident by
hearing the gingle ? How does he make sure that the gingle really originates 
from the logoype extension ?  

> I have a couple of suggestions in that case:

While your formulation sound reasonable, I am still questioning the need 
to support audio.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 21 Oct 2002 13:57:51 -0400

>from the logoype extension ?

The jingle associated with a brand may well help a blind person select the 
most appropriate certificate.  Remember that this is one of the primary 
motives for the specification.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 22 Oct 2002 09:47:18 +0200

Russ,

(...)

> motives for the specification.

 ... and for this, the blind person will certainly blindely click somewhere
on the screen ...

Denis

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 22 Oct 2002 09:42:37 -0700

>  ... and for this, the blind person will certainly blindely click somewhere

Voice recognition?

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 22 Oct 2002 12:45:27 -0400

Denis:

As you said in your last note to the list, PKIX is not doing standards for 
the MMI.

Russ

---

From: Dean Povey <[email-masked]>
Date: Wed, 23 Oct 2002 15:02:33 +1000

<meta>I have been sitting on the sidelines in this debate for a bit, 
because I thought it would all go away.  Since it appears not to have, I 
feel obliged to vent :-) </meta>

>motives for the specification.

I don't buy this.  Logos/trademarks are a piece of IP that most companies
invest a considerable amount of time and effort associating with their
brand.  Jingles are produced by advertising companies and generally have a
much shorter life time.  Sometimes companies license some existing music
for their jingle (as in Microsoft's Start Me Up campaign).  Besides which
many of companies which matter most for this spec don't have recognisable
jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the
Verisign one.

Adding a jingle to a certificate means revoking it every time a company
changes its advertising.  This is clearly silly.  Whilst logos do change,
the cost of changing them is so high in most organisations that it seems to
be a rarer event (they last years rather than weeks). The whole point of
logotypes is to provide a mechanism to increase trust recognition in
certificates. Clearly, displaying a logo is not useful in improving trust
to a blind person, however there are other means available (e.g. the
browser software can read out the subject and issuer names to them).

Notwithstanding the good intentions of the draft editors who have in many
ways produced an excellent document, I STRONGLY RECOMMEND that the whole
audio bit of the logotypes draft be deleted as a bad joke.

-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: +61 7 3023 5199   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures

---

From: Aram Perez <[email-masked]>
Date: Tue, 22 Oct 2002 23:16:20 -0700

> jingles.  Can you hum the RSA jingle Russ :-).  Does anyone know the

No I don't know those but I do know the Intel Inside one. I'm pretty sure
that if you try using the Intel Inside jingle, you'll probably hear from one
of their lawyers.

> audio bit of the logotypes draft be deleted as a bad joke.

And I thought it was a pretty good joke ;-)

Regards,
Aram Perez

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 23 Oct 2002 14:54:03 +0200

I feel like having seen this before...

We have some peoples from the "industry" wanting to do something, and they
need support from a protocol.
The protocol standards group (PKIX) sometimes gets hooked up in a debate
whether this is a good thing to do or not, rather than trying to solve the
actual protocol issues.

Those saying that audio should go away now, need to be really sure that
there are absolutely no use for this in any sensible way. I wander if you
are?, or if you just can't see it from where you stand right now.

There is much less harm in supporting something that doesn't get deployed.

If audio is supported in the protocol in a well structured manner, and
nobody deploys it, then it's just dropped before it becomes standard.

I do believe though that the deployment industry is likely to find some use
for it.

/Stefan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Aram Perez
> Sent: Wednesday, October 23, 2002 8:16 AM
> To: PKIX

---

From: Dean Povey <[email-masked]>
Date: Thu, 24 Oct 2002 09:04:23 +1000

>I do believe though that the deployment industry is likely to find some use

Err, I think the rule is that we start with a firm requirement and
implement something.  I think there has been a failure to demonstrate a
firm requirement. If someone can come up with a plausible meaningful reason
to put audio in certificates then we can consider it.  Until then, we
should concentrate on solving actual problems, not dreaming up hypothetical
ones.  Why isn't there support for MPEG movies in the draft for 
example? (I hope this doesn't give anyone ideas :-).

As someone who has to implement this stuff, let me just say that there is a
cost to specifying something that won't (or shouldn't) be used.  You still
end up having to implement and test it to give the perception that your
products are complying with standards.  It is precisely this
overspecification in the ITU-T standards that has led to so much garbage
which has to be supported already.  The certificate path processing
algorithm is a case in point.  Its complexity is created by a large number
of rarely used extensions whose usefulness is dubious at best.

So, come up with a plausible use case for audio that cannot be met by
existing mechanisms, and it can be considered, otherwise drop it, and make
implementers lives a little easier.

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 24 Oct 2002 10:56:51 +0200

I mostly agree with you.

What I mean is that there is some line, beyond which you just need to accept
the whish to do something and say - OK if some implementers want to do this
type of thing, what is the best way to do it?

I think the most cases where a firm requirement is badly needed is where
someone what to do something in a different way, where current standard
gives another way of doing almost the same thing, and where doing the
proposed changes/amendments would produce alternative solutions to closely
related problem (Like the PI versus serialNumber Attributes, OCSPv2 versus
SCVP, CMP versus CMC .....)

I think Trevor has demonstrated a reasonable need to use audio with
Logotypes.

/Stefan

> [mailto:[email-masked]]On Behalf Of Dean Povey
> Sent: Thursday, October 24, 2002 1:04 AM
> To: Stefan Santesson
> Cc: [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Oct 2002 11:36:48 +0200

Stefan,

> I think Trevor has demonstrated a reasonable need to use audio with

The argument from Trevor is not convincing: adding audio to the interface 
design does not mean adding audio for everything.

  ... but this demonstrates that it was *not* a joke (either god or bad), 
from at least two of the co-editors of the document. :-(

Denis

>>>I do believe though that the deployment industry is likely to
>>
>>find some use
>>
>>>for it.
>>>
>>

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 25 Oct 2002 11:07:45 -0400

Dean:

I agree that jingles are somewhat different than Logos.  However, the audio 
file could simple be "the right voice" saying the company name.  Several 
companies have famous people with easily distinguished voices do 
soundtracks for their commercials, little blurbs on the phone, and such.

Again, the point is accessability and helping the user make the most 
appropriate selection.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Oct 2002 11:07:04 +0100

Russ,

> I agree that jingles are somewhat different than Logos.  

OK. Since you agree it is different, let us make two documents (and hence 
let us define two extensions), one for visual logos, and another one jingles.

For the second one, it would make sense to query some blind people to make 
sure that this would be really useful for them. We should hold on the 
progression of the second document until we have verified this.

Denis

> However, the 
> audio file could simple be "the right voice" saying the company name.  
> Several companies have famous people with easily distinguished voices do

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 28 Oct 2002 08:11:07 -0500

>let us define two extensions), one for visual logos, and another one jingles.

They are not that different!  Breaking them into separate documents would 
defeat the alternate presentation to the blind.

>progression of the second document until we have verified this.

We have consulted with the people at Microsoft that write the requirements 
for the "accessability" aspects of software.  These are the people that are 
responsible for making software that can be used by disabled people.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Oct 2002 14:44:58 +0100

Russ,

>> OK. Since you agree it is different, let us make two documents (and 
>> hence let us define two extensions), one for visual logos, and another 
>> one jingles.
> 
> 
> They are not that different!  Breaking them into separate documents 
> would defeat the alternate presentation to the blind.

If, as you mention, it is an *alternate* presentation, then since blind 
people do not need to see logos, there would be no problem to break the 
specification into two pieces: one for logos, one for jingles.

If, as you do not mention, it is supplementary information, hence not for 
blind people but for fun, then you breaking it into two pieces would be more 
difficult, but could still be done.

>> For the second one, it would make sense to query some blind people to 
>> make sure that this would be really useful for them. We should hold on 
>> the progression of the second document until we have verified this.
> 
> We have consulted with the people at Microsoft that write the 
> requirements for the "accessability" aspects of software.  These are the 
> people that are responsible for making software that can be used by 
> disabled people.

Nancy questioned:

"Have any blind or otherwise visually-impaired users been consulted on this 
issue, or weighed-in on the discussion in this forum?  If so, what has their 
general opinion been?"

People at Microsoft are not *users*, nor are they all blind or otherwise 
visually-impaired.

Additionally, the specification does not address internationalisations 
issues, which is not a problem with (visual) logos, but it is with jingles.

The Oxford dictionary provides the following definition for logo:

logo / noun (pl. -os) a printed design or symbol that a company or an 
organization uses as its special sign.

Logos are only visual. Please deal with jingles separately.

The Oxford dictionary provides the following definition for jingle:

"a short song or tune that is easy to remember and is used in
advertising on radio or television".

Denis

> Russ

Now, if I had a certificate, it could well include the folling *two* 
following *community* logos. It would be up to your application, to display 
none of them, one of them or both of them.

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 28 Oct 2002 09:05:33 -0500

Denis:

>blind people but for fun, then you breaking it into two pieces would be 
>more difficult, but could still be done.

It is an option.  Dividing it into two documents is not going to change 
anything, except blur the relationship.

>"Have any blind or otherwise visually-impaired users been consulted on 
>this issue, or weighed-in on the discussion in this forum?  If so, what 
>has their general opinion been?"
>

I was not the one who raised jingles.  Consider the IBM logo.  The image 
file would contain the blue bars that make up the letters.  I am sure 
everyone is familiar with this logo.  I would expect the associated audio 
file to include a person's voice speaking "IBM."

I think that we have beat this topic to death....

Russ