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

Re: charter revisions


At 2:04 PM -0600 9/5/01, Bob Jueneman wrote:
>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 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