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

From: [email-masked]
Date: Tue, 08 Oct 2002 07:14:28 -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-06.txt
	Pages		: 20
	Date		: 2002-10-7
	
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-06.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-06.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-06.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: "Housley, Russ" <[email-masked]>
Date: Tue, 08 Oct 2002 16:09:56 -0400

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

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Oct 2002 09:46:34 +0200

Russ,

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

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

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 15 Oct 2002 11:57:26 -0400

Denis:

This is not correct.  In neither direct nor indirect addressing is the 
logotype data included directly in the certificate.  With direct, the URI 
of the data is directly in the certificate.  With indirect, the URI of the 
data is obtained from an intermediate structure.

Caching is the technique for display of this data by an off line client.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 16 Oct 2002 09:18:44 +0200

Russ,

> Caching is the technique for display of this data by an off line client.

The current text is confusing and needs clarifications along the lines that
you have provided. Explanations along the description of the various ASN.1
fields would certainly help to have a better understanding. These
explanations are currently missing.

As an example, we have:

         imageHash       SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
         imageURI        SEQUENCE SIZE (1..MAX) OF IA5String,

I would guess that each SEQUENCE SHALL have the same number of elements. 
It would be nice to say it.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 16 Oct 2002 14:57:46 -0400

Denis:

I know that you are very busy, but I think that you have not given the 
document a fair reading.  I am not saying that the document is perfect; 
however, the information that you request is in the document.

It says:

    Both direct and indirect addressing accommodate alternative URIs to
    obtain exactly the same item. This opportunity for replication is
    intended to improve availability. Therefore, if a client is unable to
    fetch the item form one URI, the client SHOULD try another URI in the
    sequence.

And, it says:

    The LogotypeReference, LogotypeImage and LogotypeAudio structures
    explicitly identify one or more one-way hash functions employed.
    Clients MUST support the SHA-1 [SHS] one-way hash function, and
    clients MAY support other one-way hash functions. CAs MUST include a
    SHA-1 hash value in every logotypes extension, and CAs MAY include
    other one-way hash values. If more than one is present, clients MUST
    validate at least one value, and clients MAY ignore other hash
    values. The client's local policy determines which hash values are
    validated and which hash values are ignored.

Therefore, your suggestion is inappropriate.  The two sequences need not 
have the same number of entries.  The imageURI sequence contains a list of 
locations where the same image file can be located.  Multiple locations are 
provided to ensure availability.  The imageHash sequence contains a list of 
hash values computed on the image file, and there is one entry for each 
hash algorithm employed.

Russ

---

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

Russ,

>     validated and which hash values are ignored.

OK. You are right. The information is there but usually when you have an
ASN.1 description, it is much better to describe one by one the components.
We both recognize that the text may be improved. I would therefore recommend
to comment one by one each component 

Now, let us pick up the last sentence you quoted: 

"The client's local policy determines which hash values are validated and
which hash values are ignored."

This is not the case. The rule is mentionned just in the previous sentence:
" If more than one is present, clients MUST validate at least one value".

This is correct and enough. The remaining of the sentence should be deleted:
"and clients MAY ignore other hash values".

> hash values computed on the image file, and there is one entry for each

I originally raised 12 concerns, you picked the second one and argued on it. 

Should I understand that you fully agree with the 11 remaining arguments ?

 :-)

Denis

---

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

>"and clients MAY ignore other hash values".

I think that the meaning is clear, but I will be pleased to make it shorter.

>Should I understand that you fully agree with the 11 remaining arguments ?

No.  At the time, I did not have time to go through them in detail.  I will 
do so this week, factoring in the discussion from others.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 21 Oct 2002 15:45:45 -0400

>supposed to deal with serious documents. Please delete.

I belive that the response from Tom Gindin shows that there is support for 
audio in support if disabled users.  I believe that the document is clear 
that the support is OPTIONAL.

>addressing. Clients MAY also support indirect addressing."

We have already had a dialogue on this point.  I hope it is resolved.

>reported and the client MUST behave as if there was no logotype included in

