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.
- Re: Logotypes [not] in certificates David P. Kemp
- Re: Logotypes [not] in certificates Dean Povey
- Re: Logotypes in certificates Aram Perez
- Re: Logotypes in certificates Dean Povey
- Re: Logotypes in certificates Anders Rundgren
- Re: Logotypes [not] in certificates Bodo Moeller
- Re: Logotypes [not] in certificates Dean Povey
- Re: Logotypes [not] in certificates Bodo Moeller
- RE: Logotypes [not] in certificates Frank Balluffi