RE: Logotypes in certificates

[[e-mail]]

As I have said a number of times already, there is no use
between machines for the Logo as part of the cert. 

This is purely for human's that might want to look at a
redition of the cert in a paper-like framework, which BTW
is essentially a per-use type of decision and not ANYTHIG
having to do with the negotiability or negotiations
process of the cert itself.

As Mssr. Kemp has pointed out as well, let the
application, if it needs to, deal with displaying a Logo
as part of its opeations.

If this presists as a topic of conversation then I would
suggest that a formal specification for the "CertViewer"
is needed as part of this same scheme so that the Logo's
will render and look the same everywhere otherwise the
logo and its intended use is pointless and the fact that
it is "potentially different" on a number of platforms
will lesson the value and increase the potential
confusion factor for the use of these additions.


--
Regards,
Todd
> 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.