I will add a similar sentence to the second paragraph of section 6.  The 
paragraph now says:

    After a certification path is successfully validated, the replying
    party trusts the information that the CA includes in the certificate,
    including any certificate extensions. The client software can choose
    to make use of such information, or the client software can ignore
    it. If client is unable to support a provided logotype, the client
    MUST NOT report an error, rather the client MUST behave as though no
    logotype extension was included in the certificate. Current standards
    do not provide any mechanism for cross-certifying CAs to constrain
    subordinate CAs from including private extensions (see the security
    considerations section).

>       LogotypeData ::= SEQUENCE OF LogotypeImage

This is related to comment 1.  No change will be made.

>black and white or in color) or different logos.

This is not supported.  The certificate may only include one image.  That 
image could be a composite of many different logos, if appropriate.  We 
discussed this face-to-face in Yokohama.  Discussion with people what 
develop graphical interfaces do not think it is a good idea to allow this 
complexity.  Too many images will confuse the user.  When it is appropriate 
to include several community logos, they must be combined into one image to 
ensure that they are consistently displayed.  If this is not done, each 
client will render the images differently...

>Text is missing to explain this structure. How is a grey scale indicated for

Do you have a recommendation?

>a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in black and white

We have tried to avoid such a statement.  Instead we allow the inclusion of 
the same image at many different resolutions so that the client can select 
the best fit.  This is also the reason that we use MIME types to name the 
format.  It allows the greatest flexibility.

>Conversion into grey scale using which kind of transposition ?

The client is always allowed to ignore the logotype altogether.  The 
stronger language added in response to your third comment makes this clear.

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

Again, related to your first comment. No change.

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

Okay.  That paragraph now reads:

    A MIME type is used to specify the format of the file containing the
    logotype data. Implementations MUST support both the JPEG and GIF
    image formats (with MIME types of "image/jpeg" and "image/gif",
    respectively). Animated images SHOULD NOT be used. Implementations
    that support audio MUST support the MP3 audio format (with a MIME
    type of "audio/mpeg").

>community " by :"the community or the communities".

This is already discussed in response to comment 5.  No change.

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

David Cross spoke against this suggestion.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Oct 2002 12:46:45 +0200

Russ,

> I belive that the response from Tom Gindin shows that there is support 
> for audio in support if disabled users.  I believe that the document is 
> clear that the support is OPTIONAL.

The document was not clear that the support is OPTIONAL. There is still much 
controversy about the need for it. No convincing arguments have been 
provided. Please delete or make a strawpol.

> We have already had a dialogue on this point.  I hope it is resolved.

Indeed.

