Re: Logotypes in certificates

[Dean Povey <[e-mail]>]

>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.

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: [e-mail] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  [phone]   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone]   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit