Subject: Re: Logotypes [not] in certificates

From: "David P. Kemp" <[email-masked]>
Date: Thu, 22 Mar 2001 09:53:35 -0500

> From: Dean Povey <[email-masked]>
>
>    [much snippage]
>
> I can see three options (well actually the fourth one is to say that
> it is up to the CA policy to enforce constraints):
> 
> 1. Using an OtherName in subjectAlt has a certain logic to it. 
> 
> 2. An uglier but perhaps more pragmatic approach is to create a logo
>    attribute and shove it in a DN (preferably in altName) with either 
>    PKCS9String or IA5String type.  
> 
> 3. Possibly the most elegant approach, but one which unfortunately has the
>    most impact on current standards is to fix the general problem of
>    enforcing constraints on user certs.

A fifth option is to regard this as an application concern.  When
you get a card with the VISA logo on it from a bank, you have no
technical assurance that the bank was authorized to display that
logo.

Similarly for a UL tag on an appliance cord, a Truste logo on a web
page, or a combat medal on a uniform.

The CA is involved in certifying the identity of the end entity, but
only the end entity itself is responsible for displaying or not
displaying a particular logotype in its communications with other end
entities.  Most of the postings in favor of logotypes in certificates
have described why branding is important to users, but have failed
to to justify the necessity of a CA's involvement in the branding
process.

---

From: Dean Povey <[email-masked]>
Date: Fri, 23 Mar 2001 07:59:17 +1000

>to to justify the necessity of a CA's involvement in the branding

Hmm, I think the reasoning for involving the CA is pretty straight 
forward. The problem that certificates is trying to solve is to provide a 
means for a user to determine the correct public key to use to talk to a 
particular entity.  Traditionally this is done by binding this key to a 
name.  However, names are frequently ambiguous and in some cases are 
difficult to recognise.  This leads to problems where an attacker obtains 
a Certificate for a name similar to an organisation they are trying to 
target.  For a concrete examples see the recent slashdot story:

http://slashdot.org/articles/01/03/22/1947233.shtml

And MicroSoft's Bulletin:
http://www.microsoft.com/technet/security/bulletin/MS01-017.asp

Logos are much easier for humans to recognise.  By having a CA bind the
public key to a logo and having the UI use it appropriately you enable
users to make much better decisions about how they use their certificates.
How many people take the trouble to read all the Certificate fields these
days?

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

---

From: Aram Perez <[email-masked]>
Date: Thu, 22 Mar 2001 22:05:11 -0800

So which is the the real logo?

Regards,
Aram Perez

---

From: Dean Povey <[email-masked]>
Date: Fri, 23 Mar 2001 20:30:34 +1000

>> This message is in MIME format. Since your mail reader does not understand
>this format, some or all of this message may not be legible.
>
>--MS_Mac_OE_3068143512_561796_MIME_Part
>Content-type: text/plain; charset="US-ASCII"
>Content-transfer-encoding: 7bit
>

Similar logos deleted.  

This is of course a valid point, but one can find similar examples in names.

One of the major banks in Australia is "The Commonwealth Bank of
Australia " (commonly shortened to CBA) so which of the following is
the correct domain name for it? (All of these are valid domains with live
websites attached).

1. www.cba.com.au
2. www.cba.com
3. www.commbank.com.au
4. www.commonwealthbank.com

The answer is actually 3, although 1 redirects to this.  Actually I can't
be 100 percent sure that it is 3 since connecting to 
https://www.commbank.com.au redirects me to the non-ssl website so the
connection is not secured :-). 

We are not proposing that logos are less ambiguous than names, simply that they are another datapoint which the user can use to make their decision. Part of
the problem can be addressed by CAs only certifying registered trademarks
which they can easily check and which have to by nature be unlike other
trademarks.  Policy and procedures can deal with many of the objections that
people raise. 

We also need to think beyond just logos.  What about photographs of employees
in Certificates?  This is such a useful thing to be able to do.  I am 
cognisant of the reticence of people to stuff too much in certs, and I think
in general this is a good principle.  But providing it is done sensibly I think
there is a fair bit to suggest that a scheme like this would significantly
contribute to the security of PKI systems.

