RE: Logotypes in certificates

Stephen Kent <kent@bbn.com> Tue, 20 March 2001 17:39 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 MAA15023 for <pkix-archive@odin.ietf.org>; Tue, 20 Mar 2001 12:39:24 -0500 (EST)
Received: from localhost by above.proper.com (8.9.3/8.9.3) with SMTP id JAA05444; Tue, 20 Mar 2001 09:37:44 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Mar 2001 09:37:33 -0800
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05414 for <ietf-pkix@imc.org>; Tue, 20 Mar 2001 09:37:32 -0800 (PST)
Received: from [128.33.238.40] (TC040.BBN.COM [128.33.238.40]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA25278; Tue, 20 Mar 2001 12:31:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010401b6dd44780032@[128.33.238.40]>
In-Reply-To: <DD62792EA182FF4E99C2FBC07E3053BD01752486@sottmxs09.entrust.com>
References: <DD62792EA182FF4E99C2FBC07E3053BD01752486@sottmxs09.entrust.com>
Date: Tue, 20 Mar 2001 12:34:13 -0500
To: Tim Moses <tim.moses@entcws.entrust.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Logotypes in certificates
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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

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