RE: charter revisions

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

Hi, Phillip,

Although you didn't attach my note, you seemed to be responding to some of my comments, at least in part, so at the risk of violently agreeing with you, let me comment further.

I wasn't suggesting that logos should be restricted to end-entities, I was only pointing out that such a restriction would immediately make the issue of name subordination and misuse of the logo by some intermediate CA go away.

I can see some significant marketing value in supporting an AUTHENTICATED use of a logo in an end-entity certificate, for example to convey a professional license or association membership in the case of an individual, and accredited membership in a trade or merchant association, such as a Visa brand.

Whether multi-cultural issues are sufficient to place the Coca-Cola logo in a certificate, I'm not so sure, but I certainly wouldn't rule out the possibility, as I discussed with the Air Canada example.  Standards organizations sometimes tend to be rather cavalier in such regards ― sort of a "let them eat ASCII" type of attitude.  But I'd certainly prefer to see the Sony name/logotype displayed than I would their name in katakana, much less in Japanese ideographs.

But I also see considerable merit in your suggestion of a trust brand, to replace the "silly padlock".  In many respects, it could be a human-readable equivalent of a CP, which is otherwise nearly useless in current practice, I believe.

(BTW, someone informed me that null crypto, e.g., plaintext, is a valid option in SSL, and worse yet, that if that option were selected because it was all that was available, the padlock icon would still appear and the https requirement for SSL security would be satisfied.  Can anyone confirm that?)

I also like your suggestion of a URL and a message digest, rather than attempting to transport the entire logo itself within the certificate. Both the retrieval and display of the logo could then be optional, and the logo could be cached within the browsers, etc. Although you didn't raise the point regarding the use by visually handicapped users, I was particularly impressed by the original reference to Scalable Vector Graphics, and to the potential use of alternate forms of identification, ranging from a audible logo (spoken, a commercial jingle, or whatever) to a braille pattern. 

Of course it would be nice to have a solid indication of interest from the client software vendors to address the "if we build it will they come" question, but the absence of such a commitment certainly hasn't stopped us in the past, and it seems quite unlikely that we could ever obtain such a commitment when we are still debating the charter, and haven't begun to work on an RFC yet. 

I don't mean to ignore or reject the valid concerns that have been expressed, but I do believe that sufficient technical progress has been made even in this limited dialogue to conclude that this is a valid work item, and one that has a least a reasonable chance of success.

We aren't trying to square the circle using straight-edge and compass, nor are we trying to invent a perpetual motion machine.  And yes, as Peter Gutman has demonstrated, anyone could include my gedanken MPEG of a cat in a certificate in any ad hoc way they wanted to, even in the DN if they were so inclined.  One of major purposes of a group such as this is to try to herd all of the cats into a reasonably straight line, and towards an agreed-upon objective, just so that kind of ad hockery doesn't occur.

But no one is forced to contribute to such an RFC, or even read it, if they lack the energy.:-)

Bob



>>> "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx> 09/05/01 09:17AM >>>
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
>