But I feel that perhaps the weight of opinion is against me :-(.

Cheers.

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 23 Mar 2001 11:43:33 +0100

Dean,

>in Certificates?  This is such a useful thing to be able to do.

That is indeed a working solution for folks working with digital ID-cards
although QC suggests another (much harder to implement and deploy)
solution.

>But I feel that perhaps the weight of opinion is against me :-(.

In IETF-PKIX yes, outside no.

Anders

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 26 Mar 2001 10:48:29 +0200

On Fri, Mar 23, 2001 at 07:59:17AM +1000, Dean Povey wrote:

> [...]  However, names are frequently ambiguous and in some cases are 

I am not sure I get your point.  Are you saying that including logos
into certificates could have prevented this from happening?
According to the Microsoft Security Bulletin,

     VeriSign, Inc., recently advised Microsoft that on January 29 and 30,
     2001, it issued two VeriSign Class 3 code-signing digital certificates
     to an individual who fraudulently claimed to be a Microsoft employee.

I fail to see what difference it would have made to include logos into
the process.

In the message that started this thread it was claimed that "logotypes
are carriers of trust," whatever this means.  The argument was made
that certificates "must be user friendly" and not only be accessible
to "technically oriented users".  Let me assume the role of advocatus
diaboli: The basic idea appears to be that users who don't have a clue
of what is going on should not notice that they don't.  The technical
process of certification is enriched with colourful logotypes to give
certificate recipients warm fuzzies and convey a feeling of "trust."
Users who don't understand the concept of chain validation and the
risks of mis-certification will gladly accept certificates as genuine
because they carry the proper logo.  In other words, we are discussing
how to enable the digital world for one of the traditional tricks for
faking physical ID, which is to use logos to evoke trust.

(Exit advocatus diaboli.  Enter Bodo.)

You say that logos bound to public keys "enable users to make much
better decisions about how they use their certificates."  Will logos
really help to make *better* decisions?  Won't they rather make it
easier to make mistakes?

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: Dean Povey <[email-masked]>
Date: Tue, 27 Mar 2001 10:13:11 +1000

<snip>
>I fail to see what difference it would have made to include logos into

Hmm, I just reread the information.  I had misunderstood, I thought it was 
just the case that they had mistakenly issued a Microsoft Corp CN, but 
that the DN was some division in Microsoft.  Providing the CA had rules 
about only issuing logos to corporate identities, rather than specific 
divisions this would mitigate the risk somewhat. But even given my 
misunderstanding I agree it is a weak example. Mea Culpa.

However, in at least one other post I have given a much better example 
where ambiguity in names leads to poor security.

>faking physical ID, which is to use logos to evoke trust.

Au contrair.  The idea is to make user's more involved in the process, not 
more removed from it.  The point about the logo is it is in your face.
Browser designers tend to hide away Certificate details.  Of course it is 
not perfect, but it is a lot better than what tends to happen at the 
moment (i.e. users just ignore it all together).

I think the risk of certification being subverted by logos is being 
overstated somewhat.  Providing the CA follows good rules for 
certification (e.g. ensure the logo is a registered trademark), they must 
surely be as good as standard text names which are also ambiguous.

The logo is just there as an extra datapoint, it cannot be relied on for 
path processing (partially because the current proposal is an external 
reference and the image may simply not be available at the time of 
processing).

>really help to make *better* decisions?  Won't they rather make it

Well, I think it is a good start if users are actually making decisions. 
Yes logos can cause a false sense of security if:

- The CA gets it wrong
- The CA lies
- The user mistakenly recognises the logo as belonging to someone else.

However, at least for the first two points, the whole PKI system falls down
in a screaming heap if this happens anyway (well at least it will for the 
first as long until CRLs become truly ubiquitous).  The third point is also
true for names.  What, are you saying that people will be more confident in
their mistake if they choose a logo over a name?  I think that the cases 
where this will happen are going to be rare in practice.  After all a logo 
is only useful if the user recognises it as belonging to an established 
brand, so they will most likely discount their trust in the site 
accordingly.

No one seems to be objecting to the fact that names are ambiguous, and that 
all of the same issues being pointed out for logos are true for names.   
Yet everyone seems comfortable with names in Certificates.  We are not 
proposing replacing names, merely adding additional information to the 
certificate to aid the user.

Cheers.
Dean.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 29 Mar 2001 14:48:19 +0200

On Tue, Mar 27, 2001 at 10:13:11AM +1000, Dean Povey wrote:

> [...]         The idea is to make user's more involved in the process, not 

So it is likely that logos will be trusted *instead of* looking at the
certificate details, rather than in addition to that.  I.e., most
users won't even notice to which country the logo applies.  This opens
a new can of worms.  Just one example: Until a couple of years ago,
the owner of the Bayer name and the Bayer cross logo for the US and
Canada was a company that had little to do with Bayer AG.  (In 1994,
Bayer AG bought the division of Sterling Winthrop that had previously
used these trademarks in North America; then, in 1995, Bayer's US and
Canadian subsidiaries changed their names from "Miles Inc." and "Miles
Canada Inc." into "Bayer Corporation" and "Bayer Inc.", respectively.)
It is because of issues like this that distinguished names are
hierarchical.

> Browser designers tend to hide away Certificate details.

If this is considered a problem, it should be changed.  Displaying
some text (as found in most certificates these days) is not
essentially harder than displaying a logo; quite in contrary.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Mar 2001 16:43:32 +0200

Dean,

>contribute to the security of PKI systems.

Photographs in certificates are already covered in RFC 3039 (see 
biometricInfo extension).

My original proposal for logos actually used the same technique to include 
logos as is used in RFC 3039 to include photos and other displayable images 
of biometric-characteristics.

/Stefan