RE: Logotypes in certificates

Michael Zolotarev <> Thu, 22 March 2001 23:18 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with SMTP id SAA25208 for <>; Thu, 22 Mar 2001 18:18:18 -0500 (EST)
Received: from localhost (daemon@localhost) by (8.9.3/8.9.3) with SMTP id PAA03552; Thu, 22 Mar 2001 15:17:37 -0800 (PST)
Received: by (bulk_mailer v1.12); Thu, 22 Mar 2001 15:17:30 -0800
Received: from ( []) by (8.9.3/8.9.3) with ESMTP id PAA03512 for <>; Thu, 22 Mar 2001 15:17:26 -0800 (PST)
Received: from ( []) by (8.9.1/8.8.7) with ESMTP id JAA04288 for <>; Fri, 23 Mar 2001 09:27:03 +1100
Received: from (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id <>; Fri, 23 Mar 2001 10:18:09 +1100
Received: by with Internet Mail Service (5.5.2650.21) id <HNY7PP42>; Fri, 23 Mar 2001 10:15:30 +1100
Message-ID: <>
From: Michael Zolotarev <>
To: "''" <>
Cc: "'Stefan Santesson'" <>, Stephen Kent <>,
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 10:15:29 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
List-ID: <>

I agree with Todd that once we touch the slippery path of using graphical
images as a formal constituent of trust establishement, the problem will
become a far more exotic one than defining a set of rules for verification

I feel that there is no common understanding of the logotype's intended
purpose (purpose, not handling!), and therefore the arguments are making
rounds. Following are the points which require clarification, in order to be
certain what use scenario we are talking about:

1 Logotypes are allowed in (to be referenced from) EE PKC:
1.1 Logotypes in EE PKC are there for 'informational use only'. They are not
part of the Subject's name, in whatever form. They must be ignored by
validation process. Identity with a logotype is no different from the same
identity less logotype.

1.2 Logotype in EE PKC is a valid component of the Subject's identity.
Identity with a logotype is different from the same identity less logotype.
A single PK cannot be bound to the two identities.

2 Logotypes are allowed to be referenced from CA certificates.
2.1 Logotypes are only allowed in self-signed CA certificates.

My original understanding of the proposal was 1.1-yes, 1.2-no, 2-yes,

This way, logotypes have a simple purpose of branding and pleasing humal
eyes. No trust. I can reference a logotype url from my certificate, and
later remove the logotype (so that the url becomes a dead one). It should
not affect the acceptance of my certificate by formal validation procedures.

(I'm not saying that branding and eyes pleasure justify the troubles :)


-----Original Message-----
From: []
Sent: Friday, March 23, 2001 6:48 AM
To: Michael Zolotarev
Cc: 'Stefan Santesson'; Stephen Kent; Michael Zolotarev;
Subject: RE: Logotypes in certificates

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.

> Now I'm really confused.
> The whole problem is, as Stephen has neatly put it, that "the whole
> of including a displayable logo is precisely an attempt by a CA to gain
> 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
> 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
> 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 []
> Sent: Friday, March 23, 2001 4:56 AM
> To: Stephen Kent; Michael Zolotarev
> Cc:
> 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
> >>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
> >>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
> >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
> >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
> >>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
> 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
> passed on.
> In addition, certain Marketing collateral may be added from time to time
> 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.