At 09:57 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote:
        ok...  does anyone else want to "touch" a secured DNS system
        that has some parts fo the tree fully signed?  Its a way to
        get some emperical understanding of how interesting/hard
        it is to hammer the DNS into a PKI-like thing.

www.rs.net has some information.


a normal cache-based system attempts to make everything appear as if it is online and dynamic .... with the characteristics of information caching as close as possibly transparent to the relying-parties.

one might claim that PKIs have tried to turn long-lived certificate-based "cache-entries" into a cult (aka from a information theory standpoint, certificates are a form of free-standing, somewhat self-describing, stale, static, long-lived cache entries) .... in part to create an independent revenue flow based on these cult objects. standard cache infrastructures usually attempt to go out of their way to try and make caching operation transparent to relying-parties (and can dynamically change/eliminate caching details to meet specific business requirement).

domain name infrastructure needs to support 1) trusted information distribution and may implement 2) cached entries. DNS has never been restricted to just trusted information distribution of IP-addresses.

CA/PKI SSL domain name certificates were deployed, in part because of integrity concerns about the domain name infrastructure. However, the "trust root" for CA/PKI SSL domain name certificates is still the domain name infrastructure (as to the authoritative owner of a domain name).

Turning DNS into a PKI-like thing happens only in the sense that CA/PKIs have only been a trusted distribution of public keys ... while DNS has always been a (somewhat) trusted distribution of any information (that happens to be registered with them). Adding public keys to DNS distribution is only turning it into a PKI-like thing from the standpoint that DNS hasn't in the past ben used as a trusted distribution for public key specific information (and the issue about the level of trust you can actually have in DNS).

My assertion is 1) DNS integrity issues have to be addressed as part of generalized DNS trust issues .... regardless of any use for trusted distribution of information that may include public keys. 2) because domain name infrastructure is the root authority for CA/PKI SSL domain name certificates, there is a suggestion that public keys be registered as part of domain name registration (to fix trust issues in domain infrastructure on behalf of the CA/PKI industry). Being able to trust DNS ... and having registered public keys .... means that existing DNS information distribution operation can turn itno trusted distribution of public keys (aka existing DNS infrastructure supports distribution of any information that happens to be registered).


some past threads about transition steps for DNS trust .... which could include having cache entries that instead of being naked public keys could be digitally signed cache entries (sharing some characteristics in common to stale, static, long-lived, free-standing digitally signed certificate objects):
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#17 Payments as an answer to spam (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
--
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]

Reply via email to