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

["Stefan Santesson" <stefan@xxxxxxxxxxxx>]

Denis,

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

I comment below;

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Denis Pinkas
> Sent: Wednesday, October 30, 2002 2:47 PM
> To: Stefan Santesson
> Cc: Housley, Russ; ietf-pkix@xxxxxxx
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>
>
>

stuff deleted...

>
>  > 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.
>
> What is the "intended scope" ? Until it is clearly defined, you cannot say
> 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
> what MUST be
> displayed.

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.

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

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.


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

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.


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

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.

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

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.

>  > I agree though that you can have multiple independent loyalty schemes.
>
> Fine. Where do you place them ?

Read section 4.2

Stuff deleted ...

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

Yes you are right. That is the defined meaning.

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

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