Re: Logotypes [not] in certificates

Dean Povey <povey@dstc.qut.edu.au> Tue, 27 March 2001 00:14 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21697 for <pkix-archive@odin.ietf.org>; Mon, 26 Mar 2001 19:14:42 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA08794; Mon, 26 Mar 2001 16:13:51 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Mar 2001 16:13:34 -0800
Received: from thunder.dstc.qut.edu.au (thunder.dstc.qut.edu.au [131.181.71.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA08709 for <ietf-pkix@imc.org>; Mon, 26 Mar 2001 16:13:31 -0800 (PST)
Received: from dstc.qut.edu.au (garnet.dstc.qut.edu.au [131.181.71.36]) by thunder.dstc.qut.edu.au (8.10.1/8.10.1) with ESMTP id f2R0DBm26956; Tue, 27 Mar 2001 10:13:12 +1000 (EST)
Message-Id: <200103270013.f2R0DBm26956@thunder.dstc.qut.edu.au>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, ietf-pkix@imc.org
Subject: Re: Logotypes [not] in certificates
In-Reply-To: Message from Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de> of "Mon, 26 Mar 2001 10:48:29 +0200." <20010326104828.A28867@cdc.informatik.tu-darmstadt.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 27 Mar 2001 10:13:11 +1000
From: Dean Povey <povey@dstc.qut.edu.au>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id QAA08714
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
Content-Transfer-Encoding: 8bit

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

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.

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

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


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

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.