RE: Logotypes in certificates

"Bob Jueneman" <bjueneman@novell.com> Sat, 31 March 2001 01:08 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 UAA24208 for <pkix-archive@odin.ietf.org>; Fri, 30 Mar 2001 20:08:46 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA00881; Fri, 30 Mar 2001 17:08:11 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Mar 2001 17:08:03 -0800
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA00849 for <ietf-pkix@imc.org>; Fri, 30 Mar 2001 17:08:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Mar 2001 18:07:30 -0700
Message-Id: <sac4cb62.005@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Fri, 30 Mar 2001 17:53:33 -0700
From: Bob Jueneman <bjueneman@novell.com>
To: ietf-pkix@imc.org
Subject: RE: Logotypes in certificates
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA00850
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

I've been behind on my e-mail or I would have jumped 
into this discussion much earlier, for I think that Stefan 
is dead on, and it isn't just about branding.

I proposed including logos in certificates about three or 
four years ago or longer, due to one overwhelming problem
when it comes to human acceptance of certificates,
and that is the issue of multiple language support and
non-ASCII characters.

I don't know about anyone else, but my Russian is extremely
rusty, and I can barely read the alphabet. I don't speak or
read Greek, but I can at least read the alphabet.

Now, if someone sends me a certificate with a name in 
Japanese, Chinese, Hebrew, Arabic, Sanscrit, Thai,
or Klingon -- arbitrary Unicode characters, if you
will --  what I am supposed to do with it? I can't even read 
the characters well enough to do a visual comparison
for equality.

And it gets worse when you consider the issue of "right to
use" names, particularly in some of the Asian countries where 
the CAs are closely tied to the government -- they will 
insist on the native language of that country being
used.

Yes, you could put either an English translation or
transliteration in an alternate subject name, but those 
names probably aren't in any sense official, and 
there are therefore significant right to use issues.
When you translate from the Cyrillic, should the name
be "Krasny Izvestia" , or "Red Star"?  Likewise
there are the "Peking" vs. "Beijing" issues, etc.
To us these issues seem be relatively unimportant, but
wars have been fought  over such linguistic matters.

My options would therefore seem to be:

1. Accept everything that comes from VeriSign, etc.,
whether I can read the entity's name or not.

2. Reject everything that comes from VeriSign, etc.,
whether I can read the entity's name or not, and
especially if I can't -- make everyone speak English! :-)

3. Participate only in closed user groups where
the decisions as to whether I should accept a
certificate are taken out of my hands and are
enforced by my MIS organization or higher-ups.

None of these are acceptable, in my opinion.

But if I put a logo in the certificate, in all likelihood
that logo is a trademark that is vigorously defended
and may be recognized worldwide.

Yes, the CAs will have to worry about trademark right 
to use issues, but in fact those issues are well understood
from a legal perspective, and certainly under better 
control than the slippery issue of right-to-use for DNS names.

I don't have an opinion yet as to issues of precisely how
such information should be encoded, and/or whether
name subordination ought to apply, but I think there is
a strong justification for the ability to include a logo
in a certificate.

Off the top of my head, I believe it ought to be possible to
associate a logo with both Subject and Issuer, and
I absolutely agree with Russ -- a policy OID or constraint
would be an absolutely terrible place to put it, except perhaps
as a seal of approval or qualification mark for a closed 
user group or association.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software