Subject: RE: Logotypes in certificates

From: Michael Zolotarev <[email-masked]>
Date: Thu, 22 Mar 2001 04:51:46 +1100

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.

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.

Michael
-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 4:07 AM
To: 'Stephen Kent'; Dean Povey
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [email-masked]
> Subject: Re: Logotypes in certificates
> 
> 
> Dean and Stefan,
> 
> As a security kinda' guy, I always approach this from the "what will 
> the bad giy do" perspective.  From that perspective, I worry that a 
> TTP CA will cerfity company X, putting the company X logo in the 
> cert. Then company X will issue a cert to a subordinate CA, and put 
> in that cert an inappropriate logo. It is not realistic for an app to 
> display a chain of logos, and expect a user to pay attention, any 
> more that if one displayed a chain of DNs.  I still maintain that we 
> can agree on what would be a reasonable set of circumstances in which 
> the logo extension would be useful and safe, but I don't see a 
> technical means of enforcing these circumstances without changes to 
> the path validation algorithm. I am open to suggestions that provide 
> the necessary controls and don't have this unfortunate side effect, 
> but I have yet to see an example of such.
> 
> 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.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2001 18:21:53 -0500

Michael,

>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.

>won't have a logotype in its own cert, and refuse certification of

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 22 Mar 2001 18:55:37 +0100

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:
>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 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Mar 2001 15:22:43 -0500

As every long-standing participant knows, I absolutely hate policy 
qualifiers.  That said, I find it extremely difficult to send this 
message.   Given the alternatives that have been discussed so far, I like 
this one much more.

Russ

At 06:55 PM 3/22/2001 +0100, Stefan Santesson wrote:
>>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.
>>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Mar 2001 10:11:25 -0500

Stefan,

>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.
>

I'd be comfortable with that approach, except that we have 
discouraged use of policy qualifiers, as Russ noted.

Let me suggest again that you send another message that includes a 
comprehensive rationale for inclusion of logotypes, indicating what 
types of certs would be allowed to contain them, what reference form 
you envision, and what controls you think should be employed to 
prevent the sorts of misuse I warned about.  With a concrete 
proposal, and well articulated rationale on the table, I think we 
have a better chance of making progress.

Steve