At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?
What I and everyone else does is use a shared secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended?
The issue is where does the authentication material come from. <blatant aads promotion> Basically, certificates were solution targeted for offline email from the early '80s. you dail-up, connect, exchange email, hang-up. then you read. some random person that you never, ever dealt with before sends you something. they claim to be somebody .... the certificate is signed by somebody you trust .... is offered as proof that they are who they claimed to be. the other approach in the online world &/or with previous relations, is have a table of authentication material. the payment (debit/credit) card world went from non-electronic, offline to electronic and online (and skipped the step altogether that certificates represent ... the electornic and offline). note that even the certificate-based infrastructure are dependent on this method .... basically the certificate-enabled infrastructures have local table of "CA" public keys (i.e. those public keys that they've previously decided to trust) ... then certificates are validated with "CA" public keys and the current message/document is validate with public key from certificate. The primary difference between cert-based infrastructure and certless-based infrastructure is that the cert-based infrastructure there CAs have the database of all public keys and create these small R/O copies of their database records called certificates and spray them all over for use in offline environments. Then relying parties just have abbreviated CA-only public key tables and can't access the full tables maintained at the CAs. In the certless-based infrastructure the relying parties either maintain their own full tables of all public keys and/or have direct online access to the full tables. There is no need for these little R/O, static, stale, redundant and superfluous copies of somebody else offline database entry (called certificates) since there can be direct, online access to the original copy. generalized case can be hooking the web server to either radius or kerberos for handling the authentication process. both radius and kerberos support shared-secrets recorded in database as authentication. the radius example at http://www.asuretee.com/ shows example of radius recording public key in lieu of shared-secret and performing ecdsa digital signature authentication. pkinit for kerberos also allows for public key recorded in lieu of shared-secret and digital signature authentication. misc. radius public key authentication posts http://www.garlic.com/subpubkey.html#radius misc. kerberos public key authentication pots http://www.garlic.com/subpubkey.html#kerberos futher discussion specifically regarding static, stale, redundant, superfluous certificates. http://www.garlic.com/~lynn/subpubkey.html#rpo slightly related discussions regarding SSL merchant comfort certificates: http://www.garlic.com/~lynn/subpubkey.html#sslcerts </blatant aads promotion> -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com