RE: Logotypes in certificates

Tim Moses <tim.moses@entrust.com> Tue, 20 March 2001 14:03 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 JAA06320 for <pkix-archive@odin.ietf.org>; Tue, 20 Mar 2001 09:03:17 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA16097; Tue, 20 Mar 2001 06:02:26 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Mar 2001 06:02:15 -0800
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA16067 for <ietf-pkix@imc.org>; Tue, 20 Mar 2001 06:02:13 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <G9HSWJWC>; Tue, 20 Mar 2001 09:01:43 -0500
Message-ID: <DD62792EA182FF4E99C2FBC07E3053BD01752486@sottmxs09.entrust.com>
From: Tim Moses <tim.moses@entrust.com>
To: ietf-pkix@imc.org
Subject: RE: Logotypes in certificates
Date: Tue, 20 Mar 2001 08:58:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B145.CC223EB0"
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

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.


-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, March 19, 2001 11:47 AM
To: Stefan Santesson
Cc: ietf-pkix@imc.org
Subject: RE: Logotypes in certificates


Stefan,

I have mixed feelings about this proposal. We have, in the 
NameConstraints extension, a powerful mechanism for making cross 
certification a safe thing to do. If one were to include a logotype 
extension in a cert that was issued by a CA who had been cross 
certified using name constraints, it holds the potential for 
seriously undermining the controls imposed by NameConstraints.

There is an issue here that merits discussion: the logotype is 
presumably useful only when people are being asked to accept/reject 
certs, in addition to or in lieu of the many software-based controls 
that v3 certs offer. If the use is in lieu of use of more extensive 
software-based controls, there may not be a conflict, since the 
context is probably that of a TTP CA where NameConstraints and 
similar controls are of minimal use. However, if the syntactic 
controls are also in use, a logotype extension may be of limited 
value and might easily degrade security.

So, I would be opposed to PKIX approving this sort of extension (even 
as a separate RFC from 2459bis) without imposing significant 
constraints on the contexts in which it is to be used, including 
limitations on its use in conjunction with other extensions, e.g., 
NameConstraints. What worries me even more, is that we might have to 
extend/modify the validation procedure to enforce such 
inter-extension constraints, which would then affect 2459bis!

Steve