Re: Logos: objection to charter revisions

[Stefan Santesson <stefan@xxxxxxxxxxxx>]

Denis,

3 Issues:

1) Should logos be checked by automatic processing?
No. Logotypes can't be processed as part of certificate validation
processing, with one exception which is the binary "allowed" or
"not allowed" local policy. 

2) What logotypes should be displayed in a chain of 
certificates?
This is up to applications to decide but in general: When you view a
certificate, only the logos of that certificate is displayed. If you view
a chain, then normally that view doesn't show certificate details and
would not show any logo at all. Future applications may however show
logotypes for each certificate as they display a chain but when
displaying a single certificate i doubt that any other logos will be
displayed.

3) Is there a conflict between automatic validation processing and
human processing of logotypes
My view is that we have no conflict.
A validation process is the first pit-stop, which will check the
trustworthiness of a certificate (including its chain) including:
- Chaining to a trusted root
- Validity periods
- Revocation status and presence of suitable status checking 
service
- key usage
- Key lengths and algorithms
- Suitability and acceptance of certificate policies
- Suitability and acceptance of present names and name forms
- Suitability and acceptance of extensions (including logos)

This process gives a yes and no answer to the question. "Is this
certificate valid, trusted and fit for its purpose?"

If the user is a mashie. This stops here and goes directly to
authorization processing in applications.

If not, then we have pit-stop number two, display of certificates, given
that the certificates passed pit-stop 1
If the user is a person and if his client is configured to display logos.
The user will have a convenient way to view the certificate through
display of logos together with associated names in text.

Now, the concern here is if a CA issues a certificate with false logos,
inconsistent with the present names. Could a user be fooled?
Yes of course would a user be fooled, but the flaw is not in the logotype
presence. The flaw is that your validation processing allows trust in a
bad CA. And if you have allowed trust in such CA, logos are the least of
your problems.

In the end, the self regulating factor is also that nobody can issue
certificates with bad information and hide from that fact. A bad CA,
which isn't living up to its decalred practices, will soon be out of
business and sued up to its ears.

I understand the fear for things we can not control, but names and logos
are simply such things. Its use and trust in them must be handled by the
market of CA's, not in a standards body.

But as I said. The protocol issues are standards work. Lets assume our
responsibility and provide solid tools needed by the market, and make
them good and globally interoperable.

Whether you like it or not. So far, all major market players I have
talked to (and they are many), including members of the European CA forum
(ECAF) and including the mobile world, wants and needs logos. Lets not
hide from this fact in our own little dream world. Lets accept the
challenge instead.

/Stefan


At 11:30 2001-09-24 +0200, Denis Pinkas wrote:

> Stefan,
>
> The current point is whether we include or not this work item on our
> "PKIX
> plate". I wonder what the decision is at this time. Nevertheless, I
> will
> provide you with some comments on your e-mail.
>
> > Denis,
> > 
> > As I catch up the logo discussion, I think your questions are pretty
> much
> > answered in the current draft.
> > 
> > In principle, there is no difference between the certificate types
> you
> > mention regarding logos. What the logos means to the relying party
> is up to
> > each relying party to define.
>
> It seems difficult define extensions which have a left open and
> hence
> undefined meaning !
>  
> > What is more important is that the different the logotypes have
> distinct
> > meanings.
> >
> > 1) Subject organization logotype: The logotype of the
> organization
> > specified in the subject field
> > 2) Issuer Logotype: The logotype of the organization specified in
> the
> > issuer field
> > 3) Concept logotype: A logotype used by the issuer to represent the
> concept
> > under which the certificate was issued.
> > 
> > The concept may represent a type of assurance level, policy or a
> family of
> > distinct services shared between multiple CAs.
>  
> > The meaning of these logotypes are the same for any type of
> certificate,
> > but in general they are only used to enhance human recognition after
> the
> > certificate having passed all other validation criteria for
> certificate
> > reliance.
>
> This is the main point that puzzles me. In other words, this extension
> is
> never checked when an automatic processing is being used, but is
> only
> checked (how ???, using which criteria ???) by a human being. When
> this
> extension appears in multiple certificates from a chain, shall all
> the
> logotypes be displayed, or printed ? How should this be done ? 
>
> But the main point is that this could lead to different results
> whether
> human interactions or automatic processing is performed. 
>
> Isn't it a problem ?  
>
> Denis
>
>  
> > /Stefan
> > 
> > At 11:02 2001-09-06 +0200, Denis Pinkas wrote:
> > 
> > >After seeing all that discussion about logos, I realized that we
> had
> > >a solution (i.e. the draft writen by Stefan) for an unknown
> problem.
> > >
> > >1) Are logos to be used in server certificates ?
> > >    If so, what would be their intended meaning
> ?
> > >
> > >2) Are logos to be used in human-user certificates ?
> > >    If so, what would be their intended meaning
> ?
> > >
> > >3) Are logos to be used in CA certificates ?
> > >    If so, what would be their intended meaning
> ?
> > >
> > >4) Are logos to be used in self-signed certificates ?
> > >    If so, what would be their intented meaning
> ?
> > >
> > >I do not think that the meaning and the use of the logo
> information will
> > >necessarilly be the same for all of the above cases.
> > >
> > >If that topic is going to stay on the charter, before we define
> a solution
> > >we should first define the requirements. So an INFORMATIONAL RFC
> on the
> > >requirements should be the first step. This Informational RFC
> should at
> > >least answer to the questions raised above.
> > >
> > >Denis