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

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

Denis,
There is a way to accomplish associating multiple community logos within
the existing draft. We permit the use of the logotype extension within
attribute certificates as well as identity certificates. It is therefore
possible to have an identity certificate, issued by Last National Bank
to merchant foo with a community of Visa, and an attribute certificate,
issued by Utah Credit Union to merchant foo with a community logo of
MasterCard. In this situation, the UI can legitimacy display a community
logotype for each valid certificate.
Trevor
-----Original Message-----
From: Stefan Santesson [mailto:stefan@xxxxxxxxxxxx] 
Sent: Thursday, October 31, 2002 6:06 AM
To: Denis Pinkas
Cc: Housley, Russ; ietf-pkix@xxxxxxx
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt


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