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

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Apr 2002 17:55:50 +0200

Russ,

Thank you for this long reply ... that did not convinced me.
The argumentation you provided is not crystal clear to me.

See my comments below.

> Denis:
> 
> I fear that you have missed the point of the logotypes draft
> altogether.  The authors recognize that the introduction needs to be
> expanded, so we may be to blame for any misunderstanding.  To try and clear
> up the misunderstanding, I offer some general observations before
> responding to your specific comments.
> 
> The logotype extension will aid in two situations:
>         1.  Certificate-based Identification
>         2.  Selection of Certificates
> 
> In the first case, the need for human recognition 

1) Recognition of what ? or of which characteristics ? 
   Please be precise.

2) Recognized by which entity ? Please be precise. 
   I would guess a human being acting as a relying party.

> depends on the manner in
> which certificates are used and whether certificates need to be visible to
> human users. If certificates are to be used in open environments and in
> applications that bring the user in conscious contact with the result of a
> certificate-based identification process, then human recognition is highly
> relevant, and it may be a necessity.
> 
> Most applications provide the human user with an opportunity to view the
> results of a successful certificate-based identification process.  When the
> user takes the steps necessary to view these results, the user is presented
> with a view of a certificate. This solution has two major problems.  First,
> the function to view a certificate is often rather hard to find for a
> non-technical user. Second, the presentation of the certificate is rather
> technical; it is not user friendly. It contains no graphic symbols or
> logotypes to enhance human recognition.
 
> In the second case, there are software applications that expose human users
> to certificates for the selection of a single certificate from a portfolio
> of certificates. In some circumstances, the software application can use
> information within the certificates to determine suitability; however, the
> user must be queried if more than one certificate is suitable. The human
> user must select one of them.

I would guess that is that case it is a recognition by the subscriber. 
Is it what you mean ? Are there other cases you are thinking of ? 
Please be precise.

> This situation is comparable to a person selecting a suitable plastic card
> from his wallet. In this situation, substantial assistance is provided by
> card color, location, and branding.
> 
> In order provide similar support for certificate selection, the users need
> tools to easily recognize and distinguish certificates. Introduction of
> logotypes into certificates provides the necessary graphic.

> Now, for your specific comments.
> 
> COMMENT 1: Subject logotype.
> 
> Currently a "subject organization logotype" is proposed. It definition is
> as follows: "a logotype representing the organization identified in the
> subject name in the certificate".
> 
>  From this definition only a single logotype would be allowed for a
> subject. It can make sense to attach more that one logotype to a subject,
> that does not reflect necessarily the organization a user belongs to (e.g.
> an individual is a Red Cross member) so the definition should be changed
> to:
> 
> "subject logotype" "a logotype representing any characteristic of the
> entity identified in the subject name in the certificate".
> 
> RESPONSE 1.
> 
> We are allowing a graphical identity of the user to facilitate certificate
> selection or acceptance. We are not trying to graphically represent every
> attribute of the user.  We certainly do not want to overwhelm the designers
> of graphic user interfaces.  We need to keep it simple.

I do not buy this argument. The current proposal limits to logo type to the
logo of the organization, whereas this limitation is not appropriate. A
subject may even have no O (Organization) component in the DN and there
could
be other logos attached to the subject field.

> COMMENT 2: Issuer logotype.
> 
> Currently an "issuer organization logotype" is proposed. It definition is
> as follows: "a logotype representing the organization identified as part of
> the issuer name in the certificate".
> 
>  From this definition a single logotype would be allowed for an issuer. It
> can make sense to attach more that one logotype to an issuer, that does not
> reflect necessarily the organization an issuer belongs to (e.g. an issuer
> may support a "Privacy Policy" and be a member from two different trade
> associations), so the definition should be changed to:
> 
> "issuer logotype: a logotype representing any characteristic of the issuer
> identified as part of the issuer name in the certificate".
>
> RESPONSE 2.
> 
> Again, we are allowing a graphical identity of the user to facilitate
> certificate selection or acceptance. We are not trying to graphically
> represent every attribute of the issuer.

I do not buy this argument. The current proposal limits to logo type to the
logo of the issuer, whereas this limitation is not appropriate. See my 
examples again.
 
