Re: charter revisions

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

>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