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

Re: charter revisions

Title: Re: charter revisions
At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
Stephen Kent wrote:
> Just as a CA may employ various means to verify a subject's claim to
> a name, a CA can employ analogous means to verify a subject's claim
> to a logotype.  In fact, this may be relatively easy to verify if the
> logo is a registered trademark (something a CA could require via its
> CPS).

As Michael Ströder pointed out, this may not be easy for CAs. Requiring
that a logo be a registered trademark doesn't mean that there won't be
conflicts. A particular logo can be trademarked by different parties in
different countries. In fact, it can sometimes be trademarked by
different parties in the same country if there is little likelihood of
confusion (as when the goods identified are very different). And it may
be difficult for a CA to judge whether a particular image matches a
registered trademark. Verifying someone's right to use a DNS name or
email address is much easier.

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.

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.

If not, I will claim that including logotypes in certificates will have
a negative effect on security. Some CAs will be glad to charge extra to
include a logotype, but if the CA does not verify the logotype and
disclaims all responsibility for the correctness of the logotype, then
what's the point? The user will be misled into believing that the
logotypes have some security significance.

PKIX has long adopted the position that a CA should not include data in certs that the CA does not verify, even though this is not a universally agreed upon position.  The same philosophy could apply here.

Certainly, CAs are welcome to include anything they want in their
certificates. But we should not provide a PKIX blessing unless there is
some security benefit.

See comments immediately above.


> >Second, there's no equivalent to name constraints for use in cross
> >certificates. If I cross certify someone, I just have to trust that they
> >(and anyone they certify) will only put proper logotypes into
> >certificates.
>
> This has been my greatest concern as well, and I'd like to see a
> better proposal on how to better control use of the extension.
> Stefan rejected some approaches, and provided rationales for the
> rejections, but that doesn't mean that we have to live with the
> current proposal if the WG finds the inherent security problematic.

Since the logotypes are to be used to identify issuers and subjects,
I think we must develop a solution to this problem. Otherwise, a
cross-certificate represents complete trust in the subject to
certify anyone.

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.

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


> >Unless these concerns can be addressed, I do not think that this
> >proposal is safe and secure. And I do not think that the IETF should
> >publish an RFC on a fundamentally insecure idea, especially from a
> >security working group.
>
> The attribute RFC has some problems too, in that bad choices of how
> to map an AC to a PKC can result in security failures, right?  So,
> the issue is not whether there are insecure ways to make use of the
> extension, but whether there are ways to make its use secure and
> whether, on the balance, we think appropriate use of the extension
> is beneficial, from a security (not marketing) perspective.

Agreed. If we believe that IETF standardization of this extension will
be beneficial from a security perspective, then we should go ahead with
it. Otherwise, we should not. I remain unconvinced.

-Steve

P.S. Note that I have no personal advantage (and, as far as I know, my
employer has no corporate advantage) to gain by the adoption or failure
of this particular proposal. My views are my own and don't represent the
views of Sun Microsystems. I just want to see the working group spend
its energies on worthwhile projects.

Same here.

Steve