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

From: [email-masked]
Date: Tue, 29 Oct 2002 06:19:26 -0500

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-07.txt
	Pages		: 21
	Date		: 2002-10-28
	
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-07.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-07.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-07.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, 29 Oct 2002 09:17:00 -0500

This update captures the things that have agreed.  The biggest change is 
the support in the syntax for color and gray scale images.  Many other 
little changes are included.

As I see it, there are two open issues:
    1) Removal of audio; and
    2) Support for more than one logotype in each of the categories

These two topics are still being discussed on the list.

Russ

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 29 Oct 2002 23:02:00 +0100

I argue against multiple logotypes,

We have already a structure for different versions of the same logotype. if
we add the possibility to have multiple logos, and for each logo, we may
have different version (different resolutions, color sets, sizes...) then we
do 2 bad things.

1) We expand the concept beyond the intended scope
2) We make it harder and more complex for the GUI implementers to make a
distinct application.

Denis,

We had this discussion in Yokohama and all examples you came up with had to
do with loyalty structures rather than communities. The community logo
represent THE community within which the issuer acts as issuer. Example - A
credit card can never be both MasterCard and VISA at the same time. If it
would, who would be responsible for it if something goes wrong???

If the community, within which the issuer operates when issuing a particular
certificate, has a combined logo from two integrated community structures -
Fine - This is then still just 1 community logo from the standards
perspective.

I agree though that you can have multiple independent loyalty schemes.

Last time you raised this, we gave you the multiple and independent loyalty
logos and you where satisfied with that, What has changed?

/Stefan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: Tuesday, October 29, 2002 3:17 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>
>
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 30 Oct 2002 13:29:08 +0100

Russ,

Thank you for this notice.

>    2) Support for more than one logotype in each of the categories

The second issue is not correctly worded. Rephrase as:
      2) Support for more than one logotype for the community category.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 30 Oct 2002 14:46:36 +0100

Stefan,

 > I argue against multiple logotypes,

Let us see what your arguments are.

 > We have already a structure for different versions of the same logotype.

I would not say "versions", I would say "presentations" or "variants".

 > if we add the possibility to have multiple logos, and for each logo,
 > we may have different version (different resolutions, color sets,
 > sizes...) then we do 2 bad things.

 > 2) We make it harder and more complex for the GUI implementers to make a

What is the "intended scope" ? Until it is clearly defined, you cannot say
that this is contradictory. So there is no demonstration here.

What is harder ? Display is always an option. We do not mandate what MUST be
displayed.

 > Denis,
 >
 > We had this discussion in Yokohama and all examples you came up with had
 > to do with loyalty structures rather than communities. The community logo
 > represent THE community within which the issuer acts as issuer.

Besides loyalty structures (BTW, where do you place them ?), there is as an
example "t-scheme approved" or what ever other "scheme" in Asia or in the
US. Same question: where do you place that information ?

 > Example - A credit card can never be both MasterCard and VISA at the
 > same time. If it would, who would be responsible for it if something
 > goes wrong???

Some merchants are accepting credit cards from Visa, Eurocard, and AMEX.
How are you going to be able to include that information in a server 
certificate ?

Some cards in my country have both the CB logo (CB = Carte Bancaire) and the 
Eurocard or VISA Logo.

How are you going to be able to include that information in a person 
certificate issued by a bank ?

 > If the community, within which the issuer operates when issuing a
 > particular certificate, has a combined logo from two integrated
 > community structures -

We never said that logos MUST be displayed. An application may look for a
given logo and chose to display it, if present. Combined logos would not
allow that feature and would be pretty big or unreadable since an
application would need to display, e.g. four, logos in a small window size.

 > I agree though that you can have multiple independent loyalty schemes.

Fine. Where do you place them ?

 > Last time you raised this, we gave you the multiple and independent
 > loyalty logos and you where satisfied with that, What has changed?

You showed me that a sequence was present in the ASN.1 syntax and thus that
the need what covered. While looking more carefully, there is indeed a
sequence but it cannot be used in this way.

     image           SEQUENCE OF LogotypeImage OPTIONAL,

