Subject: Re: charter revisions

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 05 Sep 2001 14:04:27 -0600

>Bob Jueneman wrote:
>> 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.
>
>This isn't true. Name constraints allow me to cross certify IBM's CA but
>indicate that the only DNs it is trusted to certify are those that begin
>with "c=us, o=IBM". Even if logos are restricted to end-entities,
>there's nothing stopping IBM's CA from placing a Sun logo in an
>end-entity certificate. So restricting logos to end-entities doesn't
>"make the issue of name subordination and misuse of the logo by some
>intermediate CA go away."

Sorry, Steve, you are quite correct in that sense.  I guess I wasn't thinking about corporate logos tied to organizational persons as much as I was thinking about brand identification, where the brand isn't owned by the superior CA in any case, any more than VeriSign owns c=us, o=Sun. In any case, name subordination is a very limited mechanism, that solves a problem that basically doesn't exist.  How many subordinate CAs can you point to that aren't owned and controlled by the parent CA?  And how many browsers or other client software correctly implement the constraint?  And how do you apply a name subordination constraint to a DNS name for SSL ― restrict it to entities registered under .com?

As Phillip points out, if you are going to cross-certify a CA that would violate a trademarked logo, you probably have even worse problems, particularly since such a case would provide the kind of iron-clad, smoking gun type of evidence that an attorney would love to have.  

But if we were really and truly concerned about this issue, I believe that other alternatives could be created, for example (just off the top of my head), by somehow embedding the logo URL within a policy OID that could be subject to a policy constraint, or by inventing some entirely new mechanism. We could pile on attribute certificates and/or lots of other baggage that would provide a firm, technically sound foundation for proving that someone was duly authorized to do this, that, or the other function, including displaying a logo in his certificate, but that just negates the assumption we were making about the CA being trustworthy in the first place.

>Apparently, you haven't read the draft that serves as the basis for this
>discussion, draft-ietf-pkix-logotypes-00.txt. The suggested format is a
>message digest and a URL.

Yes, I had.  I was merely echoing, or perhaps re-echoing, support for that idea, particularly after Peter Gutman had mentioned the old MPEG of a cat included within a certificate.

In any case, I believe that the merits of charter discussion have been adequately addressed, even though we may not have unanimity, and may not have even changed anyone's mind.

I move that we call the question, and let the chairs decide.

Bob

---

From: Stephen Kent <[email-masked]>
Date: Sun, 9 Sep 2001 15:06:38 -0400

At 2:04 PM -0600 9/5/01, Bob Jueneman wrote:
>Sorry, Steve, you are quite correct in that sense.  I guess I wasn't 
>thinking about corporate logos tied to organizational persons as 
>much as I was thinking about brand identification, where the brand 
>isn't owned by the superior CA in any case, any more than VeriSign 
>owns c=us, o=Sun. In any case, name subordination is a very limited 
>mechanism, that solves a problem that basically doesn't exist.  How 
>many subordinate CAs can you point to that aren't owned and 
>controlled by the parent CA?  And how many browsers or other client 
>software correctly implement the constraint?  And how do you apply a 
>name subordination constraint to a DNS name for SSL - restrict it to 
>entities registered under .com?

As a long term supporter of using the name constraints extension, I 
feel compelled to comment on this aspect of the discussion.

Name constraints work well when organizations as as CAs for 
themselves. Under such circumstances, cross certification represents 
not a declaration of "trust" between the cross certifying 
organizations, but a recognition of the authority of each 
organization re its respective name space.  This works well for all 
tree-structured names spaces where such authority is clear.  The DNS 
name space is an excellent example.

The areas where name constraints do not work well, or only in very 
limited fashion, are instances where a CA is not authoritative for 
the name space in which it issue certificates. Public TTP CAs ate the 
best example here. The best one can do when  cross certifying a CA of 
this sort is to use the excluded subtrees facility to prevent certs 
issued by that CA from being accepted if they claim to be for 
entities within one's own name space.  (Well, one could do even 
better, by adding to the excluded subtrees the name spaces of other 
organizations which you have directly cross certified, but this might 
become burdensome.)

So-called bridge CAs also suffer in this regard, and admit a similar 
set of partial safeguards certs.

Note that governmental CAs, of the sort that a number of countries 
are exploring or deploying, also can make good use of name 
constraints in the certs they issue to organizational CAs.

So, the problem with name constraints in practice arises from the 
common use of TTP CAs. This may be characteristic of how PKIs will 
evolve, or it may be a temporary feature of early phases of use of 
PKIs.

Time will tell,

Steve