Status of opportunistic encryption

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com