Subject: RE: Logotypes in certificates

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 22 Mar 2001 11:58:58 -0800

Logically speaking, this is a name in that we are talking about a token
which represents an organization. Its just a graphical token, not a
textual token. However I full agree with Steve that like other name
forms, we have to validate the CAs write to assert that logo. I for one
don't see a way to make this work with graphics, and unless it lives by
the same rules as text rules, it is open to abuse and therefore is a
very bad idea.
Trevor

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2001 9:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Logotypes in certificates

"Tom Gindin" <[email-masked]> writes:

>Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of
>the alternate name fields (probably SubjectAltName)?  If so, how would
they
>affect NameConstraints and the like?  IMHO, they would have little
effect on
>them since logos are not hierarchical names and thus couldn't easily be
>governed by NameConstraints.

That sounds like a sensible way to do it, if your cert is issued by
(say) VISA
then they'll put the VISA logo in the issuer's other-name.  I used an
other-
name for the MPEG-of-cat cert I created a few years back and both
MSIE/Windows
and Netscape accepted it (meaning they didn't reject the cert or crash)
so it
looks like a fairly clean way to do it.

Peter.

---

From: Dean Povey <[email-masked]>
Date: Fri, 23 Mar 2001 08:17:05 +1000

>the same rules as text rules, it is open to abuse and therefore is a

This is really a very defeatist attitude.  Just because you can't enforce
technically the ability to make a logo fall within a certain `space'
doesn't mean you can't control it technically.  What constraints could the
a higher level CA possibly want to enforce on a logo later in the path
other than the right to either include one or not?  Name Constraints
already exists to restrict the range of possible spaces the DN/names would fall
into (i.e. who you can issue certs to) and the subordinate CA has to follow
the certificate policy or the whole thing falls down anyway.  

This is a really esoteric problem, and there is a simple solution - punt 
it to policy and revoke the subordinate CAs cert if they break the rules.  
Honestly you have far more to worry about if the subordinate CA is not 
following your identification/authentication rules than if they are 
including a pointer to a logo in their cert.  You can no more enforce 
these with fields in the Certificate than you can enforce constraints on 
graphical types.

The big benefit of logos is surely that it makes Joe User more involved/
aware of the security process that is occurring.  Give the propensity of 
users to ignore pop up text messages (or turn them off), this has to be a 
good thing.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit