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