>    subordinate CAs from including private extensions (see the security

This is fine.

> This is related to comment 1.  No change will be made.

See above.

> This is not supported.  The certificate may only include one image.  
> That image could be a composite of many different logos, if 
> appropriate.  We discussed this face-to-face in Yokohama.  Discussion 
> with people what develop graphical interfaces do not think it is a good 
> idea to allow this complexity.  Too many images will confuse the user.  

> When it is appropriate to include several community logos, they must be 
> combined into one image to ensure that they are consistently displayed.  
> If this is not done, each client will render the images differently...

We still have different views on that topic, which is far more important 
than audio. To give a parallel: some banks are members of both VISA and 
EuroCard. Transposed into certificates, this may mean two logos. In the same 
way, a CA may be certifed by two laboratories. The logo of these two 
laboratories may be displayed.

So for community certificates, I am requesting the possibility to have more 
than one logo. The use of combined logos is not appropraite to solve this issue.

> Do you have a recommendation?

No. But I wonder whether the structure is correct. Has it been verifed by an 
image expert ? Many PDAs have B&N screens only because they are cheaper.

> We have tried to avoid such a statement.  Instead we allow the inclusion 
> of the same image at many different resolutions so that the client can 
> select the best fit.  This is also the reason that we use MIME types to 
> name the format.  It allows the greatest flexibility.

  ... but is does not provide any conformance clause.

Can we say that a client is logo-enabled if it only supports 10 x 10
pixels ? Unless the minimumm size (whatever it is) is always present in
the logo, then it is not possible to say that the client is logo-enabled.

> stronger language added in response to your third comment makes this clear.

Do you mean that if the logo is defined in color and the terminal is only 
B&N then the logo shall not be displayed ? If so, this should be clearly said.

> Again, related to your first comment. No change.

See above.

>    that support audio MUST support the MP3 audio format (with a MIME

The additional sentence for animated images is fine. No comment on the 
additional sentence for audio. See above.

> This is already discussed in response to comment 5.  No change.

I maintain the request for it. See above.

> David Cross spoke against this suggestion.

No. David Croos spoke about the *display* of the logo, not the *presence* of 
the logo. Please make the change or provide new arguments.

Denis

---

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

Denis:

I have deleted portions of the growing message thread where we appear to 
have reached agreement.  Hopefully, this will allow us to focus on the 
remaining areas of disagreement.

>The document was not clear that the support is OPTIONAL. There is still 
>much controversy about the need for it. No convincing arguments have been 
>provided. Please delete or make a strawpoll.

The first paragraph in section 3 says:

    This specification defines two types of logotype data: image data and
    audio data. Implementations MUST support image data; however, support
    for audio data is OPTIONAL.

What is unclear?

>EuroCard. Transposed into certificates, this may mean two logos. In the 
>same way, a CA may be certifed by two laboratories. The logo of these two 
>So for community certificates, I am requesting the possibility to have 
>more than one logo. The use of combined logos is not appropraite to solve 
>this issue.

I do not believe that we can support this without creating significant 
confusion.  However, it is simple and straightforward for a CA to generate 
an image file that contains a combination of logos.  This is the only way 
that I can see where the combined logo is consistently displayed.  If it is 
not consistent, then we have not helped the use make a selection from a 
group of certificates without investigating details.

>No. But I wonder whether the structure is correct. Has it been verifed by 
>an image expert ? Many PDAs have B&N screens only because they are cheaper.

It was generated from documents that describe image formats.  You may be 
correct that a CHOICE is needed with one branch for color images and 
another branch for grey scale.  I will do some further investigation.

>the logo, then it is not possible to say that the client is logo-enabled.

I would like to hear from developers on this one.

>B&N then the logo shall not be displayed ? If so, this should be clearly said.

To make such a statement, we need to implement the color vs. grey scale 
CHOICE that I described earlier.  I will do further investigation.

>No. David Croos spoke about the *display* of the logo, not the *presence* 
>of the logo. Please make the change or provide new arguments.

I propose a complete rewrite of section 5:

5. Type of certificates

    Logotypes MAY included in public key certificates and attribute
    certificates at the discretion of the certificate issuer; however;
    logotypes MUST NOT be part of certification path validation or any
    type of automated processing. The sole purpose of logotypes is to
    enhance display of a particular certificate, regardless of its
    position in a certification path.

Russ

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 25 Oct 2002 20:31:31 +0200

Russ,

I agree to everything you suggest here.

Speaking about different image formats options, I still wonder, and would
like input from implementers, if it would be worth the effort to
define/recommend some standard sizes. Some part of me believe this would
increase interoperability and as Issuer of certificates it would make life
easier for me If I have some hints about what clients may expect for optimal
performance.

But maybe this is a post-standard task for another fora?

/Stefan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: Friday, October 25, 2002 5:45 PM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> Denis:
>

---

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

Russ,

> remaining areas of disagreement.

Fine.

>>> I belive that the response from Tom Gindin shows that there is 
>>> support for audio in support if disabled users.  I believe that the 
>>> document is clear that the support is OPTIONAL.
>>
>>
>> The document was not clear that the support is OPTIONAL. There is 
>> still much controversy about the need for it. No convincing arguments 
>> have been provided. Please delete or make a strawpoll.
> 
> 

The text says:

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" does not make it optional.

>>> with people what develop graphical interfaces do not think it is a 
>>> good idea to allow this complexity.  Too many images will confuse the 
>>> user.
>>
>>
>>> When it is appropriate to include several community logos, they must 
>>> be combined into one image to ensure that they are consistently 
>>> displayed.
>> We still have different views on that topic, which is far more 
>> important than audio. To give a parallel: some banks are members of 
>> both VISA and EuroCard. Transposed into certificates, this may mean 
>> two logos. In the same way, a CA may be certifed by two laboratories. 
>> The logo of these two laboratories may be displayed.
>>
>> more than one logo. The use of combined logos is not appropraite to 
>> solve this issue.

> confusion.  

This is not an argument.

 > However, it is simple and straightforward for a CA to
> generate an image file that contains a combination of logos.  This is 
> the only way that I can see where the combined logo is consistently 
> displayed.  

No. There is no requirement to necessarily show both logos. If they are 
combined, then it would be mandatory to display both.

Your response is technology driven, since the current ASN.1 syntax does not 
allow for that case, your are trying to find a way to accomodate the need, 
without changing the syntax.

The syntax needs to be changed.

 > If it is not consistent, then we have not helped the use
> make a selection from a group of certificates without investigating 
> details.

It is still up to the client application to display or not when it wants,
in that case:

no logo (1), logo A (2), logo B (3), or both logo A and logo B (4).

>> No. But I wonder whether the structure is correct. Has it been verifed 
>> by an image expert ? Many PDAs have B&N screens only because they are 
>> cheaper.
> 
> 

Fine.

>>> We have tried to avoid such a statement.  Instead we allow the 
>>> inclusion of the same image at many different resolutions so that the 
>>> client can select the best fit.  This is also the reason that we use 
>>> MIME types to name the format.  It allows the greatest flexibility.
>>
>>

Let us hear from other opinions.

>> Do you mean that if the logo is defined in color and the terminal is 
>> only B&N then the logo shall not be displayed ? If so, this should be 
>> clearly said.
> 
> 

Fine.

>> No. David Croos spoke about the *display* of the logo, not the 
>> *presence* of the logo. Please make the change or provide new arguments.
> 
> 

This solves my concern for that point. Thanks.

Denis

---

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

Denis:

>>>much controversy about the need for it. No convincing arguments have 
>>>been provided. Please delete or make a strawpoll.
>>

I think that displaying one image and playing zero audio sequences conforms 
with this sentence.  if you disagree, please propose alternate wording for 
this sentence.

>>>same way, a CA may be certifed by two laboratories. The logo of these 
>>>two laboratories may be displayed.
>>>

It must be.  I just made it. ;-)

>>generate an image file that contains a combination of logos.  This is the 
>>only way that I can see where the combined logo is consistently displayed.
>
>Your response is technology driven, since the current ASN.1 syntax does 
>not allow for that case, your are trying to find a way to accomodate the 
>need, without changing the syntax.

No.  The authors wrote the syntax after considering this argument,

Many merchants have stickers on the doors to their retail shops that 
indicate the brands of credit cards that are accepted.  They have one 
sticker with many logos.  This is useful to the consumer because the logos 
always appear in the same configuration.  I believe that the same argument 
applies here.

>>make a selection from a group of certificates without investigating details.
>

I clearly disagree.  The choice should be no logo and one logo image (which 
may be a combination of several logos if appropriate).

Russ

---

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

Russ,

I have cut some pieces from the text to make it more readable.

(...)

>> The text says:
>>
>> 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.
>>
> I think that displaying one image and playing zero audio sequences 
> conforms with this sentence.  if you disagree, please propose alternate 
> wording for this sentence.

Displaying *zero* image and playing *zero* audio sequences conforms with 
this sentence. Is it thus a conformance clause ?

Alternate wording: delete that sentence.

Then, when we will have fixed the minimum size of the logo to be displayed, 
then we will be able to add a conformance clause for *client-enabled logos* 
(i.e. clients able to display logos, if they wish to do so).

(...)

>> No. There is no requirement to necessarily show both logos. If they 
>> are combined, then it would be mandatory to display both.
>>
>> Your response is technology driven, since the current ASN.1 syntax 
>> does not allow for that case, your are trying to find a way to 
>> accomodate the need, without changing the syntax.
> 
> sticker with many logos.  This is useful to the consumer because the 
> logos always appear in the same configuration.  I believe that the same 
> argument applies here.

In practice I have never seen a small retail shop getting the logos all at 
once e.g. from VISA and AMEX on the same sticker. There are separate logos. 
So your example is not a real life example.

> I clearly disagree.  The choice should be no logo and one logo image 
> (which may be a combination of several logos if appropriate).

We clearly disagree, but you do not provide arguments to support your position.

Since apparently you missed the logo attachments in my other e-mail, and you 
deleted the note :-( , I am sending them again, with the same comment:

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

Denis