RE: Logotypes in certificates

Stefan Santesson <stefan@addtrust.com> Tue, 20 March 2001 22:07 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 RAA27851 for <pkix-archive@odin.ietf.org>; Tue, 20 Mar 2001 17:07:28 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA19715; Tue, 20 Mar 2001 14:06:41 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Mar 2001 14:06:27 -0800
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA19650 for <ietf-pkix@imc.org>; Tue, 20 Mar 2001 14:06:26 -0800 (PST)
Received: from santesson.addtrust.com ([135.222.66.11]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 20 Mar 2001 23:05:14 +0100
Message-Id: <5.0.0.25.2.20010320195950.027eee10@mail.addtrust.com>
X-Sender: sts@mail.addtrust.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 20 Mar 2001 23:06:38 +0100
To: Stephen Kent <kent@bbn.com>, Tim Moses <tim.moses@entcws.entrust.com>
From: Stefan Santesson <stefan@addtrust.com>
Subject: RE: Logotypes in certificates
Cc: ietf-pkix@imc.org
In-Reply-To: <p05010401b6dd44780032@[128.33.238.40]>
References: < <DD62792EA182FF4E99C2FBC07E3053BD01752486@sottmxs09.entrust.com> <DD62792EA182FF4E99C2FBC07E3053BD01752486@sottmxs09.entrust.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 20 Mar 2001 22:05:14.0812 (UTC) FILETIME=[D75BAFC0:01C0B189]
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,

I think you comment is valid, but I challenge your conclusion that we 
better not use logotypes with certificates.

I think we agree that a logo in a certificate doesn't affect path 
validation processing technically (they are not part of the process), with 
or without name constraints. So when you talk about logotypes undermining 
the name constraints function I suppose you identify the case when:

1) A CA have a DN which doesn't violate name constraints from any cross 
certifying CA
2) This CA use a logotype which in fact does conflict with the same name 
constraints
3) A user looks at the logotype and ignores the DN.

For this to be true, the certificate must contain conflicting information. 
I.e. the certificate must contain a DN and a logotype which doesn't match.

I wander what CA, being certified by a significant trust anchor, that would 
do this and at the same time sign and seal this information fraud with its 
own signature? The CA simply couldn't get away with it!

I also suppose that the only way a logotype could undermine the naming 
schema is if logotypes have such significant impact on entity recognition, 
that users in general would se the logo and not notice that the DN is in 
conflict with the logotype.

If this is correct then you acknowledge the importance of logotypes as 
instrument of recognition, which speaks for that we should find a way to 
handle logotypes in certificates and not the opposite.

Personally I think that a conflict between a logotypes and a names in 
certificates can be handled on a contractual/legal level and should not 
stop us from using them in certificates.

/Stefan




At 12:34 2001-03-20 -0500, you wrote:
>At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>>Colleagues - I am supportive of the idea of including branding 
>>information in certificates.  I recognize Steve's concern.  But, I 
>>suggest that there should be no impact on processing rules ... other than 
>>... in applications where the relying party is a human, the logo from the 
>>very first certificate in the path should be displayed to him/her.  When 
>>a relying party accepts a trust anchor, their experience should be 
>>identical regardless of the details of the remainder of the path.  Best 
>>regards.  Tim.
>
>Tim,
>
>My comment re validation processing arises because of the possible 
>undermining of name constraints, as I noted earlier. So, for example, I 
>might be comfortable accepting a cert with a logo reference IF the cert 
>path validation did not include a name constraints extension. But, how do 
>I enforce this sort of rule without changing the path validation algorithm?
>
>Steve