.... and of course what you could really do is slightly tweak multiple A-record support ... and add an option to ip-address resolve request ... and piggy back any available public key(s) on the response giving the server's ip-address(es). no additional transactions needed at all ... and you have the public key before you even have made the attempt to open the tcp session. if the server had also registered their crypto preferences when they registered their public key ... you could almost imagine doing the ssl session setup integrated with the tcp session setup.
when we were on the xtp tab .... xtp was looking at doing reliable transaction in 3-packet minimum exchange; by comparison tcp has a minimum 7-packet exchange ... and currently any ssl then is over and above the tcp session setup/tear-down. the problem with the current server push of the certificate ... the tcp session has to be operational before any of the rest can be done. misc. past ssl certificate postings http://www.garlic.com/`lynn/subpubkey.html#sslcert misc. past xtp/hsp (and some osi) postings http://www.garlic.com/~lynn/subnetwork.html#xtphsp _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
