RE: Logotypes in certificates

Stefan Santesson <stefan@addtrust.com> Thu, 22 March 2001 17:56 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 MAA16145 for <pkix-archive@odin.ietf.org>; Thu, 22 Mar 2001 12:56:18 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA10910; Thu, 22 Mar 2001 09:55:34 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Mar 2001 09:55:25 -0800
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10876 for <ietf-pkix@imc.org>; Thu, 22 Mar 2001 09:55:24 -0800 (PST)
Received: from santesson.addtrust.com ([216.70.218.90]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 22 Mar 2001 18:54:12 +0100
Message-Id: <5.0.0.25.2.20010322185247.0420d990@mail.addtrust.com>
X-Sender: sts@mail.addtrust.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 22 Mar 2001 18:55:37 +0100
To: Stephen Kent <kent@bbn.com>, Michael Zolotarev <michael.zolotarev@baltimore.com>
From: Stefan Santesson <stefan@addtrust.com>
Subject: RE: Logotypes in certificates
Cc: ietf-pkix@imc.org
In-Reply-To: <p05010407b6dee6ef6571@[128.33.238.72]>
References: < <D44EACB40164D311BEF00090274EDCCA1E740A@sydneymail1.zergo.com.au> <D44EACB40164D311BEF00090274EDCCA1E740A@sydneymail1.zergo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 22 Mar 2001 17:54:13.0218 (UTC) FILETIME=[1AC65420:01C0B2F9]
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

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