oh, and some number of certification authorities actually backed some parts of DNSSEC ... including the idea that people register a public key when they registered a domain name. this was countermeasure to various kinds of domain name hijacking vulnerabilities ... i.e. the domain name owner would digitally sign communication ... and the domain name infrastructure would validate the digital signature with the onfile public key.

this became attractive to certification authorities. currently they require a ssl domain name certificate application to supply a lot of identification information. the certification authority then performs the time-consuming, error prone, and expensive process of matching the supplied identification information with the information on file with the domain name infrastructure. with communication authenticated with the onfile public keys, there is a reduction in the chance of domain name hijacking ... and therefor the certification authority has higher level of assurance that they aren't dealing with a ssl domain name certificate applicant that has just hijacked the domain name.

also, if the public keys were on file with the domain name infrastructure, then certification authorities could require that application for ssl domain name certificates be digitally signed. then the certification authorities could change from a time-consuming, error prone, and expensive process of matching identification information to the less-expensive and more reliable process of simply authenticating the digital signature. they would execute dnssec protocol with the domain name infrastructure requesting real-time retrieval of the onfile public key for the domain name. they would validate the response with DNSSEC trusted root public key on file in their local repository of trusted dnssec public keys (in much the same way that the existing PKI infrastructure validate digital signatures on digital certificates using CA public key from their local repository of trusted (CA) public keys).

This whole thing then goes to the root of improving the integrity of the SSL domain name certificate infrastructure.

The catch22 for the certification authority infrastructure is that if they can start retrieving real-time public keys for authenticating digital signatures on ssl domain name certificate applications ... then possibly the rest of the world could also start using DNSSEC to also do real-time retrieval of onfile public keys from the domain name infrastructure.

one might even imagine a highly optimized SSL type session protocol where instead of the existing protocol chatter exchange ... the servers on-file public key could piggyback on the standard DNS response for hostname->ipaddress. the client in the initial transmission send a random session key encrypted with the server's public key.

a few recent posts mentioning this catch22 dilemma for the SSL
domain name certificate industry:
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to