Hi Ted, OK, I understand your goals better now.
For Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and search for the clientAuth setting. Are you envisaging that the registration authority you mention will be your own server or a third party? If the RA receives valid authentication information and issues the customer with a certificate containing a private key, you should be able to demonstrate that you don't know the key, and therefore you are not in a position to forge an order from the customer. I doubt that a bank, faced with a chargeback request from a customer, will set any store on a document that you claim has been signed with a private key known only to the customer. Their choices are: 1. Audit your application to verify your claim that the customer must have signed and approved the contract. Verify the encrypted document is tamper-proof. Verify that the customer is indeed the owner of the relevant client certificate, and nobody else could possible know the key. Evaluate the veracity of the customer's claim that the key "must have been pinched by somebody else". Cost: weeks of time and thousands of dollars 2. Just repay the customer and claw the money back from the merchant's bank account. Cost: almost zero. If you haven't ahead of time negotiated with every bank that any customer might use, they would, I think, be on the customer's side and not yours in the case of any dispute. Have you considered one of the e-signature services like Echosign (www.echosign.adobe.com), Secured Signing (www.securedsigning.com), Docusign (www.docusign.com/) or SignNow (signnow.com)? I see SignNow talks about an API so you can integrate their service into applications. I presume others do a similar thing. The bank may have heard of them before, and you have an audit trail provided by an independent third party. You could receive an order via a shopping cart in the usual way, and say to the customer the contract will be sent via one of these services, and the order will be filled once they sign the contract. If part of the point is that a customer or the bank can independently verify that the transaction was done and hasn't been altered by you, why should they believe anything that comes from your web site? While you could deliver a document with a signature created with your private key, the software that verifies that signature would need to be from a third party and not you to give the customer any confidence no tampering was done. And one more thing I'd consider: bricks and mortar retailers need to factor "shrinkage" like pilfering and shoplifting into their pricing. If you think that a minority of customers might repudiate a transaction, would you be better off self-insuring for the risk? You could set your prices to cover the risk, make provision for it as part of every sale's proceeds, and live with it when the bad thing happens. That might be more cost-effective than investing in an elaborate non-repudiation scheme. One of our clients had a situation where the goods were delivered and the courier had a record of the deliveree's name and a signature which appeared to be the right name. The customer said it wasn't them, somebody else was pretending to be them, don't know who. Short of suing, our client could only refund their credit card and refuse to do business with them again. So a customer can conceivably repudiate a sale even when the sales contract is agreed by everyone. I haven't done it, but I agree it should be possible to map from a client certificate to a user's identity. Similar things are discussed here http://www.servlets.com/archive/servlet/ReadMsg?msgId=518530&listName=tomcat-user and here (for Spring) http://static.springsource.org/spring-security/site/docs/3.0.x/reference/x509.html Cheers Paul Foxworthy ----- -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641563.html Sent from the OFBiz - User mailing list archive at Nabble.com.
