the current SSL domain name infrastructure supposedly exists because of issues with trusting the domain name infrastructure ... except the SSL domain name certificate issuer has to trust the same (untrusted) domain name infrastructure when issuing a certificate (i.e. the SSL domain name certificate is no better than the authentication authority that the certificate authority has to rely on as the final arbitrator of domain name ownership). one of the integrity issues with the domain name infrastructure ... is that domain names have been hijacked ... once hijacked ... you can go to certificate authority and get a certificate with that domain name (and the certificate authority will check with the domain name system and confirm that the requester owns the domain name). for more ... see merchant comfort certificate thread at http://www.garlic.com/~lynn/aepay4.htm specific news clipping on hijacking http://www.garlic.com/~lynn/apay4.htm#dnsinteg1 so, the scenario goes that to fix various exposure & integrity risks to SSL domain name certificate infrastructure, the domain name infrastructure that the certification authority relies on needs to have its integrity fixed. the proposal for fixing the domain name infrastructure (on which the SSL domain name certificate issuing authority relies on as the authoritative reference for domain names) is to register public keys at the same time domain names are registered. now the interesting catch-22 is that SSL domain name certificates were in part justified because of weaknesses in the integrity of the domain name infrastructure ... however in order to issue those same SSL domain name certificates, the SSL domain name issuing authority (certificate authority) has to rely on the same domain name infrastructure (that everybody is being told that you can't really trust because of integrity problems ... aka everybody isn't to rely on domain name infrastructure ... because it can't be trusted ... so buy a SSL domain name certificate .... however the SSL domain name certificate issuing certification authority is allowed to rely on the same domain name infrastructure for its authoritative information. The SSL domain name certificate issuing certification authority just isn't telling everybody that it has to reference the domain name infrastructure in order to validate a request for an SSL domain name certificate. I would call that ironic??? Now for even more ironic. In order to fix various integrity exposures in the SSL domain name certificate ... integrity exposures in the domain name infrastructure have to be fixed (i.e. integrity is nominally no stronger than the weakest link). However, fixing integrity exposures in the domain name infrastructure (in order to fix various integrity exposures in SSL domain name certificates) ... can make those certificates superfluous, redundant and unnecessary. Now the issue isn't to use either SSL domain name certificates or domain name infrastructure. Since SSL domain name certificates issuance relies on the domain name infrastructure for its authoritative information ... then the infrastructures that the SSL domain name certificates issuance certification authority relies on has to have its integrity fixed. Now, I considered this somewhat ironic ... that in order to fix a integrity dependency that SSL domain name certificate issuance has ... the fix also eliminates much of the original justification for SSL domain name certificates (i.e. weaknesses in the domain name infrastructure) as well as making SSL domain name certificates superfluous and redundant. SSL domain name certificates provide a binding between public key and domain name. However, if public keys were registered with domain names in the domain name infrastructure ... the purpose of which was to fix various integrity problems in the domain name infrastructure and allow the domain name infrastructure to be trusted by the SSL domain name certificate issuing certification authority ... then the integrity of the domain name infrastructure can be fixed for everybody ... eliminating the purpose of the SSL domain name certificate (aka integrity problems with the domain name infrastructure). Furthermore, if public keys were registered with domain names, then the domain name infrastructure could serve up real-time bindings of public keys and domain names (as part of the domain name lookup process). If a SSL protocol ... when it asked the domain name system to resolve a domain name ... could set a flag and asked that both the resolved domain name and the registered public key be returned ... the efficiency of the SSL protocol would be improved. All in all 1) fixing integrity of domain name infrastructure (so you can trust SSL certificates) eliminates much of the requirement for SSL certificate (i.e. needed because of integrity problems in the domain name infrastructure 2) fixing integrity of domain name infrastructure with the registration of public keys and making that information public as part of standard domain name infrastructure provides a trusted binding between domain name and public key ... making the SSL domain name certificate superfluous and redundant. Now as to the other kind of certificate. My wife and I were hired by a financial services company in 1994 to work with a small client/server startup on the peninsula that wanted their server to be able to interface to the financial transaction infrastructure. One of the things that I eventually specified as part of that infrastructure was a consumer oriented certificate (along the lines of BBB, consumer reports, etc). However, the whole thing was in its infancy and they were having enuf other problems creating infrastructures ... so it has yet to happen. Two people my wife and I worked with at the startup are referenced in the following: http://www.garlic.com/~lynn/aadsmore.htm#dctriv random other refs: http://www.garlic.com/~lynn/aadsmore.htm#client3 http://www.garlic.com/~lynn/aadsmore.htm#client4 http://www.garlic.com/~lynn/96.html#32 http://www.garlic.com/~lynn/2000b.html#18 http://www.garlic.com/~lynn/95.html#13