> COMMENT 3: The "concept logotype", also renamed "community logotype" during
> the last IETF meeting or " shared community logotype" in the minutes from
> the same meeting is more hazy.
> 
> The current text states:" Many issuers may use the concept logotypes to
> co-brand with a global concept in order to gain global recognition of its
> local service provision. This type of concept branding is very common in
> credit card business where local independent card issuers issue cards
> within a globally branded concept (such as VISA and MasterCard)".
> 
> The current text also states: " the relationship between the issuer and
> either the issuer  organization logotype or the concept logotype".
> 
> A logotype is adding "human processable" information to enhance the
> properties of an already existing field from a certificate. To this respect
> it is sensible to add one (or more) logotypes that characterizes the issuer
> and the subject. The real question is to which field the "concept
> logotype / community logotype / shared community logotype" relates.
> 
> It may relate :
>    - either to the issuer, to state that an issuer belongs to some group, or
>    - to the certificate policy to state that the policy under which the
>      certificate is issued obeys to some rules imposed by the organization
>      whose logo is referenced.
> 
> This leads to two possible ways:
>     1) only consider two logotypes: issuer logotype and subject logotypes.
>     2) consider three logotypes: issuer logotypes, subject logotypes and
>        policy logotypes.
> 
> I would favor the former, but would have no major problem to go with the
> later. In that case the policy logotype would be defined as follows:
> 
> "Policy logotype: a logotype representing any characteristic of the
> certificate policy under which the certificate is issued".
> 
> RESPONSE 3.
> 
> Policy implies the wrong connotation. We are not trying to graphically
> represent a certificate policy or anything about how the certificate was
> issued. The community (or concept) logotype simply allows CA to enter into
> collective branding relationships.

A branding of what ?  Please be precise.
 
> I suppose that a large group that share a common security policy could
> register a logo for that policy and use it as a community logo.  While this
> was not the model that we considered, it certainly is accommodated.
> 
> COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified*
> to some extend by the issuer. The current text is misleading:
> 
>     "The relationship between the subject organization and the subject
>     organization logotype and the relationship between the issuer and
>     either the issuer organization logotype or the concept logotype, are
>     relationships *claimed* by the issuer."
> 
> RESPONSE 4.
> 
> The issuer is responsible for the verification of anything that is included
> in the certificate.  After all, the issuer signature covers it.  Thus, the
> issuer is claiming that the logotypes are appropriate.

Don't twist the wording.  :-)

We agree on the concept, but we should try to use another wording and avoid
to use the word "claim".
 
> COMMENT 5: During the meeting, it has been proposed to add a small image of
> the logotype in the certificate itself. In this WG we always have had a
> concern about the size of the certificate, so that it can be lodged in some
> small devices. So I would not favor to allow such provision in a
> extension standardized by this WG.
> 
> RESPONSE 5.
> 
> There are environments where the client cannot access the Internet until
> after the certificate is used.  Consider certificate-based authentication
> to an ISP.  A small logotype in the certificate could be useful to aid
> certificate selection in this situation.  The inclusion of a small logotype
> is, of course, optional.

...and instead of certificates between 1 K and 2 K bytes, have certificates 
with at least one more K !

Denis

> COMMENT 6: It should be made clear that this extension in non-critical.
> 
> RESPONSE 6.
> 
> Agree.  The logotype extension was never intended to be critical.
> 
> COMMENT 7: The document includes many typos to be corrected.
> 
> RESPONSE 7.
> 
> We will make every effort to correct them before the next draft is published.
> 
> Russ

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 04 Apr 2002 01:19:13 +0200

Denis,

Generally I have some problems with your way of arguing. My observation is 
that you ask us to be precise where there is no point in being precise and 
you fail to be precise yourself where your arguments need to be backed by 
facts and examples.

At least I think it would be fair of you to try to understand what the 
draft was written to solve and either argue that we try to find a solution 
to the wrong problem or that we try to solve the right problem the wrong way.

Right now I feel that you claim that we solve the wrong problem the wrong 
way, which is a rather hopeless originating discussion point.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Apr 2002 15:27:54 +0200

Stefan,

Your "feeling" is wrong. At the Minneapolis meeting you welcomed a technical
discussion on that topic. Please, go back to a technical discussion.

Regards,

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 04 Apr 2002 16:10:51 +0200

Denis,

I absolutely welcome a technical discussion and my last mail was not 
intended to offend you by any means.

I'll try to answer all "technical" questions I can find.

>    I would guess a human being acting as a relying party.

Yes.

>Is it what you mean ? Are there other cases you are thinking of ?

Can't understand your question. Please clarify.

>be other logos attached to the subject field.

Not a technical issue but an issue regarding the intent of the solution. 
The intent of the solution is to represent the subject organization.

If you have other usage scenarios please describe them in more clarity.

>with at least one more K !

This issue is a matter of balance between space and functionality.I don't 
believe you can argue that there is any right and wrong here.

Personally I believe that the space used is worth it in many cases.

Do you have any "technical" issues with this. e.g. cases where this would 
create certain problems we should be aware about.

/Stefan