James A. Donald wrote: > Rather the server should send out some encrypted random > data which the end user decrypts. End user should then > prove knowledge of that encrypted data.
so the random data is sent encrypted with the person's public key ... they can decrypt it with their private key. so the random data could contain someting like a session key. they send back the random data encrypted with the random session key. this demonstrates possesion of the private (aka "something you have" authentication). this avoids having to perform digital signatures on perported random data for pure authentication operations (never digital sign random data ... only digital sign what, you, yourself have personally created). For pure authentication operations ... this model eliminates the whole digtital certificate paradigm ... since the model assumes that the originator of the authentication request already has the recipients public key recorded someplace. http://www.garlic.com/~lynn/subpubkey.html#certless this has also been the suggestion for optimized SSL modification to use public keys registered with the domain name infrastructure. public key and SSL options are registered with the domain name infrastructure. An optimized DNS call returns the ip-address and any public key and SSL options as optional piggyback on the same transaction. the client generates the random session key ... and on the initial packet, transmits the random session key encoded with the server's registered public key ... along with the initial packet of data encrypted with the generated random session key. the server returns the response encrypted with the generated random session key. For real transaction oriented operations, you could even do this with UDP and a single send followed by single response (plus the DNS send/reponse). the SSL domain name certificate infrastructure was targeted as countermeasure for perceived integrity issues with the domain name infrastructure. somebody would apply to CA for SSL domain name infrastructure, they would check with the domain name infrastructure if the applicant was the valid owner of the domain name ... and then issue the SSL domain name infrastructure. the problem of course, is that the domain name infrastructure then is still the trust root as to who gets issued SSL domain name infrastructure ... the very same domain name infrastructure that was perceived to have integrity problems generating the requirement for SSL domain name infrastructure. So somewhat from the CA industry to help close various vulnerabilities in the domain name infrastructure, there has been suggestion that domain name owners register their public key. this helps with using the domain name infrastructure as the "trust root" for the CA industry related to domain name ownership and valid applicants for SSL domain name infrastructure. this also helps the CA industry, where they can change an expensive, time-consuming and error prone identification matching operation (checking the applicant's identification against the identification on file for the domain name owner with the domain name infrastructure) to a much simpler and reliably authentication operation (have the applicant digitally sign the SSL domain name application, retrieve the on-file public key and validate the digital signature). this, then creates the catch-22 for the CA industry for SSL domain name certificates (aka if the CA industry can use certificateless, onfile public keys for their purposes ... why can't the rest of the world). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
