At 5:25 PM -0700 6/20/02, Ed Gerck wrote: >Stephen Kent wrote: > >> Your example does not require cross-certification. It only >>requires that the relying parties be members of, or have access to >>the (CA) credentials for, the communities to which the individuals >>belong. Cross certification is one way to accomplish this, but it >>is not the only way. > >Cross-certification is the way to do it automatically, tamperproof and that. >But PKI does not work with cross-certification, so cross-certifcation must >not be useful ;-) there is an important difference between what one can do and what one must do. my point was that your example does not require cross certification, that's all. Moreover, there are many instances of PKI-like systems where cross certification is definitely not a desired feature, e.g., credit card issuers. > > You keep asserting that a single root does not permit scaling, >but I have yet to see a good argument supporting that assertion. > >;-) for starters, just read your own emails in this thread. You >mentioned at least >two reasons why a single root is not good for PKI. My reasons include the >observation that a single point of control is also a single point of >failure. One >perverse aspect of the single root is, thus, that as the PKI grows >and the single root >gathers all the liability there is a point after which the liability >at that single root >may not even be insurable. Just think of it: all world e-commerce >compromised because >of one snafu at one point? This would be involution, not evolution. I don't recall having said that a single root is bad for an individual PKI. Please refresh my memory. Yoru example here is also flawed. Consumer e-commerce today relies on credit cards, and there are multiple issuers each of which is independent of the others. Each acts analogously to a root for an island of certification. > > In part this seems to result from your approach to defining a >PKI, a definition not consistent with most others in the literature. > >I have not defined what a PKI is. I guess there are already plenty >of definitions >around. I just said that a PKI would need to be an infrastructure >-- that pesky >"I" at the end of PKI. We have lots of physical world infrastructure examples where there are the equivalent of multiple, independent roots. Infrastrucucture need not imply the universality that you seem to imply. >But failure to be an infrastructure is IMO one of the reasons why >PKI is at a dead >end. The DNS, OTOH, is an infrastructure. Mixing both will reduce >the infrastructure >property of the DNS, reduce interoperation and alienate business drivers. I don't see how any of these assertions are supported by what you have said. >There are many problems with the DNS, surely. I have catalogued >more than forty >serious problems. But the DNS has scaled from 10^4 users to almost 10^8 users >without much change. We should be careful in adding a limited technology such >as PKI to the DNS. The converse seems to be more reasonable -- >using the DNS to >add distribution channels (for certs and revocation information) to >a PKI. This can >be done right now. We seem to agree that the DNS could be sued to distribute certs, so the question is what should the certs attest to and who should issue them. I argue that we need certs that support validation of DNS bindings, and that the only authoritative sources for that info are the folks who manage the DNS. Anyone else is a TTP, with all the problems that implies. No other names that we might put in certs will provide the same sort of security features that DNS-based certs will provide, because people and software use DNS names to identify the machines they initiate communication with in the Internet. So, the fact that we could store certs issued by arbitrary TTPs, with non-DNS names, is true, but ultimately not very useful for basic Internet security. Steve