[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: charter revisions




At 4:00 PM -0400 9/4/01, Steve Hanna wrote:
Stephen Kent wrote:
 The same name may be used for products or by organizations in
 different "areas" if there is a belief that no confusion will result.
 However, a trademark, in its graphic form, is also a copyrighted image
 and as such is subject to a different set of legal rules that
 generally prohibit outright duplication. The legal challenges arise
 when two logos seem too similar to one another, in the eyes of one of
 the logo holders, and this is when courts step in and adjudicate the
 dispute. Nonetheless, this discussion does not argue against the
 ability of a CA to make a judgement about the legitimacy of a
 subject's claim to the right to use a trademarked logo. Perahps the
 point you're making above is that logos may not be as uniquely helpful
 in identifying an organization because of the possibility of similar
 logos being used by entities in different areas. That's a fair
 critique, but in a different dimension.

I don't think copyright would help much if two companies had trademarks in different countries for a logo that looks like a red circle. But IANAL, so I will abandon that line of argument. Maybe the international copyright and trademark system is strong enough to ensure that the same logo cannot be registered by two different entities in different countries, even if one of those entities is a sham operated by criminals for the purpose of impersonating the other.

I hate to beat a dead horse, but ... Consider the current problem for a CA that is asked to issue a cert to Company X, with a DN selected by that company. There is not a central registry for DNs where the CA can check to verify that the company in question is entitled to use the DN it proposes. Certainly this is true if the U.S. So, since CAs regularly make value judgements about appropriateness of DNs given imperfect inputs, I don't see the logo "verification" as something fundamentally different and harder. (Gee, for someone who has not been a big supporter of this I seem to spend an awful lot of time defending it ... Stefan, where are you?)


You do make a good point that two logos different enough to be legally
distinct may not be distinguishable to the average user. It's also true
that users may not remember the logo associated with a particular
company. Visa, yes. But maybe not Schwab.

Yep. And if we adopt a logo extension, I would expect to see this as part of the security considerations section.



 > Do we know of any CAs that want to include logotypes in certificates
 > that they issue, plan to verify those logotypes, and would be
 > willing to
 > provide some sort of assurances to back that up in their CPS's?

Stefan represents one such CA service provider.

Really? I haven't heard Stefan say anything about how AddTrust would verify logotypes or what assurances his company would provide in this regard. Maybe he told you this in private conversation.

Stefan certainly has indicated that his interest in pursuing this was motivated by his perception of a market need, based on his experience as CTO for AddTrust. I inferred that AddTrust would make use of this facility if it were available.


> I would prefer to find a way to impose some form of constraint on
 the appearance of logos analogous to what we do in cross certs for names
 or policies.  because a logo is not structured, the name constraints
 mechanism can never be used in so precise a fashion, even if we choose
 to put a logo in some name form. but, it would be nice to have a way
 to prevent a CA further down a cross-cert chain from introducing a
 logo if one wants to prevent such action. Just because we don't have a
 mechanism to do this yet doesn't mean we can't work toward one.

This would mean that all existing cross-certificates would allow logotypes in certificates. It might be better to say that certificate containing a logotype should not be validated (or, at least, the logotype should be ignored) unless all preceding certificates in the path have an extension that says logotypes are allowed.

I didn't mean to suggest details of solution at this point; I just wanted to express what I thought was a good requirement. To be analogous to what we can do with policy mapping and inhibition of policy mapping and with name constraints, it might sufficient if a CA could preclude inclusion of a logo extension in any subsequent cert in a path.



 > > >Third, an apparently innocuous logotype can change appearance
 > radically
 > > >when scaled to a smaller size or mapped to a different number of
 > colors.
 > > >This can be exploited to deceive cell phone users into thinking
 > that
 > > >they're communicating with their bank, for instance.
 > >
 > > I had not considered this issue. we should explore ways that this
 > > problem might be avoided. presumably anyone displaying a logo on a
 > > web page has a similar concern, so maybe there are viable means to
 > > address this issue.
 >
 > The problem with displaying a logo on a web page is different
 > (unless I
 > didn't understand you). With a logo in a certificate, we want to
 > make
 > sure that the person requesting the certificate doesn't trademark a
 > bogus logo and get it included in their certificate just so they can
 > trick a user who sees a scaled-down version of the logo into
 > believing
 > it's a trusted logo. The closest analogy is getting a web server
 > certificate for paypa1.com (where the letter ell is actually a
 > number
 > one). If you can get the user to click on an https://www.paypa1.com
 > URL,
 > the user will think they are viewing a secure paypal website if the
 > font
 > they use to view URLs displays ell and one the same way.
 >
 > When viewing a logo on a web page, the user should not make
 > decisions
 > about whose web page it is based on the logo. Instead, we have been
 > trying to convince them to look at the host name in the URL and
 > check
 > that the padlock or key is lit up to indicate that an SSL connection
 > is

> in use.

 The reality is that logos on web pages are designed to inspire
 confidence in users based on visiting the web page, period. Yes,
 someone can put up a similar logo to try to fool people, or even put
 up the valid logo without the permission of the logo owner. We rely on
 the legal system to detect and remedy these problems, ex post facto.
 That's not as good as preventing them, but many folks argue that it is
 better than not offering a logo-based marking facility.  When it comes
 to putting logos in certs, we have a better mechanism in many cases,
 since the binding is secured and there are fewer CAs than there are
 web sites.

Just seeing a logo on a web page doesn't inspire much confidence in me. Yes, the logo owner will probably pursue those who misuse the logo. But the Internet is a rough place. The miscreants may skip town with no forwarding address and I (the user) will be very sad if I gave them my brokerage account password and they emptied the account.

You and I probably are not the folks for whom the logo extension would be of great value.


That's why we have HTTPS. The end user notices that the padlock or key
is lit up and decides that the host name in the URL is OK, so they enter
their brokerage account password. If we change this so that the user is
deciding that a *logo* is OK, I want to make sure the binding between
the logotype and the public key is secure and that the logotype that
appears in the certificate is properly displayed to the user.

Agreed.


But this is completely pedantic. The original issue was that a logo can
change appearance when it's scaled or mapped to different colors. A pink
circle is different from a green circle for trademark and copyright
purposes. But how do you distinguish them when they're displayed on a
black and white screen? I don't think that web page technology has any
magic bullets in this area. And what about blind users? With URLs, they
can have their screen-reader read the URL back to them. Graphics will be
completely inaccessible.

Good points about the limitations of a logo.


Steve