Why do logotypes have to be restricted to end entity certificates?
The most usefull place for a logo is in the root certificate so that you
know the trust brand that you are relying upon. Instead of the silly padlock
there should be an icon telling you who the trust provider is (Thawte,
VeriSign, etc.) and the strength (128bit, 40bit, WEP, etc.)
As for the complexity of cross certification etc., if logotypes don't work
in those situations then don't use them. We better hope that the
introduction of logotypes does not cause a problem with the cross
certification mechanism as some seem to believe since if that were true it
would indicate that the cross certification mechanism was broken (which
would imply adding a WG charter item to fix it which I do not see anyone
proposing).
I do consider the introduction of logotypes to be an intrinsic difficulty
for the CA or RA. Whether they would consider the market for them to be
worthwhile is another matter, likely to closely track the level of client
support.
I have not seen a convincing argument on the trademark issue. The registrar
will simply have to authenticate the ownership of the mark the same they
would any other piece of information, and presumably charge accordingly.
This can be subject to a CPS etc.
These issues may not be simple, however the degree of difficulty is
certainly not so great that the idea should be thrown out as some appear to
imply. If there really is concern we can go ask some lawyers and write a
'legal considerations' section to go along with the 'security
considerations' section.
The issue of far greater interest to me is whether any makers of client
application software have any interest in supporting the scheme. If not it
would simply be another crenelation on the specification.
Another issue is size. I don't much want to see the size of certificates
increase yet further. Perhaps a hash of the image and a URL would be
preferable. Perhaps something a bit more.
At any rate there is certainly enough to justify a WG item. If the WG
ultimately decides that it cannot solve the legal and technical difficulties
it can write a note explaining them for the benefit of future WGs.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@xxxxxxxxxxxx
781 245 6996 x227
> -----Original Message-----
> From: Steve Hanna [mailto:steve.hanna@xxxxxxx]
> Sent: Wednesday, September 05, 2001 10:19 AM
> To: Paul Hoffman / IMC
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: charter revisions
>
>
>
> Paul Hoffman / IMC wrote:
> > At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
> > >Unless the author of the Internet Draft indicates otherwise, I will
> > >assume that the primary purpose of putting logotypes in
> certificates
> > >is so that users can view them to make decisions about whether the
> > >certificates are trustworthy. In that case, the risks are
> much greater
> > >than those for the use case you described.
> >
> > Are the risks any greater than what we have in 2459 now
> with spelling
> > errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> > certificate"? I agree with Russ that the benefits are
> higher, but I'm
> > not at all convinced that the risks are higher.
>
> Yes, the risks are greater than those encountered with textual names.
> For one thing, name constraints provide an effective way to limit the
> portion of the name space that can be reached via a cross certificate.
> No corresponding mechanism has been suggested for logotypes
> nor does it
> seem likely that such a mechanism could be developed.
>
> My original email cited several other security risks that are greater
> for logotypes than for textual names: CAs may find it harder
> to verify a
> certificate requester's right to use a logotype than their
> right to use
> a textual name and logotypes may change appearance radically on
> different devices. Several other risks have been pointed out in the
> recent email discussion: users may not be able to distinguish one
> logotype from another, users may not recall which logotype corresponds
> to which entity, and logotypes are not accessible to vision-impaired
> users or usable on text-only terminals.
>
> > >Unless we can develop a fairly secure way to meet the "marketing
> > >requirement" for logotypes in certificates, I would say that it is
> > >our obligation as an IETF working group to NOT accept this as a
> > >work item. Much better to have multiple incompatible ways
> > >to do something insecure (probably resulting in little deployment
> > >of this feature) than to have the PKIX working group issue an RFC
> > >explaining the one true way to do it. We are in the Security area,
> > >after all!
> >
> > The end of that paragraph doesn't follow from the beginning of the
> > paragraph. As long as the method we described doesn't have any
> > security holes, it doesn't matter if we meet some pre-existing
> > marketing "need". Further, some of the multiple, non-interoperable
> > protocols are likely to have security problems; that is worse than
> > having one protocol that doesn't meet the need of some CAs.
>
> The whole paragraph should be considered predicated by the
> first clause
> ("Unless..."). If that clause does not apply (i.e., we can develop a
> fairly secure way to place logotypes in certificates), then I
> don't have
> any objection to having this as a PKIX work item. But I have seen no
> sign that the objections raised so far can be overcome.
>
> > Mike Myers wrote:
> > >I agree with Stephen Farrell and Steve Hanna that logotypes are
> > >out of scope.
> >
> > They are out of scope; the discussion is whether to add them to
> > the scope.
>
> Of course, you are right. This is a charter discussion.
>
> RFC 2418 (BCP 25) says that "IETF developed technologies
> should not add
> insecurity to the environment in which they run." The IESG
> has enforced
> this in the past and it seems especially pertinent to a
> working group in
> the Security Area. I doubt that the IESG or the Security ADs
> will accept
> this work item in our charter unless we can argue convincingly that we
> can develop something that would not add insecurity to the environment
> in which it is run. I don't think we're there yet.
>
> -Steve
>
Attachment:
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data