There are some other problems w/ using the DNS.
No revolkation process.
DNS caching
third-party trust (DNS admins != delegation holder)
Since DNS is a online positive list .... you change the database ... and voila it is updated.
This is the scenario for credit cards going from pre-70s technology with plastic cards and the monthly revokation booklet mailed out to all merchants. The credit card industry transitioned to online infrastructure where it transactions are denied by updating the online database. It eliminates the revokation process, since there aren't an unknown number of copies of static, stale credentials/certificates floating around the world potentially being presented to an unknown variety of relying parties.
DNS caching is the closest equivalent of the certificate paradigm of static, stale copies floating around the world. The two slight differences are that cached stale, static entries tend to have very short lifetimes ... they come into creation by activities by the relying-party (not the entity being authenticated) and tend to have very short lifetimes .... of a few hours to at most a day. However, relying-parties have the choice of going directly to the root and obtaining the current copy .... a function somewhat filled in the PKI world by OCSP .... although OCSP is just a check about whether the current, static, stale copy in a relying-party's possession is current ... not what the current entry is..
From information theory standpoint, stale, static certificates are logically a form of long-lived, distributed, replicated, r/o, cache entries. Cache entry semantics have been studied in some detail in areas like distributed file systems and multiprocessor consistent shared memory caches, etc. With short-lived r/o, distributed cache entires (like DNS) ... there is a trade-off involving 1) entry life-time, 2) frequency of change, 3) impact of dealing with stale entry. We ran into a problem with doing consistent database updates over NFS (network filesystem) because while NFS advertises itself as item potent, most client implementations have this 8k cache that can be stale.
Given high value &/or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information .... then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information .... but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates .... it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door .... if somebody forgot to complete the back wall on the vault).
random, unrelated refs to past life working on processor cache design, distributed filesystems, and distributed databases
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
