My searches using Google have resulted in an abysmal signal to noise ratio, and everything I have found so far covers one part of the architecture needed to the complete exclusion of all else. For example, I found JavaScript to manipulate the client side controls so that the form would function in both MS IE and Firefox, but nothing about what ought to happen server side. Similarly, I have found openssl info about making certificate requests, keys and certificates, but nothing about how to plug it into either a web server, such as Apache's httpd server, or how to invoke it from a cgi (or, better, fastcgi or mod_perl script). And again, I found info about setting up my own ca authority to generate server and client certificates (but the pages for that say nothing about anything else that might be required), as well as pages that deal solely with configuring Apache's httpd server to use server and client certificates. I can put those peices together, but there is a major missing piece of information that I havenot been able to find.
I can easily make a form, on a server that accepts only https connections, and put on it any kind of control. But it is not clear to me what information I have to ensure I collect on that form. I can also invoke programs from cgi programs, but it is not clear to me what information collected would need to be passed to openssl to make the desired certificates and what would need to be stored in an RDBMS (or how to connect that info to the certificate). Here is what I am aiming for. 1) A registration page that is used ONLY by my registration authority, to collect a person's contact information (including a valid phone number and email address), as well as several challenge/response questions and answers. Once that data is entered, the page would return single use credentials. 2) The person so registered, logs into a separate page using the single use credentials. The page then uses the challenge questions and answers provided to more strongly verify the identity of the user(in case the credentials are misappropriated by someone). 3) Once the identity of the person has been verified, he is prompted for a password (that must pass some test for quality - URLS pointing to a good perl or Javascript package that aplies such a test, or a good regex, would be appreciated), and when this data is submitted, the server creates a client side certificate that requires the user to enter the password the user has entered, and returns it to the client. This certificate ought to be useful for non-repudiation, encryption and signing electronic documents, but not, of course, creating other certificates. The question I guess is, first can I force a client certificate to require the user to enter his password, the first time (and only the first time) it is used in a given session (so I can get a two factor authorization: what the user has, the certificate, and what he knows, his password), second, what data needs to be in the form that submits the certificate request (e.g. which contains the HTML5 keygen element), third, what goes into the call to make the certificate and what goes into the RDBMS, and finally, how is the certificate returned to the client in a way that would ensure that the browser used by the client would install the certificate generated in the right place. Does anyone know of a resource on the web that talks about all aspects of creating such a system as well as providing links to documents describing best practices (what to do and what to avoid in order to minimize vulnerabilities that can arise in creating such a system)? I am hoping someone out there can provide info that would spare me further God knows how many weeks or months of frustratingly fruitless searching using Google. Thanks. Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