There are very few (i.e. not enough explanations about the various fields).
In particular the image field is not explained (and it should !) and thus
there is no conformance clause for it (i.e. no SHALL or SHOULD).

Since a sentence is saying:

     If a logotype is represented by more than one image file, then the
     image files MUST contain variants of the roughly the same image.

My understanding is the following:

image contains one or more variants of the roughly the same image. No more
that one of the LogotypeImage SHALL be displayed, since it is roughly the
same image.

This does not permit to include images that are really different.

I am asking for:

           communityLogo   [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,

instead of:

           communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,

I hope that the above examples will be able to convince you.

Denis

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 31 Oct 2002 15:06:13 +0100

Denis,

I think you are mixing concepts and to some extent misreading the standard.

I comment below;

> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Wednesday, October 30, 2002 2:47 PM
> To: Stefan Santesson
> Cc: Housley, Russ; [email-masked]

stuff deleted...

> that this is contradictory. So there is no demonstration here.

Intentions and scopes are included in sections 1 and 2. The scope is clearly
to allow issuers to claim that they issue a certificate as part of a
community. The value of having just 1 community is that it brings clarity to
the concept. There are numerous of examples in real life of this situation:

1) Gasoline stations. They may be independent enterprises but they are
sometimes members of A community (Shell, Esso etc)
2) Shops.. same thing.
3) Credit cards
4) Airlines
....
....

The common ground is that there is a point of issuing a service under JUST 1
community. One big reason is that there generally is some kind of common
explicit or implicit liability or protection of brand involved. If one
service would be Both VISA AND MasterCard at the same time, or both SHELL
AND ESSO or.... who would protect the brands, who would take responsibility
for that ....

To my knowledge that type of situation does not exist.

All examples you state are not examples of multiple communities but examples
of other aspects of reality.

So a good thing with having just 1 community logotype proved by you here.
That is that people can't abuse the standard and put any obscure logotype as
1 of 10 community logos, making the GUI makers insane :-)

> What is harder ? Display is always an option. We do not mandate

For a GUI of this kind, especially if we want to create a visual equivalent
of an ID-card on the screen (in a standard format), it helps implementers to
know if they will handle 1 or none logo, or if they must be prepared to
handle any number of logos.

As said above, if this is not limited, as GUI maker you MUST expect CA:s to
put in a whole bunch of obscure logos here representing everything from
loyalty scheme, accreditation scheme, partners, sponsors...... you name it.

This is why the principle is good to say that the 3 main logotype types can
only be 1 logo of each type.

If you want to include more logos, you provide them as other logos,
according to section 4.2. This is a good structured way that provide clear
expectations for the GUI makers.

> US. Same question: where do you place that information ?

This is not a community. I don't issue certificate belonging to the t-scheme
community. T-scheme, TTP-NL, Web trust or whatever are conformance schemes
that has nothing to do with community. If you want to display any logotype
related to this you must define a new "other logo" type in section 4.2.

It could actually be a good idea to do that.

> How are you going to be able to include that information in a server

You don't

You may provide that information on the web page that is protected by the
server certificate. But whatever you do, it is NOT part of the community
logo in the server certificate.

> certificate issued by a bank ?

The standard allows 2 issuer logos for co-branding, 1:st the logo
representing the Issuer organization, 2:nd the logo representing the
community.

I'm not sure what function the CB logo has. If this is not covered by these
logos, you can use some of the defined other logos (section 4.2), or define
one for the purpose.

> application would need to display, e.g. four, logos in a small

That's a feature, not a problem. This means that If the application display
logo related to THE community, it can not screw up by showing just half of
the relevant logo image data.

> Fine. Where do you place them ?

Read section 4.2

Stuff deleted ...

> This does not permit to include images that are really different.

Yes you are right. That is the defined meaning.

> I hope that the above examples will be able to convince you.

I regret to say that I'm not.

I still think it would make the standard worse

What would convince me is if anyone could show a realistic and relevant case
where there are 2 independent communities, within which the issuer acts when
issuing a certificate. I have yet to see that case.

/Stefan