RE: Logotypes in certificates

[Michael Zolotarev <[e-mail]>]

Now I'm really confused.

The whole problem is, as Stephen has neatly put it, that "the whole purpose
of including a displayable logo is precisely an attempt by a CA to gain the
trust of users".

A CA requires to gain trust of a user if it is not still trusted
(obviously). Which is the case when a path construction 
(not validation!) ended up at some self-signed CA which is not among the
user's trusted roots set. This is the only case I can think of when a
decision is to be made by the user, i.e. whether to trust that CA or not. 

I cannot think of any other situation when a CA would require to "gain the
trust of users".

If so, then the scope of analysis of logotype's impact is limited to path
construction, not to path validation. Because, again, validation begins when
the trust is already defined, and it is to late for the user to intervene. 

Path validation algorithm is 'silent', it does not need to present anything
to the user. Therefore, presence of a logotype cannot possible affect the
result of the validation, as the user is not asked about anything, or
presented anything, at that stage.

Consiquently, I'm failing to understand how path validation parameters and
constrains can be affected by the logotypes.

I guess there may be something fundamental I'm missing...

Regards
Michael
 

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Friday, March 23, 2001 4:56 AM
To: Stephen Kent; Michael Zolotarev
Cc: [e-mail]
Subject: RE: Logotypes in certificates


Steve,

There was a suggestion during a dinner yesterday that logotypes actually 
could be provided as a policy qualifier. That would actually solve your 
problem since you could directly tie acceptance of logotypes in 
certificates to a particular policy.

This enables you to control the path validation problem with the use of 
policy constraints.

/Stefan


At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>Michael,
>
>>Though I don't favor including logotype or reference to a logotype to a
>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>realisation was that a logotype is by no means related to the
establishment
>>of trust. It is 100% meant for a human eye only, and verification
algorithm
>>should simply ignore it, as it ingores any other proprietory extentions.
If
>>the verification comes up with an answer 'not validated', and the software
>>prompts a user saying 'couldn't validate', and the user still makes a
>>decision to trust the cert, it is an application's problem, which already
>>exists now, and logotypes add no extra pitch to it.
>
>I think the whole purpose of including a displayable logo is precisely an 
>attempt by a CA to gain the trust of users, so I disagree with your 
>stating point. The concern I raised is not one that is addressed by your 
>example, i.e., my example of a "bad outcome" is a cert that carries a logo 
>which will be recognized by a user and thus will engender the user's 
>confidence, but it is contained in a cert that, while valid under our path 
>validation controls, has nothing to do with the entity whose logo appears 
>in the cert and which is displayed to the user.
>
>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>won't have a logotype in its own cert, and refuse certification of
>>logotypes.
>
>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>not farther, unless we adopt a means of representing the logo that is 
>subject to existing controls. Tom suggested on possible means, if we put 
>the logo in an altname field and make it a type which can be prohibited 
>using nameConstraints.
>
>Steve



This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.